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/pl
select_section): Select proper
> TLS section.
> > (mingw_pe_unique_section): Handle TLS section.
> > * config/mingw/winnt.h (mingw_pe_select_section): Declare.
> > * configure: Regenerate.
> > * configure.ac: New check for broken linker thread
rom fceb5113f33a950048d57a1ecde39084eaa09ffe Mon Sep 17 00:00:00 2001
From: Julian Waters
Date: Tue, 15 Oct 2024 20:56:22 +0800
Subject: [PATCH] Implement Windows TLS
Signed-off-by: Julian Waters
---
gcc/config/i386/i386.cc | 61 ++-
gcc/config/i386/i38
rom 05d4491d862a16426f2a0986e7f3598714615f93 Mon Sep 17 00:00:00 2001
From: Julian Waters
Date: Tue, 15 Oct 2024 20:56:22 +0800
Subject: [PATCH] Implement Windows TLS
Signed-off-by: Julian Waters
---
gcc/config/i386/i386.cc | 61 ++-
gcc/config/i386/i386.h| 1 +
gcc/config/i
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
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 misse
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
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
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
HI Jason,
I was hoping to have -Wno-invalid-noreturn=explicit directly disable
explicit noreturn warnings for instance, following the style of the
-Wno-attributes=vendor:: option, while the pattern in
-fstrong-eval-order seems to be that of using RejectNegative and
handling each specified positive
>From fe1b4d5747e05101410b6bb6db9430362e3977d9 Mon Sep 17 00:00:00 2001
From: Julian Waters
Date: Fri, 19 Jul 2024 11:22:38 +0800
Subject: [PATCH] Introduce the -Winvalid-noreturn flag from clang with extra
tuneability
Currently, gcc warns about noreturn marked functions that return both
explici
other languages too (See tree-cfg.cc). Here’s the current
> version of the patch, hope it’s good to go this time
>
>
>
> best regards,
>
> Julian
>
>
>
> From fe1b4d5747e05101410b6bb6db9430362e3977d9 Mon Sep 17 00:00:00 2001
>
> From: Julian Waters
>
> D
form was used in a bool somewhere? If I can do that
somehow, and then access the bool at the callsites where it is
required, I can figure out the rest on my own
best regards,
Julian
On Tue, Jun 11, 2024 at 10:26 AM Jason Merrill wrote:
>
> On 6/10/24 03:13, Julian Waters wrote:
&
Hi Jason,
Thanks for the reply. I'm a little bit overwhelmed with university at
the moment, would it be ok if I delay implementing this a little bit?
best regards,
Julian
On Tue, Jun 4, 2024 at 1:04 AM Jason Merrill wrote:
>
> On 6/1/24 11:31, Julian Waters wrote:
> > Hi Jaso
on 2 different OPT_ entries?
best regards,
Julian
On Sat, Jun 1, 2024 at 4:57 AM Jason Merrill wrote:
>
> On 5/29/24 09:58, Julian Waters wrote:
> > Currently, gcc warns about noreturn marked functions that return both
> > explicitly and implicitly, with no way to turn this
Currently, gcc warns about noreturn marked functions that return both
explicitly and implicitly, with no way to turn this warning off. clang does
have an option for these classes of warnings, -Winvalid-noreturn. However, we
can do better. Instead of just having 1 option that switches the warning
Hi all,
Please review a trivial change that defines which threading model is
used on Windows, so applications can check it. This is also useful for
system headers, since some headers should be switched off if pthread
is the threading model (Currently they are included unconditionally on
Windows).
g with GCC; see the file COPYING3. If not see
#else
#define SHARED_LIBGCC_SPEC " -lgcc "
#endif
-#if TARGET_USING_MCFGTHREAD
+#ifdef TARGET_USING_MCFGTHREAD
#define MCFGTHREAD_SPEC " -lmcfgthread -lkernel32 -lntdll "
#else
#define MCFGTHREAD_SPEC ""
--
2.
Hi all,
Please review a trivial change that defines which threading model is
used on Windows, so applications can check it. This is also useful for
system headers, since some headers should be switched off if pthread
is the threading model (Currently they are included unconditionally on
Windows).
On Wed, Nov 22, 2023 at 4:28 AM Xi Ruoyao wrote:
>
> On Mon, 2023-11-20 at 16:35 +0800, Julian Waters wrote:
> > Hi all, I'd like to ping the following patch
> >
> > https://gcc.gnu.org/pipermail/gcc-patches/2023-November/636924.html
>
> You posted the patch Fri
Hi all, I'd like to ping the following patch
https://gcc.gnu.org/pipermail/gcc-patches/2023-November/636924.html
best regards,
Julian
Resent as plain text to appear on the patch tracker
Hi all,
This is the beginning of a patch to introduce the extended attribute
for asm declarations proposed in
https://gcc.gnu.org/pipermail/gcc-patches/2023-November/636563.html. I
will need some reviewer help in implementing this patch, as I am
Hi all,
This is the beginning of a patch to introduce the extended attribute
for asm declarations proposed in
https://gcc.gnu.org/pipermail/gcc-patches/2023-November/636563.html. I
will need some reviewer help in implementing this patch, as I am not
very familiar with gcc's internals.
The attribu
I propose a new attribute for C++, labelled gnu::extended. This attribute
is for asm declarations, and the attribute marks them as extended asm. This
attribute shall contain all of the features of existing extended asm, but
also have additional features, described below.
gnu::extended(OutputOperan
Pinging again, this is needed for the Windows Java VM to compile under gcc
On Wed, Sep 13, 2023 at 11:09 AM Julian Waters
wrote:
> Second desperate ping for patch
> https://gcc.gnu.org/pipermail/gcc-patches/2023-August/627913.html
>
Second desperate ping for patch
https://gcc.gnu.org/pipermail/gcc-patches/2023-August/627913.html
Hi all, this is a gentle ping for the following patch:
https://gcc.gnu.org/pipermail/gcc-patches/2023-August/627913.html
Please review the second version of a patch to add clang's invalid-noreturn
flag to toggle noreturn warnings. This patch keeps the old behaviour of
always warning on every noreturn violation, but unlike clang also adds an
extra layer of fine tuning by turning invalid-noreturn into a warning with
l
Anyone?
On Sun, Aug 13, 2023 at 4:48 PM Julian Waters
wrote:
> Please review a patch to add clang's invalid-noreturn flag to toggle
> noreturn warnings. This patch keeps the old behaviour of always warning on
> every noreturn violation, but unlike clang also adds an extra
Please review a patch to add clang's invalid-noreturn flag to toggle
noreturn warnings. This patch keeps the old behaviour of always warning on
every noreturn violation, but unlike clang also adds an extra layer of fine
tuning by turning invalid-noreturn into a warning with levels, where level
1 w
Hi all,
I've revised the change to be much neater
>From 480954bc7d2b24e5d19a98260a2be0b49e112c42 Mon Sep 17 00:00:00 2001
From: TheShermanTanker
Date: Wed, 28 Jun 2023 19:11:34 +0800
Subject: [PATCH] asm not using extended syntax should always be volatile
---
gcc/cp/parser.cc | 2 +-
1 file ch
gcc's documentatation mentions that all basic asm blocks are always volatile,
yet the parser fails to account for this by only ever setting
volatile_p to true
if the volatile qualifier is found. This patch fixes this by adding a
special case check for extended_p before finish_asm_stmt is called
>F
37 matches
Mail list logo
