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=82699
Florian Weimer changed:
What|Removed |Added
Summary|ENDBR isn't generated at|ENDBR isn't generated at
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=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=gcc=rev
Log:
Document that attribute noreturn inhibits tail call optimization
PR
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
||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
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
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=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
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.
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
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=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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86236
Florian Weimer changed:
What|Removed |Added
Summary|-mstackrealign prologue |Stack alignment prologue
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=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
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
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
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
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
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
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=gcc=rev
Log:
x86: libatomic: Do not assume ELF constructors run before IFUNC resolvers
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=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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878
Florian Weimer changed:
What|Removed |Added
Status|RESOLVED|NEW
Last reconfirmed|
at gcc dot gnu.org |fw at gcc dot gnu.org
: 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48562
Florian Weimer changed:
What|Removed |Added
CC||fw at gcc dot gnu.org
See
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
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
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
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
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=84146
Florian Weimer changed:
What|Removed |Added
See Also||https://bugzilla.redhat.com
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=84064
Florian Weimer changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84128
--- Comment #1 from Florian Weimer ---
Also seems to affect -fstack-check.
: 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
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
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
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
: 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.
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
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
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.
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=edit
const-vla.c
On i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83641
Florian Weimer changed:
What|Removed |Added
Attachment #42995|0 |1
is obsolete|
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=edit
unwind.i
The attached unwin
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83302
--- Comment #5 from Florian Weimer ---
FWIW, -fstack-clash-protection avoids these issues.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61118
Florian Weimer changed:
What|Removed |Added
Summary|[6/7/8 Regression] Spurious |[6/7/8 Regression] Indirect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82900
Florian Weimer changed:
What|Removed |Added
CC||fw at gcc dot gnu.org
--- Comment #2
Assignee: unassigned at gcc dot gnu.org
Reporter: fw at gcc dot gnu.org
Target Milestone: ---
I think this program should emit a warning in C mode:
#define TRUE ((_Bool) 1)
#define FALSE ((_Bool) 0)
typedef enum { a, b, c } result;
result
f (int flag)
{
if (flag)
return
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: fw at gcc dot gnu.org
Target Milestone: ---
__stack_chk_fail is only called when something is critically wrong with the
process. At this point, it is important to minimize the amount of work done by
the process
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81780
--- Comment #1 from Florian Weimer ---
Could we turn calls to regparam (3) functions into noplt calls? Some
additional mechanics are probably needed if the address of such a function is
taken.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81646
--- Comment #5 from Florian Weimer ---
(In reply to H.J. Lu from comment #4)
> You can use -mstackrealign.
I don't want to realign the stack unconditionally for performance reasons. I
want to preserve alignment for callback functions, and give
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):
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
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=41844=e
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81066
--- Comment #8 from Florian Weimer ---
(In reply to Khem Raj from comment #7)
> (In reply to Florian Weimer from comment #6)
> > (In reply to Khem Raj from comment #5)
> > > +#ifndef __stack_t_defined
> > > +struct stack_t;
> > > +#endif
> >
>
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: fw at gcc dot gnu.org
CC: dmalcolm at redhat dot com
Target Milestone: ---
It appears that GCC suffers from the same issue as grep when it comes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78918
Florian Weimer changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81066
--- Comment #6 from Florian Weimer ---
(In reply to Khem Raj from comment #5)
> +#ifndef __stack_t_defined
> +struct stack_t;
> +#endif
Where does __stack_t_defined come from? If this is the definition from the
glibc headers, that's really
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: fw at gcc dot gnu.org
Target Milestone: ---
Target: x86-64
Created attachment 41521
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41521=edit
C test c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=13182
--- Comment #7 from Florian Weimer ---
(In reply to Eric Botcazou from comment #6)
> That's as expected: the probing mechanism maintains a protection area so the
> program can recover from a stack overflow condition by raising an exception.
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78460
--- Comment #3 from Florian Weimer ---
I see ~500 GiB with GCC 7.0.1 20170501 (prerelease) [gcc-7-branch revision
247430]. This interferes rather badly with cross-compiler-based testing.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
--- Comment #58 from Florian Weimer ---
(In reply to Dominik Vogt from comment #57)
> libsanitizer miscalculates the Pcs in the backtrace:
>
> #0 0x1000839 in NullDeref
> #1 0x10006c1 in main
> #2 0x3fff6e23069 in __libc_start_main
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56727
--- Comment #11 from Florian Weimer ---
(In reply to Jakub Jelinek from comment #10)
> Don't we also inline any beneficial inline functions at -O3 even if they
> could be interposed (definitely not suggesting we stop doing that, that
> would
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79439
--- Comment #2 from Florian Weimer ---
(In reply to Segher Boessenkool from comment #1)
> What command line options does this need?
Sorry, I used -O2 -fpic.
Indeed, GCC seems to perform target-independent optimizations based on an
assumption
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: fw at gcc dot gnu.org
Target Milestone: ---
Target: ppc64le-redhat-linux
Consider this test case:
int f (void);
void
g (void)
{
}
void
rec (int a)
{
if (f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
--- Comment #20 from Florian Weimer ---
(In reply to Andreas Krebbel from comment #19)
> As a debugging tool I think asan is a special case also regarding ABI
> compatibility. We probably do not want to export the internal symbol and
> make it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
Florian Weimer changed:
What|Removed |Added
CC||fw at gcc dot gnu.org
--- Comment #16
Assignee: unassigned at gcc dot gnu.org
Reporter: fw at gcc dot gnu.org
Target Milestone: ---
Target: tilepro-glibc-linux
Created attachment 40369
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40369=edit
Test case extracted from glibc
Compile the attac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78584
--- Comment #5 from Florian Weimer ---
Hmm. Maybe it is file-system-specific. I don't see the anomalous return
values on XFS and tmpfs.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78584
Florian Weimer changed:
What|Removed |Added
CC||fw at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78064
--- Comment #6 from Florian Weimer ---
Author: fw
Date: Mon Nov 7 19:54:05 2016
New Revision: 241929
URL: https://gcc.gnu.org/viewcvs?rev=241929=gcc=rev
Log:
PR libgcc/78064: Add missing include directive to unwind-c.c
Backport from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78064
--- Comment #5 from Florian Weimer ---
Author: fw
Date: Mon Nov 7 17:08:40 2016
New Revision: 241914
URL: https://gcc.gnu.org/viewcvs?rev=241914=gcc=rev
Log:
PR libgcc/78064: Add missing include directive to unwind-c.c
Backport from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78064
Florian Weimer changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78064
--- Comment #3 from Florian Weimer ---
Author: fw
Date: Mon Oct 24 18:25:09 2016
New Revision: 241491
URL: https://gcc.gnu.org/viewcvs?rev=241491=gcc=rev
Log:
PR libgcc/78064: Add missing include directive to unwind-c.c
PR libgcc/78064
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78091
--- Comment #3 from Florian Weimer ---
Although I have to admit, the error variable could be a bit nicer, rejecting
the register variable definition.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78091
Florian Weimer changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
Assignee: unassigned at gcc dot gnu.org
Reporter: fw at gcc dot gnu.org
Target Milestone: ---
Target: i386
Created attachment 39874
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39874=edit
posix_fallocate.i
The attached test case has been extracted f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78064
Florian Weimer changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
Assignee: fw at gcc dot gnu.org
Reporter: fw at gcc dot gnu.org
Target Milestone: ---
unwind-c.c use a HAVE_GETIPINFO preprocessor conditional, but never includes
auto-target.h, so the macro is always undefined. As a result,
_Unwind_GetIPInfo is never used.
This causes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38295
--- Comment #11 from Florian Weimer ---
Created attachment 39799
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39799=edit
label.c
(In reply to Andrew Pinski from comment #6)
> Not always since they could be in different sections via
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: fw at gcc dot gnu.org
Target Milestone: ---
Created attachment 39794
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39794=edit
label-bug.c
The attached test case abo
||fw at gcc dot gnu.org
Resolution|WONTFIX |---
--- Comment #10 from Florian Weimer ---
This is already implemented for differences between C && label addresses. I
think there is no compelling reason why this would not work for the a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77894
--- Comment #2 from Florian Weimer ---
(In reply to nsz from comment #1)
> the ifunc abi still has many problems and i don't think it's possible to
> detect
> dynamic linker support for cross compilation so if it is enabled do it only
> if
> the
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: ---
Created attachment 39703
--> https://gcc.gnu.org/bugzi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77729
Florian Weimer changed:
What|Removed |Added
CC||fw at gcc dot gnu.org
--- Comment #7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77627
--- Comment #1 from Florian Weimer ---
Observed with the trunk from 2016-09-08.
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: fw at gcc dot gnu.org
Target Milestone: ---
This snippet, derived from code provided by Ron Garret:
int main(int argc, char* argv[]) {
int x[100] = {0
||2016-09-08
Assignee|unassigned at gcc dot gnu.org |fw at gcc dot gnu.org
Ever confirmed|0 |1
: normal
Priority: P3
Component: ada
Assignee: unassigned at gcc dot gnu.org
Reporter: fw at gcc dot gnu.org
Target Milestone: ---
Created attachment 39585
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39585=edit
phg2.adb
Natasha Kerensikova repor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=1
Florian Weimer changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=1
Florian Weimer changed:
What|Removed |Added
CC||fw at gcc dot gnu.org
--- Comment #11
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: fw at gcc dot gnu.org
Target Milestone: ---
I found this gem in some glibc test case:
if (c != 0)
c /= abs (c);
This could turn into:
if (c < 0)
c = -1;
e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72783
--- Comment #1 from Florian Weimer ---
Martin and I discussed this for a bit.
The %ms hack does not work due to embedded NULs, which are copied to the
destination buffer by scanf, do not terminate the string, and are (in most
cases) detectable
301 - 400 of 456 matches
Mail list logo
