| Summary: | =media-libs/{libjpeg-turbo-1.3.1,jpeg-8d-r1}: CFLAGS="-ftree-vectorize" causing segfault, possible toolchain problem(?) | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Marco Ziebell <ziebell_marco> |
| Component: | Current packages | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | normal | CC: | anarchy, graphics+disabled, ssuominen, ziebell_marco |
| Priority: | Normal | Keywords: | PATCH |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| URL: | http://sourceforge.net/p/libjpeg-turbo/bugs/65/ | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
novectorize patch
media-libs/jpeg-8d no vectorize patch emerge --info |
||
|
Description
Marco Ziebell
2014-05-14 08:30:46 UTC
-ftree-vectorize for example on x86 (32bit) breaks zlib with certain compiler versions, i've never considered it a safe flag to use does it go away if 'inherit flag-o-matic' and 'append-cflags -fno-tree-vectorize' is added to libjpeg-turbo's ebuild (before econf)? also, post emerge --info Created attachment 376900 [details, diff]
novectorize patch
your suggestion works fine so i propose a patch for the ebuild.
What's still strage is that removing "-march=native" or "-O2" also solves the problem. Could be the way "where and when" gcc applies vectoriztion. Even if, patch works and thanks for your quick response. Created attachment 376932 [details, diff] media-libs/jpeg-8d no vectorize patch After a upstream bug report and some further research suggested by them i can commit an other patch for media-libs/jpeg-8d. https://sourceforge.net/p/libjpeg-turbo/bugs/65/ both patches should work, should I open an other bugreport? are you really seeing same problem with libjpeg.so.8 from jpeg-8d? that'd be just weird, it's very different code and without asm of anykind this is starting to sound like a compiler bug more and more please just drop -ftree-vectorize for now CCing toolchain@g.o for comment howto proceed with the debugging (In reply to Samuli Suominen from comment #1) > also, post emerge --info also you missed this, to see what compiler you are using post `emerge -pv sys-devel/gcc --nodeps` too does upgrading to gcc latest from 4.8* and if that doesn't work, to binutils latest from series of 2.24* using gcc-config to switch to 4.8* using possible binutils-config to switch to ld.gold from ld.bfd -march=native with certain processors doesn't play well, the solution is often gcc upgrade (In reply to Samuli Suominen from comment #5) > are you really seeing same problem with libjpeg.so.8 from jpeg-8d? i see now from the upstream bug you filed that they could indeed be same. Need emerge --info. Also, `echo "" | gcc -march=native -v -E - 2>&1 | grep cc1` the compiler information: sys-devel/gcc-4.7.3-r1:4.7 USE="cxx fortran gcj graphite mudflap (multilib) nls nptl openmp (-altivec) -awt -doc (-fixed-point) -go (-hardened) (-libssp) -multislot -nopie -nossp -objc -objc++ -objc-gc -regression-test -vanilla" /usr/libexec/gcc/x86_64-pc-linux-gnu/4.7.3/cc1 -E -quiet -v - -march=bdver2 -mcx16 -msahf -mno-movbe -maes -mpclmul -mpopcnt -mabm -mlwp -mfma -mfma4 -mxop -mbmi -mno-bmi2 -mtbm -mavx -mno-avx2 -msse4.2 -msse4.1 -mlzcnt -mno-rdrnd -mf16c -mno-fsgsbase --param l1-cache-size=16 --param l1-cache-line-size=64 --param l2-cache-size=1024 -mtune=bdver2 Tests with higher toolchain version is in progress Created attachment 377008 [details]
emerge --info
Switching to sys-devel/gcc-4.8.2 , sys-devel/binutils-2.24-r2 and ld.gold did solve the problem. Cool. Can you switch back to gcc 4.7 and see if it still fails. I seem to remember some bdver2 bugs but I thought they were fixed in 4.7... (In reply to MJJoker from comment #12) > Switching to sys-devel/gcc-4.8.2 , sys-devel/binutils-2.24-r2 and ld.gold > did solve the problem. (In reply to Ryan Hill from comment #13) > Cool. Can you switch back to gcc 4.7 and see if it still fails. I seem to > remember some bdver2 bugs but I thought they were fixed in 4.7... ^ This is what I meant too, test one by one, not all at once to narrow the problem down. Was it gcc upgrade from 4.7 to 4.8, or binutils from 2.23 to 2.24, or binutils ld.bfd to ld.gold, or what, specifically, made the problem go away? My Mistake. switching to the next version of GCC and binutils and ld.gold DID NOT SOLVE the problem. I made some further test over the weekend, switching back to gcc 4.7.3 or ld.bfd didn't change it. The segmentation fault is still occurring! toolchain: should I by adding 'append-cflags -fno-tree-vectorize' to jpeg and libjpeg-turbo ebuilds to prevent users from breaking it like evident in this bug? my position currently is that if gcc doesn't enable tree vectorize by default for given arch, it's likely not safe, and it should most definately not be used like this globally like the user is using in this bug i feel inclined to close this as resolved, worksforme, solved by removing user defined -ftree-vectorize from make.conf i mean, i don't like the idea of adding any append-flags -fno-tree-vectorize since that would actually disable tree vectorize for arches/gcc versions where it's enabled by default 4.7.4 is about to be released and then the branch will be closed. So I think the best thing to do is check if it's fixed there, and if not add [[ $(gcc-version) -eq 4.7 ]] && append-flags -fno-tree-vectorize The reason being that -ftree-vectorize is enabled by -O3 in 4.7, which is something we should try to support when we can. looking at the fixes in 4.7.4 I see a lot of vectorize/O3/instruction error ... waiting for 4.7.4 seems like a reasonable thing to do. As soon as 4.7.4 arrives in the tree I will continue testing! https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=4.7.4 thanks so far. 4.7.4 is now in the tree. I'm facing serious issues with the latest stable version of gentoo-sources which makes it impossible for me to compile gcc ... It will take a few more days, but I'm still on it Thanks in advancedIT will The segfault still appears with gcc-4.7.4 and gcc-4.8.3 in combination with binutils-2.32.2. I'm not sure how to continue. - the pdf behind the link which segfaults was replaced with a new version. The new version still fails to open with -ftree-vectorize - the segfault appears in an codesegment which is ancient ... libjpeg-turbo took it from libjpeg ... the bug still seems to be fishy ... I will try some further research but can't promise anything. Does it still happen on modern toolchain? I was not able to reproduce locally. Assuming fixed. |
