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?

[Jason Vas Dias]

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


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 ?

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

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.

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
) .

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.

Thanks & Regards,
Jason