[Bug plugins/52872] --enable-plugin; incorrect test for "exported symbols" and "-rdynamic" in gcc/configure.ac
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52872 --- Comment #4 from Karlson2k 2013-03-03 10:25:47 UTC --- Created attachment 29569 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29569 Possible patch
[Bug plugins/52872] --enable-plugin; incorrect test for "exported symbols" and "-rdynamic" in gcc/configure.ac
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52872
Karlson2k changed:
What|Removed |Added
CC||k2k at narod dot ru
--- Comment #5 from Karlson2k 2013-03-03 10:27:36 UTC ---
Simple patch is attached.
--- gcc/configure.ac.orig2012-09-13 17:32:31 +0400
+++ gcc/configure.ac2013-03-03 14:15:11 +0400
@@ -5117,15 +5117,15 @@ if test x"$enable_plugin" = x"yes"; then
AC_MSG_CHECKING([for exported symbols])
if test "x$export_sym_check" != x; then
echo "int main() {return 0;} int foobar() {return 0;}" > conftest.c
-${CC} ${CFLAGS} ${LDFLAGS} conftest.c -o conftest > /dev/null 2>&1
-if $export_sym_check conftest | grep foobar > /dev/null; then
+${CC} ${CFLAGS} ${LDFLAGS} conftest.c -o conftest$ac_exeext > /dev/null
2>&1
+if $export_sym_check conftest$ac_exeext | grep foobar > /dev/null; then
: # No need to use a flag
AC_MSG_RESULT([yes])
else
AC_MSG_RESULT([yes])
AC_MSG_CHECKING([for -rdynamic])
- ${CC} ${CFLAGS} ${LDFLAGS} -rdynamic conftest.c -o conftest > /dev/null
2>&1
- if $export_sym_check conftest | grep foobar > /dev/null; then
+ ${CC} ${CFLAGS} ${LDFLAGS} -rdynamic conftest.c -o conftest$ac_exeext >
/dev/null 2>&1
+ if $export_sym_check conftest$ac_exeext | grep foobar > /dev/null; then
plugin_rdynamic=yes
pluginlibs="-rdynamic"
else
Should I sent it to mailing list?
[Bug plugins/52872] --enable-plugin; incorrect test for "exported symbols" and "-rdynamic" in gcc/configure.ac
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52872 --- Comment #6 from Kai Tietz 2013-03-03 10:29:42 UTC --- Yes, patch looks reasonable. Please sent it to patch ML. This patch is small, so it is ok, but do you have already made paper-work with FSF for gcc?
[Bug tree-optimization/56501] gcc 4.6 ICE on noreturn function at -Os and above
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56501 Mikael Pettersson changed: What|Removed |Added CC||mikpe at it dot uu.se --- Comment #1 from Mikael Pettersson 2013-03-03 11:06:24 UTC --- The original ICE stopped occurring for 4.7 in r171450, which added an FRE pass after early SRA. From that point on it reproduces with -Os -fno-tree-free. It then stopped again for 4.8 in r186901, Steven Bosscher's "Simplify tree-switch-conversion.c a bit - prep work for gimple switch lowering" patch. The ICE in 4.7 occurs because tree-switch-conversion.c:check_process_case calls single_succ on a bb that has NULL succs, leading to a SEGV in VEC_edge_base_index. The patch in r186901 doesn't apply at all to 4.7, and I don't see any obvious bug fix in it that could be cherry-picked and applied to 4.7.
[Bug debug/56510] [4.8 Regression] More var-tracking scalability problems
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56510 Steven Bosscher changed: What|Removed |Added CC|steven at gcc dot gnu.org |aoliva at gcc dot gnu.org, ||jakub at gcc dot gnu.org Target Milestone|--- |4.8.0 Summary|adding -g compiles |[4.8 Regression] More |'forever' vs 49s|var-tracking scalability ||problems --- Comment #5 from Steven Bosscher 2013-03-03 11:49:13 UTC --- Indeed, var-tracking... variable tracking :21235.89 (99%) usr TOTAL :21409.16 May be a dup of bug 54402 or bug 55092 but I'll leave it to someone else to figure that out...
[Bug middle-end/55266] vector expansion: 24 movs for 4 adds
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55266
--- Comment #4 from vincenzo Innocente
2013-03-03 11:58:24 UTC ---
I see still problems when calling inline functions.
It seems that the code to satisfy the "calling ABI" is generated anyhow.
take the example below and compare the code generated for "dotd1" wrt "dotd2"
dotd2 has a "storm" of move before the reduction
c++ -std=c++11 -Ofast -march=corei7 -S conversions.cc -fabi-version=0
the avx version is better but for dotd4 (actually dotd1 is lelf see like)
typedef float __attribute__( ( vector_size( 16 ) ) ) float32x4_t;
typedef double __attribute__( ( vector_size( 32 ) ) ) float64x4_t;
inline
float64x4_t convert(float32x4_t f) {
return float64x4_t{f[0],f[1],f[2],f[3]};
}
float dotf(float32x4_t x, float32x4_t y) {
float ret=0;
for (int i=0;i!=4;++i) ret+=x[i]*y[i];
return ret;
}
inline
double dotd(float64x4_t x, float64x4_t y) {
double ret=0;
for (int i=0;i!=4;++i) ret+=x[i]*y[i];
return ret;
}
float dotd1(float32x4_t x, float32x4_t y) {
float64x4_t dx,dy;
for (int i=0;i!=4;++i) {
dx[i]=x[i]; dy[i]=y[i];
}
double ret=0;
for (int i=0;i!=4;++i) ret+=dx[i]*dy[i];
return ret;
}
float dotd2(float32x4_t x, float32x4_t y) {
float64x4_t dx=convert(x);
float64x4_t dy=convert(y);
return dotd(dx,dy);
}
float dotd3(float32x4_t x, float32x4_t y) {
float64x4_t dx{x[0],x[1],x[2],x[3]};
float64x4_t dy{y[0],y[1],y[2],y[3]};
double ret=0;
for (int i=0;i!=4;++i) ret+=dx[i]*dy[i];
return ret;
}
float dotd4(float32x4_t x, float32x4_t y) {
float64x4_t dx,dy;
for (int i=0;i!=4;++i) {
dx[i]=x[i]; dy[i]=y[i];
}
return dotd(dx,dy);
}
[Bug rtl-optimization/50728] Inefficient vector loads from aggregates passed by value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50728
--- Comment #5 from vincenzo Innocente
2013-03-03 12:01:23 UTC ---
crosspost with PR55266.
feel free to consolidate in a single PR
I see still problems when calling inline functions.
It seems that the code to satisfy the "calling ABI" is generated anyhow.
take the example below and compare the code generated for "dotd1" wrt "dotd2"
dotd2 has a "storm" of move before the reduction
c++ -std=c++11 -Ofast -march=corei7 -S conversions.cc -fabi-version=0
the avx version is better but for dotd4 (actually dotd1 is lelf see like)
typedef float __attribute__( ( vector_size( 16 ) ) ) float32x4_t;
typedef double __attribute__( ( vector_size( 32 ) ) ) float64x4_t;
inline
float64x4_t convert(float32x4_t f) {
return float64x4_t{f[0],f[1],f[2],f[3]};
}
float dotf(float32x4_t x, float32x4_t y) {
float ret=0;
for (int i=0;i!=4;++i) ret+=x[i]*y[i];
return ret;
}
inline
double dotd(float64x4_t x, float64x4_t y) {
double ret=0;
for (int i=0;i!=4;++i) ret+=x[i]*y[i];
return ret;
}
float dotd1(float32x4_t x, float32x4_t y) {
float64x4_t dx,dy;
for (int i=0;i!=4;++i) {
dx[i]=x[i]; dy[i]=y[i];
}
double ret=0;
for (int i=0;i!=4;++i) ret+=dx[i]*dy[i];
return ret;
}
float dotd2(float32x4_t x, float32x4_t y) {
float64x4_t dx=convert(x);
float64x4_t dy=convert(y);
return dotd(dx,dy);
}
float dotd3(float32x4_t x, float32x4_t y) {
float64x4_t dx{x[0],x[1],x[2],x[3]};
float64x4_t dy{y[0],y[1],y[2],y[3]};
double ret=0;
for (int i=0;i!=4;++i) ret+=dx[i]*dy[i];
return ret;
}
float dotd4(float32x4_t x, float32x4_t y) {
float64x4_t dx,dy;
for (int i=0;i!=4;++i) {
dx[i]=x[i]; dy[i]=y[i];
}
return dotd(dx,dy);
}
[Bug debug/56510] [4.8 Regression] More var-tracking scalability problems
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56510 --- Comment #6 from Jakub Jelinek 2013-03-03 12:08:19 UTC --- Why are you marking this as 4.8 Regression, when the reporter says the same problem is there for 4.6 already?
[Bug debug/56510] [4.7/4.8 Regression] More var-tracking scalability problems
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56510 Steven Bosscher changed: What|Removed |Added Summary|[4.8 Regression] More |[4.7/4.8 Regression] More |var-tracking scalability|var-tracking scalability |problems|problems --- Comment #7 from Steven Bosscher 2013-03-03 12:16:18 UTC --- (In reply to comment #6) > Why are you marking this as 4.8 Regression, when the reporter says the same > problem is there for 4.6 already? Because I've confirmed it as a regression of GCC 4.8 from GCC 4.2, also as the reported said. I haven't confirmed it for GCC 4.6. I've just now confirmed that GCC 4.7 has the same problem. Just -fno-var-tracking-assignments is enough to have sensible compile time. Not unexpected either, of course...
[Bug debug/56510] [4.7/4.8 Regression] More var-tracking scalability problems
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56510
--- Comment #8 from Jakub Jelinek 2013-03-03
12:40:09 UTC ---
Reduced testcase:
struct S { unsigned long s1; void **s2[0]; };
void **a, **b, **c, **d, **e, **f;
static void **
baz (long x, long y)
{
void **s = f;
*f = (void **) (y << 8 | (x & 0xff));
f += y + 1;
return s;
}
void bar (void);
void
foo (void)
{
void **g = b[4];
a = b[2];
b = b[1];
g[2] = e;
void **h = ((void ***)
a)[1][1][1][1][1][1][1][1][1][1][1][1][1][66];
void **i = ((struct S *) h)->s2[4];
d = baz (4, 3);
d[1] = b;
d[2] = a;
d[3] = bar;
b = d;
g[1] = i[2];
a = g;
((void (*) (void)) (i[1])) ();
}
I'd say the problem is that during expansion we turn:
_10 = MEM[(void * * * * * * * * * * * * * * *)a.1_4 + 8B];
_11 = MEM[(void * * * * * * * * * * * * * *)_10 + 8B];
_12 = MEM[(void * * * * * * * * * * * * *)_11 + 8B];
_13 = MEM[(void * * * * * * * * * * * *)_12 + 8B];
_14 = MEM[(void * * * * * * * * * * *)_13 + 8B];
_15 = MEM[(void * * * * * * * * * *)_14 + 8B];
_16 = MEM[(void * * * * * * * * *)_15 + 8B];
_17 = MEM[(void * * * * * * * *)_16 + 8B];
_18 = MEM[(void * * * * * * *)_17 + 8B];
_19 = MEM[(void * * * * * *)_18 + 8B];
_20 = MEM[(void * * * * *)_19 + 8B];
_21 = MEM[(void * * * *)_20 + 8B];
_22 = MEM[(void * * *)_21 + 8B];
h_23 = MEM[(void * *)_22 + 528B];
# DEBUG h => h_23
i_24 = MEM[(struct S *)h_23].s2[4];
into:
(debug_insn 14 13 15 2 (var_location:DI h (mem/f:DI (plus:DI (mem/f:DI (plus:DI
(mem/f:DI (plus:DI (mem/f:DI (plus:DI (mem/f:DI (plus:DI (mem/f:DI
(plus:DI (mem/f:DI (plus:DI (mem/f:DI (plus:DI (mem/f:DI (plus:DI (mem/f:DI
(plus:DI (mem/f:DI (plus:DI (mem/f:DI (plus:DI (mem/f:DI (plus:DI (mem/
f:DI (plus:DI (reg/f:DI 61 [ a.1 ])
(const_int 8 [0x8])) [0 MEM[(vo
id * * * * * * * * * * * * * * *)a.1_4 + 8B]+0 S8 A64])
(const_int 8 [0x8])) [0 MEM[(void * * *
* * * * * * * * * * *)_10 + 8B]+0 S8 A64])
(const_int 8 [0x8])) [0 MEM[(void * * * * * * *
* * * * * *)_11 + 8B]+0 S8 A64])
(const_int 8 [0x8])) [0 MEM[(void * * * * * * * * * * *
*)_12 + 8B]+0 S8 A64])
(const_int 8 [0x8])) [0 MEM[(void * * * * * * * * * * *)_13 + 8
B]+0 S8 A64])
(const_int 8 [0x8])) [0 MEM[(void * * * * * * * * * *)_14 + 8B]+0 S8 A6
4])
(const_int
8 [0x8])) [0 MEM[(void * * * * * * * * *)_15 + 8B]+0 S8 A64])
(const_int 8
[0x8])) [0 MEM[(void * * * * * * * *)_16 + 8B]+0 S8 A64])
(const_int 8 [0x8])) [0
MEM[(void * * * * * * *)_17 + 8B]+0 S8 A64])
(const_int 8 [0x8])) [0 MEM[(void *
* * * * *)_18 + 8B]+0 S8 A64])
(const_int 8 [0x8])) [0 MEM[(void * * * *
*)_19 + 8B]+0 S8 A64])
(const_int 8 [0x8])) [0 MEM[(void * * * *)_20 +
8B]+0 S8 A64])
(const_int 8 [0x8])) [0 MEM[(void * * *)_21 + 8B]+0 S8
A64])
(const_int 528 [0x210])) [0 MEM[(void * *)_22 + 528B]+0 S8 A64]))
pr56510-2.i:21 -1
(nil))
which is simply too large for any reasonable cselib handling, it would better
be split using debug temporaries.
OT, are you sure the testcase doesn't violate aliasing just about everywhere?
[Bug debug/56510] [4.7/4.8 Regression] More var-tracking scalability problems
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56510 --- Comment #9 from Steven Bosscher 2013-03-03 12:50:32 UTC --- (In reply to comment #8) > OT, are you sure the testcase doesn't violate aliasing just about > everywhere? At least -Wstrict-aliasing=2 doesn't think so, but it's certainly a test case that shows the worst one can do with C pointers :-) There is one pointer-to-int cast warning: self/compile.c:1766:8: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
[Bug c/56512] New: Memory corruption when compiling code with -O on PowerPC when using setjmp/longjmp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56512 Bug #: 56512 Summary: Memory corruption when compiling code with -O on PowerPC when using setjmp/longjmp Classification: Unclassified Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: erik.bra...@gmx.de Created attachment 29570 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29570 preproccessed file of the code, fails on -O (but not on -O0 or -O2) The code from the attached file (adapted from a Wikipedia example) shows the following (correct) output on -O0 and -O2: Child loop begin Parent Child loop end Parent The output on -O is: Child loop begin Parent ��g Parent The third line is different every time, so I suspect it's some garbage from memory. The output of gcc -v is: Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/powerpc-linux-gnu/4.7/lto-wrapper Target: powerpc-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.7.2-19ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs --enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.7 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.7 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libitm --enable-plugin --with-system-zlib --enable-objc-gc --enable-secureplt --disable-softfloat --with-cpu=default32 --disable-softfloat --enable-targets=powerpc-linux,powerpc64-linux --enable-multiarch --disable-werror --with-long-double-128 --enable-checking=release --build=powerpc-linux-gnu --host=powerpc-linux-gnu --target=powerpc-linux-gnu Thread model: posix gcc version 4.7.2 (Ubuntu/Linaro 4.7.2-19ubuntu1) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O' /usr/lib/gcc/powerpc-linux-gnu/4.7/cc1 -E -quiet -v -imultilib . -imultiarch powerpc-linux-gnu -D__unix__ -D__gnu_linux__ -D__linux__ -Dunix -D__unix -Dlinux -D__linux -Asystem=linux -Asystem=unix -Asystem=posix powerPCSetjmpLongjmpCorruption.c -msecure-plt -O -fpch-preprocess -fstack-protector -o powerPCSetjmpLongjmpCorruption.i ignoring nonexistent directory "/usr/local/include/powerpc-linux-gnu" ignoring nonexistent directory "/usr/lib/gcc/powerpc-linux-gnu/4.7/../../../../powerpc-linux-gnu/include" #include "..." search starts here: #include <...> search starts here: /usr/lib/gcc/powerpc-linux-gnu/4.7/include /usr/local/include /usr/lib/gcc/powerpc-linux-gnu/4.7/include-fixed /usr/include/powerpc-linux-gnu /usr/include End of search list. COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O' /usr/lib/gcc/powerpc-linux-gnu/4.7/cc1 -fpreprocessed powerPCSetjmpLongjmpCorruption.i -msecure-plt -quiet -dumpbase powerPCSetjmpLongjmpCorruption.c -auxbase powerPCSetjmpLongjmpCorruption -O -version -fstack-protector -o powerPCSetjmpLongjmpCorruption.s GNU C (Ubuntu/Linaro 4.7.2-19ubuntu1) version 4.7.2 (powerpc-linux-gnu) compiled by GNU C version 4.7.2, GMP version 5.0.5, MPFR version 3.1.0-p10, MPC version 0.9 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU C (Ubuntu/Linaro 4.7.2-19ubuntu1) version 4.7.2 (powerpc-linux-gnu) compiled by GNU C version 4.7.2, GMP version 5.0.5, MPFR version 3.1.0-p10, MPC version 0.9 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 674c851c1ddb45d49217fc2d358e8b83 COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O' as -v -a32 -mppc -many -o powerPCSetjmpLongjmpCorruption.o powerPCSetjmpLongjmpCorruption.s GNU assembler version 2.23.1 (powerpc-linux-gnu) using BFD version (GNU Binutils for Ubuntu) 2.23.1 COMPILER_PATH=/usr/lib/gcc/powerpc-linux-gnu/4.7/:/usr/lib/gcc/powerpc-linux-gnu/4.7/:/usr/lib/gcc/powerpc-linux-gnu/:/usr/lib/gcc/powerpc-linux-gnu/4.7/:/usr/lib/gcc/powerpc-linux-gnu/ LIBRARY_PATH=/usr/lib/gcc/powerpc-linux-gnu/4.7/:/usr/lib/gcc/powerpc-linux-gnu/4.7/../../../powerpc-linux-gnu/:/usr/lib/gcc/powerpc-linux-gnu/4.7/../../../../lib/:/lib/powerpc-linux-gnu/:/lib/../lib/:/usr/lib/powerpc-linux-gnu/:/usr/lib/../lib/:/usr/lib/gcc/powerpc-linux-gnu/4.7/../../../:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O' /usr/lib/gcc/powerpc-linux-gnu/4.7/collect2 --sysroot=/ --build-id --eh-frame-hdr -V -m elf32ppclinux --hash-style=gnu --as-needed -dynamic-linker /lib/ld.so.1 -z relro /usr/lib/gcc/powerpc-linux-gnu/4.7/../../../powerpc-linux-gnu/crt1.o /usr/lib/gcc/powerpc-linux-gnu/4.7/../../../powerpc-linux-gnu/crti.o /usr/lib/gcc/powerpc-linux-gnu/4.7/crtbegin.o -L/usr/lib/gcc/powerpc-linux-gnu/4.7 -L/usr/lib/gcc/powerpc-linux-gnu/4.7/../../../powerpc-linux-gnu -L/usr/lib/gcc/powerpc-linux-gnu/4.7/../../../../lib -L/lib/pow
[Bug c/56512] Memory corruption when compiling code with -O on PowerPC when using setjmp/longjmp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56512 --- Comment #1 from Mikael Pettersson 2013-03-03 14:43:40 UTC --- This test case is full of undefined behaviour: - you longjmp out of a frame to an older frame, and then expect to be able to longjmp back into the younger frame; that doesn't work in general - your counter variable isn't volatile (read the C standard on restrictions of auto variables in functions invoking setjmp) Your call_with_cushion() won't do what you think as the auto buffer is dead at the point of the tailcall. Is this a flawed attempt to implement coroutines?
[Bug plugins/52872] --enable-plugin; incorrect test for "exported symbols" and "-rdynamic" in gcc/configure.ac
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52872 --- Comment #7 from Karlson2k 2013-03-03 14:57:11 UTC --- (In reply to comment #6) > Yes, patch looks reasonable. Please sent it to patch ML. > This patch is small, so it is ok, but do you have already made paper-work with > FSF for gcc? This patch is simple as possible, to be quickly get it. But there are some space to improvement (like using standard macros, properly redirect error output). I'm not sure is it worth to work on it. To answer your question: no. What should I do?
[Bug c/56512] Memory corruption when compiling code with -O on PowerPC when using setjmp/longjmp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56512 --- Comment #2 from Erik Brangs 2013-03-03 15:41:21 UTC --- I'm actually trying to reproduce another bug with setjmp/longjmp on PowerPC (one that leads to the error message "longjmp causes unitialized stack frame"). Unfortunately, I haven't yet succeeded in extracting a suitable testcase from that because there is a lot of of code (including code not in C and not compiled by gcc) between the call to setjmp and the call to longjmp. In that case, the function where the setjmp happens is "exited" via a call to another function so the frame should be left intact. I was hoping that the behaviour from the attached file might be related, but it seems that this is not the case. The explanation on Wikipedia said that returning to a frame that has been exited via longjmp out is undefined in C99. Is that also the case in older standards? I'll just resolve this bug if there's nothing salvagable in the attached file. Thanks for taking time to help me.
[Bug c/56512] Memory corruption when compiling code with -O on PowerPC when using setjmp/longjmp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56512 Erik Brangs changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #3 from Erik Brangs 2013-03-03 16:44:24 UTC --- It seems that the "testcase" isn't salvagable because the behaviour is also undefined in early C standards.
[Bug other/54500] While(TRUE) loop optimization of global struct variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54500 Georg-Johann Lay changed: What|Removed |Added Status|WAITING |RESOLVED CC||gjl at gcc dot gnu.org Resolution||INVALID --- Comment #2 from Georg-Johann Lay 2013-03-03 16:55:28 UTC --- No answer and no valid test case for 6 months now. Closed as invalid.
[Bug rtl-optimization/54343] RTL postreload leaks DF memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54343 Steven Bosscher changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #7 from Steven Bosscher 2013-03-03 17:09:16 UTC --- Perhaps Jakub can have a look at this memleak, too? He's been on an impressive leak-plugging spree lately :-)
[Bug fortran/55343] Renamed C_PTR entities are not treated as equivalent types.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55343 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-03-03 CC||mikael.morin at sfr dot fr Ever Confirmed|0 |1 --- Comment #1 from Dominique d'Humieres 2013-03-03 17:31:33 UTC --- > ... This used to work in Gnu > fortran, but I don't know what version I was using at that time. I did not do an exhaustive search, but the test gives an error for all the versions I have tried. Note the test compiles without error with the Mikael's patch at http://gcc.gnu.org/ml/fortran/2013-03/msg8.html .
[Bug fortran/54730] [4.6/4.7/4.8 Regression] ICE in gfc_typenode_for_spec, at fortran/trans-types.c:1066
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54730 --- Comment #12 from Mikael Morin 2013-03-03 17:34:48 UTC --- Author: mikael Date: Sun Mar 3 17:34:42 2013 New Revision: 196414 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196414 Log: fortran/ PR fortran/54730 * gfortran.h (struct gfc_undo_change_set): New field 'previous'. (gfc_new_undo_checkpoint, gfc_drop_last_undo_checkpoint, gfc_restore_last_undo_checkpoint): New prototypes. * symbol.c (default_undo_chgset_var): Update initialization. (single_undo_checkpoint_p, gfc_new_undo_checkpoint, free_undo_change_set_data, pop_undo_change_set, gfc_drop_last_undo_checkpoint, enforce_single_undo_checkpoint): New functions. (save_symbol_data): Handle multiple change sets. Make sure old_symbol field's previous value is not overwritten. Clear gfc_new field. (restore_old_symbol): Restore previous old_symbol field. (gfc_restore_last_undo_checkpoint): New function, using body renamed from gfc_undo_symbols. Restore the previous change set as current one. (gfc_undo_symbols): New body. (gfc_commit_symbols, gfc_commit_symbol, gfc_enforce_clean_symbol_state): Call enforce_single_undo_checkpoint. (gfc_symbol_done_2): Ditto. Free change set data. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/symbol.c
[Bug fortran/54730] [4.6/4.7/4.8 Regression] ICE in gfc_typenode_for_spec, at fortran/trans-types.c:1066
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54730 --- Comment #13 from Mikael Morin 2013-03-03 17:52:10 UTC --- Author: mikael Date: Sun Mar 3 17:52:02 2013 New Revision: 196416 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196416 Log: fortran/ PR fortran/54730 * array.c (gfc_match_array_constructor): Set a checkpoint before matching a typespec. Drop it on success, restore it otherwise. testsuite/ PR fortran/54730 * gfortran.dg/array_constructor_42.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/array_constructor_42.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/array.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/55362] [4.6/4.7 Regression] ICE with size() on character pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55362 --- Comment #7 from paul.richard.thomas at gmail dot com 2013-03-03 18:09:08 UTC --- Thanks Mikael, I have been in the middle of one of my "no gfortran periods". I am back in France next week and will get to this on Tuesday or Wednesday. Cheers Paul On 2 March 2013 18:25, mikael at gcc dot gnu.org wrote: > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55362 > > Mikael Morin changed: > >What|Removed |Added > > CC||mikael at gcc dot gnu.org > > --- Comment #6 from Mikael Morin 2013-03-02 > 17:25:25 UTC --- > (In reply to comment #5) >> I'll deal with 4.6 and 4.7 tomorrow >> > Friendly reminder... :-) > > -- > Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email > --- You are receiving this mail because: --- > You are on the CC list for the bug. > You are the assignee for the bug. -- The knack of flying is learning how to throw yourself at the ground and miss. --Hitchhikers Guide to the Galaxy
[Bug fortran/54730] [4.6/4.7 Regression] ICE in gfc_typenode_for_spec, at fortran/trans-types.c:1066
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54730 Mikael Morin changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|4.6.4 |4.8.0 Summary|[4.6/4.7/4.8 Regression]|[4.6/4.7 Regression] ICE in |ICE in |gfc_typenode_for_spec, at |gfc_typenode_for_spec, at |fortran/trans-types.c:1066 |fortran/trans-types.c:1066 | --- Comment #14 from Mikael Morin 2013-03-03 18:13:28 UTC --- Fixed for 4.8.0. No backport, as the fix uses the vec API, which has been rewritten (using C++ features).
[Bug target/56513] New: Wrong code generation with -O3 on ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56513 Bug #: 56513 Summary: Wrong code generation with -O3 on ARM Classification: Unclassified Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: tim.ko...@filezilla-project.org Created attachment 29571 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29571 Small test program exhibiting the problem If I'm cross-compiling the attached sample-program using gcc 4.7.2 for ARM on an x86-64 system, the resulting binary behaves wrongly if -O3 is used. Output with -O0: value: -23 best: -1 a: -68 value: -22 best: -23 a: -23 Output with -O3: value: -23 best: -1 a: -68 value: -22 best: -23 a: 65513 BUG
[Bug target/56513] Wrong code generation with -O3 on ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56513 --- Comment #1 from Tim Kosse 2013-03-03 18:47:18 UTC --- Created attachment 29572 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29572 Preprocessed file Created using the following command: arm-unknown-linux-gnueabi-g++ -v -save-temps -O3 bug.cpp
[Bug target/56513] Wrong code generation with -O3 on ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56513 --- Comment #2 from Tim Kosse 2013-03-03 18:48:49 UTC --- Created attachment 29573 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29573 Compiler output Output of arm-unknown-linux-gnueabi-g++ -v -save-temps -O3 bug.cpp
[Bug target/56513] Wrong code generation with -O3 on ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56513 --- Comment #3 from Tim Kosse 2013-03-03 18:55:20 UTC --- Also happens with GCC 4.7.1 and 4.6.3.
[Bug tree-optimization/56270] loop over array of struct float causes compiler error: segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56270 Mikael Pettersson changed: What|Removed |Added CC||mikpe at it dot uu.se --- Comment #2 from Mikael Pettersson 2013-03-03 19:43:14 UTC --- This was fixed for 4.8 by Jan Hubicka's r193175, which rewrote finite_loop_p in tree-ssa-loop-niter.c. That patch doesn't work as-is in 4.7.2 (it applies but uses other things which aren't in 4.7.2.) The SEGV in 4.7.2 occurs in tree-vect-stmts.c:3938 3938 gcc_assert (useless_type_conversion_p (vectype, 3939 TREE_TYPE (vec_oprnd))); because vec_oprnd is NULL at that point.
[Bug c++/56506] variadic class template specialization not selected as best match
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56506
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler at
||googlemail dot com
--- Comment #2 from Daniel Krügler
2013-03-03 19:46:42 UTC ---
I don't think that either example should be accepted. My understanding is, that
the second T is still considered as a parameter pack but not as an expansion
(because it is not followed by ...) at the time of pattern match checking,
therefore the compiler would try to match a sequence of expansions from the
first T... with a corresponding parameter pack. But this pack is always
considered as a different type, even if it would contain the same single type
(e.g. consider an argument type Y, int> where we would try to match
'int' with '[int]' where I use square brackets to denote the still existing
pack). So both cannot be the same type, and this specialization can never be
found. It would work, if you would declare the partial specialization as:
template
struct X, U>...>
{
typedef int type;
};
because now the compiler don't needs to cross-match corresponding T expansions
with the U pack.
I understand that this is a somewhat more generous specialization as you would
like to have, though.
[Bug fortran/56477] [4.8 Regression] ICE on invalid with pointer assignment to function result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56477 --- Comment #3 from Mikael Morin 2013-03-03 19:58:53 UTC --- Author: mikael Date: Sun Mar 3 19:58:49 2013 New Revision: 196417 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196417 Log: fortran/ PR fortran/56477 * expr.c (gfc_check_pointer_assign): Avoid NULL pointer dereference. testsuite/ PR fortran/56477 * gfortran.dg/pointer_check_13.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/pointer_check_13.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/56477] [4.8 Regression] ICE on invalid with pointer assignment to function result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56477 Mikael Morin changed: What|Removed |Added Status|NEW |RESOLVED CC||mikael at gcc dot gnu.org Resolution||FIXED --- Comment #4 from Mikael Morin 2013-03-03 20:01:44 UTC --- Fixed.
[Bug target/56513] Wrong code generation with -O3 on ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56513 Mikael Pettersson changed: What|Removed |Added CC||mikpe at it dot uu.se --- Comment #4 from Mikael Pettersson 2013-03-03 20:11:08 UTC --- I can reproduce the wrong-code on armv5tel-linux-gnueabi with gcc-4.7-20130302 and gcc-4.6-20121109, but not with gcc-4.8-20130224. I can't reproduce on x86_64, sparc64, aarch64, or m68k.
[Bug rtl-optimization/56514] New: Using -fdisable-rtl-ira makes gcc crash (segfault)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56514 Bug #: 56514 Summary: Using -fdisable-rtl-ira makes gcc crash (segfault) Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: rtl-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: k...@free.fr Created attachment 29574 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29574 Sample code to reproduce the issue I've tried using -fdisable-rtl-ira on several files with several levels of optimisations, gcc always crashes (tested on 4.7.2 and ef11013858b41453c4953ca8d4c25e3b1668e536 for the x86_64 and avr targets). Simply do "gcc -fdisable-rtl-ira -save-temps -c main.c -o main.o" on the attached file to reproduce the issue.
[Bug rtl-optimization/56514] Using -fdisable-rtl-ira makes gcc crash (segfault)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56514 Andrew Pinski changed: What|Removed |Added Severity|major |minor --- Comment #1 from Andrew Pinski 2013-03-03 23:24:07 UTC --- >From the documnetation: "These options are intended for use for debugging GCC. Compiler users should use regular options for enabling/disabling passes instead." So yes this is exacted to crash as you just disabled the register allocator. Basically this is the case where you tell the doctor it hurts when you move your hand a specific way and the doctor tells you don't move it that way your hand was not designed to move that way.
[Bug target/56513] Wrong code generation with -O3 on ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56513 --- Comment #5 from Mikael Pettersson 2013-03-03 23:26:49 UTC --- The wrong-code stopped for 4.8 with r188526, the introduction and enabling of -ftree-coalesce-vars. At that point the wrong-code reappears with -O3 -fno-tree-coalesce-vars, however with current trunk those options give correct code. I'll investigate some more tomorrow.
[Bug c++/56464] Crashes when using implicit this in a lambda capture in member initializer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56464 Jason Merrill changed: What|Removed |Added Status|RESOLVED|NEW CC||jason at gcc dot gnu.org Resolution|DUPLICATE | --- Comment #6 from Jason Merrill 2013-03-04 03:12:05 UTC --- Not a duplicate. 54367 is the case where there is no 'this', this bug is the case where 'this' is for a NSDMI.
[Bug lto/56515] New: location references block not in block tree, verify_gimple failed (LTO + profile)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56515
Bug #: 56515
Summary: location references block not in block tree,
verify_gimple failed (LTO + profile)
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: d.g.gorbac...@gmail.com
GCC 4.8.0 20130303 (experimental):
foo.c: In function 'foo':
foo.c:1:6: error: location references block not in block tree
void foo(void) { }
^
# .MEM_10 = VDEF <.MEM_6(D)>
bar = 1;
foo.c:1:6: internal compiler error: verify_gimple failed
0x85df8f2 verify_gimple_in_cfg(function*)
../../gcc-4.8/gcc/tree-cfg.c:4727
0x84d520c execute_function_todo
../../gcc-4.8/gcc/passes.c:1963
0x84d455d do_per_function
../../gcc-4.8/gcc/passes.c:1701
0x84d532d execute_todo
../../gcc-4.8/gcc/passes.c:1996
0x84d57a1 execute_one_ipa_transform_pass
../../gcc-4.8/gcc/passes.c:2182
0x84d5873 execute_all_ipa_transforms()
../../gcc-4.8/gcc/passes.c:2208
0x8206775 expand_function
../../gcc-4.8/gcc/cgraphunit.c:1633
0x8206cda expand_all_functions
../../gcc-4.8/gcc/cgraphunit.c:1744
0x8207763 compile()
../../gcc-4.8/gcc/cgraphunit.c:2042
0x816b85d lto_main()
../../gcc-4.8/gcc/lto/lto.c:3396
[Bug lto/56515] location references block not in block tree, verify_gimple failed (LTO + profile)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56515 --- Comment #1 from Dmitry Gorbachev 2013-03-04 05:20:49 UTC --- Created attachment 29575 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29575 Bt from 4.7.3 GCC 4.8.0 20130127 (r195497) fails, too; 20130113 (r195137) - ok. GCC 4.8.0 20120916 (r191367) and earlier builds / versions (4.7, 4.6) fail with sigsegv in prepend_lexical_block().
[Bug lto/56515] location references block not in block tree, verify_gimple failed (LTO + profile)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56515 --- Comment #2 from Dmitry Gorbachev 2013-03-04 05:22:09 UTC --- Created attachment 29576 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29576 Testcase
[Bug middle-end/55644] maybe-uninitialized false positive due to incorrect flow analysis when gotos are present
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55644 --- Comment #13 from Dmitry Gorbachev 2013-03-04 05:50:44 UTC --- (In reply to comment #6) > I start to believe we should arrange for --disable-werror for any non-standard > build config ... testing matrix is simply too large and mostly false positives > pop up. Just `-Wno-error=maybe-uninitialized'. `--disable-werror' can hide real bugs.
[Bug target/56470] [4.8 Regression] ICE output_operand: invalid shift operand
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56470 Richard Earnshaw changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-03-04 Ever Confirmed|0 |1 --- Comment #1 from Richard Earnshaw 2013-03-04 07:01:07 UTC --- Confirmed. I'm a bit wary of just truncating the value. Shifts by 32 may be valid in the ARM back-end in some circumstances where we're using the shift as part of setting up the flags. Fixing this fully would require getting rid of "shift_operator" and replacing it with iterators. But that's a pretty radical overhaul. Long term that might well be worthwhile, but not this close to a release.
