[Bug c/64923] New: [s390] Generated code uses struct padding instead of just the bitfield
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64923
Bug ID: 64923
Summary: [s390] Generated code uses struct padding instead of
just the bitfield
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: siddhesh at redhat dot com
Reproducer:
struct obstack
{
unsigned use_extra_arg:1;
unsigned extra_bitfield:1;
};
void
myfree (void *f)
{
}
void (*freefun) (void *) = myfree;
void
obstack_free (struct obstack *h, void *obj)
{
if (h-use_extra_arg)
freefun ((void *) 0x42);
else
freefun ((void *) 0x0);
}
int
main (int argc, char **argv)
{
struct obstack ob;
ob.use_extra_arg = 0;
obstack_free (ob, (void *) 0);
return 0;
}
Build with:
gcc -g -O2 -o obs{,.c}
$ valgrind ./obs
==20292== Memcheck, a memory error detector
==20292== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==20292== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==20292== Command: ./obs
==20292==
==20292== Conditional jump or move depends on uninitialised value(s)
==20292==at 0x85B4: obstack_free (obs.min.c:17)
==20292==by 0x8455: main (obs.min.c:30)
==20292==
==20292==
==20292== HEAP SUMMARY:
==20292== in use at exit: 0 bytes in 0 blocks
==20292== total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==20292==
==20292== All heap blocks were freed -- no leaks are possible
==20292==
==20292== For counts of detected and suppressed errors, rerun with: -v
==20292== Use --track-origins=yes to see where uninitialised values come from
==20292== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
This works correctly on x86 since the generated code explicitly selects the
relevant bit in the bitfield to test. s390x on the other hand doesn't when
built with -O2. It looks like the instruction combiner pass removes the AND
operation that selects the bit and instead tests the entire word.
[Bug tree-optimization/64739] New: Spurious array subscript is above array bounds warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64739
Bug ID: 64739
Summary: Spurious array subscript is above array bounds
warning
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: siddhesh at redhat dot com
Reduced Reproducer:
$ cat foo.c
void
foo (char **inptrp, char *inend, int *wch, int *cnt)
{
int inlen = *cnt 7;
if (inlen != 0)
{
char *inptr = *inptrp;
char bytebuf[4];
while (inptr inend)
bytebuf[inlen++] = *inptr++;
*cnt = bytebuf[inlen] - inptr;
*wch = *inptr;
}
}
$ gcc -O3 -Wall -o foo.s -S foo.c
foo.c: In function ‘foo’:
foo.c:11:16: warning: array subscript is above array bounds [-Warray-bounds]
bytebuf[inlen++] = *inptr++;
^
The warning disappears when one adds -fno-tree-vrp to the compile command.
The actual error appears when building the iconv bits in glibc.
[Bug middle-end/61294] [4.9 Regression] erroneous memset used with constant zero length parameter warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61294 --- Comment #13 from Siddhesh Poyarekar siddhesh at redhat dot com --- Fixed in glibc: commit 1721f0a406e52f976f9daf6f59acf42c1dbd33ff Author: Siddhesh Poyarekar siddh...@redhat.com Date: Thu Nov 27 11:15:45 2014 +0530 Don't use __warn_memset_zero_len for gcc-5.0 or newer gcc now warns when the arguments to memset may have been accidentally transposed (i.e. length set to zero instead of the byte), so we don't need that bit of the code in glibc headers anymore. Tested on x86_64. Coe generated by gcc 4.8 is identical with or without the patch. I also tested gcc master, which does not result in any new failures. It does fail quite a few FORTIFY_SOURCE tests, but those failures are not due to this patch.
[Bug c++/27557] OpenMP threadprivate directive does not work with non-POD types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27557 --- Comment #14 from Siddhesh Poyarekar siddhesh at redhat dot com --- I spoke to Jason last week and have now confirmed that the first fragment indeed works correctly with 4.8. Declaring a variable threadprivate *after* it is defined is not yet supported, but it should not be very difficult to work around that limitation. I also have confirmation that the glibc support in place for threadprivate/thread_local is sufficient and complete, so I'm closing out the glibc TODO item.
[Bug c++/27557] OpenMP threadprivate directive does not work with non-POD types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27557 Siddhesh Poyarekar siddhesh at redhat dot com changed: What|Removed |Added CC||siddhesh at redhat dot com --- Comment #11 from Siddhesh Poyarekar siddhesh at redhat dot com --- I had added __cxa_thread_atexit_impl to glibc earlier this year to support c++11 thread_local destructors[1][2]. Wouldn't that be good enough support from glibc for openmp too? [1] http://sourceware.org/glibc/wiki/Destructor%20support%20for%20thread_local%20variables [2] http://sourceware.org/git/?p=glibc.git;a=commit;h=ba384f6ed9275f3966505f2375b56d169e3dc588
[Bug libgcc/56101] pthread program abort
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56101 Siddhesh Poyarekar siddhesh at redhat dot com changed: What|Removed |Added CC||siddhesh at redhat dot com --- Comment #2 from Siddhesh Poyarekar siddhesh at redhat dot com --- It's because libpthread dynamically loads libgcc_s.so.1. As a result there are two copies of dwarf_reg_size_table, where one (the dynamic one) is initialized and the other (the static one) is used, resulting in this crash.
[Bug libgcc/56101] pthread program abort
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56101
--- Comment #3 from Siddhesh Poyarekar siddhesh at redhat dot com ---
Here's the simplified non-preprocessed test, since it's not a problem with the
compiler proper:
$ cat tmain.C
#include pthread.h
#include stdlib.h
#include stdio.h
extern C
void *worker_thread(void *tap)
{
int j[1] = { 0 };
j[0] += *(int *)tap;
pthread_exit(NULL);
return NULL;
}
int main(void)
{
pthread_t t;
int targs;
if (pthread_create(t, NULL, worker_thread, targs) != 0)
exit(-1);
return(pthread_join(t, NULL));
}
[Bug libgcc/55779] Debug program abort on pthread_exit() while using -static-libgcc and -static-libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55779 Siddhesh Poyarekar siddhesh at redhat dot com changed: What|Removed |Added CC||siddhesh at redhat dot com --- Comment #1 from Siddhesh Poyarekar siddhesh at redhat dot com --- Same as bug 56101.
[Bug debug/53860] [4.8 Regression] ICE: in should_move_die_to_comdat, at dwarf2out.c:6254 with -fkeep-inline-functions -fdebug-types-section -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53860 Siddhesh Poyarekar siddhesh at redhat dot com changed: What|Removed |Added CC||siddhesh at redhat dot com --- Comment #2 from Siddhesh Poyarekar siddhesh at redhat dot com 2012-11-16 03:00:28 UTC --- (In reply to comment #1) It is caused by revision 188621: http://gcc.gnu.org/ml/gcc-cvs/2012-06/msg00531.html This was reverted with r189311, so the ICE is not reproducible anymore.
