https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881
--- Comment #34 from Julian Waters <tanksherman27 at gmail dot com> ---
(In reply to Eric Botcazou from comment #32)
> > It's a bit of a shame I couldn't figure out how to make the zero extend
> > approach work correctly. That aside, I'm concerned that this patch still
> > isn't correct, because it doesn't seem to be using the parallel rtx
> > correctly.
>
> No worries, it's the standard way of requesting a scratch register, and
> nothing will try to use the result of a CLOBBER on it. That being said, we
> could indeed try and split the instructions for better scheduling, although
> the TLS pattern for the Sun linker is multi-insn too, see
> tls_initial_exec_64_sun.
>
> I'm attaching a minor update which uses named insns to simplify the code.
Perhaps splitting the 3 instructions that make up the thread pointer load into
the 2 instructions that can be done in parallel and the last one that depends
on the 2 is an enhancement that can be done, yes. Right now it seems like gcc
cannot compile libgomp again though, this time when done with bootstrap enabled
../../../gcc-14.2.0/libgomp/team.c: In function 'gomp_team_start':
../../../gcc-14.2.0/libgomp/team.c:940:1: error: unrecognizable insn:
940 | }
| ^
(insn 290 289 291 12 (set (reg:DI 406)
(const:DI (plus:DI (unspec:DI [
(symbol_ref:DI ("gomp_tls_data") [flags 0x2a] <var_decl
0000000003e98120 gomp_tls_data>)
] UNSPEC_SECREL32)
(const_int 16 [0x10]))))
"../../../gcc-14.2.0/libgomp/team.c":354:17 -1
(nil))
during RTL pass: vregs
The corresponding command line was
libtool: compile:
/c/Users/vertig0/Downloads/eclipse-committers-2023-12-R-win32-x86_64/Workspace/MINGW-packages/mingw-w64-gcc/src/build-UCRT64/./gcc/xgcc
-B/c/Users/vertig0/Downloads/eclipse-committers-2023-12-R-win32-x86_64/Workspace/MINGW-packages/mingw-w64-gcc/src/build-UCRT64/./gcc/
-L/c/Users/vertig0/Downloads/eclipse-committers-2023-12-R-win32-x86_64/Workspace/MINGW-packages/mingw-w64-gcc/src/build-UCRT64/./gcc
-isystem /ucrt64/x86_64-w64-mingw32/include -isystem /ucrt64/include
-B/ucrt64/x86_64-w64-mingw32/bin/ -B/ucrt64/x86_64-w64-mingw32/lib/ -isystem
/ucrt64/x86_64-w64-mingw32/include -isystem
/ucrt64/x86_64-w64-mingw32/sys-include -fno-checking -DHAVE_CONFIG_H -I.
-I../../../gcc-14.2.0/libgomp -I../../../gcc-14.2.0/libgomp/config/mingw32
-I../../../gcc-14.2.0/libgomp/config/posix -I../../../gcc-14.2.0/libgomp
-I../../../gcc-14.2.0/libgomp/../include -pthread -Wall -g -march=nocona -msahf
-mtune=generic -O2 -pipe -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector-strong
-Wp,-D__USE_MINGW_ANSI_STDIO=1 -MT team.lo -MD -MP -MF .deps/team.Tpo -c
../../../gcc-14.2.0/libgomp/team.c -DDLL_EXPORT -DPIC -o .libs/team.o
I will work on trying to fix this and creating a reproducer for the issue. The
patch used here is slightly different because I'm testing it on gcc 14
