http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56866
--- Comment #13 from Winfried Magerl <winfried.mag...@t-online.de> 2013-04-24 20:58:13 UTC --- Hi, On Wed, Apr 17, 2013 at 09:49:15PM +0000, glisse at gcc dot gnu.org wrote: > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56866 > > --- Comment #12 from Marc Glisse <glisse at gcc dot gnu.org> 2013-04-17 > 21:49:15 UTC --- > (In reply to comment #11) > > If fixing broken gcc's XOP/FMA/FMA4-extensions on AMD-CPUs depends on my > > ability to extract a stand-alone-test from glibc-testsuite then I'm > > realy sorry for not having the necessary skills (as already stated). > > Skills can be learned, and the best way is through practice. Ideally someone > with the right combination of knowledge, hardware and free time would look at > it, and you seem to be the closest currently ;-) Please ask me again in 17 years when I'm hopefully finished with regular work. Easter-Holidays might give you the wrong for my available spare time....... > > Why not simply using the failing test-cases from gcc-testsuite > > which are all standalone and depends on XOP: > > Good idea. I suggest you pick a simple one: > > > +FAIL: gcc.target/i386/sse2-mul-1.c execution test > > it looks like a list of several tests in a row. If you can first replace the > aborts with printf to determine the first one that fails, then remove > everything after that point, you have already narrowed the issue quite a bit. > Then you can try to simplify what remains. Ideally, you would get a program > small enough that posting the dumps would show the obvious issue. Do make > sure > while reducing the program that it still works correctly without the bdver2 > option. I've done some basic checks and according to gdb the first abort() triggers with unmodified code. Replacing abort() with printf() does no longer trigger the if-clause and the next abort() was called. I've add a small tar-file with a simple shell-scipt check.sh which builds two binaries with no-xop and xop as options. Tested with self-build "gcc (GCC) 4.8.1 20130421" and stock OpenSuSE-12.3-compiler "gcc (GCC) 4.7.2 20130108". Searching for xop in bugzilla shows that there are bugs refering to xop/sse2-mul-1.c/bdver2 but it looks like there's no real progress in this area. If you're waiting on me to become a c-developer we might have to live with broken xop/fam/fam4-extension for the next 17 years. For my self-build home-linux which is mostly a hobby I can live with this simple patch: --- gcc-4.8-noxop/gcc/config/i386/i386.c.orig 2013-04-12 20:49:09.181351855 +0200 +++ gcc-4.8-noxop/gcc/config/i386/i386.c 2013-04-12 23:15:09.112185980 +0200 @@ -2976,9 +2976,9 @@ {"bdver2", PROCESSOR_BDVER2, CPU_BDVER2, PTA_64BIT | PTA_MMX | PTA_SSE | PTA_SSE2 | PTA_SSE3 | PTA_SSE4A | PTA_CX16 | PTA_ABM | PTA_SSSE3 | PTA_SSE4_1 - | PTA_SSE4_2 | PTA_AES | PTA_PCLMUL | PTA_AVX | PTA_FMA4 - | PTA_XOP | PTA_LWP | PTA_BMI | PTA_TBM | PTA_F16C - | PTA_FMA | PTA_PRFCHW | PTA_FXSR | PTA_XSAVE}, + | PTA_SSE4_2 | PTA_AES | PTA_PCLMUL | PTA_AVX + | PTA_LWP | PTA_BMI | PTA_TBM | PTA_F16C + | PTA_PRFCHW | PTA_FXSR | PTA_XSAVE}, {"bdver3", PROCESSOR_BDVER3, CPU_BDVER3, PTA_64BIT | PTA_MMX | PTA_SSE | PTA_SSE2 | PTA_SSE3 | PTA_SSE4A | PTA_CX16 | PTA_ABM | PTA_SSSE3 | PTA_SSE4_1 I'm still wondering why the extensions where enabled when the test-suite shows 179 additinal FAIL in 36 different c-files (current gcc-4.8.branch). If I can help testing feel free to send me an e-mail. regards winfried
