Created attachment 314305 [details]
Portage 2.2.0_alpha109 (default/linux/x86/10.0, gcc-4.7.0, glibc-2.14.1-r3, 3.4.0-gentoo i686)
System uname: Linux-3.4.0-gentoo-i686-Intel-R-_Atom-TM-_CPU_N280_@_1.66GHz-with-gentoo-2.1
Timestamp of tree: Sun, 03 Jun 2012 09:30:01 +0000
dev-lang/python: 2.7.3-r2, 3.1.4-r3, 3.2.3
sys-devel/autoconf: 2.13, 2.68
sys-devel/gcc: 4.5.3-r2, 4.7.0
sys-kernel/linux-headers: 3.1 (virtual/os-headers)
Repositories: gentoo lisp sage-on-gentoo science gentoo-haskell sunrise local-fix
CFLAGS="-O3 -march=native -mtune=native -mfpmath=sse -fomit-frame-pointer -pipe"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/dconf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c"
CXXFLAGS="-O3 -march=native -mtune=native -mfpmath=sse -fomit-frame-pointer -pipe"
FEATURES="assume-digests binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles metadata-transfer news parallel-fetch parse-eapi-ebuild-head preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch"
LINGUAS="be be_BY en en_GB ru uk"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages"
PORTDIR_OVERLAY="/usr/layman/lisp /usr/layman/sage-on-gentoo /usr/layman/science /usr/layman/haskell /usr/layman/sunrise /usr/local/portage/fix"
Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
This looks like a gcc issue to me, plus I'd have no clue how to fix this, thus reassigning to GCC team. Guys, if you need support do not hesitate to ask, but be prepared to get "Huh?" as an answer.
first thing to try is to get rid of that nasty flag -mfpmath=sse from your configuration.
Created attachment 314457 [details]
The same problem without "nasty" flag.
i can reproduce. seems that -O3 is guilty. could you report R upstream? thanks.
(In reply to comment #4)
> i can reproduce. seems that -O3 is guilty. could you report R upstream?
Ok, I'll see whether -O3 causes problem and then report this bug to R upstream.
Could you guys try to narrow it down to which -O3 suboption is actually the culprit? I'm sure we have better chances of upstream actually looking at it if we tell them what exactly is failing.
There are some known bad-code issues with -O3. 4.7.1 should be out in a week or so.
Nope, still fails with
gcc version 4.7.0-pre9999 20120607 (prerelease) commit 80506925c070c6576bd6a37e181417929fbe0956
(In reply to comment #6)
> Could you guys try to narrow it down to which -O3 suboption is actually the
> culprit? I'm sure we have better chances of upstream actually looking at it
> if we tell them what exactly is failing.
Hmm, when I use -O3 flag it fails, but when I try to replace it but separate -fxxxxx flags it does not fail. I've just tried to put flags from `man gcc` that are equivalent to -O3 in CFLAGS variable.
Anyway I will report bug to upstream about failing with -O3.
Bug reported to upstream: https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=14940
Upstream says it's not R but gcc bug. It seems they are right, so waiting for fixing problems in gcc.
>Maybe 10 times in the gcc4 series, gcc -O3 bugs have caused R builds to
>fail, so we are not likely to believe that this time the bug is in R
>without very detailed evidence
CFLAGS="-O2 -fipa-cp-clone" is also sufficient to trigger it
(In reply to comment #12)
> CFLAGS="-O2 -fipa-cp-clone" is also sufficient to trigger it
Thanks a lot for bisecting this. This saved me a lot of cycles on my slow dev box.
I have confirmed that too on gcc-4.7.1 which was recently released. I'm working on a temporary fix.
I have fixed R-2.15.0.ebuild as in the diff below. It doesn't completely fix the issue but at least it lets users keep -O3 even with gcc-4.7. It's not ideal but we have plenty of uglier and less subtle flag-o-matrickery in the tree.
Also, I have CCed the toolchain guys in case they they can help with this. I'm not sure however that this is a gcc issue, it may be R. I will leave this bug open until we have a real upstream fix or they do not agree to fix it.
RCS file: /var/cvsroot/gentoo-x86/dev-lang/R/R-2.15.0.ebuild,v
retrieving revision 1.5
diff -u -B -r1.5 R-2.15.0.ebuild
--- R-2.15.0.ebuild 19 Jun 2012 19:16:55 -0000 1.5
+++ R-2.15.0.ebuild 20 Jun 2012 17:37:05 -0000
@@ -4,7 +4,7 @@
-inherit bash-completion-r1 autotools eutils flag-o-matic fortran-2 multilib versionator
+inherit bash-completion-r1 autotools eutils flag-o-matic fortran-2 multilib versionator toolchain-funcs
DESCRIPTION="Language and environment for statistical computing and graphics"
@@ -58,6 +58,11 @@
filter-ldflags -Wl,-Bdirect -Bdirect
# avoid using existing R installation
+ # Temporary fix for bug #419761
+ if [[ ($(tc-getCC) == *gcc) && ($(gcc-version) == 4.7) ]]; then
+ append-flags -fno-ipa-cp-clone
I haven't done much testing (mostly due to lack of experience), but it appears that in some cases (at the very least in my system) the fix for the ebuild makes emerging R fail with the rather long error:
The ebuild phase 'setup' has exited unexpectedly. This type of behavior
is known to be triggered by things such as failed variable assignments
(bug #190128) or bad substitution errors (bug #200313). Normally, before
exiting, bash should have displayed an error message above. If bash did
not produce an error message above, it's possible that the ebuild has
called `exit` when it should have called `die` instead. This behavior
may also be triggered by a corrupt bash binary or a hardware problem
such as memory or cpu malfunction. If the problem is not reproducible or
it appears to occur randomly, then it is likely to be triggered by a
hardware problem. If you suspect a hardware problem then you should try
some basic hardware diagnostics such as memtest. Please do not report
this as a bug unless it is consistently reproducible and you are sure
that your bash binary and hardware are functioning properly.
This happens right at the very beginning of the emerge, and it happened consistently. I copied the ebuild to a local repository, and took the hint that perhaps the "exit" in the diff is what was causing the problem. I removed it from the ebuild in the local repository, and R can now successfully emerge on my system. Perhaps this should be fixed, or perhaps the problem is more complex than that?
(In reply to comment #15)
> This happens right at the very beginning of the emerge, and it happened
> consistently. I copied the ebuild to a local repository, and took the hint
> that perhaps the "exit" in the diff is what was causing the problem. I
> removed it from the ebuild in the local repository, and R can now
> successfully emerge on my system. Perhaps this should be fixed, or perhaps
> the problem is more complex than that?
Yes, the problem is indeed more complicated than that. You know, getting old is dramatic. Your brain melts and slowly changes into this useless goop, and this in turn makes you forget about removing debugging code once you're done working on an ebuild... ;o)
Thanks a lot for spotting that. It is now fixed.
Closing that as it's blocking the gcc-4.7 tracker.