| Summary: | [4.0/wrong-code] aspell-en fails if aspell compiled with -maltivec | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Kathryn Kulick (RETIRED) <gothgirl> |
| Component: | Current packages | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
| Status: | VERIFIED LATER | ||
| Severity: | normal | CC: | chriswhite, gad.kadosh, hiyuh.root, morpheusz, ppc, tedrodgers |
| Priority: | High | ||
| Version: | 2005.1 | ||
| Hardware: | PPC | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | emerge --info, emerge --pretend, emege failed outputs are "cat"ed | ||
|
Description
Kathryn Kulick (RETIRED)
2005-09-08 20:12:45 UTC
Could you please try the gcc-4.0.2_pre ebuild in the tree and see if this is still a problem? Can someone using gcc-4.0.2-r1 on ppc please confirm if this is still a problem or not? I can not reproduce it on the ppc dev box, but I'd like to be sure. I can reproduce this with aspell 0.60.4, but it doesn't seem to segfault with aspell-0.50.5-r4 Alright "-maltivec -mabi=altivec" seem to be the culprit. As far as I can tell
its generating wrong code:
#0 0x375343c4 in free_norm_table<acommon::FromUniNormEntry> (d=0x1)
at convert.cpp:243
#1 0x375343b4 in free_norm_table<acommon::FromUniNormEntry> (d=0x1007b5f8)
at convert.cpp:245
#2 0x37537594 in ~NormTables (this=0x1007aac8) at convert.cpp:485
#3 0x374fba48 in acommon::GlobalCacheBase::release (this=0x37638940,
d=0x1007aac8) at cache.cpp:45
#4 0x374fbab8 in acommon::release_cache_data (cache=0x37638940, d=0x1007aac8)
at cache.cpp:67
#5 0x10023e78 in acommon::Cacheable::release (this=0x1007aac8) at cache.hpp:37
#6 0x3753ddcc in acommon::CachePtr<acommon::NormTables>::reset (
this=0x1007a6e8, p=0x0) at cache.hpp:49
#7 0x3753de14 in ~CachePtr (this=0x1007a6e8) at cache.hpp:63
#8 0x37537be8 in ~Convert (this=0x1007a6d0) at convert.cpp:983
#9 0x10023f8c in ~ConvObj (this=0x10078178) at convert.hpp:229
#10 0x375b6004 in ~Language (this=0x10078110) at language.hpp:63
#11 0x374fba48 in acommon::GlobalCacheBase::release (this=0x37638a68,
d=0x10078110) at cache.cpp:45
The 0x1 does not look right to me at all. No idea how to reduce this to a
testcase to send upstream though.
I have that problem too. In fact applications that use aspell crash when they need to check spelling. it's a combination of this bug and bug #96794 - not sure if they are related though. I tried to compile aspell without -maltivec -mabi=altivec and it still results in the same problems when emerging some dictionary. *** Bug 118684 has been marked as a duplicate of this bug. *** Now that I compiled it with gcc-3.4.4 it works, but with gcc-4.0.2 it doesn't work for me even without -maltivec -mabi=altivec. gcc-4.1 seems to fix the issue if you filter the altivec flags. I compiled it with sys-devel/gcc-4.1.0_beta20060120 and it compiled just fine, alitvec, -mabi=altivec, and -maltivec included. I made a simple document with lots of typos and ran `aspell -c test.txt` on it and it ran ok. (In reply to comment #9) > I compiled it with sys-devel/gcc-4.1.0_beta20060120 and it compiled just fine, > alitvec, -mabi=altivec, and -maltivec included. In my case, using sys-devel/gcc-4.1.0, CFLAGS="-Os -mcpu=G4 -mtune=G4 -maltivec -mtune=altivec -fno-strict-aliasing -Wall -pipe" in /etc/make.conf. (It's just for compilation error detecting.) Then, like running "emerge -e world". When emerging app-text/aspell-0.60.4 in official tree, the ebuild filered -maltivec and -mabi=altivec at the moment. So, app-text/aspell-0.60.4 was compiled with CFLAGS="-Os -mcpu=G4 -mtune=G4 -fno-strict-aliasing -Wall -pipe". It seems no compilation errors. But libtool wornings are, though. And then, like "emerge -e world" will emerge app-dicts/aspell-en-6.0.0 as next step. Its emerge process failed with the completely same error messages in first report. According to the bug #122855 (it might alpha specific, though), -Os in CFLAGS may produce aspell's segfault. This report suggests to use -O2 instead of -Os by replace-flags. So, I've tried to do it. Therefore, I've modified ebuild and emerge app-text/aspell-0.60.4 with CFLAGS="-O2 -mcpu=G4 -mtune=G4 -fno-strict-aliasing -Wall -pipe". Then, emerge app-dicts/aspell-en-6.0.0. But, it reproduces segfault, too. Created attachment 81838 [details]
emerge --info, emerge --pretend, emege failed outputs are "cat"ed
Well, this is fixed for now by filtering altivec for just this package. I'll keep an eye on this for 4.1.1. *** Bug 127083 has been marked as a duplicate of this bug. *** lu_zero says this is fixed now. |