ty: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: eggert at gnu dot org
Target Milestone: ---
Created attachment 54896
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54896&action=edit
compressed test pro
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: eggert at gnu dot org
Target Milestone: ---
Created attachment 54895
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54895&action=edit
compressed test program illustratin
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: eggert at gnu dot org
Target Milestone: ---
This is (GCC) 13.0.1 20230401 (Red Hat 13.0.1-0) on x86-64.
Compile the following program with 'gcc -O2 -S -fanalyzer t.c'
Assignee: unassigned at gcc dot gnu.org
Reporter: eggert at gnu dot org
Target Milestone: ---
We ran into this problem in Gnulib when considering how to migrate towards C23.
With GCC 12.2.1 20221121 (Red Hat 12.2.1-4) on x86-64, compile the following
one-line program t.c with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101682
Paul Eggert changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101682
--- Comment #2 from Paul Eggert ---
Clang's warnings are not a problem here, because in clang 12.0.0 (the current
release) __has_c_attribute(nodiscard) is false, so code like this works:
#ifndef __has_c_attribute
# define __has_c_attribute(x) 0
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: eggert at gnu dot org
Target Milestone: ---
The grammar at the start of section 6.7 of the current C2x draft (N2596) says
that attribute specifiers may appear either before or after
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: eggert at gnu dot org
Target Milestone: ---
Created attachment 50859
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50859&action=edit
doc patch for -fno-trampolines confusi
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: eggert at gnu dot org
Target Milestone: ---
This is with gcc (GCC) 10.2.1 20201125 (Red Hat 10.2.1-9) on x86-64. For the
function:
_Bool signed1_overflow (signed char a, signed char b)
{
signed char r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97370
Paul Eggert changed:
What|Removed |Added
CC||eggert at gnu dot org
--- Comment #4 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80646
Paul Eggert changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82170
Paul Eggert changed:
What|Removed |Added
Version|7.1.1 |8.3.1
--- Comment #10 from Paul Eggert --
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85563
Paul Eggert changed:
What|Removed |Added
CC||eggert at gnu dot org
--- Comment #8 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71157
--- Comment #9 from Paul Eggert ---
(In reply to Eric Gallager from comment #8)
> Try marking it up with __attribute__((returns_nonnull)) and/or
> __attribute__((nonnull)). If the first one works, then it's a case where GCC
> should suggest it,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81401
Paul Eggert changed:
What|Removed |Added
CC||eggert at gnu dot org
--- Comment #3 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85602
--- Comment #4 from Paul Eggert ---
Thanks, that workaround is much better for coreutils, and I installed it here:
https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=f6cb50cc991d461f443ea3afc517c9e1e37ef496
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85602
--- Comment #2 from Paul Eggert ---
Thanks for looking into it. For what it's worth, the practical effect of this
new warning was that I changed that part of coreutils to not use strncat,
causing 3 lines of code to grow to 8 lines. See the end of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85562
Paul Eggert changed:
What|Removed |Added
CC||eggert at gnu dot org
--- Comment #2 from
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: eggert at gnu dot org
Target Milestone: ---
GCC 8's --suggest-attribute=malloc diagnoses static functions, even though the
malloc attribute is useless for static functions (after all, the com
: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: eggert at gnu dot org
Target Milestone: ---
Created attachment 44051
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44051&action=edit
test program illustrating the regression
I ran into some problems build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48968
--- Comment #13 from Paul Eggert ---
(In reply to Eric Gallager from comment #12)
> (In reply to Paul Eggert from comment #11)
> > Also please see related bugs Bug 21161, Bug 54561, Bug 61118, Bug 65041, Bug
> > 83162. Perhaps they should be merg
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: eggert at gnu dot org
Target Milestone: ---
Created attachment 42778
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42778&action=edit
Source file illustrating compiler bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83251
--- Comment #1 from Paul Eggert ---
Created attachment 42774
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42774&action=edit
Test case subroutines (you also need foomain.i)
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: eggert at gnu dot org
Target Milestone: ---
Created attachment 42773
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42773&action=edit
Test case main
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83177
--- Comment #1 from Paul Eggert ---
Created attachment 42727
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42727&action=edit
Compiler output generated for crash on v.i
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: eggert at gnu dot org
Target Milestone: ---
Host: x86-64
Created attachment 42726
--> https://gcc.gnu.org/bugzilla/attachment.cgi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80776
--- Comment #3 from Paul Eggert ---
(In reply to Richard Biener from comment #1)
> Possibly the walk in remove_range_assertions visits the latter before the
> former block but in principle we do have code to handle this there.
I just ran into th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61118
--- Comment #14 from Paul Eggert ---
Also please see related reports Bug 21161, Bug 48968, Bug 54561, Bug 65041, and
Bug 83162. The last-listed one also is a regression, perhaps induced by the
fancier optimization in recent GCC versions. I suspec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48968
--- Comment #11 from Paul Eggert ---
Also please see related bugs Bug 21161, Bug 54561, Bug 61118, Bug 65041, Bug
83162. Perhaps they should be merged?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21161
Paul Eggert changed:
What|Removed |Added
CC||eggert at gnu dot org
--- Comment #5 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65041
--- Comment #4 from Paul Eggert ---
Also please see Bug 83162, which may be related.
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: eggert at gnu dot org
Target Milestone: ---
Created attachment 42717
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42717&action=edit
Test case for "gcc -O2 -S -Wclobbered"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65041
Paul Eggert changed:
What|Removed |Added
CC||eggert at gnu dot org
--- Comment #3 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61118
Paul Eggert changed:
What|Removed |Added
CC||eggert at gnu dot org
--- Comment #12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82914
--- Comment #4 from Paul Eggert ---
(In reply to Richard Biener from comment #2)
> You are not using aligned on a 'struct or struct member' but on the variable
> in all but (b).
If that's the intent, then GCC is mishandling the first example I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82914
--- Comment #1 from Paul Eggert ---
(In reply to Paul Eggert from comment #0)
Sorry, but my example in comment #0 (although it illustrates a bug) doesn't
illustrate the bug that crashed GCC. Here's a better example:
struct t { long mem; };
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: eggert at gnu dot org
Target Milestone: ---
I'm reporting a GCC problem that caused Emacs to SIGSEGV as described here:
https://bugs.gnu.org/29183
I track
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82170
Paul Eggert changed:
What|Removed |Added
Attachment #42149|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82170
Paul Eggert changed:
What|Removed |Added
Attachment #42148|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82170
--- Comment #3 from Paul Eggert ---
(In reply to Marc Glisse from comment #2)
> Note that n==(int)n (gcc documents that this must work) may work with more
> gcc versions and is more readable.
Thanks, good point, I'll suggest switching to that in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82170
--- Comment #1 from Paul Eggert ---
Created attachment 42149
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42149&action=edit
assembly-language output for poorly-optimized code
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: eggert at gnu dot org
Target Milestone: ---
Created attachment 42148
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42148&action=edit
source code that is poorly optimized on x86-64
GCC on Fedora 26 x86-
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: eggert at gnu dot org
Target Milestone: ---
This is following up a Gnulib bug report:
http://lists.gnu.org/archive/html/bug-gnulib/2017-07/msg00150.html
which appears to stem from a bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51309
--- Comment #2 from Paul Eggert ---
(In reply to Eric Gallager from comment #1)
> I can't seem to reproduce the warning
Thanks, I can no longer reproduce the warning either. I used GCC 7.1.1 20170622
(Red Hat 7.1.1-3). So it looks like the probl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80659
Paul Eggert changed:
What|Removed |Added
CC||eggert at gnu dot org
--- Comment #8 from
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: eggert at gnu dot org
Target Milestone: ---
I found this problem when compiling GNU Emacs with GCC 7.1.0 and with Clang
3.9.1. GCC missed an uninitialized-variable bug that Clang correctly
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: eggert at gnu dot org
Target Milestone: ---
I found this problem when compiling Emacs with GCC 7.1.0 on x86-64. Emacs uses
__builtin_unreachable to let the compiler know
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80646
--- Comment #3 from Paul Eggert ---
(In reply to Richard Biener from comment #1)
> So I start to belive this is a gdb bug.
Thanks, I filed a GDB bug report here:
https://sourceware.org/bugzilla/show_bug.cgi?id=21473
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53896
--- Comment #3 from Paul Eggert ---
(In reply to Martin Liška from comment #2)
> it's still up to user to mark the function as pure.
Thanks for looking into it. We have worked around the problem in GNU Emacs by
avoiding the -Wsuggest-attribute=p
: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: eggert at gnu dot org
Target Milestone: ---
Created attachment 41327
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41327&action=edit
gzipped tarball of three
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80515
--- Comment #6 from Paul Eggert ---
> main always return according to the standard
No, the C standard does not require 'main' to return. It's perfectly acceptable
for 'main' to never return, and many programs are written that way.
> what you ar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80515
--- Comment #4 from Paul Eggert ---
> main() has an implicit return 0.
That's irrelevant to the purpose of the warning. The warning is there to catch
the common typo of a function containing a return statement even though it is
declared 'noretur
iority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: eggert at gnu dot org
Target Milestone: ---
For this one-line C program:
__attribute__ ((__noreturn__)) int main (void) { for (;;); }
GCC complains:
: warning: function declared ‘noreturn’ has a ‘return’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68971
--- Comment #12 from Paul Eggert ---
Ah, sorry, I am using GCC 6.3.1, whereas __builtin_mul_overflow_p is a GCC
7-ism. Somehow I got it into my head that __builtin_mul_overflow(A,B,C) should
be a constant expression if A, B, are constant express
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68971
--- Comment #10 from Paul Eggert ---
Unfortunately, the patch for Bug#68120 does not seem to have addressed the
problem here. For example, although the following code uses the new feature
enabled by that patch:
int f (void) {
return (__bui
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=4210
--- Comment #25 from Paul Eggert ---
I'd like this bug to be changed from SUSPENDED to CONFIRMED, given that it's
continuing to be a problem (e.g., bug#79479).
Also, I'd like to suggest what I hope is a simple fix. In 2006 Joseph wrote
"skip_eval
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79479
--- Comment #14 from Paul Eggert ---
Thanks, please feel free to mark this as a duplicate of Bug#4210. I plan to
follow up there.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79479
--- Comment #12 from Paul Eggert ---
If the proposed change would introduce significant problems with false
positives or false negatives, then surely GCC already has these problems in
conditional expressions. These problems ought to be addressed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79479
--- Comment #9 from Paul Eggert ---
> 1) It's too subtle for non-expert programmers to understand.
Actually, it's typically easy for non-experts to follow this. For example,
although GCC falsely warns about this:
/*1*/ if (0) return INT_MAX +
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79479
--- Comment #7 from Paul Eggert ---
> the translation of a program that contains an overflowing constant expression
> has undefined behavior
Sure, but the programs in question do not contain constant expressions in sense
of the C standard. They
: c
Assignee: unassigned at gcc dot gnu.org
Reporter: eggert at gnu dot org
Target Milestone: ---
Created attachment 40722
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40722&action=edit
gcc -m32 -Woverflow incorrectly complains about this
Compile the attached
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78685
--- Comment #5 from Paul Eggert ---
Just to clarify: 'main' (in the sample program) is just an example. The
problems developers are seeing when debugging Emacs almost all involve
functions other than 'main'.
It should be OK for -Og to optimize s
ent: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: eggert at gnu dot org
Target Milestone: ---
Host: x86-64
Created attachment 40253
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40253&action=edit
preprocessed C program illustrating -Og problem
Ema
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: eggert at gnu dot org
Target Milestone: ---
I found this bug when trying to build Emacs with -fcheck-pointer-bounds.
Suppose the file profile.i contains:
extern _Nor
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: eggert at gnu dot org
Target Milestone: ---
Created attachment 39869
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39869&action=edit
test program illustrating -Wmaybe-uninit
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: eggert at gnu dot org
Target Milestone: ---
GCC's recently-added -Wbool-operation flag rejects useful code like this:
#include
enum { BILLION = 1000 * 1000 * 1000 };
time_t foo (time_t s, int res) { return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71157
--- Comment #6 from Paul Eggert ---
> this is because it thinks skip_space() may return NULL:
That sounds like a bug, then, as skip_spaces immediately dereferences its
argument, so it cannot possibly return NULL.
Also, skip_spaces is never pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71157
--- Comment #4 from Paul Eggert ---
I worked around the GCC bug by applying the attached file etags.c.patch to GNU
Emacs. etags.c.patch replaces some weird but valid C code (add a small constant
to a pointer and test whether the resulting pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71157
--- Comment #3 from Paul Eggert ---
Created attachment 38532
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38532&action=edit
patched version of e.i that avoids GCC bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71157
--- Comment #2 from Paul Eggert ---
Created attachment 38531
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38531&action=edit
GNU Emacs lib-src/etags.c patch to work around GCC bug
: c
Assignee: unassigned at gcc dot gnu.org
Reporter: eggert at gnu dot org
Target Milestone: ---
Created attachment 38504
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38504&action=edit
preprocessed source code for emacs/lib-src/etags.c
I discovered this when co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68120
--- Comment #6 from Paul Eggert ---
(In reply to Martin Sebor from comment #5)
> Patch posted for review:
> https://gcc.gnu.org/ml/gcc-patches/2016-05/msg00013.html
Thanks. This patch appears to address almost all the request, and it is
definite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69763
Paul Eggert changed:
What|Removed |Added
CC||eggert at gnu dot org
--- Comment #1 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68120
--- Comment #2 from Paul Eggert ---
(In reply to Paul Eggert from comment #0)
> I am working around the problem with macro definitions like this:
>
> # define INT_ADD_OVERFLOW(a, b) \
>(__builtin_constant_p ((a) == (b)) \
> ? _GL_INT_AD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68971
--- Comment #8 from Paul Eggert ---
(In reply to Martin Sebor from comment #7)
> Perhaps what's needed is for GCC to treat the builtins as constant
> expressions when they're invoked with them as operands. If you agree with
> that approach, I s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68971
--- Comment #6 from Paul Eggert ---
(In reply to Martin Sebor from comment #5)
> This is a valid constant expression
I'm aware of the distinction between constant and other expressions. I'm trying
to give the ordinary user's viewpoint, not the v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68971
--- Comment #4 from Paul Eggert ---
(In reply to Martin Sebor from comment #1)
> constant expressions are evaluated during translation
This is not a constant expression. Not that that should matter. For example:
enum { a = (1 ? 0 : 1 / 0) };
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: eggert at gnu dot org
Target Milestone: ---
Compile the following code with 'gcc -O2 -S u.c' (x86-64, GCC 5.3.1 20151207
(Red Hat 5.3.1-2)):
int
main (void)
{
Assignee: unassigned at gcc dot gnu.org
Reporter: eggert at gnu dot org
Target Milestone: ---
I ran into this problem when developing Gnulib code. This is with GCC 5.2.0 on
x86-64. Compile the following program t.c with 'gcc -Wall t.c':
int
main (void)
{
int i = 0;
int j
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: eggert at gnu dot org
Target Milestone: ---
Compile this with "gcc -S" (x86-64):
enum {
x = 20,
y = 20,
a = __builtin_constant_p (x + y) ? x : -1,
};
ement
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: eggert at gnu dot org
Target Milestone: ---
This is a followup to Bug#61129, which asked for integer-overflow-detecting
arithmetic intrinsics. We have them now (thanks!) but I'm ru
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68110
--- Comment #3 from Paul Eggert ---
(In reply to Andrew Pinski from comment #2)
> So the question is does anyone use this function without "a - b" later on?
Not that I know of. The usual pattern for callers of the Gnulib macro is to use
the mac
: c
Assignee: unassigned at gcc dot gnu.org
Reporter: eggert at gnu dot org
Target Milestone: ---
I ran into this minor performance issue when changing Gnulib's lib/intprops.h
to use the new __builtin_sub_overflow function. I found that
__builtin_sub_overflow is less effi
y: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: eggert at gnu dot org
Target Milestone: ---
On x86-64 for this program:
long i = 0x7fffL;
int main (void)
{
return i + 1 < i;
}
gcc -ftrapv -O2 -S generates this code:
main:
movqi(%ri
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: eggert at gnu dot 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28901
--- Comment #12 from Paul Eggert ---
(In reply to Manuel López-Ibáñez from comment #11)
> Another alternative is to only warn if the variable is defined in the main
> file (MAIN_FILE_P) as opposed to an included file.
Thanks, this is a reasonab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28901
Paul Eggert changed:
What|Removed |Added
CC||eggert at gnu dot org
--- Comment #10
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: eggert at gnu dot org
Created attachment 34031
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34031&action=edit
Program with -Wmaybe-uninitialized problem
Compile the attached prog
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: eggert at gnu dot org
This is a followup to PR c/54113, which was about -Wmissing-prototypes. This
followup bug report is the same, except it is about -Wmissing-declarations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63495
--- Comment #6 from Paul Eggert ---
That was fast! Thank you.
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: eggert at gnu dot org
Compile and run the following two-line program with an x86 target:
struct __attribute__ ((aligned (8))) s { char c; };
_Static_assert (_Alignof (struct s) >= 8, "wrong alignment");
This s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61409
--- Comment #3 from Paul Eggert ---
(In reply to Manuel López-Ibáñez from comment #1)
> My guess is that what is uninitialized is "rw" and some optimization pass
> messed up the variable names when creating temporaries.
I'm afraid it's more ser
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: eggert at gnu dot org
Created attachment 32887
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32887&action=edit
sample program illustrating the false positive
GCC 4.9.0 x86-64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56955
Paul Eggert changed:
What|Removed |Added
Attachment #32832|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56955
--- Comment #18 from Paul Eggert ---
(In reply to Richard Biener from comment #16)
> void foo (int *p)
> {
> int *q = realloc (p, sizeof (int));
> *q = 2;
> }
>
> may I remove the store *q = 2 as dead?
Yes, the consensus nowadays is that y
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56955
--- Comment #14 from Paul Eggert ---
(In reply to Dan Gohman from comment #13)
> *p can't alias a or b without violating the weaker assumption.
Sorry, you've lost me there. Pointers in realloc'ed storage can alias
already-existing pointers, an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56955
--- Comment #12 from Paul Eggert ---
(In reply to Rich Felker from comment #10)
> This assumption only aids
> optimization in the case where a pointer residing in the obtained memory is
> used (e.g. dereferenced or compared with another pointer)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56955
--- Comment #11 from Paul Eggert ---
Created attachment 32834
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32834&action=edit
Sample illustrating GCC's optimization with __attribute__ ((malloc))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56955
Paul Eggert changed:
What|Removed |Added
Attachment #32831|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56955
--- Comment #8 from Paul Eggert ---
Comment on attachment 32831
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32831
Clarify documentation for __attribute__ ((malloc)).
>Index: gcc/ChangeLog
>===
1 - 100 of 152 matches
Mail list logo
