Bugzilla Bug 249226

This bug will be used to track packages that are broken by the upcoming GCC
4.4.

  - Please file a NEW bug for each package and make it BLOCK this one.
  - GCC 4.3 porting issues should not block this bug.  Use bug #198121 instead.
  - Do NOT use this bug for issues with GCC-4.4 itself.  File a new bug and
assign it to toolchain.
  - Do NOT add comments, logs, patches, discussion, rants, or stories about
your Uncle Milt here.  There are other channels for such things.


Until 4.4.0 is released, filing bugs without patches enclosed is strongly
discouraged and will likely end up RESOLVED WONTFIX.

something new i want to try.  when filing bugs against packages, please include
a link to the bug or ml message where the patch has been reported upstream, or
the diff or commit message where the patch was applied.

Lots more GCC 4.4-broken packages (and suggested fixes) can be found by
Googling
site:bugs.debian.org ftbfs-gcc-4.4
I'll be filing more reports based on results of that search.

Alexander E. Patrakov sent my way a common problem in multiple packages with
the dtoa.c source file: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=518927

I'll be starting a tree scan today, and report packages that do contain that.

nspr and konqueror do.  nspr is fixed in the gcc-porting overlay.  see
https://bugzilla.mozilla.org/show_bug.cgi?id=439144 for the update of dtoa that
was sent to the author.  also
https://bugzilla.redhat.com/show_bug.cgi?id=487844.

mozilla-derived software also have the problem (nvu and sunbird, as well as
virtualbox). It also was present in ruby 1.9.1_pre1 (not sure on the current
one, the process is still working in series.

dtoa.c files are present in cdrtools and cdrdao although they don't hit the
particular word1 define Alexander pointed out.

ruby is built w/ -fno-strict-aliasing, so it won't hit the problem either, but
yes, i'd like to have that flag used on as few packages as possible.

For reference here is the list of packages that do contain the broken dtoa.c:

/var/log/dtoa-scan/app-editors:nvu-1.0-r4.log
/var/log/dtoa-scan/app-emacs:ruby-mode-1.9.1_pre1.log
/var/log/dtoa-scan/app-emulation:virtualbox-guest-additions-2.1.4.log
/var/log/dtoa-scan/app-emulation:virtualbox-ose-2.1.4-r1.log
/var/log/dtoa-scan/app-office:mozilla-sunbird-0.9.log
/var/log/dtoa-scan/dev-lang:mono-2.2-r3.log
/var/log/dtoa-scan/dev-lang:polyml-5.2.1.log
/var/log/dtoa-scan/dev-lang:ruby-1.8.6_p287-r12.log
/var/log/dtoa-scan/dev-libs:nspr-4.7.3.log
/var/log/dtoa-scan/kde-base:kdelibs-3.5.10-r2.log
/var/log/dtoa-scan/mail-client:mozilla-thunderbird-2.0.0.19.log
/var/log/dtoa-scan/net-libs:webkit-gtk-0_p40220.log
/var/log/dtoa-scan/net-libs:xulrunner-1.8.1.19.log
/var/log/dtoa-scan/net-libs:xulrunner-1.9.0.7.log
/var/log/dtoa-scan/www-client:seamonkey-1.1.14.log
/var/log/dtoa-scan/x11-drivers:xf86-input-virtualbox-2.1.4.log
/var/log/dtoa-scan/x11-drivers:xf86-video-virtualbox-2.1.4.log
/var/log/dtoa-scan/x11-libs:qt-assistant-4.5.0.log
/var/log/dtoa-scan/x11-libs:qt-demo-4.5.0.log
/var/log/dtoa-scan/x11-libs:qt-gui-4.5.0.log
/var/log/dtoa-scan/x11-libs:qt-opengl-4.5.0.log
/var/log/dtoa-scan/x11-libs:qt-phonon-4.5.0.log
/var/log/dtoa-scan/x11-libs:qt-qt3support-4.5.0.log
/var/log/dtoa-scan/x11-libs:qt-sql-4.5.0.log
/var/log/dtoa-scan/x11-libs:qt-svg-4.5.0.log
/var/log/dtoa-scan/x11-libs:qt-webkit-4.5.0.log
/var/log/dtoa-scan/x11-plugins:enigmail-0.95.7-r3.log
/var/log/dtoa-scan/x11-plugins:lightning-0.9.log

Results of building rawhide w/ 4.4:
https://www.redhat.com/archives/fedora-devel-list/2009-February/msg00180.html

Link to debian bug reports

http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-gcc-4.4;users=debian-gcc@lists.debian.org

I have noticed something and am not sure if it is a real "bug". Basically
shortly after I installed gcc-4.4, I started to recompile things with it. I
started getting crashes when launching firefox and thunderbird. Finally I
traced it down to the fact that I had compiled libzip with -O3. Switching my
flags to the more sane -O2 and recompiling that lib fixed things.

So my question is:

if an application or library used to work with -O3 and doesn't anymore, is that
a regression? I imagine that the lib breaks strict aliasing rules causing -O3
to break the code.

I know that Gnome's policy is not to accept bugs caused by -O3, what is
gentoo's overall policy on this?

I'd consider it a regression.  I don't know if our Gnome team would, but at the
very least they could add a `replace-flags -O3 -O2` to the ebuild (though in a
perfect world i would like to see the actual bug fixed).

I'm not sure this is an aliasing bug though, since strict aliasing is enabled
at -O2.  It could be related to the vectorizer which is enabled at -O3 for some
architectures.  If you want to narrow it down, you can see what flags are
turned on by -O3 like so:

$ gcc-4.4.0 -O2 -Q --help=opt > gcc44.o2.flags
$ gcc-4.4.0 -O3 -Q --help=opt > gcc44.o3.flags
$ diff -u gcc44.o2.flags gcc44.o3.flags

But in any case, please file a bug for libzip so we can investigate it.