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
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:
Results of building rawhide w/ 4.4:
Link to debian bug reports
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.