[Bug target/80881] [7/8 Regression] null pointer access in libgomp.h

[jyong at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881

jyong at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-11-30
 Ever confirmed|0   |1

--- Comment #14 from jyong at gcc dot gnu.org ---
Doing some simple testcases, looks like generates:

movl %gs:0, %eax
movl _a@ntpoff(%eax), %eax

While MSVC does (Intel syntax):
mov ecx, DWORD PTR __tls_index
mov eax, DWORD PTR fs:__tls_array
mov eax, DWORD PTR [eax+ecx*4]
mov eax, DWORD PTR _a[eax]

For a statement "return a;" where a is a thread local integer.
I'm not sure how to modify the machine definition to emit this.

[Bug target/80881] [7/8 Regression] null pointer access in libgomp.h

[lh_mouse at 126 dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881

--- Comment #13 from Liu Hao  ---
Native TLS requires essential support from LD, which I don't think is going to
be available in foreseeable future.

Without native TLS GCC tries to use emulated TLS, and if it generates code
attempting to use the native one (which does not exist), it is, of course, a
bug.

[Bug target/80881] [7/8 Regression] null pointer access in libgomp.h

[daniel.f.starke at freenet dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881

--- Comment #12 from Daniel Starke  ---
I am not an expert on this field but your build does not use platform tls
support as mine is supposed to do. Furthermore, I was building all under
Windows. The only difference during the build process was the target
architecture (x86/x64). Using --enable-targets=all produced a compiler able to
build for both architectures. Not specifying --build= should just default to
the base compilers default target (which is, nevertheless, Windows). The only
issue I could possible see here is that the base compiler used to build GCC did
not support platform tls support but GCC still assumed it was available
resulting in a wrong setup. In this sense I was cross compiling (mingw x86 to
mingw-w64 x64).
Nevertheless, building GCC without --enable-tls like you did produces a working
executable for me too as mentioned on 2017-05-26.

[Bug target/80881] [7/8 Regression] null pointer access in libgomp.h

[lh_mouse at 126 dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881

--- Comment #11 from Liu Hao  ---
Diff'ing configure options used to build both GCC produces the following
result:

```
E:\Desktop>gcc-7.1.0-debug-broken-tls\bin\gcc.exe -v 2>&1 | sed "s/ --/\n&/g" >
yours.txt

E:\Desktop>gcc -v 2>&1 | sed "s/ --/\n&/g" > mine.txt

E:\Desktop>gcc-7.1.0-debug-broken-tls\bin\gcc.exe -v 2>&1 | sed "s/ --/\n&/g" >
yours.txt

E:\Desktop>diff --color -U1 mine.txt yours.txt
--- mine.txt2017-11-30 09:42:33.612869600 +0800
+++ yours.txt   2017-11-30 09:42:35.493977200 +0800
@@ -1,47 +1,35 @@
 Using built-in specs.
-COLLECT_GCC=gcc
-COLLECT_LTO_WRAPPER=C:/MinGW/MSYS2/mingw64/lib/gcc/x86_64-w64-mingw32/7.2.1/lto-wrapper.exe
+COLLECT_GCC=gcc-7.1.0-debug-broken-tls\bin\gcc.exe
+COLLECT_LTO_WRAPPER=e:/desktop/gcc-7.1.0-debug-broken-tls/bin/../libexec/gcc/x86_64-w64-mingw32/7.1.0/lto-wrapper.exe
 Target: x86_64-w64-mingw32
-Configured with: ../gcc/configure
- --prefix=/mingw64
- --with-local-prefix=/mingw64/local
- --build=x86_64-w64-mingw32
+Configured with: ../../src/gcc-7.1.0/configure
  --host=x86_64-w64-mingw32
- --target=x86_64-w64-mingw32
- --with-native-system-header-dir=/mingw64/x86_64-w64-mingw32/include
- --libexecdir=/mingw64/lib
- --enable-bootstrap
- --with-arch=x86-64
- --with-tune=nocona
- --enable-languages=c,lto,c++
- --enable-shared
+ --enable-languages=c,c++
+ --enable-seh-exceptions
+ --enable-threads=posix
+ --enable-tls
+ --disable-nls
+ --disable-shared
  --enable-static
- --enable-threads=mcf
- --enable-graphite
  --enable-fully-dynamic-string
- --enable-libstdcxx-time=yes
- --disable-libstdcxx-pch
- --disable-libstdcxx-debug
- --disable-isl-version-check
  --enable-lto
+ --enable-plugins
  --enable-libgomp
- --disable-multilib
- --enable-checking=release
- --disable-rpath
+ --with-dwarf2
  --disable-win32-registry
- --enable-nls
- --disable-werror
- --disable-symvers
- --with-libiconv
- --with-system-zlib
- --with-gmp=/mingw64
- --with-mpfr=/mingw64
- --with-mpc=/mingw64
- --with-isl=/mingw64
- --with-pkgversion='gcc-7-branch HEAD with MCF thread model, built by
LH_Mouse.'
- --with-bugurl=https://gcc-mcf.lhmouse.com/
- --with-gnu-as
- --with-gnu-ld
- --disable-tls
-Thread model: mcf
-gcc version 7.2.1 20171119 (gcc-7-branch HEAD with MCF thread model, built by
LH_Mouse.)
+ --enable-version-specific-runtime-libs
+ --prefix=/mingw64-64
+ --with-sysroot=/mingw64-64
+ --target=x86_64-w64-mingw32
+ --enable-targets=all
+ --enable-checking=release
+ --with-gmp=/usr/new-gcc/lib/gmp-5.0.5
+ --with-mpfr=/usr/new-gcc/lib/mpfr-2.4.2
+ --with-mpc=/usr/new-gcc/lib/mpc-0.9
+ --with-isl=/usr/new-gcc/lib/isl-0.18
+ --with-cloog=/usr/new-gcc/lib/cloog-0.18.4
+ --with-host-libstdcxx='-lstdc++ -lsupc++'
+ --disable-cloog-version-check
+ --enable-cloog-backend=isl
+Thread model: posix
+gcc version 7.1.0 (GCC)

E:\Desktop>
```

I notice that:
0) You didn't specify `--build=`.
1) You specified `--enable-targets=all` but I think this does not affect mingw
targets according to  and should be
removed.

Maybe you should try adding `--build=`?

[Bug target/80881] [7/8 Regression] null pointer access in libgomp.h

[lh_mouse at 126 dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881

--- Comment #10 from Liu Hao  ---
Compiling this rather simple program using your gcc:

```
__thread int a = 1;

int get_a(void){
   return a;
}
```

resulted in wrong assembly:

```
E:\Desktop\gcc-7.1.0-debug-broken-tls\bin>gcc E:\Desktop\test.c -S -masm=intel
-O2 -o -
.file   "test.c"
.intel_syntax noprefix
.text
.p2align 4,,15
.globl  get_a
.defget_a;  .scl2;  .type   32; .endef
.seh_proc   get_a
get_a:
.seh_endprologue
mov rax, QWORD PTR fs:0
mov eax, DWORD PTR a@tpoff[rax]
ret
.seh_endproc
.globl  a
.data
.align 4
a:
.long   1
.ident  "GCC: (GNU) 7.1.0"
```

With my working GCC it resulted in:

```
E:\Desktop>gcc E:\Desktop\test.c -S -masm=intel -O2 -o -
.file   "test.c"
.intel_syntax noprefix
.text
.globl  get_a
.defget_a;  .scl2;  .type   32; .endef
.seh_proc   get_a
get_a:
sub rsp, 40
.seh_stackalloc 40
.seh_endprologue
lea rcx, __emutls_v.a[rip]
call__emutls_get_address
mov eax, DWORD PTR [rax]
add rsp, 40
ret
.seh_endproc
.section .rdata,"dr"
.align 4
__emutls_t.a:
.long   1
.globl  __emutls_v.a
.data
.align 32
__emutls_v.a:
.quad   4
.quad   4
.quad   0
.quad   __emutls_t.a
.ident  "GCC: (gcc-7-branch HEAD with MCF thread model, built by
LH_Mouse.) 7.2.1 20171119"
.def__emutls_get_address;   .scl2;  .type   32; .endef
```

[Bug target/80881] [7/8 Regression] null pointer access in libgomp.h

[daniel.f.starke at freenet dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881

--- Comment #9 from Daniel Starke  ---
This was a native build.
I have added the GCC build in question to
https://sourceforge.net/projects/gcc-win64/files/7.1.0/gcc-7.1.0-debug-broken-tls.7z

[Bug target/80881] [7/8 Regression] null pointer access in libgomp.h

[lh_mouse at 126 dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881

--- Comment #8 from Liu Hao  ---
I cannot reproduce this problem on either i686-w64-mingw32 or
x86_64-w64-mingw32 with --enable-tls.


On line 677 in libgomp.h there is a call to `gomp_thread()` which is supposed
to return a pointer to a __thread object. However, from your first post, it is
weird that for i686 GCC generates code referring the GS segment register, since
GS is unused by x86 Windows.

On x86 Windows, TLS is indirected from the FS register. It is Microsoft's
rocket science, hence GCC still relies on the emutls solution. The GS register
is known to be utilized by x64 Windows and Linux AFAICT.

I presume that your GCC generated Linux code for Windows targets. If you are
cross-compiling for example it may becaused by GCC scripts mistaking the host
for the build. This still requires investigation.

Reference: 

[Bug target/80881] [7/8 Regression] null pointer access in libgomp.h

[daniel.f.starke at freenet dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881

--- Comment #7 from Daniel Starke  ---
Error report from Dr.Memory:
Error #1: UNADDRESSABLE ACCESS: reading 0x-0x0008 8
byte(s)
# 0 gomp_resolve_num_threads  
[../../../../src/gcc-7.1.0/libgomp/libgomp.h:677]
# 1 GOMP_parallel 
[../../../../src/gcc-7.1.0/libgomp/parallel.c:166]
# 2 main   [h:\Temp\cpp017/test.c:11]
Note: @0:00:00.450 in thread 3376
Note: instruction: mov%fs:0x00 -> %rax

Backtrace from SIGSEGV in GDB:
#0  gomp_resolve_num_threads (specified=specified@entry=0, count=count@entry=0)
at ../../../../src/gcc-7.1.0/libgomp/parallel.c:47
threads_requested = 
max_num_threads = 
num_threads = 
busy = 
pool = 
#1  0x0040184f in GOMP_parallel (fn=fn@entry=0x401520 ,
data=data@entry=0x22fe60, num_threads=num_threads@entry=0, 
flags=flags@entry=0) at ../../../../src/gcc-7.1.0/libgomp/parallel.c:166
No locals.
#2  0x00401604 in main () at test.c:11
var = {3.72983052e-039, 0, 7.3767739e+033, 0, 7.34706519e+033, 0,
3.20827844e-039, 0, 9.03661843e-038, 0, 3.20798697e-039, 0, 
  3.67341985e-039, 0, 6.86636248e-044, 0, 1.40129846e-045, 0,
7.53898574e-043, 0, 2, 0, 3.67341985e-039, 0, 3.67341985e-039, 0, 
  1.07899982e-043, 0, 2.75506488e-040, 0, 7.67135411e+033, 0, 0, 0,
8.59029811e+009, 0, 0, 0, 3.67390189e-039, 0, 0, 0, 5.60519386e-045, 0, 
  7.53898574e-043, 0, 2.2337, 0, 1.07899982e-043, 0,
4.20389539e-045, 0, 1.77964905e-043, 0, 7.41472914e+033, 0, 3.71850803e-039, 0, 
  8.59029811e+009, 0, 3.67420457e-039, 0, 4.20389539e-043, 0,
3.20836812e-039, 0, 1.8758415e-012, 0, 3.72900095e-039, 0, 1.40129846e-045, 
  0, 3.67420457e-039, 0, 0, 0, 3.67390189e-039, 0, 0, 0,
1.07899982e-043, 0, 4.48415509e-044, 4.20389539e-045, 3.67420457e-039, 0, 0, 0, 
  2.80259693e-045, 0, 3.67420457e-039, 0, 0, 0, 1.40129846e-045, 0, 0,
0, 1.56945428e-043, 0, 0, 0, 0, 0, 3.72904579e-039, 0, 
  5.60519386e-044, 0, 3.20930979e-039, 0, 8.51989466e-043, 0,
3.20865959e-039, 0, 9.82653682e-039, 4.49998415e-039, 5.87344331e+022, 
  2.67781571e+020, 0, 0, 6.74539118e-039, 0, 2.38775653e-039, 0,
-2.81029619e+037, 2.86705666e-042, 0, 0, 1.83673515e-039, 0, 0, 0, 
  1.56945428e-043, 0, 0, 0, 0, 0, 0, 0, 0, 0, 9.93057972e-035, 0, 0, 0,
0, 0, 0, 0, 0, 0, 9.1315e-039, 0, 3.21108104e-039, 0, 
  3.20936585e-039, 0, 7.34316878e+033, 0, 3.20935604e-039, 0,
3.72902337e-039, 0, 0, 0, 3.67341985e-039, 0, 0, 1.34524653e-043, 
  7.18866112e-043, 2.80259693e-045, 3.67341985e-039, 0,
7.63497105e+033, 0, 3.67341985e-039, 0, 3.72900095e-039, 0, 3.21121556e-039, 0, 
  1.34524653e-043, 0, 0, 0, 0, 0, -nan(0x7dd000), 2.86845796e-042,
1.82959882e-018, 0, 3.67341985e-039, 0, 7.48008123e+033, 0, 0, 0, 
  3.72902337e-039, 0...}
PI = 3.14159274

Stack level 0, frame at 0x22edd0:
 rip = 0x401629 in gomp_resolve_num_threads
(../../../../src/gcc-7.1.0/libgomp/parallel.c:47); saved rip 0x40184f
 called by frame at 0x22ee30
 source language c.
 Arglist at 0x22ed88, args: specified=specified@entry=0, count=count@entry=0
 Locals at 0x22ed88, Previous frame's sp is 0x22edd0
 Saved registers:
  rbx at 0x22edb0, rsi at 0x22edb8, rdi at 0x22edc0, rip at 0x22edc8, xmm15 at
0x22edc8

Used mingw-w64-v5.0.2.

[Bug target/80881] [7/8 Regression] null pointer access in libgomp.h

[jyong at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881

--- Comment #6 from jyong at gcc dot gnu.org ---
Crash seems to be coming from the mingw-w64 runtime tls handler.

[Bug target/80881] [7/8 Regression] null pointer access in libgomp.h

[jyong at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881

--- Comment #5 from jyong at gcc dot gnu.org ---
Can you post the full backtrace? Meanwhile, I'll setup gcc with --enable-tls
and give this a try.

[Bug target/80881] [7/8 Regression] null pointer access in libgomp.h

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jyong at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
CCing Cygwin/Mingw maintainer.

[Bug target/80881] [7/8 Regression] null pointer access in libgomp.h

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|7.2 |7.3

[Bug target/80881] [7/8 Regression] null pointer access in libgomp.h

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|7.2 |7.3

--- Comment #4 from Richard Biener  ---
GCC 7.2 is being released, adjusting target milestone.