Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 620794 - app-text/openjade-1.3.2 triggers undefined behaviour
Summary: app-text/openjade-1.3.2 triggers undefined behaviour
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal QA (vote)
Assignee: Michał Górny
Depends on:
Reported: 2017-06-04 15:33 UTC by moatu
Modified: 2019-09-17 07:15 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---

Build log of app-text/openjade-1.3.2-r7 (,135.40 KB, text/x-log)
2017-06-15 06:26 UTC, moatu

Note You need to log in before you can comment on or make changes to this bug.
Description moatu 2017-06-04 15:33:36 UTC
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().
Comment 1 Pacho Ramos gentoo-dev 2017-06-04 18:15:51 UTC
please provide "emerge --info" output and full build.log
Comment 2 moatu 2017-06-15 06:26:20 UTC
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.
Comment 3 Pacho Ramos gentoo-dev 2018-02-08 13:47:24 UTC
please retry with 1.3.2-r7
Comment 4 moatu 2018-02-19 14:36:53 UTC
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)
Comment 5 Pacho Ramos gentoo-dev 2018-02-19 20:03:23 UTC
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

Comment 6 moatu 2018-02-20 19:40:54 UTC
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?
Comment 7 Pacho Ramos gentoo-dev 2018-02-20 20:05:03 UTC
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 :/
Comment 8 Pacho Ramos gentoo-dev 2018-04-17 14:17:11 UTC
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