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
--- 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 #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 #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 #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
Julian Waters changed:
What|Removed |Added
Attachment #59322|0 |1
is obsolete|
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 #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
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 #53 from Julian Waters ---
Alright, will remove the DECL_P
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 #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
--- 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
Julian Waters changed:
What|Removed |Added
Attachment #59290|0 |1
is obsolete|
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 #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 #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=115300
--- Comment #2 from Julian Waters ---
Understood, will also report this to binutils
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115300
Bug ID: 115300
Summary: gcc 14 cannot compile itself on Windows when
bootstrap-lto is specified
Product: gcc
Version: 14.1.1
Status: UNCONFIRMED
Severity: norm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111654
--- Comment #7 from Julian Waters ---
I recently stumbled upon -Wno-attributes, which can apparently take a parameter
like -Wno-attributes=vendor:: and I think that's appropriate for this
particular situation. How does -Wno-invalid-noreturn,
-Wn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105645
--- Comment #5 from Julian Waters ---
Hopefully that was enough to draw more attention to this bug. Any ideas why
this might be happening?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115230
Bug ID: 115230
Summary: -fvisibility=hidden does not hide Template
Specializations from being exported
Product: gcc
Version: 14.1.1
Status: UNCONFIRMED
Severit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105645
Julian Waters changed:
What|Removed |Added
CC||tanksherman27 at gmail dot com
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106103
Julian Waters changed:
What|Removed |Added
CC||tanksherman27 at gmail dot com
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113875
--- Comment #3 from Julian Waters ---
Compiler configure options as requested by the gcc bug site:
$ gcc -v
Using built-in specs.
COLLECT_GCC=C:\msys64\ucrt64\bin\gcc.exe
COLLECT_LTO_WRAPPER=C:/msys64/ucrt64/lib/gcc/x86_64-w64-mingw32/13.2.0/lto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113875
Bug ID: 113875
Summary: g++ crash with Internal Compiler Error when compiling
HotSpot for Windows with -Os and -flto
Product: gcc
Version: unknown
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113760
Bug ID: 113760
Summary: gcc rejects valid empty-declaration in pedantic mode
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105576
Julian Waters changed:
What|Removed |Added
CC||tanksherman27 at gmail dot com
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110734
--- Comment #20 from Julian Waters ---
cppreference at least seems to indicate it retroactively applies to C++11
https://en.cppreference.com/w/cpp/language/asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110734
--- Comment #18 from Julian Waters ---
Oops, I meant warning: 'no_reorder' attribute ignored [-Wattributes] in my
above comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110734
--- Comment #17 from Julian Waters ---
Looking at the source of the C++ parser it doesn't seem like asm (""); is
considered a statement but rather is correctly parsed as a declaration, see
cp_parser_block_declaration and cp_parser_declaration_st
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110734
--- Comment #12 from Julian Waters ---
Will do, will save the new attribute for gcc 15 and just fix the attribute
specifier sequence here
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110734
Julian Waters changed:
What|Removed |Added
Attachment #56717|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110734
--- Comment #7 from Julian Waters ---
I have a new attribute proposed for asm declarations that fixes this issue, but
I need help from reviews to proceed with fixing up the patch properly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110734
Julian Waters changed:
What|Removed |Added
CC||tanksherman27 at gmail dot com
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110734
--- Comment #5 from Julian Waters ---
Note: Trying this with a top level asm gives me:
$ g++ -O3 -flto=auto -std=c++14 -pedantic -Wpedantic -fno-omit-frame-pointer
exceptions.cpp
exceptions.cpp:8:1: error: expected unqualified-id before 'asm'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86286
Julian Waters changed:
What|Removed |Added
CC||tanksherman27 at gmail dot com
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111654
--- Comment #6 from Julian Waters ---
Sorry for the late reply, I was busy with certain things
Are we going with numeric invalid-noreturn or explicit-noreturn +
implicit-noreturn? I'm not to sure how to implement the latter, if we're going
with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111654
--- Comment #2 from Julian Waters ---
(In reply to Manuel López-Ibáñez from comment #1)
> (In reply to Julian Waters from comment #0)
> > Created attachment 56022 [details]
> > Patch to add invalid-noreturn to gcc
>
> Patches should be submitte
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44209
Julian Waters changed:
What|Removed |Added
CC||tanksherman27 at gmail dot com
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111654
Bug ID: 111654
Summary: Introduce clang's invalid-noreturn warning
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: dr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95130
--- Comment #19 from Julian Waters ---
(In reply to Tomas Kalibera from comment #17)
> (In reply to Tomas Kalibera from comment #16)
> > (In reply to Julian Waters from comment #15)
> > > It seems like the patch also doesn't fix the strftime case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95130
--- Comment #18 from Julian Waters ---
That's great news! With regards to this patch, I'm fairly certain you have to
proactively send it to gcc-patches mailing list for it to be merged; No gcc
committer has the time to look for this issue and com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95130
Julian Waters changed:
What|Removed |Added
CC||tanksherman27 at gmail dot com
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110734
--- Comment #4 from Julian Waters ---
My mistake, I forgot to mention that it was indeed inside a function body. I
can't seem to figure out what in parser.cc is causing this bug, anything on
your end?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110734
--- Comment #2 from Julian Waters ---
Is this accurately described as an enhancement? This is erroneous behaviour
with something that is already meant to be a feature in gcc (applying
attributes to statements, as seen inside parser.cc), not a fe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110734
Julian Waters changed:
What|Removed |Added
Version|unknown |13.1.1
--- Comment #1 from Julian Water
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110734
Bug ID: 110734
Summary: Attributes cannot be applied to asm statements
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component
62 matches
Mail list logo
