Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: fw at gcc dot gnu.org
Target Milestone: ---
Target: i386
Created attachment 42995
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42995&action=edit
unwind.i
The a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83641
Florian Weimer changed:
What|Removed |Added
Attachment #42995|0 |1
is obsolete|
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: fw at gcc dot gnu.org
Target Milestone: ---
Created attachment 43010
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43010&action=edit
const-vla.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83654
--- Comment #1 from Florian Weimer ---
I forgot to mention that I used “-O2 -fstack-clash-protection”, but there's a
valgrind warning with -O0, too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83654
--- Comment #2 from Florian Weimer ---
I forgot to add a compiler barrier to f2 for the executable test case, so it is
not strictly equivalent.
With it, valgrind reports:
==375147== Invalid read of size 4
==375147==at 0x8048403: f2 (in /roo
Keywords: wrong-code
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: fw at gcc dot gnu.org
Target Milestone: ---
Created attachment 43039
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43
: wrong-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: fw at gcc dot gnu.org
Target Milestone: ---
Target: i686
Created attachment 43219
--> https://gcc.gnu.org/bugzilla/attachment.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83994
--- Comment #2 from Florian Weimer ---
It's still callee-saved, so it is picked by get_scratch_register_on_entry if it
is saved by the function, under the assumption that it is used only after the
prologue has saved it and there is no need to sav
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: fw at gcc dot gnu.org
Target Milestone: ---
Target: x86-64
I tried this:
struct C {
virtual ~C();
virtual void f();
};
void
f (C *p)
{
p->f();
p->f();
}
with r256939 and -mindirect-branch
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: target
Assignee: law at redhat dot com
Reporter: fw at gcc dot gnu.org
Target Milestone: ---
Target: i686
Compile this with -O2 -m32 -march=i686 -fstack-clash-protection
: wrong-code
Severity: normal
Priority: P3
Component: target
Assignee: law at redhat dot com
Reporter: fw at gcc dot gnu.org
Target Milestone: ---
Target: i686
Created attachment 43291
--> https://gcc.gnu.org/bugzilla/attachment.cgi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84128
--- Comment #1 from Florian Weimer ---
Also seems to affect -fstack-check.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84064
Florian Weimer changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: fw at gcc dot gnu.org
Blocks: 81652
Target Milestone: ---
Target: x86-64
Created attachment 43306
--> https://gcc.gnu.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84146
Florian Weimer changed:
What|Removed |Added
See Also||https://bugzilla.redhat.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84148
Florian Weimer changed:
What|Removed |Added
CC||fw at gcc dot gnu.org
--- Comment #1
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
||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=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.
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
Florian Weimer changed:
What|Removed |Added
Status|NEW |WAITING
See Also|
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&root=gcc&view=rev
Log:
PR libgcc/60790: x86: Do not assume ELF constructors run before IFUNC resol
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=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=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 personality
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 th
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=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=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=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=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
> th
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 the
: 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=90569
Florian Weimer changed:
What|Removed |Added
CC||fw at gcc dot gnu.org
--- Comment #8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90579
Florian Weimer changed:
What|Removed |Added
CC||fw at gcc dot gnu.org
See
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
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
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 bu
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 c
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 Fedo
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: fw at gcc dot gnu.org
Target Milestone: ---
Target: x86_64
Consider this program:
int a;
int
f1 (int a)
{
return a;
}
int
f2 (void)
{
return f1 (a) - a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86435
--- Comment #2 from Florian Weimer ---
(In reply to Alexander Monakov from comment #1)
> Without -fpic, f1 is considered not interposable.
That's an odd assumption. ld can interpose the definition with -z muldefs,
after all.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86435
--- Comment #4 from Florian Weimer ---
(In reply to Andreas Schwab from comment #3)
> But the assembler is allowed to resolve the reference directly without the
> possibility for interposition.
Hmm. The assembler would still produce a relocatio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53769
Florian Weimer changed:
What|Removed |Added
CC||fw at gcc dot gnu.org
--- Comment #7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53769
--- Comment #9 from Florian Weimer ---
(In reply to Vincent Lefèvre from comment #8)
> (In reply to Florian Weimer from comment #7)
> > Furthermore, if I don't misread the standard, the expectation is that if an
> > implementation does not suppor
||2018-09-21
Assignee|unassigned at gcc dot gnu.org |fw at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #2 from Florian Weimer ---
Documentation patch posted:
https://gcc.gnu.org/ml/gcc-patches/2018-09/msg01224.html
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: fw at gcc dot gnu.org
CC: msebor at gcc dot gnu.org
Target Milestone: ---
It is fairly common to assume that that the ... part of a variadic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81035
--- Comment #3 from Florian Weimer ---
Author: fw
Date: Fri Sep 21 19:49:36 2018
New Revision: 264490
URL: https://gcc.gnu.org/viewcvs?rev=264490&root=gcc&view=rev
Log:
Document that attribute noreturn inhibits tail call optimization
PR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81035
Florian Weimer changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82699
Florian Weimer changed:
What|Removed |Added
Summary|ENDBR isn't generated at|ENDBR isn't generated at
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: fw at gcc dot gnu.org
Target Milestone: ---
Target: x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87411
Florian Weimer changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
-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=83970
--- Comment #1 from Florian Weimer ---
Bug 87412 is a related issue, but without -fno-plt.
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=87421
Florian Weimer changed:
What|Removed |Added
CC||fw at gcc dot gnu.org
--- Comment #2
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=84829
--- Comment #4 from Florian Weimer ---
Does -mieee-fp still impact code generation on i386? What about x86-64 with
SSE2?
I would expect that existing users of -mieee-fp receive an error when they
compile and link with a upgraded glibc, so I don
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84829
--- Comment #6 from Florian Weimer ---
(In reply to Jakub Jelinek from comment #5)
> -mieee-fp does affect code generation on x86 and m68k, but I don't see how
> it is related to any changes in glibc.
> And besides code generation changes it affe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84761
--- Comment #1 from Florian Weimer ---
This bit needs to change for glibc 2.27 and later:
#ifdef __i386__
# define DL_INTERNAL_FUNCTION __attribute__((regparm(3), stdcall))
#else
# define DL_INTERNAL_FUNCTION
#endif
We removed the regparm attri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84761
--- Comment #3 from Florian Weimer ---
(In reply to rguent...@suse.de from comment #2)
> I think as there are already quite some __GLIBC_PREREQ uses in the
> sanitizer lib changing the above prototype appropriately would be
> good enough.
If th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48562
Florian Weimer changed:
What|Removed |Added
CC||fw at gcc dot gnu.org
See
: libgcc
Assignee: unassigned at gcc dot gnu.org
Reporter: fw at gcc dot gnu.org
Target Milestone: ---
Target: i686
__get_cpuid performs the EFLAGS check even with -march=x86-64. I think the
instruction was introduced with the Pentium, so we can avoid the check
at gcc dot gnu.org |fw at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878
Florian Weimer changed:
What|Removed |Added
Status|RESOLVED|NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878
--- Comment #16 from Florian Weimer ---
(In reply to andysem from comment #12)
> Is read-only memory a valid use case for __atomic intrinsics anyway? These
> intrinsics are primarily targeted to implement std::atomic,
I strongly disagree about t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60790
--- Comment #10 from Florian Weimer ---
Patch posted:
https://gcc.gnu.org/ml/gcc-patches/2018-03/msg01546.html
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=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=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
||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=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 prac
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=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=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 t
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: fw at gcc dot gnu.org
Target Milestone: ---
gcc -O2 -Wall yields:
t.c: In function ‘yp_update’:
t.c:27:3: warning: ‘master’ may be used uninitialized in this function
[-Wmaybe
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: fw at gcc dot gnu.org
Target Milestone: ---
This is a bit inconsistent. I would expect an error on the definition because
it is inconsistent with the forward declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69843
--- Comment #2 from Florian Weimer ---
(In reply to Jakub Jelinek from comment #1)
> Is the forward declaration here in glibc headers?
> If yes, using __attribute__((may_alias)) there too wouldn't hurt.
> Or do you mean users forward declare stan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66298
--- Comment #1 from Florian Weimer ---
Other examples. All should receive warnings.
while (check_something())
// do_something(); (commented out)
do_something();
if (check_something())
#include "/dev/null"
do_something();
if (che
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70126
--- Comment #1 from Florian Weimer ---
There seems to be a fundamental incompatibility here with supporting the GNU CC
VLA extension and this new (and apparently dead) C++ VLA specification.
I wonder how much existing G++ code applies sizeof to
: enhancement
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: fw at gcc dot gnu.org
Target Milestone: ---
In glibc, we have a few cases where we call a function through an
inappropriately typed function pointer, or from a different
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70458
--- Comment #3 from Florian Weimer ---
(In reply to Richard Biener from comment #2)
> I also seriously question
>
> "The glibc consensus is to keep such calls."
>
> can you provide a reference to the relevant discussion?
https://sourceware.org
-invalid
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: fw at gcc dot gnu.org
Target Milestone: ---
GCC accepts this code, but sizeof of a function type is invalid in C11 (and
likely earlier). It is a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70753
--- Comment #2 from Florian Weimer ---
(In reply to Marek Polacek from comment #1)
> Why would it have to be error? If you want errors instead of warnings, use
> -pedantic-errors.
I did not know about -pedantic-errors. It is extremely surprisi
: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: fw at gcc dot gnu.org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
Target Milestone: ---
Please backport this ASAN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71255
Florian Weimer changed:
What|Removed |Added
CC||fw at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71255
--- Comment #5 from Florian Weimer ---
(In reply to Marek Polacek from comment #4)
> Can you provide an example how do you envision such a pragma? Should it
> only have an effect on "sockaddr{,_*}"-named structs?
I expect that we'd put somethin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71255
--- Comment #9 from Florian Weimer ---
(In reply to rguent...@suse.de from comment #8)
> While a pragma might work I'd say for the case in question we'd like to
> have a "tentative" forward declaration that can be merged with subsequent
> forward
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71255
--- Comment #14 from Florian Weimer ---
I believe the equivalent C test case:
#include
struct sockaddr;
struct sockaddr *f();
struct __attribute__((may_alias)) sockaddr {};
struct sockaddr *f()
{
return NULL;
}
still does not work:
t.c:7:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71255
--- Comment #16 from Florian Weimer ---
(In reply to Marek Polacek from comment #15)
> Yeah, only the C++ side was changed. I think it's wrong that we reject the
> testcase in Comment 14 in C (I have a fix for that).
Good.
> But even with that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71255
--- Comment #18 from Florian Weimer ---
(In reply to rguent...@suse.de from comment #17)
> On Fri, 27 May 2016, fw at gcc dot gnu.org wrote:
> > I think the real question is whether it matters anywhere if a pointer to an
> > in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71255
--- Comment #20 from Florian Weimer ---
(In reply to rguent...@suse.de from comment #19)
> On Fri, 27 May 2016, fw at gcc dot gnu.org wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71255
> >
> > --- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71255
--- Comment #22 from Florian Weimer ---
(In reply to Marek Polacek from comment #21)
> The testcase in Comment 14 should now compile fine.
What's the best way to detect that a compiler has this fix? We cannot use a
configure check. Is there an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71255
--- Comment #25 from Florian Weimer ---
(In reply to Manuel López-Ibáñez from comment #23)
> (In reply to Florian Weimer from comment #22)
> > (In reply to Marek Polacek from comment #21)
> > > The testcase in Comment 14 should now compile fine.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71255
--- Comment #28 from Florian Weimer ---
We can put such a version check into the glibc headers and see how it works out
in practice. As long as there is consensus to fix any related breakage
(related to the attribute and forward declarations) fo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71445
--- Comment #15 from Florian Weimer ---
There is now a proposal to revert the glibc change instead:
https://sourceware.org/ml/libc-alpha/2016-06/msg00339.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80180
Florian Weimer changed:
What|Removed |Added
CC||fw at gcc dot gnu.org
--- Comment #5
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: fw at gcc dot gnu.org
Target Milestone: ---
Created attachment 41844
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: fw at gcc dot gnu.org
Target Milestone: ---
Target: i386
It would be helpful to have an i386 compilation mode which preserves the
16-byte stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81646
--- Comment #3 from Florian Weimer ---
(In reply to Jakub Jelinek from comment #1)
> The Linux ABI says the stack should be 16-byte alignment, anything else is a
> bug.
The GCC manual recommends this (under -mincoming-stack-boundary):
This
101 - 200 of 494 matches
Mail list logo
