Re: gcc possibly generating invalid assembler

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Apr 18, 2017 at 08:42:32PM +0200, John Paul Adrian Glaubitz wrote:
On 04/14/2017 09:36 AM, Wouter Verhelst wrote:
Then I ran 'make CFLAGS=-save-temps' to see whether it perhaps did add
some inline assembly somewhere but you missed the #include and this time
it... worked?

Actually, adding -save-temps to CFLAGS doesn't help. However, since you
wrote "CFLAGS=-save-temps" instead of "CFLAGS+=-save-temps", I assume
you overrode the optimization level which has influence on the code
generation.

Good point, but nope, even with 'CFLAGS+=-save-temps' it succeeds.

Next attempt, "make V=1" returns the following command line:

m68k-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I../.. -I../../urcu -I../..  -I../.. -I../../tests/common -g -g -O2 -pthread -MT test_urcu_defer.o -MD -MP -MF .deps/test_urcu_defer.Tpo -c -o test_urcu_defer.o test_urcu_defer.c 

when I add CFLAGS=-save-temps (or CFLAGS+=, it makes not difference), it
turns out that the bit "-g -O2 -pthread" is dropped; it may be either
due to lack of pthread support, or the optimization level. Feels like
someone failed to read the automake documentation properly (CFLAGS is
supposed to remain unset; and indeed checking out configure.ac reveals
some CFLAGS munging that shouldn't happen).

Anyway, that means the most likely cause is the optimizer.

-- 
< ron> I mean, the main *practical* problem with C++, is there's like a dozen
       people in the world who think they really understand all of its rules,
       and pretty much all of them are just lying to themselves too.
 -- #debian-devel, OFTC, 2016-02-12
--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Video for Linux]     [Yosemite News]     [Linux S/390]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux