On 2/20/25 7:16 AM, Julian Waters wrote:
Patch with the amendments to the commit message as requested.
best regards,
Julian
From e8e742b1f809af2c1a9697c31335e184738b258a Mon Sep 17 00:00:00 2001
From: Julian Waters
Date: Tue, 15 Oct 2024 20:56:22 +0800
Subject: [PATCH] Implement Windows TLS
M
Patch with the amendments to the commit message as requested.
best regards,
Julian
>From e8e742b1f809af2c1a9697c31335e184738b258a Mon Sep 17 00:00:00 2001
From: Julian Waters
Date: Tue, 15 Oct 2024 20:56:22 +0800
Subject: [PATCH] Implement Windows TLS
MIME-Version: 1.0
Content-Type: text/plain;
Julian Waters writes:
> Apologies, here is the implementation with regenerated configure this time.
> Do excuse me sending an entirely new mail instead of replying to the previous
> one, I have to do it this way due to a quirk in my email client.
>
> best regards,
> Julian
>
> gcc/ChangeLog:
>
Thanks for the advice, I will apply the suggested changes to the commit
message as soon as possible. I'm assuming the target maintainers in this
case would be the MINGW maintainers, Jonathan Yong and Liu Hao?
best regards,
Julian
On Wed, Feb 19, 2025 at 10:27 PM Sam James wrote:
> Julian Waters
Apologies, here is the implementation with regenerated configure this time. Do
excuse me sending an entirely new mail instead of replying to the previous one,
I have to do it this way due to a quirk in my email client.
best regards,
Julian
gcc/ChangeLog:
* config/i386/i386.cc (ix86_leg
Hi all,
This is a reimplementation of Windows Thread Local Storage, rewritten to
support native thread local access on Windows, which had previous been using
emulated thread local storage mechanisms. Note that due to issues on my end, I
was unable to regenerate configure no matter what I tried.
> Sorry for not being fast enough to rewrite the patch on my end to integrate
> your changes (I'm maintaining this patch for both gcc 14 and master at the
> same time, which is a little complicated), but I appreciate the help :) How
> did you figure out the issue so quickly?
By comparing what happ
I also tried using UNSPEC_PCREL instead of making a new UNSPEC_TLS_WIN32
enumeration, but it unfortunately didn't recognise the resulting RTL.
Perhaps something for another day
On Tue, Oct 8, 2024 at 5:19 PM Eric Botcazou wrote:
> > Thanks for the patch! You certainly worked that out faster than
Sorry for not being fast enough to rewrite the patch on my end to integrate
your changes (I'm maintaining this patch for both gcc 14 and master at the
same time, which is a little complicated), but I appreciate the help :) How
did you figure out the issue so quickly? I was going in circles trying t
Thanks for the patch! You certainly worked that out faster than I could
create a reproducer. It's a bit late for me now, so I'll have to try it out
tomorrow. Note however that in the final patch I will be only doing TLS for
mingw32.h and not cygming.h. The reason for this is that Cygwin likely
cann
> I'm not quite sure what you mean by a testcase, but when compiling gcc
> itself, when libgomp/libgcc (Can't remember which) is being compiled, gcc
> will spit out invalid assembly that looks something like
>
> movabsq $8+__gcov_indirect_call@secrel32, %rax
OK, I can reproduce this at -O0:
_gco
Understood. I will try to reproduce the issue in the meantime as I rewrite
the patch
best regards,
Julian
On Mon, Oct 7, 2024 at 5:07 PM Sam James wrote:
> Julian Waters writes:
>
> > Resending again as I forgot to send it to the list
> >
> >> Sorry, I somehow missed it. :-( Then a configure
Julian Waters writes:
> Resending again as I forgot to send it to the list
>
>> Sorry, I somehow missed it. :-( Then a configure check should be added in
>> the
>> compiler to tell whether the detected linker has the fix or not.
>
>> There are already some specific checks for the PE linker at
Resending again as I forgot to send it to the list
> Sorry, I somehow missed it. :-( Then a configure check should be added
in the
> compiler to tell whether the detected linker has the fix or not.
> There are already some specific checks for the PE linker at
configure.ac:6500,
> although they d
> The linker bug blocking this patch has actually already been fixed, see
> https://github.com/bminor/binutils-gdb/commit/72cd2c70977943054ff784b7278cef
> 5262288f32 for the patch that fixed it (Thanks for the help Jan!).
Sorry, I somehow missed it. :-( Then a configure check should be added in t
Hi Eric,
Thanks for getting back to me, I wasn't actually asking if it was ok (The
ping was poorly worded, sorry), more trying to draw attention to the patch.
The linker bug blocking this patch has actually already been fixed, see
https://github.com/bminor/binutils-gdb/commit/72cd2c70977943054ff78
> Pinging https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662860.html
> as it has been buried under several other patches. Is the patch ok for
> master?
No, you should modify it along the way I suggested privately, and a blocker is
the missing support in the linker AFAICS.
--
Eric Botc
Hi all,
Pinging https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662860.html
as it has been buried under several other patches. Is the patch ok for
master?
best regards,
Julian
Pinging https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662860.html
again and also paging for Jan Hubicka, the x86 expert
best regards,
Julian
Hi all,
Pinging https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662860.html as
it has been buried under several other patches. Any i386 experts here to
help me with the patch and commit it once it has been refined? Is the patch
ok?
best regards,
Julian
Hello everyone,
This patch is an initial implementation of native Thread Local Storage on
Windows, which currently emulates TLS via emutls. This was heavily referenced
from Daniel Green's original work with Windows TLS from a decade ago, so credit
should be attributed to him as well (https://gi
21 matches
Mail list logo
