Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: fweimer at redhat dot com
Target Milestone: ---
This:
struct T1;
struct T2;
void close(T1*);
void close(T2*);
T1* open(const char *) __attribute__ ((__malloc__ (close
Priority: P3
Component: preprocessor
Assignee: unassigned at gcc dot gnu.org
Reporter: fweimer at redhat dot com
Target Milestone: ---
This:
#pragma GCC warning "foo" "bar"
#pragma GCC error "foo" "bar"
produces:
/tmp/t.c:1:21:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65142
--- Comment #5 from Florian Weimer ---
The fix is incomplete because short reads can happen in practice for
/dev/random at least.
The usual retry loop is needed. It is not clear what to do on EINTR.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65142
Florian Weimer changed:
What|Removed |Added
CC||fweimer at redhat dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67205
--- Comment #5 from Florian Weimer ---
(In reply to Eric Botcazou from comment #4)
> The truth is, the versions of GNAT released by AdaCore use a general scheme
> to eliminate (almost) all trampolines, at least on native platforms, so
> there is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67205
--- Comment #3 from Florian Weimer ---
(In reply to Eric Botcazou from comment #2)
> > The attached example requires generation of trampolines. This may be due to
> > bug 57999, but I think a front-end fix would be more reliable.
>
> Please cla
Assignee: unassigned at gcc dot gnu.org
Reporter: fweimer at redhat dot com
CC: polacek at redhat dot com
Target Milestone: ---
Created attachment 36179
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36179&action=edit
trampoline.adb
The attached
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56726
--- Comment #12 from Florian Weimer ---
(In reply to Chip Salzenberg from comment #11)
> Indeed, 16 is required by the ABI; see
> http://www.x86-64.org/documentation/abi.pdf page 12. Only the SIMD __m256
> is bigger than 16, and there seems no e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56726
Florian Weimer changed:
What|Removed |Added
CC||fweimer at redhat dot com
--- Comment
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: fweimer at redhat dot com
This sample program:
int f(void *);
void g(void)
{
unsigned size = 128;
while (1)
{
unsigned buf[size];
if (f(buf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61126
--- Comment #3 from Florian Weimer ---
(In reply to Matthias Klose from comment #2)
> -Wunused-parameter is enabled by -Wall. I'm surprised that -Wextra is used
> without -Wall, but it happens in the testsuite in more places.
This is not what the
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: fweimer at redhat dot com
The gfortran.dg/wextra_1.f test case assumes that -Wextra enables
-Wununused-parameter, but this does not happen. No warning is printed on line
4, leading to a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7652
--- Comment #30 from Florian Weimer ---
(In reply to Manuel López-Ibáñez from comment #29)
> I like the previous suggestion of using "goto LABEL;". In fact, the warning
> message could explicitly say "use % to silence this warning".
Does this mea
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7652
--- Comment #25 from Florian Weimer ---
(In reply to Matthew Woehlke from comment #22)
> case B:
> ...
> [[gcc:fallthrough]] // suppress warning for fall-through to 'case C'
Do we have such attributes in the C compiler?
I contemplated
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59711
--- Comment #6 from Florian Weimer ---
Created attachment 31772
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31772&action=edit
pr59711.adb
Here's the same thing in Ada (where it actually works—it's actually fairly
idiomatic code, I believe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59711
--- Comment #1 from Florian Weimer ---
Created attachment 31765
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31765&action=edit
funcpointer.c
Test case without nested function.
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: fweimer at redhat dot com
Created attachment 31764
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31764&action=edit
u.c
The attached test case
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58270
--- Comment #1 from Florian Weimer ---
The compiler is free to assume that both i1 and i2 are zero and the first store
is dead (because this is the only valid array index). So if the buggy()
function stores a value of 1.0 at mem.dmem[0] unconditi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54582
Florian Weimer changed:
What|Removed |Added
CC||fweimer at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55616
--- Comment #7 from Florian Weimer 2013-01-31
11:05:48 UTC ---
(In reply to comment #6)
> Just write
> number_of_elements_in_path+100U
> or use unsigned type for
> number_of_elements_in_path
Thanks, this is helpful. It seems you need
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55616
--- Comment #4 from Florian Weimer 2013-01-31
10:26:12 UTC ---
(In reply to comment #3)
> I don't see anything bogus on the warning, it is useful to inform the
> developer
> about potentially unintended optimization removing some conditio
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55616
Florian Weimer changed:
What|Removed |Added
CC||than at redhat dot com
--- Com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55616
Bug #: 55616
Summary: bogus warning about undefined overflow after overflow
check
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54388
--- Comment #10 from Florian Weimer 2012-08-30
15:39:21 UTC ---
(In reply to comment #9)
> BTW, we definitely need a comment on why this particular code is so tricky.
>
> // NB: Interesting use of comma operator semantics.
>
> at the very lea
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54365
--- Comment #8 from Florian Weimer 2012-08-30
13:56:04 UTC ---
(In reply to comment #7)
> This is not surprising, just use integer arithmetic instead of pointer
> arithmetic. Pointer arithmetic not only has undefined wrapping, it is defined
> on
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54365
--- Comment #6 from Florian Weimer 2012-08-30
13:33:05 UTC ---
(In reply to comment #5)
> -fwrapv doesn't appear to make a difference:
>
> $ gcc compilerbug.c
> $ ./a.out
> it wraps
> $ gcc -O2 compilerbug.c
> $ ./a.out
> no wrap
> $ gc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54365
Florian Weimer changed:
What|Removed |Added
CC||fweimer at redhat dot com
--- Comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19351
Florian Weimer changed:
What|Removed |Added
CC||fweimer at redhat dot com
--- Comment
28 matches
Mail list logo
