[Bug tree-optimization/42108] [4.4/4.5 Regression] Vectorizer cannot deal with PAREN_EXPR gracefully, 50% performance regression
--- Comment #8 from sfilippone at uniroma2 dot it 2009-11-20 08:32 --- (In reply to comment #6) Richard Guenther wrote: Well, within eval there's nothing really obvious to me. The innermost loop is exactly the same: But it is a very inefficient way of vectorizing, because the inner loop's body is either executed twice or three times per outer loop (depending on the value of i). While I agree that I would code in a different way, still there is the change in compiler's behaviour. Although comment 7 indicates it's probably only at 64bits -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42108
[Bug libstdc++/38875] parallel fill and copy in the parallel version of libstdc++
--- Comment #14 from singler at gcc dot gnu dot org 2009-11-20 09:53 --- Created an attachment (id=19064) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19064action=view) Functional patch for parallel fill and fill_n. -- singler at gcc dot gnu dot org changed: What|Removed |Added Attachment #19053|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38875
[Bug libstdc++/38875] parallel fill and copy in the parallel version of libstdc++
--- Comment #15 from singler at gcc dot gnu dot org 2009-11-20 09:56 --- There is slowdown, also for large inputs, for the most simple case, namely filling constant integer values. If assignment is more expensive, thing will get better. Please try with your application. -- singler at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |ASSIGNED Last reconfirmed|2009-01-16 15:51:05 |2009-11-20 09:56:12 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38875
[Bug c++/29017] %s substituted with different untranslated words can't be properly translated
--- Comment #2 from paolo at gcc dot gnu dot org 2009-11-20 10:05 --- Subject: Bug 29017 Author: paolo Date: Fri Nov 20 10:05:37 2009 New Revision: 154360 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154360 Log: /cp 2009-11-20 Shujing Zhao pearly.z...@oracle.com PR c++/29017 * cp-tree.h (composite_pointer_operation): New type. (composite_pointer_type): Adjust prototype with new argument. * typeck.c (composite_pointer_type): Accept composite_pointer_operation as argument and emit diagnostic to be visible to gettext and checked at compile time. (composite_pointer_type_r): Likewise. (common_pointer_type): Update call to composite_pointer_type. (cp_build_binary_op): Likewise. * call.c (build_conditional_expr): Likewise. /testsuite 2009-11-20 Shujing Zhao pearly.z...@oracle.com * g++.old-deja/g++.jason/rfg20.C: Make expected dg-error strings explicit. * g++.old-deja/g++.rfg/00321_01-.C: Likewise. * g++.old-deja/g++.rfg/00324_02-.C: Likewise. * g++.old-deja/g++.law/typeck1.C: Likewise. * g++.old-deja/g++.bugs/900324_02.C: Likewise. * g++.dg/conversion/ptrmem9.C: Likewise. * g++.dg/expr/cond2.C: Likewise. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/cp/cp-tree.h trunk/gcc/cp/typeck.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/conversion/ptrmem9.C trunk/gcc/testsuite/g++.dg/expr/cond2.C trunk/gcc/testsuite/g++.old-deja/g++.bugs/900324_02.C trunk/gcc/testsuite/g++.old-deja/g++.jason/rfg20.C trunk/gcc/testsuite/g++.old-deja/g++.law/typeck1.C trunk/gcc/testsuite/g++.old-deja/g++.rfg/00321_01-.C trunk/gcc/testsuite/g++.old-deja/g++.rfg/00324_02-.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29017
[Bug target/42113] [4.3/4.4/4.5 Regression] Internal Compiler error with -O3, breaking commit known
--- Comment #3 from ubizjak at gmail dot com 2009-11-20 10:06 --- Both files compile OK with 4.5 cross from x86_64-pc-linux-gnu. Probably a target specific patch should be backported from mainline to 4.3 and 4.4 branches. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42113
[Bug c++/29017] %s substituted with different untranslated words can't be properly translated
--- Comment #3 from paolo dot carlini at oracle dot com 2009-11-20 10:07 --- Fixed for 4.5.0. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29017
[Bug target/42113] [4.3/4.4/4.5 Regression] Internal Compiler error with -O3, breaking commit known
--- Comment #4 from ubizjak at gmail dot com 2009-11-20 10:42 --- Confirmed with 4.4 cross. -- ubizjak at gmail dot com changed: What|Removed |Added CC|ubizjak at gmail dot com| AssignedTo|unassigned at gcc dot gnu |ubizjak at gmail dot com |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-11-20 10:42:41 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42113
[Bug rtl-optimization/42116] New: ice on valid code (unrecognizable insn)
Compiling an ARC cross compiler gives ICE: [lu...@localhost gcc]$/home/luben/ware/arc_gcc_rel2.2/gcc/build/./gcc/xgcc -v -save-temps -B/home/luben/ware/arc_gcc_rel2.2/gcc/build/./gcc/ -nostdinc -B/home/luben/ware/arc_gcc_rel2.2/gcc/build/arc-elf32/newlib/ -isystem /home/luben/ware/arc_gcc_rel2.2/gcc/build/arc-elf32/newlib/targ-include -isystem /home/luben/ware/arc_gcc_rel2.2/gcc/src/newlib/libc/sys/arc/sys -isystem /home/luben/ware/arc_gcc_rel2.2/gcc/src/newlib/libc/include -B/opt/arc-tools/arc-elf32/bin/ -B/opt/arc-tools/arc-elf32/lib/ -isystem /opt/arc-tools/arc-elf32/include -isystem /opt/arc-tools/arc-elf32/sys-include -isystem ../../src/gcc/config/arc/gmon -O2 -Wall -g -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -mno-sdata -I. -I. -I../../src/gcc -I../../src/gcc/. -I../../src/gcc/../include -I../../src/gcc/../libcpp/include -I../../src/gcc/../libdecnumber -I../libdecnumber -c -o gmon.o ../../src/gcc/config/arc/gmon/gmon.c -Wno-extra # suppress inane warning about missing initializer. Reading specs from /home/luben/ware/arc_gcc_rel2.2/gcc/build/./gcc/specs Target: arc-elf32 Configured with: ../src/configure --prefix=/opt/arc-tools --target=arc-elf32 --program-prefix=arc- --with-build-time-tools=/opt/arc-tools/bin --with-newlib --with-headers --enable-multilib --enable-languages=c,c++ Thread model: single gcc version 4.2.1 (ARC_2.2) /home/luben/ware/arc_gcc_rel2.2/gcc/build/./gcc/cc1 -E -quiet -nostdinc -v -I. -I. -I../../src/gcc -I../../src/gcc/. -I../../src/gcc/../include -I../../src/gcc/../libcpp/include -I../../src/gcc/../libdecnumber -I../libdecnumber -iprefix /home/luben/ware/arc_gcc_rel2.2/gcc/build/gcc/../lib/gcc/arc-elf32/4.2.1/ -isystem /home/luben/ware/arc_gcc_rel2.2/gcc/build/./gcc/include -D__A5__ -DIN_GCC -DCROSS_COMPILE -isystem /home/luben/ware/arc_gcc_rel2.2/gcc/build/arc-elf32/newlib/targ-include -isystem /home/luben/ware/arc_gcc_rel2.2/gcc/src/newlib/libc/sys/arc/sys -isystem /home/luben/ware/arc_gcc_rel2.2/gcc/src/newlib/libc/include -isystem /opt/arc-tools/arc-elf32/include -isystem /opt/arc-tools/arc-elf32/sys-include -isystem ../../src/gcc/config/arc/gmon -isystem ./include ../../src/gcc/config/arc/gmon/gmon.c -mno-sdata -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wno-extra -fworking-directory -O2 -fpch-preprocess -o gmon.i ignoring nonexistent directory /home/luben/ware/arc_gcc_rel2.2/gcc/build/arc-elf32/newlib/targ-include ignoring nonexistent directory /opt/arc-tools/arc-elf32/include ignoring nonexistent directory /opt/arc-tools/arc-elf32/sys-include ignoring duplicate directory ./include ignoring duplicate directory . ignoring duplicate directory ../../src/gcc/. #include ... search starts here: #include ... search starts here: . ../../src/gcc ../../src/gcc/../include ../../src/gcc/../libcpp/include ../../src/gcc/../libdecnumber ../libdecnumber /home/luben/ware/arc_gcc_rel2.2/gcc/build/./gcc/include /home/luben/ware/arc_gcc_rel2.2/gcc/src/newlib/libc/sys/arc/sys /home/luben/ware/arc_gcc_rel2.2/gcc/src/newlib/libc/include ../../src/gcc/config/arc/gmon End of search list. /home/luben/ware/arc_gcc_rel2.2/gcc/build/./gcc/cc1 -fpreprocessed gmon.i -quiet -dumpbase gmon.c -mno-sdata -auxbase-strip gmon.o -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wno-extra -version -o gmon.s GNU C version 4.2.1 (ARC_2.2) (arc-elf32) compiled by GNU C version 4.4.2. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 4a0a315b8c704b68e64bbad6f09259fc ../../src/gcc/config/arc/gmon/gmon.c: In function '__monstartup': ../../src/gcc/config/arc/gmon/gmon.c:197: error: unrecognizable insn: (insn 38 37 39 3 ../../src/gcc/config/arc/gmon/gmon.c:137 (set (reg:SI 180) (const_int -1 [0x])) -1 (nil) (nil)) ../../src/gcc/config/arc/gmon/gmon.c:197: internal compiler error: in extract_insn, at recog.c:2077 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. -- Summary: ice on valid code (unrecognizable insn) Product: gcc Version: 4.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ltuikov at yahoo dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42116
[Bug rtl-optimization/42116] ice on valid code (unrecognizable insn)
--- Comment #1 from ltuikov at yahoo dot com 2009-11-20 10:56 --- Created an attachment (id=19065) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19065action=view) Preprocessed source code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42116
[Bug rtl-optimization/42116] ice on valid code (unrecognizable insn)
--- Comment #2 from ltuikov at yahoo dot com 2009-11-20 10:57 --- Created an attachment (id=19066) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19066action=view) Assembly output -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42116
[Bug middle-end/42110] [4.5 Regression] ICE with inlining
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-11-20 10:58 --- Honza? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||hubicka at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-11-20 10:58:05 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42110
[Bug target/42113] [4.3/4.4 Regression] Internal Compiler error with -O3, breaking commit known
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P4 Summary|[4.3/4.4/4.5 Regression]|[4.3/4.4 Regression] |Internal Compiler error with|Internal Compiler error with |-O3, breaking commit known |-O3, breaking commit known Target Milestone|--- |4.4.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42113
[Bug rtl-optimization/42116] ice on valid code (unrecognizable insn)
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-11-20 11:01 --- GCC 4.2 is no longer maintained, please try a newer release. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added GCC target triplet||arc-elf32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42116
[Bug c++/42060] [4.4/4.5 Regression] [c++0x] ICE throwing array with initializer list
-- paolo dot carlini at oracle dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |paolo dot carlini at oracle |dot org |dot com Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-11-20 11:14:18 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42060
[Bug rtl-optimization/42116] ice on valid code (unrecognizable insn)
--- Comment #4 from ltuikov at yahoo dot com 2009-11-20 11:24 --- The source I'm trying to compile I got directly from arc. I'll try 4.4.2 from GNU. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42116
[Bug middle-end/41883] [4.5 Regression] ICE from '-O -fprofile-arcs -fsched2-use-superblocks -ftree-vrp -fschedule-insns2 -freorder-blocks'
--- Comment #2 from reichelt at gcc dot gnu dot org 2009-11-20 12:23 --- Confirmed. Reduced testcase (crashes with -fprofile-arcs -fsched2-use-superblocks -fschedule-insns2 -freorder-blocks -O): int foo(int i) { if (i) return 0; __builtin_alloca(4); return 0; } -- reichelt at gcc dot gnu dot org changed: What|Removed |Added CC||reichelt at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-valid-code Last reconfirmed|-00-00 00:00:00 |2009-11-20 12:23:29 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41883
[Bug tree-optimization/42117] New: VRP fails to get rid of compares
The vrp47 testcase currently fails on i386 and S/390. The ssa code before vrp looks different for both compared to x86_64 due to a different value returned by BRANCH_COST. (Branches on S/390 are relatively cheap due to a sophisticated branch prediction unit.) Therefore during gimplification fold_truthop (line 5866) uses more branches for function h in vrp47.c than the x86_64 variant. The problem can also be reproduced on x86 when compiling for a cpu with low branch costs defined in i386.c as e.g. -march=i386. int h(int x, int y) { if ((x = 0 x = 1) (y = 0 y = 1)) return x y; else return -1; } Compile the testcase above with: cc1 -m32 -O2 vrp47.c -fdump-tree-vrp -march=i386 The vrp pass is not able to get rid of the comparisons in this case (069t.vrp1 from i386): h (int x, int y) { int D.2021; unsigned int y.1; unsigned int x.0; bb 2: x.0_4 = (unsigned int) x_3(D); if (x.0_4 = 1) goto bb 3; else goto bb 7; bb 3: y.1_6 = (unsigned int) y_5(D); if (y.1_6 = 1) goto bb 4; else goto bb 7; bb 4: if (x_3(D) != 0) goto bb 5; else goto bb 6; bb 5: if (y_5(D) != 0) goto bb 7; else goto bb 6; bb 6: bb 7: # D.2021_1 = PHI 0(6), -1(3), -1(2), 1(5) return D.2021_1; } -- Summary: VRP fails to get rid of compares Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: krebbel at gcc dot gnu dot org GCC build triplet: i386-gnu-linux, s390x-ibm-linux GCC host triplet: i386-gnu-linux, s390x-ibm-linux GCC target triplet: i386-gnu-linux, s390x-ibm-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42117
[Bug target/42113] [4.3/4.4 Regression] Internal Compiler error with -O3, breaking commit known
--- Comment #5 from ubizjak at gmail dot com 2009-11-20 12:58 --- This reduced testcase fails also on 4.5: --cut here-- int make_file (int a, int b) { int foo = a * sizeof (int); if (b) foo += sizeof (int); return foo; } --cut here-- -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42113
[Bug tree-optimization/42117] VRP should do if-conversion
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-11-20 13:12 --- Confirmed. We do see x_2: [0, 1] EQUIVALENCES: { x_3(D) } (1 elements) y_11: [0, 1] EQUIVALENCES: { y_5(D) } (1 elements) but have no code that actually makes use of this information in bb 4: if (x_3(D) != 0) goto bb 5; else goto bb 6; bb 5: if (y_5(D) != 0) goto bb 7; else goto bb 6; bb 6: bb 7: # D.2047_1 = PHI 0(6), -1(3), -1(2), 1(5) return D.2047_1; which we want to if-convert to bb 4: tmp = x_3 y_5; bb 7: # D.2047_1 = PHI tmp(4), -1(3), -1(2) but there is no code in VRP that does if-conversion. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-11-20 13:12:34 date|| Summary|VRP fails to get rid of |VRP should do if-conversion |compares| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42117
[Bug fortran/42118] New: Slow forall
I think that forall statement must be at least as fast as equivalent do- -end do construction. But the next program (variant of LU-decomposition) shows that fragment containing forall statement is approximately at 2.5(!) times slower then fragment with do-end do. program test implicit none integer, parameter :: n = 2000 integer i, j double precision, dimension (n, n) :: a, a1 double precision, dimension (n) :: work real time_begin, time_end integer, dimension(1) :: max_loc intrinsic random_number, maxloc, CPU_TIME call random_number(a) a1=a CALL CPU_TIME(time_begin) do i = 1, n-1 max_loc = maxloc(abs(a(i:,i))) j = max_loc(1) + i - 1 if (a(j,i) == 0.0) stop 'Zero pivot' if (i /= j) then work(i:n) = a(i,i:n) a(i,i:n) = a(j,i:n) a(j,i:n) = work(i:n) end if a(i+1:,i) = a(i+1:,i) / a(i,i) do j = i+1, n a(i+1:,j) = a(i+1:,j) - a(i,j) * a(i+1:,i) end do end do CALL CPU_TIME(time_end) print *, 'Time of operation was ', time_end - time_begin, ' seconds' a=a1 CALL CPU_TIME(time_begin) do i = 1, n-1 max_loc = maxloc(abs(a(i:,i))) j = max_loc(1) + i - 1 if (a(j,i) == 0.0) stop 'Zero pivot' if (i /= j) then work(i:n) = a(i,i:n) a(i,i:n) = a(j,i:n) a(j,i:n) = work(i:n) end if a(i+1:,i) = a(i+1:,i) / a(i,i) forall (j = i+1:n) a(i+1:,j) = a(i+1:,j) - a(i,j) * a(i+1:,i) end do CALL CPU_TIME(time_end) print *, 'Time of operation was ', time_end - time_begin, ' seconds' end program test GCC version 4.4.2. Windows Vista SP2, CPU: Intel Core 2 Quad Q6600, RAM: 3 GB Gfortran O3 file_name.f95 -- Summary: Slow forall Product: gcc Version: 4.4.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: gretsov at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42118
[Bug target/42113] [4.3/4.4 Regression] Internal Compiler error with -O3, breaking commit known
--- Comment #6 from ubizjak at gmail dot com 2009-11-20 13:40 --- Created an attachment (id=19067) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19067action=view) patch to fix mode of scratch register in *cmp_s{add,sub}_si{,di} This patch fixes wrong modes of scratch register in *cmp_s{add,sub}_si{,di} patterns. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42113
[Bug tree-optimization/42108] [4.4/4.5 Regression] Vectorizer cannot deal with PAREN_EXPR gracefully, 50% performance regression
--- Comment #9 from dominiq at lps dot ens dot fr 2009-11-20 13:45 --- I am rather confused by some comments: (1) Although I am not fluent with x86 assembly, I am pretty sure that no code in eval is vectorized (assembly taken from this pr or from the original post http://gcc.gnu.org/ml/fortran/2009-11/msg00163.html). (2) If I am not mistaken, the k loop always handle 3 elements for i, i+n, and i+2*n. (3) On a core2duo 2.1Ghz, I only see small changes in the timing between 4.3.4 to trunk, -O1 to -O3, and 32 or 64 bit mode. Now if I do the following change: --- pr42108_1_db.f902009-11-20 14:14:05.0 +0100 +++ pr42108_1_db_1.f90 2009-11-20 14:15:24.0 +0100 @@ -7,12 +7,10 @@ subroutine eval(foo1,foo2,foo3,foo4,x,n do i=2,n foo3(i)=foo2*foo4(i) do j=1,i-1 - temp=0.0d0 - jmini=j-i - do k=i,nnd,n -temp=temp+(x(k)-x(k+jmini))**2 - end do - temp = sqrt(temp+foo1) + temp = sqrt( (x(i) - x(j))**2 + +(x(i+n) - x(j+n))**2 + +(x(i+2*n)-x(j+2*n))**2 + +foo1) foo3(i)=foo3(i)+temp*foo4(j) foo3(j)=foo3(j)+temp*foo4(i) end do I go from 9.2s to 5.5s for n=2. So the k loop is not automatically unrolled even with -funroll-loops. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42108
[Bug tree-optimization/42108] [4.4/4.5 Regression] Vectorizer cannot deal with PAREN_EXPR gracefully, 50% performance regression
--- Comment #10 from sfilippone at uniroma2 dot it 2009-11-20 14:03 --- (In reply to comment #9) I am rather confused by some comments: (1) Although I am not fluent with x86 assembly, I am pretty sure that no code in eval is vectorized (assembly taken from this pr or from the original post http://gcc.gnu.org/ml/fortran/2009-11/msg00163.html). (2) If I am not mistaken, the k loop always handle 3 elements for i, i+n, and i+2*n. Yup, in the test case, in the original application the factor might be different from 3. And yes, it may be better to declare the array as 2D -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42108
[Bug fortran/42118] Slow forall
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-11-20 14:03 --- Confirmed. GFortran seems to split the loops differently and uses a larger temporary for the forall case. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-11-20 14:03:56 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42118
[Bug tree-optimization/42108] [4.4/4.5 Regression] Vectorizer cannot deal with PAREN_EXPR gracefully, 50% performance regression
--- Comment #11 from sfilippone at uniroma2 dot it 2009-11-20 14:12 --- (In reply to comment #10) Again, I am no asking for help in writing a better code (I think I know how to handle this, and I will convince my colleague), I just thought it was worth mentioning that the optimizer has apparently done a worse job lately (at least on the platform I am using). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42108
[Bug tree-optimization/42108] [4.4/4.5 Regression] Vectorizer cannot deal with PAREN_EXPR gracefully, 50% performance regression
--- Comment #12 from rguenth at gcc dot gnu dot org 2009-11-20 14:13 --- The loop is not unrolled because the frontend presents us with very funny obfuscated code: do k=i,nnd,n temp=temp+(x(k)-x(k+jmini))**2 end do gets translated to { character(kind=4) countm1.6; integer(kind=4) D.1551; integer(kind=4) D.1550; integer(kind=4) D.1549; D.1549 = i; D.1550 = *nnd; D.1551 = *n; k = D.1549; if (D.1551 0) { if (D.1550 D.1549) goto L.6;, countm1.6 = (character(kind=4)) (D.1550 - D.1549) / (character(kind=4)) D.1551;; } else { if (D.1550 D.1549) goto L.6;, countm1.6 = (character(kind=4)) (D.1549 - D.1550) / (character(kind=4)) -D.1551;; } while (1) { { real(kind=8) D.1556; real(kind=8) D.1555; D.1555 = (((*x)[(integer(kind=8)) k + -1] - (*x)[(integer(kind=8)) (k + jmini) + -1])); D.1556 = D.1555 * D.1555; temp = temp + D.1556; } L.5:; k = k + D.1551; if (countm1.6 == 0) goto L.6; countm1.6 = countm1.6 + 4294967295; } L.6:; } WTF!? The funny conditional initialization of countm1.6 makes the analysis of the number of iterations of this loop impossible (not to mention the conversions to character(kind=4)). Why does the frontend do induction variable optimization at all and not simply generate a loop with a non-unit counting IV? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42108
[Bug target/40836] ICE: insn does not satisfy its constraints (iwmmxt_movsi_insn)
--- Comment #23 from yipiha2008 at gmail dot com 2009-11-20 14:16 --- Forget #22, as expected it does not work (kernel compiled with a patched GCC as per #22 does not boot) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40836
[Bug fortran/42118] Slow forall
--- Comment #2 from burnus at gcc dot gnu dot org 2009-11-20 14:20 --- (In reply to comment #0) I think that forall statement must be at least as fast as equivalent do- -end do construction. The Fortran standardization committee thought likewise, however, as it turned out in practice, it is sometimes not trivial for the compiler to see whether there is any dependence on the RHS (right-hand side) with regards to the LHS and thus it might use a temporary array even if none is needed - and temporary arrays are slow (and memory hungry). Thus, a DO loop should be always faster or as fast as a FORALL (assignment) statement (unless, one does something really stupid in the DO loop). [At least that is what I gathered from the comments at comp.lang.fortran and which matches my knowledge regarding how it is done in gfortran.] Having said that, gfortran still should try to make your program as fast for FORALL as it is for the DO loop. But the next program (variant of LU-decomposition) shows that fragment containing forall statement is approximately at 2.5(!) times slower then fragment with do-end do. You could check using -fdump-tree-original how the two versions are handled; my guess is that the FORALL version uses a temporary array. (-fdump-tree-original creates a file.f90.004* which contains a dump of the internal representation of your code, which looks similar to C.) Seemingly, Richard already looked at the dump and confirmed my suspicion. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42118
[Bug fortran/42112] overloaded function with allocatable result problem
--- Comment #3 from burnus at gcc dot gnu dot org 2009-11-20 14:22 --- pure function f() result(i) integer :: i integer, allocatable :: loc_ar(:) allocate(loc_ar(1)) loc_ar = gen_g() ! does not work That looks OK if gen_g returns a size-1 array or a scalar - and with Fortran 2003 it should also be valid if the array has a different size (automatic (re)allocation on assignment). generates f () { g (loc_ar); } loc_ar has been allocated and the pointer to it is passed to g() where is becomes associated with the result variable j. You then try to allocate j, which is already allocated. That sounds completely wrong for Fortran 95 but also for 2003. There is absolutely no valid reason to mess around with the LHS argument, i.e. C_LOC(loc_ar(1)) should be the same before and after the assignment (unless in F2003 if the array size of LHS/RHS does not match or if loc_ar was before not allocated). To me it sounds as if there is the problem that the attributes of the specific function belonging to the generic function are not properly used. That is: expr-symtree-n.sym-attr vs. expr-value.function.esym-attr. (Cf. PR 41777 ) -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||wrong-code Last reconfirmed|-00-00 00:00:00 |2009-11-20 14:22:49 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42112
[Bug c/42098] gcc does not honor alignment specification, gives different alignment than g++
--- Comment #2 from jepler at unpythonic dot net 2009-11-20 14:45 --- (In reply to comment #0) Given the declaration: typedef volatile double D __attribute__((aligned(16))); That should have been aligned(8) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42098
[Bug tree-optimization/41919] [4.5 Regression] optimized code with -O2 or -O3 gives strange result
--- Comment #8 from hjl at gcc dot gnu dot org 2009-11-20 14:50 --- Subject: Bug 41919 Author: hjl Date: Fri Nov 20 14:49:22 2009 New Revision: 154366 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154366 Log: 2009-11-20 H.J. Lu hongjiu...@intel.com Backport from mainline: 2009-11-18 Alexandre Oliva aol...@redhat.com PR debug/41926 * gcc.dg/vect/vect-debug-pr41926.c: New. 2009-11-16 Paolo Carlini paolo.carl...@oracle.com PR c++/42055 * g++.dg/template/crash92.C: New. 2009-11-08 Richard Guenther rguent...@suse.de PR rtl-optimization/41928 * gfortran.dg/pr41928.f90: New testcase. 2009-11-06 Jakub Jelinek ja...@redhat.com PR middle-end/41935 * gcc.dg/pr41935.c: New test. * c-c++-common/pr41935.c: New test. * gcc.c-torture/execute/pr41935.c: New test. 2009-11-04 Richard Guenther rguent...@suse.de PR tree-optimization/41919 * gcc.c-torture/execute/pr41919.c: New testcase. 2009-11-03 Tobias Burnus bur...@net-b.de PR fortran/41907 * gfortran.dg/missing_optional_dummy_6.f90: New test. 2009-11-02 Martin Jambor mjam...@suse.cz PR tree-optimization/41750 * gcc.c-torture/execute/pr41750.c: New test. 2009-11-02 Jakub Jelinek ja...@redhat.com PR tree-optimization/41841 * gcc.dg/pr41841.c: New test. Added: branches/gcc-4_4-branch/gcc/testsuite/c-c++-common/pr41935.c - copied unchanged from r154365, trunk/gcc/testsuite/c-c++-common/pr41935.c branches/gcc-4_4-branch/gcc/testsuite/g++.dg/template/crash92.C - copied unchanged from r154365, trunk/gcc/testsuite/g++.dg/template/crash92.C branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/execute/pr41750.c - copied unchanged from r154365, trunk/gcc/testsuite/gcc.c-torture/execute/pr41750.c branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/execute/pr41919.c - copied unchanged from r154365, trunk/gcc/testsuite/gcc.c-torture/execute/pr41919.c branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/execute/pr41935.c - copied unchanged from r154365, trunk/gcc/testsuite/gcc.c-torture/execute/pr41935.c branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/pr41841.c - copied unchanged from r154365, trunk/gcc/testsuite/gcc.dg/pr41841.c branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/pr41935.c - copied unchanged from r154365, trunk/gcc/testsuite/gcc.dg/pr41935.c branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/vect/vect-debug-pr41926.c - copied unchanged from r154365, trunk/gcc/testsuite/gcc.dg/vect/vect-debug-pr41926.c branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/missing_optional_dummy_6.f90 - copied unchanged from r154365, trunk/gcc/testsuite/gfortran.dg/missing_optional_dummy_6.f90 branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/pr41928.f90 - copied unchanged from r154365, trunk/gcc/testsuite/gfortran.dg/pr41928.f90 Modified: branches/gcc-4_4-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41919
[Bug c++/42055] [4.5 Regression] ICE with ambiguous template specialization
--- Comment #3 from hjl at gcc dot gnu dot org 2009-11-20 14:50 --- Subject: Bug 42055 Author: hjl Date: Fri Nov 20 14:49:22 2009 New Revision: 154366 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154366 Log: 2009-11-20 H.J. Lu hongjiu...@intel.com Backport from mainline: 2009-11-18 Alexandre Oliva aol...@redhat.com PR debug/41926 * gcc.dg/vect/vect-debug-pr41926.c: New. 2009-11-16 Paolo Carlini paolo.carl...@oracle.com PR c++/42055 * g++.dg/template/crash92.C: New. 2009-11-08 Richard Guenther rguent...@suse.de PR rtl-optimization/41928 * gfortran.dg/pr41928.f90: New testcase. 2009-11-06 Jakub Jelinek ja...@redhat.com PR middle-end/41935 * gcc.dg/pr41935.c: New test. * c-c++-common/pr41935.c: New test. * gcc.c-torture/execute/pr41935.c: New test. 2009-11-04 Richard Guenther rguent...@suse.de PR tree-optimization/41919 * gcc.c-torture/execute/pr41919.c: New testcase. 2009-11-03 Tobias Burnus bur...@net-b.de PR fortran/41907 * gfortran.dg/missing_optional_dummy_6.f90: New test. 2009-11-02 Martin Jambor mjam...@suse.cz PR tree-optimization/41750 * gcc.c-torture/execute/pr41750.c: New test. 2009-11-02 Jakub Jelinek ja...@redhat.com PR tree-optimization/41841 * gcc.dg/pr41841.c: New test. Added: branches/gcc-4_4-branch/gcc/testsuite/c-c++-common/pr41935.c - copied unchanged from r154365, trunk/gcc/testsuite/c-c++-common/pr41935.c branches/gcc-4_4-branch/gcc/testsuite/g++.dg/template/crash92.C - copied unchanged from r154365, trunk/gcc/testsuite/g++.dg/template/crash92.C branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/execute/pr41750.c - copied unchanged from r154365, trunk/gcc/testsuite/gcc.c-torture/execute/pr41750.c branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/execute/pr41919.c - copied unchanged from r154365, trunk/gcc/testsuite/gcc.c-torture/execute/pr41919.c branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/execute/pr41935.c - copied unchanged from r154365, trunk/gcc/testsuite/gcc.c-torture/execute/pr41935.c branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/pr41841.c - copied unchanged from r154365, trunk/gcc/testsuite/gcc.dg/pr41841.c branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/pr41935.c - copied unchanged from r154365, trunk/gcc/testsuite/gcc.dg/pr41935.c branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/vect/vect-debug-pr41926.c - copied unchanged from r154365, trunk/gcc/testsuite/gcc.dg/vect/vect-debug-pr41926.c branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/missing_optional_dummy_6.f90 - copied unchanged from r154365, trunk/gcc/testsuite/gfortran.dg/missing_optional_dummy_6.f90 branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/pr41928.f90 - copied unchanged from r154365, trunk/gcc/testsuite/gfortran.dg/pr41928.f90 Modified: branches/gcc-4_4-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42055
[Bug c/41935] [4.4/4.5 Regression] ICE : tree check: expected integer_cst, have nop_expr in int_cst_value, at tree.c:8301
--- Comment #10 from hjl at gcc dot gnu dot org 2009-11-20 14:50 --- Subject: Bug 41935 Author: hjl Date: Fri Nov 20 14:49:22 2009 New Revision: 154366 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154366 Log: 2009-11-20 H.J. Lu hongjiu...@intel.com Backport from mainline: 2009-11-18 Alexandre Oliva aol...@redhat.com PR debug/41926 * gcc.dg/vect/vect-debug-pr41926.c: New. 2009-11-16 Paolo Carlini paolo.carl...@oracle.com PR c++/42055 * g++.dg/template/crash92.C: New. 2009-11-08 Richard Guenther rguent...@suse.de PR rtl-optimization/41928 * gfortran.dg/pr41928.f90: New testcase. 2009-11-06 Jakub Jelinek ja...@redhat.com PR middle-end/41935 * gcc.dg/pr41935.c: New test. * c-c++-common/pr41935.c: New test. * gcc.c-torture/execute/pr41935.c: New test. 2009-11-04 Richard Guenther rguent...@suse.de PR tree-optimization/41919 * gcc.c-torture/execute/pr41919.c: New testcase. 2009-11-03 Tobias Burnus bur...@net-b.de PR fortran/41907 * gfortran.dg/missing_optional_dummy_6.f90: New test. 2009-11-02 Martin Jambor mjam...@suse.cz PR tree-optimization/41750 * gcc.c-torture/execute/pr41750.c: New test. 2009-11-02 Jakub Jelinek ja...@redhat.com PR tree-optimization/41841 * gcc.dg/pr41841.c: New test. Added: branches/gcc-4_4-branch/gcc/testsuite/c-c++-common/pr41935.c - copied unchanged from r154365, trunk/gcc/testsuite/c-c++-common/pr41935.c branches/gcc-4_4-branch/gcc/testsuite/g++.dg/template/crash92.C - copied unchanged from r154365, trunk/gcc/testsuite/g++.dg/template/crash92.C branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/execute/pr41750.c - copied unchanged from r154365, trunk/gcc/testsuite/gcc.c-torture/execute/pr41750.c branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/execute/pr41919.c - copied unchanged from r154365, trunk/gcc/testsuite/gcc.c-torture/execute/pr41919.c branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/execute/pr41935.c - copied unchanged from r154365, trunk/gcc/testsuite/gcc.c-torture/execute/pr41935.c branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/pr41841.c - copied unchanged from r154365, trunk/gcc/testsuite/gcc.dg/pr41841.c branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/pr41935.c - copied unchanged from r154365, trunk/gcc/testsuite/gcc.dg/pr41935.c branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/vect/vect-debug-pr41926.c - copied unchanged from r154365, trunk/gcc/testsuite/gcc.dg/vect/vect-debug-pr41926.c branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/missing_optional_dummy_6.f90 - copied unchanged from r154365, trunk/gcc/testsuite/gfortran.dg/missing_optional_dummy_6.f90 branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/pr41928.f90 - copied unchanged from r154365, trunk/gcc/testsuite/gfortran.dg/pr41928.f90 Modified: branches/gcc-4_4-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41935
[Bug fortran/41907] [4.5 Regression] 465.tonto in SPEC CPU 2006 runtime failure
--- Comment #10 from hjl at gcc dot gnu dot org 2009-11-20 14:50 --- Subject: Bug 41907 Author: hjl Date: Fri Nov 20 14:49:22 2009 New Revision: 154366 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154366 Log: 2009-11-20 H.J. Lu hongjiu...@intel.com Backport from mainline: 2009-11-18 Alexandre Oliva aol...@redhat.com PR debug/41926 * gcc.dg/vect/vect-debug-pr41926.c: New. 2009-11-16 Paolo Carlini paolo.carl...@oracle.com PR c++/42055 * g++.dg/template/crash92.C: New. 2009-11-08 Richard Guenther rguent...@suse.de PR rtl-optimization/41928 * gfortran.dg/pr41928.f90: New testcase. 2009-11-06 Jakub Jelinek ja...@redhat.com PR middle-end/41935 * gcc.dg/pr41935.c: New test. * c-c++-common/pr41935.c: New test. * gcc.c-torture/execute/pr41935.c: New test. 2009-11-04 Richard Guenther rguent...@suse.de PR tree-optimization/41919 * gcc.c-torture/execute/pr41919.c: New testcase. 2009-11-03 Tobias Burnus bur...@net-b.de PR fortran/41907 * gfortran.dg/missing_optional_dummy_6.f90: New test. 2009-11-02 Martin Jambor mjam...@suse.cz PR tree-optimization/41750 * gcc.c-torture/execute/pr41750.c: New test. 2009-11-02 Jakub Jelinek ja...@redhat.com PR tree-optimization/41841 * gcc.dg/pr41841.c: New test. Added: branches/gcc-4_4-branch/gcc/testsuite/c-c++-common/pr41935.c - copied unchanged from r154365, trunk/gcc/testsuite/c-c++-common/pr41935.c branches/gcc-4_4-branch/gcc/testsuite/g++.dg/template/crash92.C - copied unchanged from r154365, trunk/gcc/testsuite/g++.dg/template/crash92.C branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/execute/pr41750.c - copied unchanged from r154365, trunk/gcc/testsuite/gcc.c-torture/execute/pr41750.c branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/execute/pr41919.c - copied unchanged from r154365, trunk/gcc/testsuite/gcc.c-torture/execute/pr41919.c branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/execute/pr41935.c - copied unchanged from r154365, trunk/gcc/testsuite/gcc.c-torture/execute/pr41935.c branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/pr41841.c - copied unchanged from r154365, trunk/gcc/testsuite/gcc.dg/pr41841.c branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/pr41935.c - copied unchanged from r154365, trunk/gcc/testsuite/gcc.dg/pr41935.c branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/vect/vect-debug-pr41926.c - copied unchanged from r154365, trunk/gcc/testsuite/gcc.dg/vect/vect-debug-pr41926.c branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/missing_optional_dummy_6.f90 - copied unchanged from r154365, trunk/gcc/testsuite/gfortran.dg/missing_optional_dummy_6.f90 branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/pr41928.f90 - copied unchanged from r154365, trunk/gcc/testsuite/gfortran.dg/pr41928.f90 Modified: branches/gcc-4_4-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41907
[Bug debug/41926] [4.5 Regression][VTA] internal compiler error: verify_ssa failed
--- Comment #6 from hjl at gcc dot gnu dot org 2009-11-20 14:50 --- Subject: Bug 41926 Author: hjl Date: Fri Nov 20 14:49:22 2009 New Revision: 154366 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154366 Log: 2009-11-20 H.J. Lu hongjiu...@intel.com Backport from mainline: 2009-11-18 Alexandre Oliva aol...@redhat.com PR debug/41926 * gcc.dg/vect/vect-debug-pr41926.c: New. 2009-11-16 Paolo Carlini paolo.carl...@oracle.com PR c++/42055 * g++.dg/template/crash92.C: New. 2009-11-08 Richard Guenther rguent...@suse.de PR rtl-optimization/41928 * gfortran.dg/pr41928.f90: New testcase. 2009-11-06 Jakub Jelinek ja...@redhat.com PR middle-end/41935 * gcc.dg/pr41935.c: New test. * c-c++-common/pr41935.c: New test. * gcc.c-torture/execute/pr41935.c: New test. 2009-11-04 Richard Guenther rguent...@suse.de PR tree-optimization/41919 * gcc.c-torture/execute/pr41919.c: New testcase. 2009-11-03 Tobias Burnus bur...@net-b.de PR fortran/41907 * gfortran.dg/missing_optional_dummy_6.f90: New test. 2009-11-02 Martin Jambor mjam...@suse.cz PR tree-optimization/41750 * gcc.c-torture/execute/pr41750.c: New test. 2009-11-02 Jakub Jelinek ja...@redhat.com PR tree-optimization/41841 * gcc.dg/pr41841.c: New test. Added: branches/gcc-4_4-branch/gcc/testsuite/c-c++-common/pr41935.c - copied unchanged from r154365, trunk/gcc/testsuite/c-c++-common/pr41935.c branches/gcc-4_4-branch/gcc/testsuite/g++.dg/template/crash92.C - copied unchanged from r154365, trunk/gcc/testsuite/g++.dg/template/crash92.C branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/execute/pr41750.c - copied unchanged from r154365, trunk/gcc/testsuite/gcc.c-torture/execute/pr41750.c branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/execute/pr41919.c - copied unchanged from r154365, trunk/gcc/testsuite/gcc.c-torture/execute/pr41919.c branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/execute/pr41935.c - copied unchanged from r154365, trunk/gcc/testsuite/gcc.c-torture/execute/pr41935.c branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/pr41841.c - copied unchanged from r154365, trunk/gcc/testsuite/gcc.dg/pr41841.c branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/pr41935.c - copied unchanged from r154365, trunk/gcc/testsuite/gcc.dg/pr41935.c branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/vect/vect-debug-pr41926.c - copied unchanged from r154365, trunk/gcc/testsuite/gcc.dg/vect/vect-debug-pr41926.c branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/missing_optional_dummy_6.f90 - copied unchanged from r154365, trunk/gcc/testsuite/gfortran.dg/missing_optional_dummy_6.f90 branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/pr41928.f90 - copied unchanged from r154365, trunk/gcc/testsuite/gfortran.dg/pr41928.f90 Modified: branches/gcc-4_4-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41926
[Bug rtl-optimization/41928] [4.5 Regression] segfault at gcc/bitmap.c:297
--- Comment #10 from hjl at gcc dot gnu dot org 2009-11-20 14:50 --- Subject: Bug 41928 Author: hjl Date: Fri Nov 20 14:49:22 2009 New Revision: 154366 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154366 Log: 2009-11-20 H.J. Lu hongjiu...@intel.com Backport from mainline: 2009-11-18 Alexandre Oliva aol...@redhat.com PR debug/41926 * gcc.dg/vect/vect-debug-pr41926.c: New. 2009-11-16 Paolo Carlini paolo.carl...@oracle.com PR c++/42055 * g++.dg/template/crash92.C: New. 2009-11-08 Richard Guenther rguent...@suse.de PR rtl-optimization/41928 * gfortran.dg/pr41928.f90: New testcase. 2009-11-06 Jakub Jelinek ja...@redhat.com PR middle-end/41935 * gcc.dg/pr41935.c: New test. * c-c++-common/pr41935.c: New test. * gcc.c-torture/execute/pr41935.c: New test. 2009-11-04 Richard Guenther rguent...@suse.de PR tree-optimization/41919 * gcc.c-torture/execute/pr41919.c: New testcase. 2009-11-03 Tobias Burnus bur...@net-b.de PR fortran/41907 * gfortran.dg/missing_optional_dummy_6.f90: New test. 2009-11-02 Martin Jambor mjam...@suse.cz PR tree-optimization/41750 * gcc.c-torture/execute/pr41750.c: New test. 2009-11-02 Jakub Jelinek ja...@redhat.com PR tree-optimization/41841 * gcc.dg/pr41841.c: New test. Added: branches/gcc-4_4-branch/gcc/testsuite/c-c++-common/pr41935.c - copied unchanged from r154365, trunk/gcc/testsuite/c-c++-common/pr41935.c branches/gcc-4_4-branch/gcc/testsuite/g++.dg/template/crash92.C - copied unchanged from r154365, trunk/gcc/testsuite/g++.dg/template/crash92.C branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/execute/pr41750.c - copied unchanged from r154365, trunk/gcc/testsuite/gcc.c-torture/execute/pr41750.c branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/execute/pr41919.c - copied unchanged from r154365, trunk/gcc/testsuite/gcc.c-torture/execute/pr41919.c branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/execute/pr41935.c - copied unchanged from r154365, trunk/gcc/testsuite/gcc.c-torture/execute/pr41935.c branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/pr41841.c - copied unchanged from r154365, trunk/gcc/testsuite/gcc.dg/pr41841.c branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/pr41935.c - copied unchanged from r154365, trunk/gcc/testsuite/gcc.dg/pr41935.c branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/vect/vect-debug-pr41926.c - copied unchanged from r154365, trunk/gcc/testsuite/gcc.dg/vect/vect-debug-pr41926.c branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/missing_optional_dummy_6.f90 - copied unchanged from r154365, trunk/gcc/testsuite/gfortran.dg/missing_optional_dummy_6.f90 branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/pr41928.f90 - copied unchanged from r154365, trunk/gcc/testsuite/gfortran.dg/pr41928.f90 Modified: branches/gcc-4_4-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41928
[Bug tree-optimization/41841] segfault using '-O -fipa-cp -fipa-struct-reorg -fwhole-program -fprofile-generate'
--- Comment #6 from hjl at gcc dot gnu dot org 2009-11-20 14:50 --- Subject: Bug 41841 Author: hjl Date: Fri Nov 20 14:49:22 2009 New Revision: 154366 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154366 Log: 2009-11-20 H.J. Lu hongjiu...@intel.com Backport from mainline: 2009-11-18 Alexandre Oliva aol...@redhat.com PR debug/41926 * gcc.dg/vect/vect-debug-pr41926.c: New. 2009-11-16 Paolo Carlini paolo.carl...@oracle.com PR c++/42055 * g++.dg/template/crash92.C: New. 2009-11-08 Richard Guenther rguent...@suse.de PR rtl-optimization/41928 * gfortran.dg/pr41928.f90: New testcase. 2009-11-06 Jakub Jelinek ja...@redhat.com PR middle-end/41935 * gcc.dg/pr41935.c: New test. * c-c++-common/pr41935.c: New test. * gcc.c-torture/execute/pr41935.c: New test. 2009-11-04 Richard Guenther rguent...@suse.de PR tree-optimization/41919 * gcc.c-torture/execute/pr41919.c: New testcase. 2009-11-03 Tobias Burnus bur...@net-b.de PR fortran/41907 * gfortran.dg/missing_optional_dummy_6.f90: New test. 2009-11-02 Martin Jambor mjam...@suse.cz PR tree-optimization/41750 * gcc.c-torture/execute/pr41750.c: New test. 2009-11-02 Jakub Jelinek ja...@redhat.com PR tree-optimization/41841 * gcc.dg/pr41841.c: New test. Added: branches/gcc-4_4-branch/gcc/testsuite/c-c++-common/pr41935.c - copied unchanged from r154365, trunk/gcc/testsuite/c-c++-common/pr41935.c branches/gcc-4_4-branch/gcc/testsuite/g++.dg/template/crash92.C - copied unchanged from r154365, trunk/gcc/testsuite/g++.dg/template/crash92.C branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/execute/pr41750.c - copied unchanged from r154365, trunk/gcc/testsuite/gcc.c-torture/execute/pr41750.c branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/execute/pr41919.c - copied unchanged from r154365, trunk/gcc/testsuite/gcc.c-torture/execute/pr41919.c branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/execute/pr41935.c - copied unchanged from r154365, trunk/gcc/testsuite/gcc.c-torture/execute/pr41935.c branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/pr41841.c - copied unchanged from r154365, trunk/gcc/testsuite/gcc.dg/pr41841.c branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/pr41935.c - copied unchanged from r154365, trunk/gcc/testsuite/gcc.dg/pr41935.c branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/vect/vect-debug-pr41926.c - copied unchanged from r154365, trunk/gcc/testsuite/gcc.dg/vect/vect-debug-pr41926.c branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/missing_optional_dummy_6.f90 - copied unchanged from r154365, trunk/gcc/testsuite/gfortran.dg/missing_optional_dummy_6.f90 branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/pr41928.f90 - copied unchanged from r154365, trunk/gcc/testsuite/gfortran.dg/pr41928.f90 Modified: branches/gcc-4_4-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41841
[Bug tree-optimization/41750] [4.5 Regression] IPA-SRA is broken
--- Comment #27 from hjl at gcc dot gnu dot org 2009-11-20 14:50 --- Subject: Bug 41750 Author: hjl Date: Fri Nov 20 14:49:22 2009 New Revision: 154366 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154366 Log: 2009-11-20 H.J. Lu hongjiu...@intel.com Backport from mainline: 2009-11-18 Alexandre Oliva aol...@redhat.com PR debug/41926 * gcc.dg/vect/vect-debug-pr41926.c: New. 2009-11-16 Paolo Carlini paolo.carl...@oracle.com PR c++/42055 * g++.dg/template/crash92.C: New. 2009-11-08 Richard Guenther rguent...@suse.de PR rtl-optimization/41928 * gfortran.dg/pr41928.f90: New testcase. 2009-11-06 Jakub Jelinek ja...@redhat.com PR middle-end/41935 * gcc.dg/pr41935.c: New test. * c-c++-common/pr41935.c: New test. * gcc.c-torture/execute/pr41935.c: New test. 2009-11-04 Richard Guenther rguent...@suse.de PR tree-optimization/41919 * gcc.c-torture/execute/pr41919.c: New testcase. 2009-11-03 Tobias Burnus bur...@net-b.de PR fortran/41907 * gfortran.dg/missing_optional_dummy_6.f90: New test. 2009-11-02 Martin Jambor mjam...@suse.cz PR tree-optimization/41750 * gcc.c-torture/execute/pr41750.c: New test. 2009-11-02 Jakub Jelinek ja...@redhat.com PR tree-optimization/41841 * gcc.dg/pr41841.c: New test. Added: branches/gcc-4_4-branch/gcc/testsuite/c-c++-common/pr41935.c - copied unchanged from r154365, trunk/gcc/testsuite/c-c++-common/pr41935.c branches/gcc-4_4-branch/gcc/testsuite/g++.dg/template/crash92.C - copied unchanged from r154365, trunk/gcc/testsuite/g++.dg/template/crash92.C branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/execute/pr41750.c - copied unchanged from r154365, trunk/gcc/testsuite/gcc.c-torture/execute/pr41750.c branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/execute/pr41919.c - copied unchanged from r154365, trunk/gcc/testsuite/gcc.c-torture/execute/pr41919.c branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/execute/pr41935.c - copied unchanged from r154365, trunk/gcc/testsuite/gcc.c-torture/execute/pr41935.c branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/pr41841.c - copied unchanged from r154365, trunk/gcc/testsuite/gcc.dg/pr41841.c branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/pr41935.c - copied unchanged from r154365, trunk/gcc/testsuite/gcc.dg/pr41935.c branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/vect/vect-debug-pr41926.c - copied unchanged from r154365, trunk/gcc/testsuite/gcc.dg/vect/vect-debug-pr41926.c branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/missing_optional_dummy_6.f90 - copied unchanged from r154365, trunk/gcc/testsuite/gfortran.dg/missing_optional_dummy_6.f90 branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/pr41928.f90 - copied unchanged from r154365, trunk/gcc/testsuite/gfortran.dg/pr41928.f90 Modified: branches/gcc-4_4-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41750
[Bug target/40836] ICE: insn does not satisfy its constraints (iwmmxt_movsi_insn)
--- Comment #24 from enrico dot scholz at informatik dot tu-chemnitz dot de 2009-11-20 15:07 --- I do not think that the non working kernel is caused by the patch, but that there are yet more regressions for the iwmmxt arch and that this arch has never been tested with gcc 4.4. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40836
[Bug fortran/42119] New: internal compiler error: in expand_expr_addr_expr_1, at expr.c:6862
Test file (Test.f90): - module Test use ISO_C_BINDING contains subroutine Callback(arg) bind(C) integer(C_INT) :: arg end subroutine Callback subroutine Check(proc) type(C_FUNPTR) :: proc end subroutine Check end module Test program Main use Test type(C_FUNPTR) :: proc call Check(C_FUNLOC(Callback)) ! This works fine: ! proc = C_FUNLOC(Callback) ! call Check(proc) end program Main - Compiler output: - sm...@ubuntu:~/Code$ gfortran -v Test.f90 Driving: gfortran -v Test.f90 -lgfortranbegin -lgfortran -lm -shared-libgcc Using built-in specs. Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.4.1-4ubuntu8' --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --enable-multiarch --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4 --program-suffix=-4.4 --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --disable-werror --with-arch-32=i486 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.4.1 (Ubuntu 4.4.1-4ubuntu8) COLLECT_GCC_OPTIONS='-v' '-shared-libgcc' '-mtune=generic' /usr/lib/gcc/x86_64-linux-gnu/4.4.1/f951 Test.f90 -quiet -dumpbase Test.f90 -mtune=generic -auxbase Test -version -fintrinsic-modules-path /usr/lib/gcc/x86_64-linux-gnu/4.4.1/finclude -o /tmp/ccn1uZ8e.s GNU Fortran (Ubuntu 4.4.1-4ubuntu8) version 4.4.1 (x86_64-linux-gnu) compiled by GNU C version 4.4.1, GMP version 4.3.1, MPFR version 2.4.1-p2. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Test.f90: In function main: Test.f90:21: internal compiler error: in expand_expr_addr_expr_1, at expr.c:6862 Please submit a full bug report, with preprocessed source if appropriate. See file:///usr/share/doc/gcc-4.4/README.Bugs for instructions. -- Summary: internal compiler error: in expand_expr_addr_expr_1, at expr.c:6862 Product: gcc Version: 4.4.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: nvab at ibrae dot ac dot ru GCC build triplet: x86_64-linux-gnu GCC host triplet: x86_64-linux-gnu GCC target triplet: x86_64-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42119
[Bug target/41979] GCC fails to compile MPC-HC's ffmpeg/libavcodec
-- brunorex at gmail dot com changed: What|Removed |Added Status|NEW |SUSPENDED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41979
[Bug middle-end/42119] internal compiler error: in expand_expr_addr_expr_1, at expr.c:6862
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-11-20 15:33 --- Confirmed. Sth as simple as Index: gcc/expr.c === --- gcc/expr.c (revision 154364) +++ gcc/expr.c (working copy) @@ -6834,7 +6834,8 @@ expand_expr_addr_expr_1 (tree exp, rtx t /* ??? This should be considered a front-end bug. We should not be generating ADDR_EXPR of something that isn't an LVALUE. The only exception here is STRING_CST. */ - if (CONSTANT_CLASS_P (exp)) + if (CONSTANT_CLASS_P (exp) + || (TREE_CODE (exp) == ADDR_EXPR TREE_CONSTANT (exp))) return XEXP (expand_expr_constant (exp, 0, modifier), 0); /* Everything must be something allowed by is_gimple_addressable. */ might fix it, though the recursion in this function for CONST_DECLs make it a bit convoluted to call it obvious. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|fortran |middle-end Ever Confirmed|0 |1 Keywords||ice-on-valid-code Known to fail||4.5.0 Last reconfirmed|-00-00 00:00:00 |2009-11-20 15:33:46 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42119
[Bug target/40836] ICE: insn does not satisfy its constraints (iwmmxt_movsi_insn)
--- Comment #25 from yipiha2008 at gmail dot com 2009-11-20 15:45 --- Further tests show that you're right about the non working kernel. Should the iwmmxt arch be disabled by default on GCC 4.5? At least it would make it clear that this arch is untested/not supported. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40836
[Bug fortran/42072] [F03] wrong-code with C_F_PROCPOINTER
--- Comment #7 from janus at gcc dot gnu dot org 2009-11-20 15:51 --- The runtime problem and the obsolete comment in the manual are fixed now. So the only issue left is the wrong static declaration reported in comment #3. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42072
[Bug c++/42121] New: g++ should warn or error on internal 0 size array in struct
Currently g++ requires the -pedantic flag to give a warning on a zero sized array that is not the last field in a struct. As far as I can see, this is actually always a significant error if it is not the trailing field in the struct... Demonstration: temp(510)$ cat zero-size-array.cpp #include iostream #include cstddef struct bogus { int a; char b[]; int c; } bogus; int main(void) { std::cout size of struct bogus = sizeof(bogus) std::endl; std::cout offset of field b = offsetof(struct bogus, b) std::endl; std::cout offset of field c = offsetof(struct bogus, b) std::endl; return 0; } temp(511)$ g++ -Wall -o zero-size-array zero-size-array.cppsize-array.cppe-array.cpp temp(512)$ zero-size-array size of struct bogus =8 offset of field b =4 offset of field c =4 temp(513)$ g++ -Wall -pedantic -o zero-size-array zero-size-array.cppize-array.cpp zero-size-array.cpp:7: error: ISO C++ forbids zero-size array 'b' temp(514)$ g++ --version g++ (GCC) 4.1.2 20070626 (Red Hat 4.1.2-14) -David -- Summary: g++ should warn or error on internal 0 size array in struct Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: david dot resnick at comverse dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42121
[Bug bootstrap/42093] bootstrap hangs in stage2 run of build/gengtype
--- Comment #2 from ramana at gcc dot gnu dot org 2009-11-20 16:00 --- (In reply to comment #1) only seen when configuring with --with-mode=thumb, disabling scheduling for thumb2 shows the same endless loop. Confirmed unless there's a miscompilation in libc that we are missing. -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-11-20 16:00:02 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42093
[Bug c++/42060] [4.4/4.5 Regression] [c++0x] ICE throwing array with initializer list
--- Comment #1 from paolo at gcc dot gnu dot org 2009-11-20 16:03 --- Subject: Bug 42060 Author: paolo Date: Fri Nov 20 16:03:19 2009 New Revision: 154371 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154371 Log: cp/ 2009-11-20 Paolo Carlini paolo.carl...@oracle.com PR c++/42060 * except.c (build_throw): Check the tree returned by decay_conversion for error_mark_node. testsuite/ 2009-11-20 Paolo Carlini paolo.carl...@oracle.com PR c++/42060 * g++.dg/cpp0x/initlist28.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp0x/initlist28.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/except.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42060
[Bug c++/42060] [4.4 Regression] [c++0x] ICE throwing array with initializer list
--- Comment #2 from paolo dot carlini at oracle dot com 2009-11-20 16:05 --- Fixed for 4.5.0. -- paolo dot carlini at oracle dot com changed: What|Removed |Added AssignedTo|paolo dot carlini at oracle |unassigned at gcc dot gnu |dot com |dot org Status|ASSIGNED|NEW Summary|[4.4/4.5 Regression] [c++0x]|[4.4 Regression] [c++0x] ICE |ICE throwing array with |throwing array with |initializer list|initializer list Target Milestone|4.4.3 |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42060
[Bug fortran/42122] New: -fdump-tree-original shows wrong static decl for functions with procptr argument
Follow-up to PR42072. Consider this simple program: contains subroutine setpointer (p) procedure(), pointer :: p end subroutine end Compiling this with -fdump-tree-original shows: setpointer (void (*T62) (void) * p) { (void) 0; } MAIN__ () { static void setpointer (void (*T62) (void)); (void) 0; } As one can see, the static declaration inside MAIN__ differs from the actual declaration of 'setpointer'. -- Summary: -fdump-tree-original shows wrong static decl for functions with procptr argument Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: janus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42122
[Bug fortran/42072] [F03] wrong-code with C_F_PROCPOINTER
--- Comment #8 from janus at gcc dot gnu dot org 2009-11-20 16:08 --- (In reply to comment #7) So the only issue left is the wrong static declaration reported in comment #3. This is now PR 42122. Closing this one. -- janus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42072
[Bug target/42123] New: dll{im,ex}port attributes don't (yet) work on namespaces.
As per subject, the dll attributes can't be applied to c++ namespaces - this in fact applies to all windows platforms, not just cygwin. This would be a desirable mechanism for eliminating the use of auto-import by using explicit dllimport attributes, without having to uglify every header in the whole library to do so. -- Summary: dll{im,ex}port attributes don't (yet) work on namespaces. Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: davek at gcc dot gnu dot org GCC build triplet: i686-pc-cygwin GCC host triplet: i686-pc-cygwin GCC target triplet: i686-pc-cygwin http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42123
[Bug target/42123] dll{im,ex}port attributes don't (yet) work on namespaces.
--- Comment #1 from davek at gcc dot gnu dot org 2009-11-20 16:11 --- Created an attachment (id=19068) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19068action=view) work-in-progress This patch is a bit overly keen in how far it propagates dllimport, leading to the regression of g++.dg/ext/dllimport8.C without even using -D_GLIBCXX_IMPORT. (This is the old don't-import-a-static-class-member-if-you've-seen-a-definition issue.) So, not ready for primetime just yet... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42123
[Bug target/42123] dll{im,ex}port attributes don't (yet) work on namespaces.
-- davek at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |davek at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-11-20 16:11:58 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42123
[Bug tree-optimization/39960] [4.5 Regression] struct-reorg is broken
--- Comment #6 from olga at gcc dot gnu dot org 2009-11-20 16:57 --- Subject: Bug 39960 Author: olga Date: Fri Nov 20 16:57:35 2009 New Revision: 154374 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154374 Log: 2009-11-17 Olga Golovanevsky o...@il.ibm.com PR middle-end/39960 * ipa-struct-reorg.c (find_pos_in_stmt): New parameter. (ref_pos): New field in structure. (insert_new_var_in_stmt): New function. Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-struct-reorg.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39960
[Bug target/40959] build fails - No rule to make target `/usr/ports/lang/gcc43/work/build/ia64-portbld-freebsd8.0/libgcc/crtfastmath.o', needed by `T_TARGET'. Stop.
--- Comment #10 from sje at cup dot hp dot com 2009-11-20 16:59 --- Does freebsd use glibc? Does freebsd have a system libunwind? I am going to guess yes to the first question and no to the second in which case you need to edit gcc/config.gcc and modify the 'ia64*-*-freebsd*' entry to include the t-libunwind-elf and ia64/t-glibc-libunwind makefile fragments to the tm_file list. That is what 'ia64*-*-linux* does when 'with_system_libunwind' is set to no. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40959
[Bug target/41810] Cannot build gcc: gthr-default.h:466: error: '__mutex' was not declared in this scope
--- Comment #10 from ro at CeBiTec dot Uni-Bielefeld dot DE 2009-11-20 17:10 --- Subject: Re: Cannot build gcc: gthr-default.h:466: error: '__mutex' was not declared in this scope The #c4 patch looks wrong, instead of that you should IMHO just not use UNUSED macro on __gthread_mutex_destroy argument. It is perfectly fine on __gthread_key_delete. You're right, of course. I should have looked closer. Testing and comparison with pthread results found two other bugs, one of which I could already fix in gthr-solaris.h. I've tried to debug the other (objc) testcase, but gdb 6.6 cannot fully handle it, and I couldn't yet get a gdb 7.0 to debug a 64-bit binary. Given that this is a bootstrap failure, I'll submit and install the fix now and check the remainder later. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41810
[Bug target/41810] Cannot build gcc: gthr-default.h:466: error: '__mutex' was not declared in this scope
--- Comment #11 from ro at gcc dot gnu dot org 2009-11-20 17:17 --- Mine. -- ro at gcc dot gnu dot org changed: What|Removed |Added CC|ro at techfak dot uni- | |bielefeld dot de| AssignedTo|unassigned at gcc dot gnu |ro at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-11-20 17:17:12 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41810
[Bug fortran/42045] [F03] passing a procedure pointer component to a procedure pointer dummy
--- Comment #4 from janus at gcc dot gnu dot org 2009-11-20 17:24 --- With this patch Index: gcc/fortran/resolve.c === --- gcc/fortran/resolve.c (revision 154369) +++ gcc/fortran/resolve.c (working copy) @@ -1321,6 +1321,8 @@ resolve_actual_arglist (gfc_actual_arglist *arg, p e-rank = comp-as-rank; e-expr_type = EXPR_FUNCTION; } + if (gfc_resolve_expr (e) == FAILURE) + return FAILURE; goto argument_list; } @@ -2519,6 +2521,10 @@ resolve_function (gfc_expr *expr) if (expr-symtree) sym = expr-symtree-n.sym; + /* If this is a procedure pointer component, it has already been resolved. */ + if (gfc_is_proc_ptr_comp (expr, NULL)) +return SUCCESS; + if (sym sym-attr.intrinsic resolve_intrinsic (sym, expr-where) == FAILURE) return FAILURE; @@ -10219,8 +10225,9 @@ resolve_fl_derived (gfc_symbol *sym) } else if (c-attr.proc_pointer c-ts.type == BT_UNKNOWN) { - c-ts = *gfc_get_default_type (c-name, NULL); - c-attr.implicit_type = 1; + /* Since PPCs are not implicitly typed, a PPC without an explicit +interface must be a subroutine. */ + gfc_add_subroutine (c-attr, c-name, c-loc); } /* Procedure pointer components: Check PASS arg. */ the only remaining regression is proc_ptr_comp_2.f90, which is invalid with respect to the interpretation in http://www.j3-fortran.org/doc/year/09/09-236r1.txt. -- janus at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |janus at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-11-20 17:24:11 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42045
[Bug target/42081] big-endian arm MULTILIB_DEFAULTS hard-coded to little-endian
--- Comment #1 from tom at giftssoft dot com 2009-11-20 17:26 --- It looks like this bug is related to bug 16350, which was created on 2004-07-03 and resulted in patch 800-arm-bigendian.patch being applied on 2007-11-07 to gcc 4.3.0. Prior to this patch, gcc defaulted to little-endian mode on both big-endian and little-endian arm targets, and had to be explicitly told to compile in big-endian mode. This patch modified gcc to detault to big-endian mode on big-endian arm targets and little-endian mode on littlr-endian arm targets. However, the hunk of the patch that replaced: { marm, mlittle-endian, mhard-float, mno-thumb-interwork } with: { marm, TARGET_ENDIAN_OPTION, mhard-float, mno-thumb-interwork } was somehow not applied. Therefore, this bug can be restated as follows: The patch to resolve bug 16350 was only partially applied and resulted in an inconsistent linux-elf.h file in which part of it still assumes little-endian on all arm targets (the old behavor) and part of it assumes big-endian on big-endian arm targets (the new behavior). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42081
[Bug target/40411] -std=c99 does not enable c99 mode in Solaris C library
--- Comment #16 from ro at gcc dot gnu dot org 2009-11-20 17:53 --- Mine. -- ro at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ro at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2009-06-17 19:42:47 |2009-11-20 17:53:02 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40411
[Bug middle-end/42119] internal compiler error: in expand_expr_addr_expr_1, at expr.c:6862
--- Comment #2 from mikael at gcc dot gnu dot org 2009-11-20 17:59 --- This is the same as PR 38530 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42119
[Bug fortran/38530] ICE with the example for c_funloc
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-11-20 18:05 --- *** Bug 42119 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||nvab at ibrae dot ac dot ru http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38530
[Bug middle-end/42119] internal compiler error: in expand_expr_addr_expr_1, at expr.c:6862
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-11-20 18:05 --- *** This bug has been marked as a duplicate of 38530 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42119
[Bug c++/42121] g++ should warn or error on internal 0 size array in struct
--- Comment #1 from redi at gcc dot gnu dot org 2009-11-20 18:09 --- Looks like this is for compatibility with GNU C, which allows it, but only in the form char b[0] not char b[] -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42121
[Bug target/40959] build fails - No rule to make target `/usr/ports/lang/gcc43/work/build/ia64-portbld-freebsd8.0/libgcc/crtfastmath.o', needed by `T_TARGET'. Stop.
--- Comment #11 from kargl at gcc dot gnu dot org 2009-11-20 18:10 --- (In reply to comment #10) Does freebsd use glibc? Does freebsd have a system libunwind? I am going to guess yes to the first question and no to the second in which case you need to edit gcc/config.gcc and modify the 'ia64*-*-freebsd*' entry to include the t-libunwind-elf and ia64/t-glibc-libunwind makefile fragments to the tm_file list. That is what 'ia64*-*-linux* does when 'with_system_libunwind' is set to no. FreeBSD does not use glibc; never has and never will. FreeBSD does not have a libunwind. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40959
[Bug target/42113] [4.3/4.4/4.5 Regression] Internal Compiler error with -O3, breaking commit known
-- ubizjak at gmail dot com changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2009- ||11/msg01115.html Target Milestone|4.4.3 |4.3.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42113
[Bug c++/42121] g++ should warn or error on internal 0 size array in struct
--- Comment #2 from david dot resnick at comverse dot com 2009-11-20 18:38 --- (In reply to comment #1) Looks like this is for compatibility with GNU C, which allows it, but only in the form char b[0] not char b[] b[] seems simply broken unless last in an array for the C99 flexible array member type stuff, no? I'm not really convinced about the merits/utility of b[0] as an internal struct field either, it is an odd way to make a union maybe? In standard C, a size 0 array is forbidden, at least in C99 doc I have handy, per constraint in section 6.7.5.2 indicating: Constraints [#1] The [ and ] may delimit an expression or *. If [ and ] delimit an expression (which specifies the size of an array), it shall have an integer type. If the expression is a constant expression then it shall have a value greater than zero. The element type shall not be an incomplete or function type. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42121
[Bug c++/42121] g++ should warn or error on internal 0 size array in struct
--- Comment #3 from redi at gcc dot gnu dot org 2009-11-20 18:49 --- (In reply to comment #2) In standard C, a size 0 array is forbidden, at least in C99 doc I have handy, Yes, but it's a long-standing GNU extension: http://gcc.gnu.org/onlinedocs/gcc-4.4.2/gcc/Zero-Length.html#Zero-Length The C++ front end says: /* As an extension we allow zero-sized arrays. We always allow them in system headers because glibc uses them. */ Maybe the C++ front-end could be made stricter, so that it accepts char b[0] (like the C front end) but not char b[] (which is a C99 flexible array member, and must be the last member) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42121
[Bug c++/42121] g++ should warn or error on internal 0 size array in struct
--- Comment #4 from david dot resnick at comverse dot com 2009-11-20 18:56 --- (In reply to comment #3) (In reply to comment #2) In standard C, a size 0 array is forbidden, at least in C99 doc I have handy, Yes, but it's a long-standing GNU extension: http://gcc.gnu.org/onlinedocs/gcc-4.4.2/gcc/Zero-Length.html#Zero-Length The C++ front end says: /* As an extension we allow zero-sized arrays. We always allow them in system headers because glibc uses them. */ Maybe the C++ front-end could be made stricter, so that it accepts char b[0] (like the C front end) but not char b[] (which is a C99 flexible array member, and must be the last member) OK, but if you read that link the whole rationale is to do with it being the last field in a struct, not an internal member, right? Seems like there is no possible use in an internal member, and not diagnosing this as warnable means you don't notice if, say, someone accidentally adds something after the flexible array member. Which happened to us, which is why I noticed this issue. If this will break existing usage, I see the reason not to change. But I'm curious what possible use a non-terminal zero sized array in a struct might have. -David -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42121
[Bug target/41473] [4.5 Regression] dsymutil Assertion failed ...
--- Comment #29 from howarth at nitro dot med dot uc dot edu 2009-11-20 18:59 --- I have some additional comments from the dsymutils maintainer... 7397601 is a bug in dsymutils. It was not handling the case when the dwarf debug info contained an AT_location with form DW_FORM_block1 with zero length. It may also be possible to have the compiler not emit that as a work around. Clarification: The fix was made for any block form (DW_FORM_block1, DW_FORM_block2, DW_FORM_block4, DW_FORM_block) variant that had zero length. One other question. Does dwarf debug info on an AT_location with form DW_FORM_block1 that has zero length have any real meaning or is that likely just accidental noise on the dwarf debug output? It is probably accidental noise, or a bug. The variable should be checked to make sure it really doesn't have a location, and if it doesn't just don't emit the DW_AT_location attribute. If it does have a valid location, then a lenght of zero is probably a bug. If zero length dwarf debug info, is either invalid or effectively a noop, we may just be suffering from the fact binutils is immune to such flaws in the dwarf output. Then, darwin might actually be useful in helping identify bogus dwarf info being emitted. Thanks in advance for any clarifications. I have modified dwarfdump to properly dump the information and I did check the DWARF spec, and it seems that it is ok to have DW_FORM_blockXXX forms with zero length, so it isn't invalid DWARF. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41473
[Bug c++/42124] New: warning: array subscript is below array bounds
CPP code: #include malloc.h #include errno.h const int INT_INVALID = 0x8000; template class T, int N class TOPLIST { int ind[N], n, lim; T vals[N]; public: TOPLIST() { n = 0; lim = N; } void reset() { n = 0; } void add(int index, T value) { int m; if(n==lim) { if(vals[n-1]=value) return; } else n++; for(m=n-1; m0 vals[m-1]value; m--) { vals[m] = vals[m-1]; ind[m] = ind[m-1]; } vals[m] = value; ind[m] = index; } T val(int index) { if(index0 || index=n) return T(0); else return vals[index]; } int indx(int index) { if(index0 || index=n) return INT_INVALID; else return ind[index]; } bool IsValid(void) const { return n0; } }; const char C39PAT[4][11] = { 0111221211, 121122, 211222, 321221 }; int ReadC39() { TOPLISTint, 3 T; int c; for(c=0; c4; c++) T.add(c, c); for(c=0; c4; c++) if(C39PAT[c][T.indx(0)+1]=='2') break; return (c4) ? C39PAT[c][0] : '?'; } int main() { return 0; } Command which produces the above mentioned warning: g++ -v --save-temp xxx.cpp -O3 -Wall And the *.ii files. # 1 xxx.cpp # 1 built-in # 1 command-line # 1 xxx.cpp # 1 /usr/include/malloc.h 1 3 4 # 24 /usr/include/malloc.h 3 4 # 1 /usr/include/features.h 1 3 4 # 347 /usr/include/features.h 3 4 # 1 /usr/include/sys/cdefs.h 1 3 4 # 353 /usr/include/sys/cdefs.h 3 4 # 1 /usr/include/bits/wordsize.h 1 3 4 # 354 /usr/include/sys/cdefs.h 2 3 4 # 348 /usr/include/features.h 2 3 4 # 371 /usr/include/features.h 3 4 # 1 /usr/include/gnu/stubs.h 1 3 4 # 1 /usr/include/bits/wordsize.h 1 3 4 # 5 /usr/include/gnu/stubs.h 2 3 4 # 1 /usr/include/gnu/stubs-32.h 1 3 4 # 8 /usr/include/gnu/stubs.h 2 3 4 # 372 /usr/include/features.h 2 3 4 # 25 /usr/include/malloc.h 2 3 4 # 1 /usr/lib/gcc/i686-pc-linux-gnu/4.4.1/include/stddef.h 1 3 4 # 149 /usr/lib/gcc/i686-pc-linux-gnu/4.4.1/include/stddef.h 3 4 typedef int ptrdiff_t; # 211 /usr/lib/gcc/i686-pc-linux-gnu/4.4.1/include/stddef.h 3 4 typedef unsigned int size_t; # 26 /usr/include/malloc.h 2 3 4 # 1 /usr/include/stdio.h 1 3 4 # 30 /usr/include/stdio.h 3 4 extern C { # 1 /usr/lib/gcc/i686-pc-linux-gnu/4.4.1/include/stddef.h 1 3 4 # 35 /usr/include/stdio.h 2 3 4 # 1 /usr/include/bits/types.h 1 3 4 # 28 /usr/include/bits/types.h 3 4 # 1 /usr/include/bits/wordsize.h 1 3 4 # 29 /usr/include/bits/types.h 2 3 4 typedef unsigned char __u_char; typedef unsigned short int __u_short; typedef unsigned int __u_int; typedef unsigned long int __u_long; typedef signed char __int8_t; typedef unsigned char __uint8_t; typedef signed short int __int16_t; typedef unsigned short int __uint16_t; typedef signed int __int32_t; typedef unsigned int __uint32_t; __extension__ typedef signed long long int __int64_t; __extension__ typedef unsigned long long int __uint64_t; __extension__ typedef long long int __quad_t; __extension__ typedef unsigned long long int __u_quad_t; # 131 /usr/include/bits/types.h 3 4 # 1 /usr/include/bits/typesizes.h 1 3 4 # 132 /usr/include/bits/types.h 2 3 4 __extension__ typedef __u_quad_t __dev_t; __extension__ typedef unsigned int __uid_t; __extension__ typedef unsigned int __gid_t; __extension__ typedef unsigned long int __ino_t; __extension__ typedef __u_quad_t __ino64_t; __extension__ typedef unsigned int __mode_t; __extension__ typedef unsigned int __nlink_t; __extension__ typedef long int __off_t; __extension__ typedef __quad_t __off64_t; __extension__ typedef int __pid_t; __extension__ typedef struct { int __val[2]; } __fsid_t; __extension__ typedef long int __clock_t; __extension__ typedef unsigned long int __rlim_t; __extension__ typedef __u_quad_t __rlim64_t; __extension__ typedef unsigned int __id_t; __extension__ typedef long int __time_t; __extension__ typedef unsigned int __useconds_t; __extension__ typedef long int __suseconds_t; __extension__ typedef int __daddr_t; __extension__ typedef long int __swblk_t; __extension__ typedef int __key_t; __extension__ typedef int __clockid_t; __extension__ typedef void * __timer_t; __extension__ typedef long int __blksize_t; __extension__ typedef long int __blkcnt_t; __extension__ typedef __quad_t __blkcnt64_t; __extension__ typedef unsigned long int __fsblkcnt_t; __extension__ typedef __u_quad_t __fsblkcnt64_t; __extension__ typedef unsigned long int __fsfilcnt_t; __extension__ typedef __u_quad_t __fsfilcnt64_t; __extension__ typedef int __ssize_t; typedef __off64_t __loff_t; typedef __quad_t *__qaddr_t; typedef char *__caddr_t; __extension__ typedef int __intptr_t; __extension__ typedef unsigned int __socklen_t; # 37 /usr/include/stdio.h 2 3 4 # 45 /usr/include/stdio.h 3 4 struct _IO_FILE; typedef struct _IO_FILE FILE; # 65 /usr/include/stdio.h 3 4
[Bug c++/42124] warning: array subscript is below array bounds
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-11-20 19:12 --- D.2919_10 = C39PAT[0][-2147483647]; Well there is an array subscript is below array bounds. It is hard for GCC to figure out that is dead code really without full unrolling ... -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|major |normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42124
[Bug tree-optimization/42108] [4.4/4.5 Regression] Vectorizer cannot deal with PAREN_EXPR gracefully, 50% performance regression
--- Comment #13 from toon at moene dot org 2009-11-20 19:45 --- The funny conditional initialization of countm1.6 makes the analysis of the number of iterations of this loop impossible (not to mention the conversions to character(kind=4)). Why does the frontend do induction variable optimization at all and not simply generate a loop with a non-unit counting IV? It's not trying to be funny - it just follows the text of the Fortran Standard (hey, what a concept !): 12 8.1.6.6.1Loop initiation 13 1 When the DO statement is executed, the DO construct becomes active. If loop-control is 14 2 [ , ] do-variable = scalar-int-expr 1 , scalar-int-expr 2 [ , scalar-int-expr 3 ] 15 3 the following steps are performed in sequence. 16 (1)The initial parameter m1 , the terminal parameter m2 , and the incrementation parameter m3 are 17 of type integer with the same kind type parameter as the do-variable. Their values are established 18 by evaluating scalar-int-expr 1 , scalar-int-expr 2 , and scalar-int-expr 3 , respectively, including, if ne- 19 cessary, conversion to the kind type parameter of the do-variable according to the rules for numeric 20 conversion (Table 7.11). If scalar-int-expr 3 does not appear, m3 has the value 1. The value of m3 21 shall not be zero. 22 (2)The DO variable becomes defined with the value of the initial parameter m1 . 23 (3)The iteration count is established and is the value of the expression (m2 - m1 + m3 )/m3 , unless that 24 value is negative, in which case the iteration count is 0. Only interprocedural analysis can tell us that this is a simple loop only executed 3 times (I got this wrong at first - it's *always* executed 3 times). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42108
[Bug c++/42124] warning: array subscript is below array bounds
--- Comment #2 from djszapi at archlinux dot us 2009-11-20 19:59 --- (In reply to comment #1) D.2919_10 = C39PAT[0][-2147483647]; Well there is an array subscript is below array bounds. It is hard for GCC to figure out that is dead code really without full unrolling ... If you look at the code you can see 'there is an array subscript is below array bounds' situation can't be occured! So it's a gcc bug I think so definetely. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42124
[Bug c++/42121] g++ should warn or error on internal 0 size array in struct
--- Comment #5 from joseph at codesourcery dot com 2009-11-20 20:57 --- Subject: Re: g++ should warn or error on internal 0 size array in struct On Fri, 20 Nov 2009, david dot resnick at comverse dot com wrote: (In reply to comment #3) (In reply to comment #2) In standard C, a size 0 array is forbidden, at least in C99 doc I have handy, Yes, but it's a long-standing GNU extension: http://gcc.gnu.org/onlinedocs/gcc-4.4.2/gcc/Zero-Length.html#Zero-Length The C++ front end says: /* As an extension we allow zero-sized arrays. We always allow them in system headers because glibc uses them. */ Maybe the C++ front-end could be made stricter, so that it accepts char b[0] (like the C front end) but not char b[] (which is a C99 flexible array member, and must be the last member) OK, but if you read that link the whole rationale is to do with it being the last field in a struct, not an internal member, right? Seems like there is no possible use in an internal member, and not diagnosing this as warnable means you don't notice if, say, someone accidentally adds something after the flexible array member. Which happened to us, which is why I noticed this issue. If this will break existing usage, I see the reason not to change. But I'm curious what possible use a non-terminal zero sized array in a struct might have. Several cases of C99 flexible array members that C99 does not permit are only diagnosed as pedwarns-if-pedantic for C because of glibc using them. (I gave an example in http://gcc.gnu.org/ml/gcc-patches/2002-08/msg01149.html.) I haven't looked into why it does this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42121
[Bug c/42097] Reference operator () error from included file.
--- Comment #4 from bradhomer at gbis dot com 2009-11-20 21:20 --- Subject: Re: Reference operator () error from included file. Thank you. The code I submitted for the bug has worked for years in the world of Borland. Obviously not so good in the world of linux. Again thank you for your help. Brad On 19 Nov 2009 19:12:36 -, pinskia at gcc dot gnu dot org gcc-bugzi...@gcc.gnu.org wrote: --- Comment #3 from pinskia at gcc dot gnu dot org 2009-11-19 19:12 --- Take a look at The C Programming Language by Kernighan and Ritchie, chapter 5. But this is not a reference operator at this point. It is for a reference type. Reference types are different from the reference operator. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42097 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42097
[Bug libstdc++/42019] shared_ptr can not be used with -fno-rtti
--- Comment #3 from redi at gcc dot gnu dot org 2009-11-20 21:23 --- Subject: Bug 42019 Author: redi Date: Fri Nov 20 21:23:02 2009 New Revision: 154377 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154377 Log: 2009-11-20 Jonathan Wakely jwakely@gmail.com PR libstdc++/42019 * include/tr1/shared_ptr.h: Only use typeid when RTTI is enabled. * include/bits/shared_ptr_base.h: Likewise. * include/bits/shared_ptr.h: Likewise. * testsuite/tr1/2_general_utilities/shared_ptr/misc/42019.cc: New. * testsuite/20_util/shared_ptr/misc/42019.cc: New. Added: trunk/libstdc++-v3/testsuite/20_util/shared_ptr/misc/42019.cc trunk/libstdc++-v3/testsuite/tr1/2_general_utilities/shared_ptr/misc/42019.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/shared_ptr.h trunk/libstdc++-v3/include/bits/shared_ptr_base.h trunk/libstdc++-v3/include/tr1/shared_ptr.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42019
[Bug libgomp/42125] New: check libgomp fails
I downloaded the source code gcc 4.4.2 and compiled at cygwin. I used ../gcc-4.4.2/configure --enable-shared --enable-threads=posix --enable-libssp --enable-libgomp --enable-languages=c,c++ --enable-decimal-float --disable-bootstrap --without-x --enable-version-specific-runtime-libs to do configure, then make. The first errors are xgcc -pthread is not recognized libgomp.lib: File format not recognized so I changed /i686-pc-cygwin/libgomp/libtool file and search for the .lib file extension and change it to .dll.a. and modify file /i686-pc-cygwin/libgomp/Makefile with CFLAGS = -g -O2 -pthread XCFLAGS = -Wall -Werror -Wc,-pthread changed to CFLAGS = -g -O2 XCFLAGS = -Wall -Werror -Wc, added -lpthread at line: libgomp.la: $(libgomp_la_OBJECTS) $(libgomp_la_DEPENDENCIES) $(LINK) -rpath $(toolexeclibdir) $(libgomp_la_LDFLAGS) $(libgomp_la_OBJECTS) $(libgomp_la_LIBADD) $(LIBS) -lpthread Then again to do make. This time it goes thought. But when use make check-target-libgomp to do check, every case fails. It seems that a thread-support library doesn't generated with libgomp. -- Summary: check libgomp fails Product: gcc Version: 4.4.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bwcc60 at hotmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42125
[Bug libstdc++/42019] shared_ptr can not be used with -fno-rtti
--- Comment #4 from redi at gcc dot gnu dot org 2009-11-20 21:26 --- Fixed for 4.5.0 -- redi at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42019
[Bug c/42097] Reference operator () error from included file.
--- Comment #5 from paolo dot carlini at oracle dot com 2009-11-20 21:36 --- Note: linux is an operating system; borland is a software company. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42097
[Bug c++/38646] [4.3/4.4/4.5 regression] ICE with invalid specialization of variadic template
--- Comment #8 from simartin at gcc dot gnu dot org 2009-11-20 21:37 --- Subject: Bug 38646 Author: simartin Date: Fri Nov 20 21:37:23 2009 New Revision: 154378 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154378 Log: gcc/cp/ 2009-11-20 Simon Martin simar...@users.sourceforge.net PR c++/38646 * pt.c (process_partial_specialization): Do not turn wrongly located parameter pack arguments into error_mark_node. Split too long lines into two. gcc/testsuite/ 2009-11-20 Simon Martin simar...@users.sourceforge.net PR c++/38646 * g++.dg/cpp0x/pr38646.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp0x/pr38646.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38646
[Bug middle-end/42103] [4.4 regression] packed 64-bit field reports as violation of strict aliasing rules
--- Comment #2 from tlesher at digium dot com 2009-11-20 21:44 --- Created an attachment (id=19069) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19069action=view) Two files that each use one of either the 32-bit or 64-bit versions of the function Each file in this attachment contains one of either put_unaligned_uint32 or put_unaligned_uint64. The 32-bit version compiles with no errors, while the 64-bit version causes the strict aliasing warning. I've included a simple Makefile and the base unaligned.h source file, for ease of examination. I've also confirmed that using the 'may_alias' attribute in the 64-bit version suppresses the warning, although I think this qualifies as a workaround, not a fix to the problem. I'm also not sure how our project leaders would consider such a workaround, given that the intent behind extra warnings is to make the code better. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42103
[Bug c++/38646] [4.3/4.4 regression] ICE with invalid specialization of variadic template
--- Comment #9 from simartin at gcc dot gnu dot org 2009-11-20 21:46 --- Fixed in 4.5 -- simartin at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.3/4.4/4.5 regression] ICE|[4.3/4.4 regression] ICE |with invalid specialization |with invalid specialization |of variadic template|of variadic template http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38646
[Bug c/42126] New: gcc optimizes line away/optimizes to an endless loop
The problem with the endless loop is in the function smpAllocMsg. There gcc makes out of the while loop (freeList == 0) an endless loop. The problem with the line which is optimized away is in the smpSendMsgBroadcast, its the line serviceMsg= msg. This problem can be avoided if I call another function (I tested printf) before the while loop (msg-refCount 0). These 2 problems only occur if I use the -O2 switch with -O1 it works. What I do not understand is, why is gcc doing that, although I´m using the volatile keyword!? -- Summary: gcc optimizes line away/optimizes to an endless loop Product: gcc Version: 4.4.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: codemasterhs at yahoo dot de GCC host triplet: cygwin GCC target triplet: i586-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42126
[Bug c/42126] gcc optimizes line away/optimizes to an endless loop
--- Comment #1 from codemasterhs at yahoo dot de 2009-11-20 22:28 --- Created an attachment (id=19070) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19070action=view) the out from gcc with -v -save-temps -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42126
[Bug c/42126] gcc optimizes line away/optimizes to an endless loop
--- Comment #2 from schwab at linux-m68k dot org 2009-11-20 22:45 --- Neither freeList nor serviceMsg are volatile. Thus freeList can never change and serviceMsg = msg is a dead assignment. -- schwab at linux-m68k dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42126
[Bug c/42126] gcc optimizes line away/optimizes to an endless loop
--- Comment #3 from codemasterhs at yahoo dot de 2009-11-20 22:50 --- (In reply to comment #2) Neither freeList nor serviceMsg are volatile. Thus freeList can never change and serviceMsg = msg is a dead assignment. But they are, or is my syntax wrong? static volatile struct smpMsg_t *serviceMsg; static volatile struct smpMsg_t *freeList; -- codemasterhs at yahoo dot de changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42126
[Bug tree-optimization/42108] [4.4/4.5 Regression] Vectorizer cannot deal with PAREN_EXPR gracefully, 50% performance regression
--- Comment #14 from rguenth at gcc dot gnu dot org 2009-11-20 23:48 --- (In reply to comment #13) The funny conditional initialization of countm1.6 makes the analysis of the number of iterations of this loop impossible (not to mention the conversions to character(kind=4)). Why does the frontend do induction variable optimization at all and not simply generate a loop with a non-unit counting IV? It's not trying to be funny - it just follows the text of the Fortran Standard (hey, what a concept !): 12 8.1.6.6.1Loop initiation 13 1 When the DO statement is executed, the DO construct becomes active. If loop-control is 14 2 [ , ] do-variable = scalar-int-expr 1 , scalar-int-expr 2 [ , scalar-int-expr 3 ] 15 3 the following steps are performed in sequence. 16 (1)The initial parameter m1 , the terminal parameter m2 , and the incrementation parameter m3 are 17 of type integer with the same kind type parameter as the do-variable. Their values are established 18 by evaluating scalar-int-expr 1 , scalar-int-expr 2 , and scalar-int-expr 3 , respectively, including, if ne- 19 cessary, conversion to the kind type parameter of the do-variable according to the rules for numeric 20 conversion (Table 7.11). If scalar-int-expr 3 does not appear, m3 has the value 1. The value of m3 21 shall not be zero. 22 (2)The DO variable becomes defined with the value of the initial parameter m1 . 23 (3)The iteration count is established and is the value of the expression (m2 - m1 + m3 )/m3 , unless that 24 value is negative, in which case the iteration count is 0. Only interprocedural analysis can tell us that this is a simple loop only executed 3 times (I got this wrong at first - it's *always* executed 3 times). I don't see that the standard suggests the specific code the Frontend generates. In fact it should be valid to increment the DO variable by m3 and express the exit test in terms of the DO variable as well. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42108
[Bug c/42126] gcc optimizes line away/optimizes to an endless loop
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-11-20 23:53 --- The pointer is not declared volatile. static struct smpMsg_t * volatile freeList; would be a volatile pointer. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42126
[Bug middle-end/42103] [4.4 regression] packed 64-bit field reports as violation of strict aliasing rules
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-11-21 00:54 --- (In reply to comment #2) I've also confirmed that using the 'may_alias' attribute in the 64-bit version suppresses the warning, although I think this qualifies as a workaround, not a fix to the problem. I'm also not sure how our project leaders would consider such a workaround, given that the intent behind extra warnings is to make the code better. It is not a work around, it fixes the aliasing issue in your code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42103
[Bug c/42114] c99-stdint test fails for ptrdiff test
--- Comment #4 from hutchinsonandy at gcc dot gnu dot org 2009-11-21 01:35 --- Subject: Bug 42114 Author: hutchinsonandy Date: Sat Nov 21 01:34:51 2009 New Revision: 154392 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154392 Log: PR Testsuite/42114 * gcc-dg/c99-stdint-1.c: Condition test for target without signal.h. XFAIL ptrdiff range test for avr. * gcc-dg/c99-stdint-2.c: XFAIL for avr target. * gcc-dg/c99-stdint-5.c: Condition test for target without signal.h. * gcc-dg/c99-stdint-6.c: Ditto. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/c99-stdint-1.c trunk/gcc/testsuite/gcc.dg/c99-stdint-2.c trunk/gcc/testsuite/gcc.dg/c99-stdint-5.c trunk/gcc/testsuite/gcc.dg/c99-stdint-6.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42114
[Bug middle-end/42127] New: Verify_flow_info: Wrong frequency of block. Profiled bootstrap failed.
GCC 4.5.0 20091119 (r154346) ../../gcc-4.5/gcc/gengtype-parse.c: In function âarray_and_function_declarators_optâ: ../../gcc-4.5/gcc/gengtype-parse.c:508:1: error: verify_flow_info: Wrong frequency of block 13 -184951 ../../gcc-4.5/gcc/gengtype-parse.c:508:1: internal compiler error: verify_flow_info failed -- Summary: Verify_flow_info: Wrong frequency of block. Profiled bootstrap failed. Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: d dot g dot gorbachev at gmail dot com 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=42127
[Bug fortran/42090] [4.3/4.4/4.5 Regression] I/O: Problems when reading partial records in formatted direct access files
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2009-11-21 02:44 --- Subject: Bug 42090 Author: jvdelisle Date: Sat Nov 21 02:44:01 2009 New Revision: 154397 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154397 Log: 2009-11-20 Jerry DeLisle jvdeli...@gcc.gnu.org PR libgfortran/42090 Backport from trunk. * io/transfer.c (skip_record): Set bytes_left_subrecord to zero after skipping the remaining bytes in the record. (next_record_r): Call skip_record with the number of bytes_left to be skipped. Modified: branches/gcc-4_3-branch/libgfortran/ChangeLog branches/gcc-4_3-branch/libgfortran/io/transfer.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42090
[Bug c++/42057] [4.5 Regression] ICE with invalid parameter of virtual function
-- paolo dot carlini at oracle dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |paolo dot carlini at oracle |dot org |dot com Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-11-21 02:44:47 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42057
[Bug fortran/42090] [4.3/4.4/4.5 Regression] I/O: Problems when reading partial records in formatted direct access files
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2009-11-21 02:46 --- Subject: Bug 42090 Author: jvdelisle Date: Sat Nov 21 02:45:48 2009 New Revision: 154398 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154398 Log: 2009-11-20 Jerry DeLisle jvdeli...@gcc.gnu.org PR libgfortran/42090 * gfortran.dg/direct_io_11.f90: New test. Added: branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/direct_io_11.f90 Modified: branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42090
[Bug c++/9050] [DR 147] Can't explicitly specialize C++ constructor templates
-- jason at gcc dot gnu dot org changed: What|Removed |Added Summary|Can't explicitly specialize |[DR 147] Can't explicitly |C++ constructor templates |specialize C++ constructor ||templates Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9050
[Bug fortran/42090] [4.3/4.4/4.5 Regression] I/O: Problems when reading partial records in formatted direct access files
--- Comment #11 from jvdelisle at gcc dot gnu dot org 2009-11-21 03:33 --- Fixed and closing. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42090
[Bug tree-optimization/42078] [4.5 Regression] ICE in gimple_assign_set_rhs_code
--- Comment #8 from aoliva at gcc dot gnu dot org 2009-11-21 05:04 --- Subject: Bug 42078 Author: aoliva Date: Sat Nov 21 05:04:30 2009 New Revision: 154400 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154400 Log: gcc/ChangeLog: PR tree-optimization/42078 * gimple.h (gimple_replace_lhs): New declaration. * gimple.c (gimple_replace_lhs): New function. * tree-ssa-math-opts.c (execute_cse_reciprocals): Call it before modifying the call. gcc/testsuite/ChangeLog: PR tree-optimization/42078 * gcc.dg/pr42078.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr42078.c Modified: trunk/gcc/ChangeLog trunk/gcc/gimple.c trunk/gcc/gimple.h trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-math-opts.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42078
[Bug target/42128] New: ICE in libgcc
ICE in compiling libgcc2.c (--target=h8300-elf) with -msx (with or without -mn -mint32) ../../../../../gcc-svn/libgcc/../gcc/libgcc2.c: In function e__negdi2f: ../../../../../gcc-svn/libgcc/../gcc/libgcc2.c:76:1: internal compiler error: in dwarf2out_begin_epilogue, at dwarf2out.c:2840 To fix this: Index: gcc/config/h8300/h8300.c === --- gcc/config/h8300/h8300.c(revision 154364) +++ gcc/config/h8300/h8300.c(working copy) @@ -719,7 +719,10 @@ x = gen_rtx_PARALLEL (VOIDmode, vec); if (!pop_p) x = Fpa (x); - emit_insn (x); + if (return_p) +emit_jump_insn (x); + else +emit_insn (x); } /* Return true if X has the value sp + OFFSET. */ -- Summary: ICE in libgcc Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: kikairoya at gmail dot com GCC host triplet: x86_64-pc-linux-gnu GCC target triplet: h8300-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42128
[Bug c++/9050] [DR 147] Can't explicitly specialize C++ constructor templates
--- Comment #11 from jason at gcc dot gnu dot org 2009-11-21 06:34 --- Subject: Bug 9050 Author: jason Date: Sat Nov 21 06:33:56 2009 New Revision: 154403 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154403 Log: PR c++/9050, DR 147, DR 318 * parser.c (cp_parser_lookup_name): If the name matches the explicit class scope, we're naming the constructor. (cp_parser_constructor_declarator_p): Just use cp_parser_unqualified_id if we have a nested-name-specifier. (cp_parser_direct_declarator): Handle getting an overload set as a constructor declarator. (cp_parser_unqualified_id): Avoid looking up the constructor when naming the destructor. (cp_parser_diagnose_invalid_type_name): Give good diagnostic for improper use of constructor as template. * typeck.c (finish_class_member_access_expr): Give good diagnostic about calling constructor. * error.c (dump_aggr_type): Don't print A::A for injected-class-name. Added: trunk/gcc/testsuite/g++.dg/template/ctor9.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/error.c trunk/gcc/cp/parser.c trunk/gcc/cp/typeck.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/lookup/name-clash4.C trunk/gcc/testsuite/g++.dg/tc1/dr147.C trunk/gcc/testsuite/g++.old-deja/g++.jason/temporary5.C trunk/gcc/testsuite/g++.old-deja/g++.pt/ctor2.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9050