[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#721720: marked as done (-floop-parallelize-all misleadingly accepted)

Your message dated Tue, 23 Jun 2015 07:24:48 +0000
with message-id <E1Z7IZc-0001tY-Ii@franck.debian.org>
and subject line Bug#789156: Removed package(s) from unstable
has caused the Debian Bug report #721720,
regarding -floop-parallelize-all misleadingly accepted
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
721720: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=721720
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
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

--- End Message ---
--- Begin Message --- 
Version: 4.7.4-3+rm

Dear submitter,

as the package gcc-4.7 has just been removed from the Debian archive
unstable we hereby close the associated bug reports.  We are sorry
that we couldn't deal with your issue properly.

For details on the removal, please see https://bugs.debian.org/789156

The version of this package that was in Debian prior to this removal
can still be found using http://snapshot.debian.org/.

This message was generated automatically; if you believe that there is
a problem with it please contact the archive administrators by mailing
ftpmaster@ftp-master.debian.org.

Debian distribution maintenance software
pp.
Luca Falavigna (the ftpmaster behind the curtain)

--- End Message ---
Reply to: