[Bug inline-asm/90907] Binary crashes if both asm() and __thread are used in the same code

2019-06-18 Thread fujim...@clear-code.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90907

Fujimoto Seiji  changed:

   What|Removed |Added

 Resolution|INVALID |FIXED

--- Comment #2 from Fujimoto Seiji  ---
I can follow your reasoning, but as far as I can tell Clang can
handle it without any problem (storing only `x` in .tbss section).

$ clang foo.c
$ ./a.out && echo $?
0

Also as a practical matter, it's not really unintuitive for users
why __thread keyword should affect asm() right after the line.

[Bug c/90907] New: Binary crashes if both asm() and __thread are used in the same code

2019-06-17 Thread fujim...@clear-code.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90907

Bug ID: 90907
   Summary: Binary crashes if both asm() and __thread are used in
the same code
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fujim...@clear-code.com
  Target Milestone: ---

Created attachment 46494
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46494=edit
Preprocessed file for the reproduction code

Condier the following code:

__thread int x;
asm (
".global foo\n"
"foo:\n"
"  ret"
);
void foo(void);
int main(){foo();}

GCC (all of 6.3.0, 7.4.0, 8.3.0 and 9.1.0) fails to compile this code
properly and the resulting executable crashes with a segmentation fault.

$ gcc foo.c
$ ./a.out
Segmentation fault

An interesting thing is that moving __thread line after asm() fixes
the issue. Indeed, I can confirm that the following (slightly-tweaked)
code works fine with GCC 9.1.0.

asm (
".global foo\n"
"foo:\n"
"  ret"
);
void foo(void);
__thread int x;
int main(){foo();}

This suggests that something is wrong with GCC's code generation for
__thread.

$ gcc foo-reordered.c
$ ./a.out && echo $?
0

I can reproduce this bug on the following platforms:

* Debian 9.8 (x64:Intel i5-7200U)
* Ubuntu 18.04 (aarch64:Cavium ThunderX 88XX)

The exact build option for the GCC version I used is:

$ gcc-9 -v
Using built-in specs.
COLLECT_GCC=gcc-9
COLLECT_LTO_WRAPPER=/usr/lib/gcc/aarch64-linux-gnu/9/lto-wrapper
Target: aarch64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
9.1.0-2ubuntu2~18.04' --with-bugurl=file:///usr/share/doc/gcc-9/README.Bugs
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-9
--program-prefix=aarch64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-libquadmath --disable-libquadmath-support --enable-plugin
--enable-default-pie --with-system-zlib --with-target-system-zlib=auto
--enable-multiarch --enable-fix-cortex-a53-843419 --disable-werror
--enable-checking=release --build=aarch64-linux-gnu --host=aarch64-linux-gnu
--target=aarch64-linux-gnu
Thread model: posix
gcc version 9.1.0 (Ubuntu 9.1.0-2ubuntu2~18.04)