Bug#721720: -floop-parallelize-all misleadingly accepted

[Zefram <zefram@fysh.org>]

Package: gcc-4.7
Version: 4.7.2-5
Severity: normal

There's a funny arrangement for gcc's -floop-parallelize-all option
(and it looks like some related options too) where it's always accepted,
but the optimisation mechanism that it controls depends on an optional
library package being installed.  This turns out to make it difficult
to detect whether the optimisation is really available.

I've run into this with building libmemcached from source.  I'm doing
this independent of the Debian libmemcached package, actually as part of
the Perl module Memcached::libmemcached, which I'm building from CPAN on
a non-system Perl.  The gcc in question is targeting x86_64-linux-gnu.
The library has an autoconf configure script.  I can simulate the relevant
test this way:

$ cat t.c
int main()
{
  return 0;
}
$ gcc-4.7 -O2 -floop-parallelize-all -c t.c && echo OK   
OK

As the option is accepted, it's used in compilation of the library code.
Compilation of a couple of the modules then fails.  I can demonstrate
this with an eviscerated version of the library's CRC32 code:

$ cat c.c
static const int crc32tab[256] = {};
int c(const char *key, int key_length)
{
  int x;
  int crc= ~0;
  for (x= 0; x < key_length; x++)
     crc= (crc >> 8) ^ crc32tab[(crc ^ key[x]) & 0xff];
  return ((~crc) >> 16) & 0x7fff;
}
$ gcc-4.7 -O2 -floop-parallelize-all -c c.c && echo OK
c.c: In function 'c':
c.c:2:5: sorry, unimplemented: Graphite loop optimizations can only be used if the libcloog-ppl0 package is installed

I've advised the Perl module maintainer that the configure
test ought to include some complex loop code in order to
properly trigger failure.  Bug report for that module is at
<https://rt.cpan.org/Ticket/Display.html?id=88378>.

But I think that this problem should be addressed in the Debian gcc.
The simple configure test *should* work.  There's a practical problem in
determining what complexity of code is required for the test; this is
liable to vary between gcc versions and between target architectures.
In principle, I think it's wrong for gcc to accept an option when its
only effect will be to later break compilation.  The option should be
rejected up front if its implementation is not available.

-zefram