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=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=95989
Florian Weimer changed:
What|Removed |Added
CC||fw at gcc dot gnu.org
--- Comment #9
||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
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:
>
>
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 #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
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=70024
Florian Weimer changed:
What|Removed |Added
CC||fw at gcc dot gnu.org
--- Comment #10
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=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 #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=92372
--- Comment #6 from Florian Weimer ---
Created attachment 47686
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47686=edit
Preprocessed C++ sources from graph-tool
(In reply to Martin Liška from comment #5)
> (In reply to Florian Weimer
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=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
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 code (and
> that would
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
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=92425
Florian Weimer changed:
What|Removed |Added
CC||fw at gcc dot gnu.org
--- Comment #3
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=92337
Florian Weimer changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
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.
: 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=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
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
: 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=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
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
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 #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
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
Florian Weimer changed:
What|Removed |Added
CC||fw at gcc dot gnu.org
--- Comment #2
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
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 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=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
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=91174
Florian Weimer changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
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
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=91092
--- Comment #9 from Florian Weimer ---
(In reply to Andreas Schwab from comment #8)
> What about cmake, metaconfig, meson, scons, ...
I hope that the more modern things get this correct and encourage more
high-level checks.
I plan to build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91092
--- Comment #7 from Florian Weimer ---
(In reply to Jonathan Wakely from comment #5)
> Would an ugly but pragmatic approach be possible? e.g. if the first line of
> the translation unit is "/* confdefs.h */ then assume GCC is being invoked
> by
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91092
--- Comment #2 from Florian Weimer ---
Current util-linux is an example:
$ ./configure
[…]
checking wchar_t support... yes
[…]
$ ./configure CC="gcc -Werror=implicit-function-declaration"
[…]
configure: WARNING: wchar_t support not found; not
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: fw at gcc dot gnu.org
Target Milestone: ---
Once configure scripts have been cleaned up (and we have verified this for
Fedora and perhaps Debian), c99/gnu99/c11/gnu11 modes should all default to
emitting
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: fw at gcc dot gnu.org
Target Milestone: ---
Once configure scripts have been cleaned up (and we have verified this for
Fedora and perhaps Debian), c99/gnu99/c11/gnu11 mode should all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90579
Florian Weimer changed:
What|Removed |Added
CC||fw at gcc dot gnu.org
See
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90569
Florian Weimer changed:
What|Removed |Added
CC||fw at gcc dot gnu.org
--- Comment #8
: diagnostic
Severity: minor
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: fw at gcc dot gnu.org
Target Milestone: ---
Consider this:
void f1() __attribute__ ((__noreturn__)) throw ();
void f2() __attribute__ ((__noreturn__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90370
--- Comment #5 from Florian Weimer ---
(In reply to Florian Weimer from comment #4)
> (In reply to Jonathan Wakely from comment #3)
> > The issue is basically that the C++ Standard Library defines two categories
> > for error numbers known to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90370
--- Comment #4 from Florian Weimer ---
(In reply to Jonathan Wakely from comment #3)
> The issue is basically that the C++ Standard Library defines two categories
> for error numbers known to the implementation: "generic" and "system", where
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90370
Florian Weimer changed:
What|Removed |Added
CC||fw at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90245
Florian Weimer changed:
What|Removed |Added
CC||fw at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65886
Florian Weimer changed:
What|Removed |Added
CC||fw at gcc dot gnu.org
--- Comment #38
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90110
Florian Weimer changed:
What|Removed |Added
CC||fw at gcc dot gnu.org
--- Comment #8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
--- Comment #49 from Florian Weimer ---
(In reply to Bernd Edlinger from comment #48)
> (In reply to Florian Weimer from comment #47)
> > (In reply to Bernd Edlinger from comment #43)
> > > does anybody know what is the Ada and/or D syntax for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
--- Comment #47 from Florian Weimer ---
(In reply to Bernd Edlinger from comment #43)
> does anybody know what is the Ada and/or D syntax for that?
Syntax for what?
I fear we need eagerly load all vector registers before calling the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89923
--- Comment #3 from Florian Weimer ---
But the precedent with wchar_t is that the type of the format string determines
the type of the %s arguments. I'm not sure if that's a good precedent, but
it's what we have today.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60790
Florian Weimer changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60790
--- Comment #14 from Florian Weimer ---
Author: fw
Date: Wed Mar 20 10:42:35 2019
New Revision: 269818
URL: https://gcc.gnu.org/viewcvs?rev=269818=gcc=rev
Log:
PR libgcc/60790: x86: Do not assume ELF constructors run before IFUNC resolvers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88805
Florian Weimer changed:
What|Removed |Added
Status|NEW |WAITING
See Also|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88805
--- Comment #7 from Florian Weimer ---
Related mailing list discussion:
https://gcc.gnu.org/ml/gcc/2019-03/msg00106.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88805
--- Comment #6 from Florian Weimer ---
Note: Current libtool does not know about the need for linking against
libgcc.a, either, so this should be fixed by changing how libgcc and libgcc_s
are linked, not in the compiler drivers.
||fw at gcc dot gnu.org
--- Comment #5 from Florian Weimer ---
I can reproduce this using g++ and gcc-8.3.1-2.fc29.x86_64, with this test
file:
static int
implementation_avx2 (void)
{
return 1;
}
static int
implementation (void)
{
return 0;
}
static __typeof__ (implementation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89461
Florian Weimer changed:
What|Removed |Added
CC||fw at gcc dot gnu.org
--- Comment #4
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=88917
Florian Weimer changed:
What|Removed |Added
CC||hjl.tools at gmail dot com
--- Comment
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=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
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
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
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 #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
++
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=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
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
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 #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
Florian Weimer changed:
What|Removed |Added
Keywords||wrong-code
: 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=88793
Florian Weimer changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
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
: 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'
The 'cold
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
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=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=88240
--- Comment #9 from Florian Weimer ---
(In reply to Thomas De Schampheleire from comment #6)
> (In reply to Florian Weimer from comment #5)
> > This is QEMU with TCG, right? It could be an i387 emulation bug.
>
> I don't think so. Isn't it so
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88240
Florian Weimer changed:
What|Removed |Added
CC||fw at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88088
--- Comment #8 from Florian Weimer ---
(In reply to Segher Boessenkool from comment #7)
> The number of targets where such a warning is meaningless is _big_, that is
> the point (most of the (older) embedded targets).
There are a lot of targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88088
--- Comment #6 from Florian Weimer ---
I'm not a fan of target-specific warnings. In this case, the number of targets
where this the warning would not be appropriate would be vanishingly small,
though, so I do not think this is a problem in
||2018-11-19
Assignee|unassigned at gcc dot gnu.org |fw at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #31 from Florian Weimer ---
(In reply to Martin Liška from comment #30)
> Jakub: Can the bug be marked as resolved?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60790
--- Comment #13 from Florian Weimer ---
My GCC 8 backport has not been reviewed yet:
https://gcc.gnu.org/ml/gcc-patches/2018-10/msg00524.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87855
Florian Weimer changed:
What|Removed |Added
CC||fw at gcc dot gnu.org
--- Comment #15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66298
--- Comment #3 from Florian Weimer ---
This would also help to detect the incorrect pragma placement in bug 63326:
int main()
{
int result = 1;
if (result < 0)
#pragma GCC diagnostic ignored "-Wunused-result"
return result;
return 0;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84039
Florian Weimer changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87421
Florian Weimer changed:
What|Removed |Added
CC||fw at gcc dot gnu.org
--- Comment #2
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: fw at gcc dot gnu.org
CC: hjl.tools at gmail dot com
Target Milestone: ---
Target: x86_64
GCC 9.0.0 (20180924) generates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83970
--- Comment #1 from Florian Weimer ---
Bug 87412 is a related issue, but without -fno-plt.
-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: fw at gcc dot gnu.org
Target Milestone: ---
Target: x86_64
Consider this test program:
__attribute__ ((weak))
int
f1 (int (*f2) (void
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87411
Florian Weimer changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: fw at gcc dot gnu.org
Target Milestone: ---
Target: x86_64
201 - 300 of 455 matches
Mail list logo
