gcc possibly generating invalid assembler

gcc possibly generating invalid assembler

[John Paul Adrian Glaubitz]

Hi!

I have unsuccessfully been trying to build liburcu on Debian/m68k. After
adding "m68k" as a detected architecture in configure.ac, the build
fails with the assembler generating syntax error messages [1]:

gcc -DHAVE_CONFIG_H -I. -I../.. -I../../urcu   -Wdate-time -D_FORTIFY_SOURCE=2 -I../.. -I../.. -I../../tests/common -g -g -O2
-fdebug-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -Wformat -Werror=format-security -pthread -c -o test_urcu_defer.o test_urcu_defer.c
/tmp/ccXHVXOc.s: Assembler messages:
/tmp/ccXHVXOc.s:312: Error: syntax error -- statement `add.l %d1,nr_writes@TLSLE+4(%a0)' ignored
/tmp/ccXHVXOc.s:440: Error: syntax error -- statement `add.l %d1,nr_writes@TLSLE+4(%a0)' ignored

Since the source code file in question doesn't contain any m68k inline
assembly, I would suspect this to be a problem with the code generated
by gcc.

Any suggestions?

Adrian

> [1] https://people.debian.org/~glaubitz/liburcu_0.9.3-3_m68k.build

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: gcc possibly generating invalid assembler

[Wouter Verhelst]

On Thu, Apr 13, 2017 at 01:08:59PM +0200, John Paul Adrian Glaubitz wrote:
> Hi!
> 
> I have unsuccessfully been trying to build liburcu on Debian/m68k. After
> adding "m68k" as a detected architecture in configure.ac, the build
> fails with the assembler generating syntax error messages [1]:
> 
> gcc -DHAVE_CONFIG_H -I. -I../.. -I../../urcu   -Wdate-time -D_FORTIFY_SOURCE=2 -I../.. -I../.. -I../../tests/common -g -g -O2
> -fdebug-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -Wformat -Werror=format-security -pthread -c -o test_urcu_defer.o test_urcu_defer.c
> /tmp/ccXHVXOc.s: Assembler messages:
> /tmp/ccXHVXOc.s:312: Error: syntax error -- statement `add.l %d1,nr_writes@TLSLE+4(%a0)' ignored
> /tmp/ccXHVXOc.s:440: Error: syntax error -- statement `add.l %d1,nr_writes@TLSLE+4(%a0)' ignored

Interesting.

> Since the source code file in question doesn't contain any m68k inline
> assembly, I would suspect this to be a problem with the code generated
> by gcc.
> 
> Any suggestions?

I wanted to have a closer look, so added a line saying "[m68k],
[ARCHTYPE="gcc"]," to the AS_CASE statement in configure.ac (which I'm
assuming is what you did, too; next time it would be useful if you
shared your patches ;-) ). Then I ran make until it encountered the
above error.

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?

Not sure what's going on here.

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

Re: gcc possibly generating invalid assembler

[John Paul Adrian Glaubitz]

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.

Will verify that.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: gcc possibly generating invalid assembler

[Wouter Verhelst]

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

Re: gcc possibly generating invalid assembler

[John Paul Adrian Glaubitz]

On 04/19/2017 09:39 AM, Wouter Verhelst wrote:
> Good point, but nope, even with 'CFLAGS+=-save-temps' it succeeds.

For me, building the package succeeds with the following added to
debian/rules:

ifeq ($(DEB_HOST_ARCH_CPU), m68k)
        export DEB_CFLAGS_MAINT_APPEND += -O0
endif

> 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 
> 
> Anyway, that means the most likely cause is the optimizer.

I agree. It's definitely the optimization level which triggers
the issue.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: gcc possibly generating invalid assembler

[Wouter Verhelst]

On Wed, Apr 19, 2017 at 09:39:38AM +0200, Wouter Verhelst wrote:
> Anyway, that means the most likely cause is the optimizer.

side note: there actually is some inline assembly, but it looks like
that's coming from places like /usr/m68k-linux-gnu/include/byteswap.h
etc, so not the cause of this problem

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

Re: gcc possibly generating invalid assembler

[Wouter Verhelst]

On Wed, Apr 19, 2017 at 09:39:38AM +0200, Wouter Verhelst wrote:
> 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).

Filed https://bugs.lttng.org/issues/1095 about that issue. Haven't filed
a bug report about the optimizer bug yet.

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

Re: gcc possibly generating invalid assembler

[Richard Z]

On Thu, Apr 13, 2017 at 01:08:59PM +0200, John Paul Adrian Glaubitz wrote:
> Hi!
> 
> I have unsuccessfully been trying to build liburcu on Debian/m68k. After
> adding "m68k" as a detected architecture in configure.ac, the build
> fails with the assembler generating syntax error messages [1]:
> 
> gcc -DHAVE_CONFIG_H -I. -I../.. -I../../urcu   -Wdate-time -D_FORTIFY_SOURCE=2 -I../.. -I../.. -I../../tests/common -g -g -O2
> -fdebug-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -Wformat -Werror=format-security -pthread -c -o test_urcu_defer.o test_urcu_defer.c
> /tmp/ccXHVXOc.s: Assembler messages:
> /tmp/ccXHVXOc.s:312: Error: syntax error -- statement `add.l %d1,nr_writes@TLSLE+4(%a0)' ignored
> /tmp/ccXHVXOc.s:440: Error: syntax error -- statement `add.l %d1,nr_writes@TLSLE+4(%a0)' ignored
> 
> Since the source code file in question doesn't contain any m68k inline
> assembly, I would suspect this to be a problem with the code generated
> by gcc.
> 
> Any suggestions?

The comments in gcc/config/m68k/m68k.c:m68k_final_prescan_insn() mention 
this as potential problem but I have no deep insight or clue why the solution
doesn't work.



Richard

-- 
Name and OpenPGP keys available from pgp key servers

Re: gcc possibly generating invalid assembler

[Michael Jeanson]

On Thu, Apr 13, 2017 at 01:08:59PM +0200, John Paul Adrian Glaubitz wrote:
> 
> I have unsuccessfully been trying to build liburcu on Debian/m68k. After
> adding "m68k" as a detected architecture in configure.ac, the build
> fails with the assembler generating syntax error messages [1]:
> 
> gcc -DHAVE_CONFIG_H -I. -I../.. -I../../urcu   -Wdate-time -D_FORTIFY_SOURCE=2 -I../.. -I../.. -I../../tests/common -g -g -O2
> -fdebug-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -Wformat -Werror=format-security -pthread -c -o test_urcu_defer.o test_urcu_defer.c
> /tmp/ccXHVXOc.s: Assembler messages:
> /tmp/ccXHVXOc.s:312: Error: syntax error -- statement `add.l %d1,nr_writes@TLSLE+4(%a0)' ignored
> /tmp/ccXHVXOc.s:440: Error: syntax error -- statement `add.l %d1,nr_writes@TLSLE+4(%a0)' ignored

The invalid asm is related to Thread Local Storage and liburcu has a
compat layer that can be enabled at configure for platforms that don't
have it.

With './configure --disable-compiler-tls' the build succeeds and the
regression test suite completes without having to disable optimisations.

Hope this helps,

Michael

Re: gcc possibly generating invalid assembler

[Wouter Verhelst]

On Thu, Apr 20, 2017 at 05:00:35PM -0400, Michael Jeanson wrote:
> On Thu, Apr 13, 2017 at 01:08:59PM +0200, John Paul Adrian Glaubitz wrote:
> > 
> > I have unsuccessfully been trying to build liburcu on Debian/m68k. After
> > adding "m68k" as a detected architecture in configure.ac, the build
> > fails with the assembler generating syntax error messages [1]:
> > 
> > gcc -DHAVE_CONFIG_H -I. -I../.. -I../../urcu   -Wdate-time -D_FORTIFY_SOURCE=2 -I../.. -I../.. -I../../tests/common -g -g -O2
> > -fdebug-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -Wformat -Werror=format-security -pthread -c -o test_urcu_defer.o test_urcu_defer.c
> > /tmp/ccXHVXOc.s: Assembler messages:
> > /tmp/ccXHVXOc.s:312: Error: syntax error -- statement `add.l %d1,nr_writes@TLSLE+4(%a0)' ignored
> > /tmp/ccXHVXOc.s:440: Error: syntax error -- statement `add.l %d1,nr_writes@TLSLE+4(%a0)' ignored
> 
> The invalid asm is related to Thread Local Storage and liburcu has a
> compat layer that can be enabled at configure for platforms that don't
> have it.

Last I checked, m68k does have TLS, though. It is a requirement for
recent versions of glibc, and although the m68k port was stuck on it for
a while, recent versions should have it.

In fact, when checking the generated asm code, it shows that the
nr_writes@TLSLE indirection is used in other locations too; but those
don't have the "+4" bit right after that. I suspect that's the problem.

(then again, trying to use gcc5 rather than gcc6 does not fix the issue,
so meh)

> With './configure --disable-compiler-tls' the build succeeds and the
> regression test suite completes without having to disable optimisations.

Well, that's good to know :-)

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