>>> Compiling source in /dev/shm/portage/dev-qt/qtgui-5.4.1-r1/work/qtbase-opensource-src-5.4.1 ... * Running emake in src/gui make -j3 powerpc64-unknown-linux-gnu-g++ -c -O2 -g -pipe -mcpu=G5 -mtune=G5 -maltivec -Wall -O3 ...
Yes, this is expected. It was introduced in 5.3 and is enabled for qtcore and qtgui. See http://code.qt.io/cgit/qt/qtbase.git/commit/?id=cd652500af18671e0d64b30d51c79a0c45b973a3 I'm inclined to leave it as-is. Does it cause any problems?
I'm sure it will break. Especially the niche architectures are somewhat volatile in the face of novel compiler optimisations. Gentoo has a QA policy about this kind of thing for a reason.
I agree, we should fully respect CFLAGS.
I don't disagree in principle, but what exactly does "fully respect CFLAGS" mean? And how is -O3 different from other -ffoo flags that sometimes upstreams add to their software?
I'm not sure what you mean...randomly overriding user CFLAGs for no reason has never been allowed.
(In reply to Michael Palimaka (kensington) from comment #5) > I'm not sure what you mean...randomly overriding user CFLAGs for no reason > has never been allowed. It's not "for no reason"... please read the upstream commit message. I'll fix this but how about adding also a 'replace-flags -O2 -O3' for amd64?
Actually, I don't really care. Fixed in cvs. https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/eclass/qt5-build.eclass?r1=1.22&r2=1.23
(In reply to Davide Pesavento from comment #6) > (In reply to Michael Palimaka (kensington) from comment #5) > > I'm not sure what you mean...randomly overriding user CFLAGs for no reason > > has never been allowed. > > It's not "for no reason"... please read the upstream commit message. It would have been nice if upstream had instead figured out which specific -O3 feature they wanted.
