why some gcc/guality tests fail unless gcc built with -mtune=generic on x86_64? is there a GCC test suite 'enter GDB on failure' option?

Xi Ruoyao ryxi@stu.xidian.edu.cn
Mon May 28 15:17:00 GMT 2018


On 2018-05-28 14:19 +0000, Jason Vas Dias wrote:
> Good day  -
> 
> I just noticed that with the gcc-{5,6,7} branches,
> when GCC is configured to build by default for the native machine
> by specifying
>    '--with-tune=native' or
>    '--with-arch-64=x86-64 --with-tune=haswell'
>    (which should produce identical results on my machine)
> , the testsuite test:
>   gcc.dg/guality/example.c fails:
> ...
> FAIL: c is -1, not 6299808
> FAIL: c is -1, not 6299824
> FAIL: c is -1, not 6299840
> FAIL: c is -1, not 6299856
> FAIL: c is -1, not 6299872
> FAIL: 114 PASS, 5 FAIL, 0 UNRESOLVED
> 
> So this is compiled with for example gcc 7.3.1 on my system:
> 
> gcc7 -march=x86-64 -mtune=native -B/usr/local/lib64/gcc/x86_64-linux-gnu/7.3.1 /home/devel/OS/gcc-7-
> branch/gcc/testsuite/gcc.dg/guality/example.c  -O2 -g -lm -o ./example.7.n.exe
> 
> But I get NO failures when using generic tuning:
> 
> gcc7 -march=x86-64 -mtune=generic -B/usr/local/lib64/gcc/x86_64-linux-gnu/7.3.1 /home/devel/OS/gcc-7-
> branch/gcc/testsuite/gcc.dg/guality/example.c -O2 -g -lm -o ./example.7.g.exe

Reproduced with -mtune=haswell -O2 -g.  With my native tune
(-mtune=skylake) this didn't happen.

> Is this a fault with '-mtune=generic', or with the test case, or with
> something else ?
> 
> I believe this may be a known issue, but please could anyone point to
> what precisely is going wrong when -mtune=native is used ?

"guality" tests tend to fail with optimization.  I believe they are
fragile and ignore them.

> This is with binutils-2.30 and GDB-8.1, but I believe it would happen
> with any binutils ?

It should happen with any binutils, but NOT with any GDB.  Actually there
is a chance that this is a GDB bug.

> I would like to ensure use of '-mtune=native' is not introducing some
> basic compiler bugs into my code. I do see code running alot faster when
> compiled with -mtune=native - but is this at the cost of correctness?
> Or is the test just incorrect when compiled with '-mtune=native' ?
> If anyone just knows, please let me know - I am investigating
> the hard way.

No.  guality means "quality of debug information".  It just makes (some
parts of) your program hard to debug.  I always debug my program with
"-O0 -g" and no "march" or "mtune".  Even "-Og -g" may make some program
undebugable.

> Does anyone know how to get the testsuite to print a gdb stack dump
> or just go interactive for the above guality/example.c on the event
> of an 'FAIL' ? ie. I'd like to break at guality.h, line 367:
>  case INCORRECT:
>     fprintf (stderr, "FAIL: %s... )
> or get it to print a complete GCC stack dump there or just
> bring GDB to the foreground and let the user interact with
> it - that is what I am trying to do - I see one can set
> the 'GUALITY_GDB_NAME' and 'GUALITY_GDB_ARGS' environment
> variables, but is their use documented anywhere ? ie. what
> arguments would I use to get GDB to stop & go interactive?
> (Give that one cannot run the main process under GDB since
>  then its child GDBs cannot run
> ) .

Not GCC stack dump, but the stack dump of the program compiled
by GCC.  Perhaps, use libunwind?

> It is very difficult to see which of the hundreds of possible
> iterations the program is failing at without something like
> the above - it could benefit from printing more verbose test
> details.

I think the verbose message may be "optimized away".  It's
not useful.

> Thanks & Regards,
> Jason
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
-- 
Xi Ruoyao <ryxi@stu.xidian.edu.cn>
School of Aerospace Science and Technology, Xidian University



More information about the Gcc-help mailing list