> 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
14 matches
Mail list logo
