Starting with 4.8 GCC uses aggressive loop optimizations by default. This triggers undefined behaviour in OpenJade (which in turn lets the emerge fail with feature stricter enabled), e.g. In file included from /usr/include/OpenSP/Vector.h:77:0, from ./../style/FOTBuilder.h:13, from TeXFOTBuilder.h:9, from TeXFOTBuilder.cxx:11: /usr/include/OpenSP/Vector.cxx: In member function ‘virtual void OpenJade_DSSSL::TeXFOTBuilder::endParagraph()’: /usr/include/OpenSP/Vector.cxx:124:5: warning: iteration 384307168202282326ul invokes undefined behavior [-Waggressive-loop-optimizations] (void)new (ptr_ + size_++) T; ^ /usr/include/OpenSP/Vector.cxx:123:3: note: containing loop while (n-- > 0) ^ Adding -fno-aggressive-loop-optimizations to disable aggressive loop optimizations solves the problem. Also note that adding -fno-aggressive-loop-optimizations to (global) CFLAGS/CXXFLAGS does not help since the ebuild filters this flag. Since upstream seems essentially dead, I post it here. A simple fix would be to add the line append-cxxflags -fno-aggressive-loop-optimizations in src_configure().
please provide "emerge --info" output and full build.log
Created attachment 476518 [details] Build log of app-text/openjade-1.3.2-r7 Hardened profile, GCC version 5.4.0, app-text/opensp version 1.5.2-r3.
please retry with 1.3.2-r7
Hi Pacho Thanks for coming back to this issue. I reemerged openjade-1.3.2-r7 and the merge succeeded. However, in the build.log there is still the warning about undefined behaviour due to aggressive-loop-optimizations. This makes me feel a little uncomfortable as portage does not warn about this. Can you explain to me what happened that portage now ignores those warnings? (There was no noteworthy change to the ebuild and also no entry in /usr/portage/profiles/... as far as I can tell) Thanks.
I don't know as I neither know why that warning is so major to deserve portage to die with it. I would open a separate bug against portage to handle that flag and explain there why do you think that warning is so dangerous to need ebuilds to set -fno-aggressive-loop-optimizations when appears :/ You can also add that new bug to "See also" field of this one as this will benefit from it Thanks
Hi Pacho Sorry I might have been a little unclear. I know why portage previously died: I've set the feature 'stricter' which runs some post-qa-checks -- most notably /usr/lib/portage/python2.7/install-qa-check.d/90gcc-warnings -- which bails out on some GCC warnings (and the aggressive-loop-optimization is one of those warnings). What changed (and this lets me wondering) is that portage stopped doing that and I don't understand why as neither the openjade.ebuild nor the 90gcc-warnings script nor something in /usr/portage/profile/ were altered in the last half year. (The 'stricter' mechanism with the install-qa-check itself works at it bailed out on other packages yesterday.) Since you suggested I should retry the same version which previously failed (namely openjade-1.3.2-r7) and which hasn't changed since, you must have some clue why you think it would work now. Is this so? Or was it just a blind guess?
It was a guess because I thought that maybe it was behaving differently with current gcc versions Also, I wanted to clarify how to handle this kind of warnings globally instead of passing -fno-aggressive-loop-optimizations depending on people asking for it or not. That is the reason that I wanted to know how this was handled currently. If -Waggressive-loop-optimizations warning is such a problem to deserve the disabling of aggressive loop optimizations, it should die if possible to catch that failures and fix them in a consistent way across the tree :/
I will CC gcc maintainers to know if we should start workarounding this warning downstream or this is most for a QA warning asking people to send bugs to upstreams
(In reply to Pacho Ramos from comment #7) > It was a guess because I thought that maybe it was behaving differently with > current gcc versions > > Also, I wanted to clarify how to handle this kind of warnings globally > instead of passing -fno-aggressive-loop-optimizations depending on people > asking for it or not. That is the reason that I wanted to know how this was > handled currently. If -Waggressive-loop-optimizations warning is such a > problem to deserve the disabling of aggressive loop optimizations, it should > die if possible to catch that failures and fix them in a consistent way > across the tree :/ I'm not aware of drastic GCC changes. Nowadays GCC relies more on unreachable state of undefined behaviour and applies more optimizations (skips upper bound checks, assumes non-aliasing, vectorizes loops, etc.). In this specific case iteration number looks very hard to reach in practice thus the warning is harmless. But it says nothing about other cases.
