https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881
--- Comment #95 from LIU Hao ---
To be honest, I think `set_have_as_tls=no` is a rather horrible idea. It
changes the output ABI about thread-local storage according to the linker,
which is just there, happens to be used, in an unpredictable way.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881
LIU Hao changed:
What|Removed |Added
Attachment #59742|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881
--- Comment #93 from Julian Waters ---
I've revised the patch to implement the desired configure semantics. If anyone
wants to test the Latest TLS out I'd appreciate it (To ensure that it works on
more than just my own laptop. Please do check if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881
Julian Waters changed:
What|Removed |Added
Attachment #59516|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881
LIU Hao changed:
What|Removed |Added
Attachment #59666|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881
--- Comment #90 from LIU Hao ---
As mentioned yesterday, the libstdc++ `call_once` has to be reimplemented to
get rid of `__once_callable` and `__once_call` which can't be exported from
libstdc++ DLL.
You might want to introduce a builtin macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881
--- Comment #89 from Julian Waters ---
Understood. I will try to improve the check in that case. A side effect of this
is that native TLS will be enabled by default for Windows unless --disable-tls
is passed, unless I rewrite the check extensivel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881
--- Comment #88 from Eric Botcazou ---
> Eric, I've just come to realize that the configure check might not be
> needed, because the intention is to only allow native TLS on Windows when
> --enable-tls is forcefully enabled, similar to win32 thre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881
--- Comment #87 from Julian Waters ---
Eric, I've just come to realize that the configure check might not be needed,
because the intention is to only allow native TLS on Windows when --enable-tls
is forcefully enabled, similar to win32 thread mod
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881
--- Comment #86 from Uroš Bizjak ---
(In reply to Julian Waters from comment #83)
> Uros: I see, I'll try to do so. I was mainly avoiding that to break less
> code (I have a habit of doing that to anything I touch). Although, the
> resulting ass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881
--- Comment #85 from LIU Hao ---
Created attachment 59666
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59666&action=edit
libstdc++ fix
It is not possible to export a `__thread` variable with native TLS, because
it's not possible to acces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881
--- Comment #84 from LIU Hao ---
(In reply to Julian Waters from comment #83)
> Liu Hao: The registers it's using seem to be all over the place. Prior it
> was using rdx for the gs:[88] load and rax for everything else, now it's
> either using an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881
--- Comment #83 from Julian Waters ---
Liu Hao: The registers it's using seem to be all over the place. Prior it was
using rdx for the gs:[88] load and rax for everything else, now it's either
using any register it can find, or using rdx to store
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881
--- Comment #82 from LIU Hao ---
(In reply to Uroš Bizjak from comment #81)
> (In reply to Julian Waters from comment #75)
> > Any feedback on the new patch?
>
> I would propose you legitimize TLS address using get_thread_pointer (as is
> the ca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881
--- Comment #81 from Uroš Bizjak ---
(In reply to Julian Waters from comment #75)
> Any feedback on the new patch?
I would propose you legitimize TLS address using get_thread_pointer (as is the
case with Eric's patch). Generic optimizers are the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881
--- Comment #80 from LIU Hao ---
In libstdc++ there is:
```
/// @cond undocumented
# ifdef _GLIBCXX_HAVE_TLS
// If TLS is available use thread-local state for the type-erased callable
// that is being run by std::call_once in the current
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881
--- Comment #79 from LIU Hao ---
Created attachment 59639
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59639&action=edit
quote symbols for intel syntax
This patch is necessary for TLS in Intel syntax to work with GNU AS. Details
follow.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881
--- Comment #78 from LIU Hao ---
I changed it to `ix86_GOT_alias_set()` and checked output assembly. The patch
should be fine for these setups:
* x86_64-w64-mingw-32 (-O0, -O1, -O2, -Os)
* i686-w64-mingw-32 (-O0, -O1, -O2, -Os)
Simple test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881
--- Comment #77 from LIU Hao ---
../../gcc/gcc/config/i386/i386.cc: In function 'rtx_def*
legitimize_tls_address(rtx, tls_model, bool)':
../../gcc/gcc/config/i386/i386.cc:12196:27: error: 'GOT_ALIAS_SET' was not
declared in this scope; did you me
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881
--- Comment #76 from LIU Hao ---
I can include this patch for some testing on GCC 14 now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881
--- Comment #75 from Julian Waters ---
Any feedback on the new patch?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881
--- Comment #74 from Julian Waters ---
Sorry for the noise, any feedback on the new patch?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881
--- Comment #73 from Julian Waters ---
Thanks for the reminder, I did choose to leave that out since I was under the
impression that regenerating configure should be done in a separate commit. I
chose a different approach for the configure check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881
--- Comment #72 from Sam James ---
Note that your patch doesn't include the changes to generated configure. While
Eric knows that and likely decided not to include that in his, I'm pointing it
out because you might not be aware for your own patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881
Julian Waters changed:
What|Removed |Added
Attachment #59322|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881
--- Comment #70 from Eric Botcazou ---
> I apologize for vanishing suddenly and not giving progress reports, I am
> currently busy with some JDK work. The only thing left missing is the
> configure check. I will return to finishing TLS support on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881
--- Comment #69 from Julian Waters ---
I apologize for vanishing suddenly and not giving progress reports, I am
currently busy with some JDK work. The only thing left missing is the configure
check. I will return to finishing TLS support once and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881
--- Comment #68 from Julian Waters ---
I don't know why but apparently using force_reg and copy_to_mode_reg to load
into registers instead of using gen_rtx_SET and emit_insn fixes the garbage
movabsq instructions. I was going to ask why, but I su
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881
--- Comment #67 from Julian Waters ---
Command line used in compiling the reproducer: xgcc -O2 -S -std=c11 -pedantic
-Wpedantic tls.c
The thing that has me puzzled is that the main differences between both patches
are in the load of the primary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881
--- Comment #66 from Eric Botcazou ---
> That's gonna be a problem, sigh. The only noteworthy difference I can see
> between the 2 patches that is related to the secrel32 unspec is one of the
> GET_CODE == SYMBOL_REF is enclosed in brackets. Unle
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881
--- Comment #65 from Eric Botcazou ---
> Just tried it again, it emits broken assembly on both master and gcc 14 with
> the "Latest TLS" patch
What command line do you use to compile the minimal reproducer?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881
--- Comment #64 from Julian Waters ---
Just tried it again, it emits broken assembly on both master and gcc 14 with
the "Latest TLS" patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881
--- Comment #63 from Julian Waters ---
(I know the predicates have been brought up as a potential cause for this, but
if it cannot be replicated with the candidate patch the problem may lie
elsewhere)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881
--- Comment #62 from Julian Waters ---
That's gonna be a problem, sigh. The only noteworthy difference I can see
between the 2 patches that is related to the secrel32 unspec is one of the
GET_CODE == SYMBOL_REF is enclosed in brackets. Unless thi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881
--- Comment #61 from Eric Botcazou ---
> Just a heads up, the minimal reproducer seems to be getting garbage movabsq
> instructions emitted again with the first stage gcc in the bootstrap phase
I cannot reproduce on the mainline though.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881
--- Comment #60 from Uroš Bizjak ---
(In reply to Uroš Bizjak from comment #59)
> (In reply to Julian Waters from comment #57)
> > Just a heads up, the minimal reproducer seems to be getting garbage movabsq
> > instructions emitted again with the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881
--- Comment #59 from Uroš Bizjak ---
(In reply to Julian Waters from comment #57)
> Just a heads up, the minimal reproducer seems to be getting garbage movabsq
> instructions emitted again with the first stage gcc in the bootstrap phase
You prob
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881
Julian Waters changed:
What|Removed |Added
Attachment #59319|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881
--- Comment #57 from Julian Waters ---
Just a heads up, the minimal reproducer seems to be getting garbage movabsq
instructions emitted again with the first stage gcc in the bootstrap phase
.file "tls.c"
.text
.section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881
--- Comment #56 from Julian Waters ---
Ah, I see. I had been under the impression that gcc would see the parallel and
realize that the 2 loads could be done at the same time. Since it can see that
without the parallel anyway, and doing so allows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881
Julian Waters changed:
What|Removed |Added
Attachment #59318|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881
--- Comment #54 from Uroš Bizjak ---
(In reply to Julian Waters from comment #51)
> Created attachment 59318 [details]
> Attempt to parallelize the load from gs/fs and load of _tls_index
>
> I've written a slightly different version of the patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881
--- Comment #53 from Julian Waters ---
Alright, will remove the DECL_P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881
--- Comment #52 from Eric Botcazou ---
> - Similarly, the !DECL_P was said to not be required, but upon closer
> examination, the ELF select_section seems to do that, so I've left it in
> since it does look like it is used for some purpose
No, i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881
--- Comment #51 from Julian Waters ---
Created attachment 59318
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59318&action=edit
Attempt to parallelize the load from gs/fs and load of _tls_index
I've written a slightly different version of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881
--- Comment #50 from Eric Botcazou ---
> Please note that RIP-relative addresses are one byte shorter than absolute
> addresses and are interchangeable on x86_64 Linux. If this is also true on
> Windows (UNSPEC_PCREL was introduced for PE linkers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881
--- Comment #49 from LIU Hao ---
On Windows x64 almost all symbols in the flat address space are to be
referenced by RIP-relative addressing. I don't know whether things would work
otherwise.
This correspond to GCC's `-mcmodel=medium` and Clang'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881
--- Comment #48 from Uroš Bizjak ---
Comment on attachment 59315
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59315
Candidate patch
>+static rtx
>+ix86_tls_index (void)
>+{
>+ if (!ix86_tls_index_symbol)
>+ix86_tls_index_symbol = ge
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881
Eric Botcazou changed:
What|Removed |Added
Attachment #59307|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881
--- Comment #46 from Eric Botcazou ---
> Note that there is no indirection on the offset for TARGET_WIN32_TLS so it's
> similar to TLS_MODEL_LOCAL_EXEC rather than to TLS_MODEL_INITIAL_EXEC.
It's more of a TLS_MODEL_LOCAL_DYNAMIC model in the en
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881
--- Comment #45 from Eric Botcazou ---
> c) Emit complete TLS sequence in legitimize_tls_address (i386.cc). Please
> see TLS_MODEL_INITIAL_EXEC part for your case.
Note that there is no indirection on the offset for TARGET_WIN32_TLS so it's
simi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881
--- Comment #44 from Eric Botcazou ---
> Multi insn can be used as an interim solution, but please use modern
> approach to create TLS sequences. All infrastructure is already there.
OK, thanks for the detailed instructions.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881
Eric Botcazou changed:
What|Removed |Added
Attachment #59300|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881
Sam James changed:
What|Removed |Added
CC||sjames at gcc dot gnu.org
--- Comment #42 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881
--- Comment #41 from Uroš Bizjak ---
(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 c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881
Eric Botcazou changed:
What|Removed |Added
Attachment #59298|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881
--- Comment #39 from Eric Botcazou ---
Created attachment 59305
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59305&action=edit
WI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881
--- Comment #38 from Eric Botcazou ---
It's the legitimate_pic_operand_p hunk that I dropped earlier...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881
--- Comment #37 from Eric Botcazou ---
Created attachment 59304
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59304&action=edit
Minimal reproducer
To be compiled with -O:
team.c: In function 'gomp_team_start':
team.c:22:1: error: unrecog
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881
--- Comment #36 from Julian Waters ---
No luck in creating a reproducer or even figuring out why the plus is happening
directly on the UNSPEC_SECREL32 unfortunately. There's no hint as to why this
is happening at all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881
--- Comment #35 from Julian Waters ---
Created attachment 59300
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59300&action=edit
gcc 14 version, broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881
--- Comment #34 from Julian Waters ---
(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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881
Eric Botcazou changed:
What|Removed |Added
Attachment #59295|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881
--- Comment #32 from Eric Botcazou ---
> 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 p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881
--- Comment #31 from Julian Waters ---
(In reply to Eric Botcazou from comment #30)
> AFAICT the last missing piece is the configure check for the linker.
It's a bit of a shame I couldn't figure out how to make the zero extend
approach work corr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881
Eric Botcazou changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881
Julian Waters changed:
What|Removed |Added
Attachment #59290|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881
--- Comment #28 from LIU Hao ---
(In reply to Julian Waters from comment #27)
> I think I remember clang using __tls_index instead of _tls_index for 32 bit
> as well, but that's the only difference I remember. On another note, Cygwin
Yes, you ar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881
--- Comment #27 from Julian Waters ---
X(In reply to LIU Hao from comment #26)
> Comment on attachment 59290 [details]
> Newer patch for TLS support, incomplete
>
> > + "mov{l}\t{_tls_index(%%rip), %k0|%k0, DWORD PTR
> > [rip+_tls_index]}\;mov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881
--- Comment #26 from LIU Hao ---
Comment on attachment 59290
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59290
Newer patch for TLS support, incomplete
> + "mov{l}\t{_tls_index(%%rip), %k0|%k0, DWORD PTR
> [rip+_tls_index]}\;mov{q}\t{%
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881
--- Comment #25 from Julian Waters ---
Created attachment 59290
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59290&action=edit
Newer patch for TLS support, incomplete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881
--- Comment #24 from Julian Waters ---
Thanks for the patch, I've been looking through it these past few days. While
the simpler parts of it I can manage, I'm struggling terribly with
understanding the RTL shifting code in legitimize_tls_address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881
--- Comment #23 from Alexandre Pereira Nunes
---
Created attachment 58642
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58642&action=edit
My latest gcc tls support patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881
--- Comment #22 from Alexandre Pereira Nunes
---
(In reply to Julian Waters from comment #19)
>
> Alexandre, how's your progress on Windows TLS going? Could we collaborate to
> get this into gcc somehow?
Hi Julian,
I used to manage a collect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881
Andrew Pinski changed:
What|Removed |Added
Known to fail||14.1.0, 15.0
--- Comment #21 from Andrew
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881
--- Comment #20 from Julian Waters ---
Could the version for this be bumped to either 14 or 15 too? Thanks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881
Julian Waters changed:
What|Removed |Added
CC||tanksherman27 at gmail dot com
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881
Alexandre Pereira Nunes changed:
What|Removed |Added
CC||alexandre.nunes at gmail dot
c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881
Richard Biener changed:
What|Removed |Added
Target Milestone|7.5 |---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881
Richard Biener changed:
What|Removed |Added
Target Milestone|7.4 |7.5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881
Richard Biener changed:
What|Removed |Added
Target Milestone|7.3 |7.4
--- Comment #17 from Richard Biener
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881
Daniel Starke changed:
What|Removed |Added
Known to work|5.3.0 |
--- Comment #16 from Daniel Starke ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881
Jakub Jelinek changed:
What|Removed |Added
Summary|[7/8 Regression] null |Implement Windows native
84 matches
Mail list logo
