[Bug c/57046] New: wrong code generated by gcc 4.8.0 on i686
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57046 Bug #: 57046 Summary: wrong code generated by gcc 4.8.0 on i686 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: matti...@acm.org Created attachment 29917 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29917 Test case including driver demonstrating the bug Gcc 4.8.0 silently miscompiles the attached short test case (emac.c) on 32-bit x86 with -O2. It appears that the value returned from get_value is thrown away. gcc -V output: Using built-in specs. COLLECT_GCC=/usr/local/gcc/4.8.0/bin/gcc COLLECT_LTO_WRAPPER=/home/local/linux/gcc/4.8.0/bin/../libexec/gcc/i686-pc-linux-gnu/4.8.0/lto-wrapper Target: i686-pc-linux-gnu Configured with: ../gcc-4.8.0/configure --prefix=/usr/local/gcc/4.8.0 --with-mpc=/tmp/extra --with-gmp=/tmp/extra --with-mpfr=/tmp/extra --with-isl=/tmp/extra --with-cloog=/tmp/extra --with-as=/usr/local/binutils/2.23.2/bin/as --with-ld=/usr/local/binutils/2.23.2/bin/ld.gold --enable-languages=c,c++,objc,go Thread model: posix gcc version 4.8.0 (GCC)
[Bug c/55217] New: False -Wstrict-overflow warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55217
Bug #: 55217
Summary: False -Wstrict-overflow warning
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: matti...@acm.org
This code yields a false -Wstrict-overflow warning in gcc 4.7.2:
void h(int *s);
void f(int n, int s)
{
int r = 1;
for (int i = 1; i < n; i++)
if (r)
r++;
if (r * s >= s + 3) // warning here
for (int j = 0; j < r; j++)
h(&s);
}
beta.c:8:12: warning: assuming signed overflow does not occur when assuming
that (X + c) < X is always false [-Wstrict-overflow]
The condition is not on the form X+c= s + 3) // warning here
for (int j = 0; j < r; j++)
h(&s);
}
[Bug c/57485] New: memcpy in aggregate return not eliminated
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57485
Bug ID: 57485
Summary: memcpy in aggregate return not eliminated
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: mattiase at acm dot org
Returning a big aggregate sometimes yields an avoidable temporary and memcpy.
In this example, gcc manages to pass a pointer to the destination variable as
the hidden struct return pointer only when that variable is being initialised,
not when assigned separately.
Observed in 4.8.0 for x86-64 and i686.
struct S { int a[100]; };
struct S f(void);
void g(struct S *p);
void h(void) {
#if 0
struct S s = f(); // no local temporary
#else
struct S s;
s = f(); // local temporary and memcpy
#endif
g(&s);
}
[Bug target/3920] [PPC] wrong register number for CTR in stabs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3920 --- Comment #10 from Mattias Engdegård --- Stabs is rather obsolete and I don't personally care about it any more. As far as I can tell from the source (GCC 5.3 and GDB 7.10), the problem (wrong CTR numbering in stabs) is still there, but if it were up to me I wouldn't waste any time on it.
[Bug c/43421] New: strict-aliasing warning from innocent code
Compiling the code below (with -O2 -Wall -std=c99, gcc 4.4.3) gives the warning
apa.c: In function 'f':
cc1: warning: dereferencing pointer '({anonymous})' does break strict-aliasing
rules
apa.c:9: note: initialized from here
which is both unhelpful and dubious - is the code really doing anything wrong
here?
static int g(const void *p) {
int x;
__builtin_memcpy(&x, p, sizeof x);
return x;
}
struct s { char d[5]; };
int f(struct s ss) {
int t = 0;
for (int i = 0; i < 2; i++)
t += g(ss.d);
return t;
}
--
Summary: strict-aliasing warning from innocent code
Product: gcc
Version: 4.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mattiase at acm dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43421
[Bug c/65402] New: global register variables miscompiled when unit contains sse4.2 functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65402
Bug ID: 65402
Summary: global register variables miscompiled when unit
contains sse4.2 functions
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: mattiase at acm dot org
The mere presence of a function with the attribute target("sse4.2") is enough
for gcc to miscompile other functions with respect to global register
variables:
code below! -
__attribute__((target("sse4.2"))) void F(void) {}
register long gr1 asm("r12");
register long gr2 asm("r13");
long G(void);
int H(void) {
gr1 = G(); /* Any code at all, really. */
return 1;
}
- code above!
The existence of F causes H to save/restore all global register variables in
its prologue/epilogue, which of course makes these variables impossible to use
inside H. Comment out the definition of F, and the problem disappears.
This occurs in GCC 4.9.2 on x86-64 (Linux), with -O0 or -O2.
Possible workaround: move the register declarations to above F. This is not
always easy (in our case, F is really the stuff in ia32intrin.h that happened
to be included from header files that we need for the types in the register
variable declarations).
Although it's good practice to put the global register declarations at the top
of the unit, not doing so shouldn't cause functions below to be miscompiled.
This appears to be a regression; the bug is not present in GCC 4.8.1.
[Bug libgomp/67141] New: wrong libgomp mutex initialisation order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67141 Bug ID: 67141 Summary: wrong libgomp mutex initialisation order Product: gcc Version: 5.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp Assignee: unassigned at gcc dot gnu.org Reporter: mattiase at acm dot org CC: jakub at gcc dot gnu.org Target Milestone: --- Libgomp may use a mutex, acc_device_lock, prior to initialising it depending on the constructor calling order: it is initialised in initialize_env and used in goacc_host_init, both declared __attribute__ ((constructor)) but in different files. This was discovered on Windows after a change to the pthread library in mingw-w64, making all-zero an invalid mutex value. Apparently the constructors were called in the "wrong" order, and pthread_mutex_lock called before pthread_mutex_init.
[Bug c/43421] strict-aliasing warning from innocent code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43421 Mattias Engdegård changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #1 from Mattias Engdegård 2011-03-10 11:41:06 UTC --- Gcc 4.5.2 no longer gives the spurious warning, so apparently this has been fixed. My thanks to whomever did it.
[Bug middle-end/109637] New: unnecessary range check in complete switch on bitfield
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109637
Bug ID: 109637
Summary: unnecessary range check in complete switch on bitfield
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: mattiase at acm dot org
Target Milestone: ---
This fully populated switch still produces some kind of useless range check:
struct S { unsigned x : 2; };
int f (struct S *s) {
switch(s->x) {
case 0: return 0;
case 1: return 1;
case 2: return 2;
case 3: return 3;
}
}
->
movzbl (%rdi), %eax
andl$3, %eax
leal-1(%rax), %edx
movzbl %al, %eax
cmpb$3, %dl
movl$0, %edx
cmovnb %edx, %eax
ret
GCC apparently understands that the switch is complete at some level since
anything after the switch is recognised as dead code, so the range check is a
bit puzzling.
The code is fine if we explicitly mask the switch value as in `switch(s->x &
3)`:
movzbl (%rdi), %eax
andl$3, %eax
ret
