[Bug libgcc/56101] pthread program abort
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56101 Siddhesh Poyarekar changed: What|Removed |Added CC||siddhesh at redhat dot com --- Comment #2 from Siddhesh Poyarekar --- 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 ---
Here's the simplified non-preprocessed test, since it's not a problem with the
compiler proper:
$ cat > tmain.C
#include
#include
#include
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 changed: What|Removed |Added CC||siddhesh at redhat dot com --- Comment #1 from Siddhesh Poyarekar --- Same as bug 56101.
[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 changed: What|Removed |Added CC||siddhesh at redhat dot com --- Comment #11 from Siddhesh Poyarekar --- 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 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 changed: What|Removed |Added CC||siddhesh at redhat dot com --- Comment #2 from Siddhesh Poyarekar 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.
[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 --- 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 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 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 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 --- Fixed in glibc: commit 1721f0a406e52f976f9daf6f59acf42c1dbd33ff Author: Siddhesh Poyarekar 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.
