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@xxxxxxxxxxxxxxxxx>
School of Aerospace Science and Technology, Xidian University
