https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94615
Florian Weimer changed:
What|Removed |Added
CC||fw at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878
--- Comment #21 from Florian Weimer ---
(In reply to Avi Kivity from comment #20)
> Note that clang generates cmpxchg16b when the conditions are ripe:
>
> https://godbolt.org/z/j9Whgh
I believe this is a different, C++-specific issue. The C fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878
--- Comment #23 from Florian Weimer ---
Ahh, I think this bug here is specific to __uint128 (with the C front end at
least)
The C translation of the C++ reproducer from comment 20:
struct a
{
long _Alignas(16) x;
long y;
};
_Bool
cmpxchg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878
--- Comment #26 from Florian Weimer ---
(In reply to Florian Weimer from comment #23)
> Ahh, I think this bug here is specific to __uint128 (with the C front end at
> least)
>
> The C translation of the C++ reproducer from comment 20:
>
> struc
||fw at gcc dot gnu.org
Status|UNCONFIRMED |RESOLVED
See Also||https://sourceware.org/bugz
||illa/show_bug.cgi?id=4792
--- Comment #4 from Florian Weimer ---
This
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95989
Florian Weimer changed:
What|Removed |Added
CC||fw at gcc dot gnu.org
--- Comment #9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95989
--- Comment #11 from Florian Weimer ---
It turns out that libc.a did not contain pthread_self until glibc 2.27. The
symbol was only present in libc.so.6 (as a weird forwarder, for compatibility
with long-defunct LinuxThreads).
This means there
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96200
Florian Weimer changed:
What|Removed |Added
CC||fw at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96284
--- Comment #7 from Florian Weimer ---
(In reply to David Brown from comment #6)
> I'm not bothered about my own code - I have makefiles with the relevant
> options set in case I make mistakes. My hope is for gcc to be able to have
> stricter wa
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: fw at gcc dot gnu.org
Target Milestone: ---
I do not know how many warnings it would generate to warn for code like this
(if i is not known to be non
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96460
--- Comment #2 from Florian Weimer ---
(In reply to Richard Biener from comment #1)
> It's perfectly valid code ... guess similar to -Wconversion though.
If the modulo result is never negative, it's not *perfectly* valid because GCC
has to add i
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: fw at gcc dot gnu.org
Target Milestone: ---
enum E : bool { One, Two };
int
f1 (int x)
{
return (E) x;
}
The conversion must first be to type bool
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: fw at gcc dot gnu.org
Target Milestone: ---
I believe this needs to be accepted:
enum E : bool { One, Two, Three };
See <http://eel.is/c++draft/dcl.enum#5>, “If the underlying type is fixed, th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96500
Florian Weimer changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96460
--- Comment #4 from Florian Weimer ---
(In reply to Eric Gallager from comment #3)
> There already is a warning from -Wsign-conversion for it:
It's for the conversion, not the modulo. My hypothesis is that for the modulo,
the warning is much mor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96832
Florian Weimer changed:
What|Removed |Added
CC||fw at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96200
--- Comment #6 from Florian Weimer ---
(In reply to H.J. Lu from comment #4)
> On Linux/i386 and Linux/x86-64, thread pointer access is done via syscall.
> On Linux/x86-64, __builtin_thread_pointer and __builtin_set_thread_pointer
> may be implem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96200
--- Comment #8 from Florian Weimer ---
(In reply to H.J. Lu from comment #7)
> Give that the tcb field is setup by the C run-time on Linux/x86, should
> it be provided by a run-time header file?
Yes, it seems reasonable to me. Ideally, it would
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: fw at gcc dot gnu.org
Target Milestone: ---
This code example produces a warning:
#include
struct buffer {
char string[10];
};
int
f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96951
--- Comment #2 from Florian Weimer ---
Then the warning should recommend to use memccpy, perhaps?
if (memccpy (p->string, s, '\0', sizeof (p->string)) == NULL)
return -1;
return 0;
--
Red Hat GmbH, https://de.redhat.com/ , Registered s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96952
Florian Weimer changed:
What|Removed |Added
CC||fw at gcc dot gnu.org
See
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96951
--- Comment #4 from Florian Weimer ---
Thanks.
Checking for the null byte at the end (as in comment 0) currently seems the
most convenient way. Writing those additional null bytes is not entirely free.
As an industry standard, the strlcpy functi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40770
Florian Weimer changed:
What|Removed |Added
CC||fw at gcc dot gnu.org
--- Comment #16
: diagnostic
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: fw at gcc dot gnu.org
Target Milestone: ---
Created attachment 47160
--> https://gcc.gnu.org/bugzilla/attachment.cgi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92337
--- Comment #1 from Florian Weimer ---
Note: 31-bit s390 and 32-bit powerpc also match the triggering conditions, and
glibc fails to build there, too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92337
Florian Weimer changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92039
--- Comment #6 from Florian Weimer ---
*** Bug 92337 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456
Bug 56456 depends on bug 92337, which changed state.
Bug 92337 Summary: Bogus -Werror=array-bounds below array bounds warning in
glibc stdlib/strtod_l.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92337
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92425
Florian Weimer changed:
What|Removed |Added
CC||fw at gcc dot gnu.org
--- Comment #3
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: fw at gcc dot gnu.org
Target Milestone: ---
Target: nios2-elf
Consider this test case:
enum { size = 100 };
struct flexible
{
int length;
int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91628
--- Comment #16 from Florian Weimer ---
(In reply to rdapp from comment #15)
> Any feedback on the two options I proposed? Is the .S file variant (I posted
> last) ok?
I'd prefer the patch from comment 13, but I'm not a GCC developer. You shoul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85678
--- Comment #13 from Florian Weimer ---
(In reply to Wilco from comment #12)
> Giving errors on old-style code by default sounds like a good idea. We could
> add -std=legacy similar to Fortran to support building old K&R code (and
> that would en
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838
--- Comment #93 from Florian Weimer ---
(In reply to Viktor Ostashevskyi from comment #92)
> I've tried to run some old binaries yesterday (StarOffice 5.1, get it from
> archive.org) and hit this bug.
>
> What are possible workarounds?
You need
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92372
Florian Weimer changed:
What|Removed |Added
CC||fw at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92372
--- Comment #6 from Florian Weimer ---
Created attachment 47686
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47686&action=edit
Preprocessed C++ sources from graph-tool
(In reply to Martin Liška from comment #5)
> (In reply to Florian Wei
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80005
--- Comment #7 from Florian Weimer ---
(In reply to Nathan Sidwell from comment #6)
> Reopening. Sadly my fear turned out to be true. real code out there
> presumes __has_include__ (with the trailing underbars) is how to get at this
> feature.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80005
--- Comment #8 from Florian Weimer ---
(And now the glibc stable release branches are fixed as well. Oops.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80005
--- Comment #10 from Florian Weimer ---
It only affects RISC-V, and the use is not in an installed header, so I think
the glibc case is rather harmless.
(But that's only because I watched out for this particular issue and requested
changes from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70024
Florian Weimer changed:
What|Removed |Added
CC||fw at gcc dot gnu.org
--- Comment #10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19351
--- Comment #27 from Florian Weimer 2012-08-20 21:13:29
UTC ---
Author: fw
Date: Mon Aug 20 21:13:23 2012
New Revision: 190546
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=190546
Log:
Fix PR C++/19351: integer overflow in operator new[]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19351
Florian Weimer changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54411
Bug #: 54411
Summary: libiberty: objalloc_alloc integer overflows
(CVE-2012-3509)
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54411
Florian Weimer changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54411
--- Comment #3 from Florian Weimer 2012-08-29 19:18:58
UTC ---
(In reply to comment #2)
> You do realise that pretty much nothing in the toolchain checks for
> overflows in calculating allocation sizes?
bfd_alloc2 (bfd's XNEWVEC variant) contai
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54411
--- Comment #5 from Florian Weimer 2012-09-18 08:34:12
UTC ---
Author: fw
Date: Tue Sep 18 08:34:05 2012
New Revision: 191413
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=191413
Log:
PR other/54411: integer overflow in objalloc_alloc
2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19351
Florian Weimer changed:
What|Removed |Added
CC||fw at gcc dot gnu.org
--- Comment #22
Component: ada
Assignee: unassigned at gcc dot gnu.org
Reporter: fw at gcc dot gnu.org
Host: amd64-debian-linux-gnu
Target: amd64-debian-linux-gnu
Build: amd64-debian-linux-gnu
Created attachment 30507
--> http://gcc.gnu.org/bugzi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53972
Bug #: 53972
Summary: array constant expression expression not valid as
template argument
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
|RESOLVED
CC||fw at gcc dot gnu.org
Resolution||INVALID
--- Comment #4 from Florian Weimer 2012-03-28 05:38:56
UTC ---
Some platforms (such as VMS) support $ in identifiers, similar to _. It seems
that
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57902
Florian Weimer changed:
What|Removed |Added
Attachment #30507|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88560
Florian Weimer changed:
What|Removed |Added
CC||fw at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88576
Florian Weimer changed:
What|Removed |Added
CC||fw at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48200
--- Comment #28 from Florian Weimer ---
It seems that using symbol aliases (via .symver) in conjunction with LTO and a
version script which has a local: * clause causes the LTO plugin to assume that
the aliased function definitions are not (exter
: UNCONFIRMED
Keywords: documentation
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: fw at gcc dot gnu.org
Target Milestone: ---
The documentation says this:
'cold'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88793
--- Comment #2 from Florian Weimer ---
(In reply to Alexander Monakov from comment #1)
> (In reply to Florian Weimer from comment #0)
> > However, optimizing for size is a very big hammer and causes substantial
> > performance issues on i386 and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88793
Florian Weimer changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: fw at gcc dot gnu.org
Target Milestone: ---
Target: powerpc64le-redhat-linux-gnu
With gcc-8.2.1-6.fc28.ppc64le, this code
void
f (double d, char *target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88892
Florian Weimer changed:
What|Removed |Added
Keywords||wrong-code
Summary|Double-to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88892
--- Comment #3 from Florian Weimer ---
Started with r253210. I don't think the new pattern is used in this case, so
maybe this is a pre-existing latent bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88892
--- Comment #4 from Florian Weimer ---
Eh, forget what I wrote. The pattern *is* used. r253210 looks definitely to
blame.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88892
--- Comment #6 from Florian Weimer ---
(In reply to Eric Gallager from comment #5)
> This is one of the reasons -Wfloat-conversion exists:
>
> $ gcc -c -Wall -Wextra -Wfloat-conversion -Wdouble-promotion
> -Wunsuffixed-float-constants -pedantic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88993
--- Comment #4 from Florian Weimer ---
(In reply to Jakub Jelinek from comment #3)
> Rather than warning about this the bugs should be fixed, there is no reason
> why glibc needs to malloc memory for these cases.
I completely agree. The warning
++
Assignee: unassigned at gcc dot gnu.org
Reporter: fw at gcc dot gnu.org
Target Milestone: ---
Target: armv7l-unknown-linux-gnueabihf
In glibc, we have a test, nptl/tst-thread-exit-clobber, that attempts to verify
if registers are properly restored by unwinding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
--- Comment #4 from Florian Weimer ---
So I'm not really an Arm person or a GCC person, but doesn't the personality
routine call the landing pad, as identified by the LDSA? And then that ends
with a call to __cxa_end_cleanup, which is clear a no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
--- Comment #6 from Florian Weimer ---
Okay, please assume that __gxx_personality_v0 is a red herring. Apparently,
there is unwinding information for VFP registers, too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
--- Comment #17 from Florian Weimer ---
(In reply to Ramana Radhakrishnan from comment #15)
> Created attachment 45552 [details]
> new patch.
>
> Testing this and would be grateful for a test run.
I believe the #pragma GCC push_options needs to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
--- Comment #18 from Florian Weimer ---
(In reply to Ramana Radhakrishnan from comment #15)
> Created attachment 45552 [details]
> new patch.
>
> Testing this and would be grateful for a test run.
Is this hunk needed as well, or will the unwind
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
--- Comment #20 from Florian Weimer ---
(In reply to Ramana Radhakrishnan from comment #15)
> Created attachment 45552 [details]
> new patch.
>
> Testing this and would be grateful for a test run.
I can confirm that this patch fixes the glibc t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89142
Florian Weimer changed:
What|Removed |Added
CC||fw at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88917
Florian Weimer changed:
What|Removed |Added
CC||hjl.tools at gmail dot com
--- Comment
ty: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: fw at gcc dot gnu.org
Target Milestone: ---
Target: armv7l-unknown-linux-gnueabihf
This example:
#define C "nor"
void
f (int *x)
{
asm volatile ("
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60790
--- Comment #11 from Florian Weimer ---
Author: fw
Date: Wed May 23 11:13:05 2018
New Revision: 260603
URL: https://gcc.gnu.org/viewcvs?rev=260603&root=gcc&view=rev
Log:
x86: libatomic: Do not assume ELF constructors run before IFUNC resolvers
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: fw at gcc dot gnu.org
Target Milestone: ---
Compile this with “gcc -O2” on a 64-bit platform:
#define
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: fw at gcc dot gnu.org
Target Milestone: ---
Target: i386-*-linux-gnu
Consider this test case:
#include
int f1 (__m64 *);
int
f2 (void
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85939
--- Comment #3 from Florian Weimer ---
(In reply to Uroš Bizjak from comment #1)
> Please also use -mincoming-stack-boundary=2 to tell the compiler about
> possible incoming stack (mis)alignment.
This does change the result; alignment is perform
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85939
--- Comment #4 from Florian Weimer ---
Unfortunately, -mincoming-stack-boundary=2 makes -mstackrealign useless because
now any leaf function realigns the stack.
The usual effect (no matter what the documentation says) is that -mstackrealign
pref
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85939
--- Comment #7 from Florian Weimer ---
(In reply to H.J. Lu from comment #6)
> I believe __m64 is 4-byte aligned.
https://github.com/hjl-tools/x86-psABI/blob/801352a1470ae8542a3a1f83fb2abda35feab075/low-level-sys-info.tex#L108
says alignment is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85929
--- Comment #3 from Florian Weimer ---
(In reply to Richard Biener from comment #2)
> That is,
> for > UINT_MAX # of elements the code will infintely loop AFAICS (but it will
> not access elements out of bounds).
The way I read the original sour
Keywords: wrong-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: fw at gcc dot gnu.org
Target Milestone: ---
#include
void f1 (void *, int);
register int edi __asm__ (&quo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86236
Florian Weimer changed:
What|Removed |Added
Summary|-mstackrealign prologue |Stack alignment prologue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86275
--- Comment #5 from Florian Weimer ---
(In reply to Jakub Jelinek from comment #4)
> The question is if this is a problem with recent kernel headers and any
> glibc, or e.g. both latest glibc and 2.27; if yes, then we probably need
> some workaro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86275
--- Comment #7 from Florian Weimer ---
(In reply to Milhouse from comment #6)
> Is there any other information I can add, or anything I can test (patches
> etc.) that might help clarify/determine/narrow down where this problem lies?
I posted a g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86275
Florian Weimer changed:
What|Removed |Added
Status|NEW |RESOLVED
See Also|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91174
Florian Weimer changed:
What|Removed |Added
CC||fw at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91174
--- Comment #3 from Florian Weimer ---
(In reply to Antony Polukhin from comment #2)
> (In reply to Florian Weimer from comment #1)
> > For which ABI do you propose the change? It's not correct for GNU/Linux:
>
> As far as I understand the prop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91174
Florian Weimer changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91227
Florian Weimer changed:
What|Removed |Added
CC||fw at gcc dot gnu.org
--- Comment #11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91227
--- Comment #13 from Florian Weimer ---
(In reply to Marc Glisse from comment #12)
> (In reply to Florian Weimer from comment #11)
> > GCC on ELF provides defined address ordering for separate objects via linker
> > ordering and section attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91092
--- Comment #14 from Florian Weimer ---
(In reply to Vincent Lefèvre from comment #13)
> By "implicit function declarations", does this include K&R style
> declarations?
No, there is nothing implicit about them.
> I've found out a few days ago
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91092
--- Comment #16 from Florian Weimer ---
(In reply to Vincent Lefèvre from comment #15)
> (In reply to Florian Weimer from comment #14)
> > (In reply to Vincent Lefèvre from comment #13)
> > > By "implicit function declarations", does this include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91628
Florian Weimer changed:
What|Removed |Added
CC||fw at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91481
--- Comment #18 from Florian Weimer ---
I'm going to request a CVE ID for this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91628
--- Comment #4 from Florian Weimer ---
(In reply to Iain Buclaw from comment #3)
> The use of the function is for the garbage collector to be able to scan
> native TLS data.
>
> The logic of said function pretty much matches what the glibc macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91628
--- Comment #6 from Florian Weimer ---
__tls_get_offset looks like this:
__tls_get_offset:
la %r2,0(%r2,%r12)
jg __tls_get_addr
The caller should be able to prepare for the la instruction, by subtracting r12
from r2.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91628
--- Comment #8 from Florian Weimer ---
(In reply to rdapp from comment #7)
> Created attachment 46817 [details]
> Proposed patch using __tls_get_offset
>
> I drafted a patch that uses __tls_get_offset instead of the internal symbol
> following F
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91628
--- Comment #10 from Florian Weimer ---
(In reply to rdapp from comment #9)
> I opted for inline assembly to make sure r12 is not changed directly before
> the function call. Do you have an idea to guarantee this in another way?
Wouldn't an out-
: missed-optimization
Severity: enhancement
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: fw at gcc dot gnu.org
Target Milestone: ---
In some cases, it is desirable as an optimization not to save any callee-saved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92086
--- Comment #3 from Florian Weimer ---
It also saves stack space.
I'm not sure if it is prudent to repurpose noreturn+nothrow for this. There
might be existing such functions where people expect to see a full call stack.
Something more explicit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92086
--- Comment #4 from Florian Weimer ---
(In reply to Andrew Pinski from comment #1)
> I dont see this helping code in real life programs. Can you explain where
> you think this could be used?
The thread start routine wrapper in glibc. On x86-64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81842
--- Comment #15 from Florian Weimer ---
This is all very strange.
How have extended makecontext for x86 AVX2/AVX-512 support? The CPU context
needs to be stored somewhere, after all.
I find it difficult to believe that there is no space left a
1 - 100 of 480 matches
Mail list logo
