[Bug tree-optimization/47228] [4.6 Regression] wrong code with loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47228 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P1 CC||jamborm at gcc dot gnu.org --- Comment #4 from Jakub Jelinek 2011-01-26 08:28:31 UTC --- Yeah, clearly SRA fault, as it replaces b[x_1] = c; where both lhs and rhs is correctly type S, i.e. 3 byte packed BLKmode structure, with MEM_REF store which is SImode 4 byte.
[Bug tree-optimization/47426] [4.6 Regression] wrong code with -O2 -fipa-pta
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47426 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||jakub at gcc dot gnu.org Resolution||FIXED --- Comment #6 from Jakub Jelinek 2011-01-26 08:39:39 UTC --- Fixed.
[Bug fortran/47469] New: Check whether arrayfunc_assign_needs_temporary misses TBP/PPC attributes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47469 Summary: Check whether arrayfunc_assign_needs_temporary misses TBP/PPC attributes Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org CC: pa...@gcc.gnu.org, ja...@gcc.gnu.org Found when looking at PR 47455 and trans-expr.c: I wonder whether for type-bound procedures or for procedure-pointer components, the "pointer" or "allocatable" attribute is properly taken into account in arrayfunc_assign_needs_temporary. However, I have not checked whether this is an really and issue or whether there are other related issues. Thus, something like: --- a/gcc/fortran/trans-expr.c +++ b/gcc/fortran/trans-expr.c @@ -5346,8 +5381,8 @@ arrayfunc_assign_needs_temporary (gfc_expr * expr1, gfc_expr * expr2) return true; /* Functions returning pointers need temporaries. */ - if (expr2->symtree->n.sym->attr.pointer - || expr2->symtree->n.sym->attr.allocatable) + if (gfc_expr_attr (expr2).pointer + || gfc_expr_attr (expr2).allocatable) return true; /* Character array functions need temporaries unless the
[Bug c/47470] New: Less-optimized Code Size when using Optimizations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47470
Summary: Less-optimized Code Size when using Optimizations
Product: gcc
Version: 3.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: tomer.l...@nuvoton.com
Created attachment 23129
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23129
Generated Assembly with and w/o optimizations
Hi,
Consider the following code:
int a,b,c,d;
int main (void)
{
while (a || b || c)
{
if (d)
break;
}
return 0;
}
When compiling w/o optimization, the produced code is even smaller than when
providing optimization flags (-O or -Os).
It seems like when using some sort of optimization, the compiler always creates
a loop pre-header. When optimized, the compiler performs a dual comparison,
once in the pre-header, the other in the loop. Without optimizations, only a
single comparison is used, thus code is much smaller (please see attachment for
the generated assembly). Since we are very tight on code size, is there a way
to force the compiler to avoid the usage of such a pre-header while using -Os
optimization? I haven't found any flag/switch for that.
Thanks in advance.
[Bug c++/47206] [4.6 Regression] [C++0x] ICE: SIGSEGV in cp_tree_equal (tree.c:2150) with -fno-elide-constructors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47206 Dodji Seketeli changed: What|Removed |Added CC||dodji at gcc dot gnu.org --- Comment #2 from Dodji Seketeli 2011-01-26 09:53:30 UTC --- I believe this is the same issue as PR c++/47041. That other bug got fixed on trunk and this testcase pass on trunk (4.6) as well. At least since revision r169108
[Bug c++/47206] [4.6 Regression] [C++0x] ICE: SIGSEGV in cp_tree_equal (tree.c:2150) with -fno-elide-constructors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47206 Dodji Seketeli changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #3 from Dodji Seketeli 2011-01-26 09:57:33 UTC --- Fixed in trunk (4.6) *** This bug has been marked as a duplicate of bug 47041 ***
[Bug c++/47041] [4.6 Regression] Internal compiler error in build_data_member_initialization, add cp/semantics.c:5483
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47041 --- Comment #7 from Dodji Seketeli 2011-01-26 09:57:33 UTC --- *** Bug 47206 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/47237] [4.3/4.4/4.5/4.6 Regression] builtin_apply_args broken WRT local ABI changes.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47237 Jan Hubicka changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |hubicka at gcc dot gnu.org |gnu.org | --- Comment #1 from Jan Hubicka 2011-01-26 10:06:05 UTC --- testing patch.
[Bug fortran/47339] Fortran 2003/2008: Valid NAMELIST rejected; Fortran 95: Invalid namelist objects accepted
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47339 Tobias Burnus changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #5 from Tobias Burnus 2011-01-26 10:12:51 UTC --- Author: burnus Date: Wed Jan 26 10:12:47 2011 New Revision: 169282 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169282 Log: 2011-01-26 Tobias Burnus PR fortran/47339 PR fortran/43062 * match.c (gfc_match_namelist): Allow assumed-length characters. * resolve.c (resolve_fl_namelist): Adapt and add error messages. * symbol.c (check_conflict): Allow allocatables in NML for * F2003. * trans-io.c (nml_get_addr_expr,transfer_namelist_element): Changes due to that change. 2011-01-26 Tobias Burnus PR fortran/47339 PR fortran/43062 * fortran.dg/namelist_69.f90: New test. * fortran.dg/namelist_70.f90: New test. * fortran.dg/namelist_assumed_char.f90: Modify dg-error, augment * test. * fortran.dg/namelist_3.f90: Adapt test. * fortran.dg/namelist_34.f90: Ditto. * fortran.dg/namelist_35.f90: Ditto. * fortran.dg/namelist_5.f90: Ditto. * fortran.dg/namelist_63.f90: Ditto. * gfortran.dg/alloc_comp_constraint_1.f90: Ditto. Added: trunk/gcc/testsuite/gfortran.dg/namelist_69.f90 trunk/gcc/testsuite/gfortran.dg/namelist_70.f90 Modified: trunk/gcc/fortran/match.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/symbol.c trunk/gcc/fortran/trans-io.c trunk/gcc/testsuite/gfortran.dg/alloc_comp_constraint_1.f90 trunk/gcc/testsuite/gfortran.dg/namelist_3.f90 trunk/gcc/testsuite/gfortran.dg/namelist_34.f90 trunk/gcc/testsuite/gfortran.dg/namelist_35.f90 trunk/gcc/testsuite/gfortran.dg/namelist_5.f90 trunk/gcc/testsuite/gfortran.dg/namelist_63.f90 trunk/gcc/testsuite/gfortran.dg/namelist_assumed_char.f90 --- Comment #6 from Tobias Burnus 2011-01-26 10:13:26 UTC --- FIXED on the trunk (4.6)
[Bug fortran/43062] NAMELIST attribute conflicts with ALLOCATABLE attribute
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43062 Tobias Burnus changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #24 from Tobias Burnus 2011-01-26 10:12:52 UTC --- Author: burnus Date: Wed Jan 26 10:12:47 2011 New Revision: 169282 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169282 Log: 2011-01-26 Tobias Burnus PR fortran/47339 PR fortran/43062 * match.c (gfc_match_namelist): Allow assumed-length characters. * resolve.c (resolve_fl_namelist): Adapt and add error messages. * symbol.c (check_conflict): Allow allocatables in NML for * F2003. * trans-io.c (nml_get_addr_expr,transfer_namelist_element): Changes due to that change. 2011-01-26 Tobias Burnus PR fortran/47339 PR fortran/43062 * fortran.dg/namelist_69.f90: New test. * fortran.dg/namelist_70.f90: New test. * fortran.dg/namelist_assumed_char.f90: Modify dg-error, augment * test. * fortran.dg/namelist_3.f90: Adapt test. * fortran.dg/namelist_34.f90: Ditto. * fortran.dg/namelist_35.f90: Ditto. * fortran.dg/namelist_5.f90: Ditto. * fortran.dg/namelist_63.f90: Ditto. * gfortran.dg/alloc_comp_constraint_1.f90: Ditto. Added: trunk/gcc/testsuite/gfortran.dg/namelist_69.f90 trunk/gcc/testsuite/gfortran.dg/namelist_70.f90 Modified: trunk/gcc/fortran/match.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/symbol.c trunk/gcc/fortran/trans-io.c trunk/gcc/testsuite/gfortran.dg/alloc_comp_constraint_1.f90 trunk/gcc/testsuite/gfortran.dg/namelist_3.f90 trunk/gcc/testsuite/gfortran.dg/namelist_34.f90 trunk/gcc/testsuite/gfortran.dg/namelist_35.f90 trunk/gcc/testsuite/gfortran.dg/namelist_5.f90 trunk/gcc/testsuite/gfortran.dg/namelist_63.f90 trunk/gcc/testsuite/gfortran.dg/namelist_assumed_char.f90 --- Comment #25 from Tobias Burnus 2011-01-26 10:13:45 UTC --- FIXED on the trunk (4.6). Thanks for the report Xavier!
[Bug c/47470] Less-optimized Code Size when using Optimizations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47470 --- Comment #1 from Mikael Pettersson 2011-01-26 10:17:18 UTC --- gcc-3.3.2 is ancient and no longer supported upstream. Please try gcc-4.4.5 or newer. Also you haven't told us which target you're compiling for, or how your gcc was configured.
[Bug middle-end/40979] induct benchmark 60% slower when compiled with -fgraphite-identity
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40979 --- Comment #9 from Dominique d'Humieres 2011-01-26 10:23:12 UTC --- This pr is not fixed at revision 169261 (gfc). AFAIU -ftree-loop-linear is now implemented through graphite. This leads to a sort of regression with respect to revision 169227(gfc6): [macbook] lin/test% gfc -Ofast -ftree-loop-linear induct.f90 [macbook] lin/test% time a.out > /dev/null 22.380u 0.023s 0:22.40 100.0%0+0k 0+0io 0pf+0w [macbook] lin/test% gfc6 -Ofast -ftree-loop-linear induct.f90 [macbook] lin/test% time a.out > /dev/null 13.978u 0.019s 0:13.99 99.9%0+0k 0+0io 0pf+0w
[Bug debug/47471] New: stdarg functions extraneous too-early prologue end
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47471
Summary: stdarg functions extraneous too-early prologue end
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jan.kratoch...@redhat.com
Target: x86_64-fedora15-linux-gnu
GDB tracker:
http://sourceware.org/bugzilla/show_bug.cgi?id=12435
---
int v;
void f (int i, ...)
{
v++;
}
int main (void) { f (1); return 0; }
---
gcc -o 1 1.c -Wall -g
FAIL gcc (GCC) 4.6.0 20110126 (experimental)
FAIL gcc-4.6.0-0.3.fc15.x86_64
PASS gcc (GCC) 4.5.3 20110124 (prerelease)
PASS gcc-4.5.1-4.fc14.x86_64
GNU gdb (GDB) 7.2.50.20110125-cvs
FAIL:
gdb -nx ./1 -ex 'b f' -ex r
Starting program: .../1
Program exited normally.
PASS:
gdb -nx ./1 -ex 'b f' -ex r
Starting program: .../1
Breakpoint 1, f (i=1) at 1.c:4
4 v++;
GDB workaround is in the GDB PR above but it touches .debug_line parsing which
is sensitive due to missing DWARF prologue end markers - wouldn't a GCC fix be
better?
Extended opcode 2: set Address to 0x400454
Special opcode 7: advance Address by 0 to 0x400454 and Line by 2 to 3
Advance PC by 47 to 0x400483
Special opcode 5: advance Address by 0 to 0x400483 and Line by 0 to 3
^####
Advance PC by 38 to 0x4004a9
Special opcode 6: advance Address by 0 to 0x4004a9 and Line by 1 to 4
The marked line causes GDB prologue-end detection heuristics to fail.
The marked line should be removed.
00400454 :
int v;
void f (int i, ...)
{
400454: 55 push %rbp
400455: 48 89 e5mov%rsp,%rbp
400458: 48 83 ec 48 sub$0x48,%rsp
40045c: 48 89 b5 58 ff ff ffmov%rsi,-0xa8(%rbp)
400463: 48 89 95 60 ff ff ffmov%rdx,-0xa0(%rbp)
40046a: 48 89 8d 68 ff ff ffmov%rcx,-0x98(%rbp)
400471: 4c 89 85 70 ff ff ffmov%r8,-0x90(%rbp)
400478: 4c 89 8d 78 ff ff ffmov%r9,-0x88(%rbp)
40047f: 84 c0 test %al,%al
400481: 74 20 je 4004a3
= Wrong marker - not hit.
400483: 0f 29 45 80 movaps %xmm0,-0x80(%rbp)
400487: 0f 29 4d 90 movaps %xmm1,-0x70(%rbp)
40048b: 0f 29 55 a0 movaps %xmm2,-0x60(%rbp)
40048f: 0f 29 5d b0 movaps %xmm3,-0x50(%rbp)
400493: 0f 29 65 c0 movaps %xmm4,-0x40(%rbp)
400497: 0f 29 6d d0 movaps %xmm5,-0x30(%rbp)
40049b: 0f 29 75 e0 movaps %xmm6,-0x20(%rbp)
40049f: 0f 29 7d f0 movaps %xmm7,-0x10(%rbp)
4004a3: 89 bd 4c ff ff ff mov%edi,-0xb4(%rbp)
= Correct prologue end would be here.
v++;
4004a9: 8b 05 f1 03 20 00 mov0x2003f1(%rip),%eax#
6008a0
4004af: 83 c0 01add$0x1,%eax
4004b2: 89 05 e8 03 20 00 mov%eax,0x2003e8(%rip)#
6008a0
}
4004b8: c9 leaveq
4004b9: c3 retq
[Bug fortran/47472] New: Rules printed by -M option contains duplicate slash when -J option is used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47472 Summary: Rules printed by -M option contains duplicate slash when -J option is used Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: thenl...@users.sourceforge.net Example: testuse.f90: program testuse use testmake end program testuse testmake.f90: module testmake integer :: i, j end module testmake $ gfortran -Jobj -o obj/testmake.o -c testmake.f90 $ gfortran -Jobj -M -cpp testuse.f90 testuse.o: testuse.f90 obj//testmake.mod Expected output is: testuse.o: testuse.f90 obj/testmake.mod
[Bug fortran/47455] [4.6 Regression][OOP] internal compiler error: in fold_convert_loc, at fold-const.c:2028
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47455
--- Comment #4 from Tobias Burnus 2011-01-26
10:36:41 UTC ---
Created attachment 23130
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23130
Draft patch, working but failing due to another related bug
(In reply to comment #3)
[First patch]
Works for the test case, but does not regtest. The following makes more sense:
Replace "proc_pointer" by "pointer || allocatable"
* * *
However, the test case - in the attachment - fails due to a different and in
principle unrelated reason:
find_x2 (struct __class_class_t_T & restrict this)
{
struct tx * res;
res.i.data = 0B;
res = 0B;
The "res.i.data = 0" is obviously wrong: The pointer "res" should be already be
set to NULL - thus the component should in that case never be set.
[Bug target/44392] [4.5 Regression] libgcc compile with --enable-target-optspace (-Os) causes recursion in __bswapsi2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44392 Ramana Radhakrishnan changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #15 from Ramana Radhakrishnan 2011-01-26 10:44:56 UTC --- This is now fixed.
[Bug fortran/47472] Rules printed by -M option contains duplicate slash when -J option is used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47472 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #1 from Tobias Burnus 2011-01-26 11:04:57 UTC --- For digging: The "-cpp -M" functionality has been added 2010-06-13 with commit Rev. 160684.
[Bug other/47467] [4.6 Regression] hwint.h:239:3: error: implicit declaration of function 'abs'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47467 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.01.26 11:08:06 Target Milestone|--- |4.6.0 Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther 2011-01-26 11:08:06 UTC --- Confirmed. Saw this on x86_64-linux as well. In theory it should work, the file properly includes config.h, system.h which includes stdlib.h before including hwint.h.
[Bug c/47473] New: Incorrect computation with complex numbers when using -std=c99
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47473 Summary: Incorrect computation with complex numbers when using -std=c99 Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: ab...@live.com Created attachment 23131 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23131 complexbug3.i This is a report about an issue encountered in MinGW GCC. The maintainers of the MinGW project suggested to report it here. The command line that triggers the bug is: gcc -v -save-temps -Wall -std=c99 complexbug3.c -o complexbug3.exe The option -std=c99 triggers the bug. The resultant output is: Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=c:/program files/mingw/bin/../libexec/gcc/mingw32/4.5.0/lto-wrapper.exe Target: mingw32 Configured with: ../gcc-4.5.0/configure --enable-languages=c,c++,ada,fortran,objc,obj-c++ --disable-sjlj-exceptions --with-dwarf2 --enable-shared --enable-libgomp --disable-win32-registry --enable-libstdcxx-debug --enable-version-specific-runtime-libs --disable-werror --build=mingw32 --prefix=/mingw Thread model: win32 gcc version 4.5.0 (GCC) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-std=c99' '-o' 'complexbug3.exe' '-mtune=i386' '-march=i386' c:/program files/mingw/bin/../libexec/gcc/mingw32/4.5.0/cc1.exe -E -quiet -v -iprefix c:\program files\mingw\bin\../lib/gcc/mingw32/4.5.0/ complexbug3.c -mtune=i386 -march=i386 -std=c99 -Wall -fpch-preprocess -o complexbug3.i ignoring nonexistent directory "c:\program files\mingw\bin\../lib/gcc/mingw32/4.5.0/../../../../mingw32/include" ignoring nonexistent directory "c:/mingw/include" ignoring nonexistent directory "/mingw/include" ignoring duplicate directory "c:/program files/mingw/lib/gcc/../../lib/gcc/mingw32/4.5.0/include" ignoring duplicate directory "c:/program files/mingw/lib/gcc/../../lib/gcc/mingw32/4.5.0/include-fixed" ignoring nonexistent directory "c:/program files/mingw/lib/gcc/../../lib/gcc/mingw32/4.5.0/../../../../mingw32/include" ignoring nonexistent directory "/mingw/include" #include "..." search starts here: #include <...> search starts here: c:\program files\mingw\bin\../lib/gcc/mingw32/4.5.0/../../../../include c:\program files\mingw\bin\../lib/gcc/mingw32/4.5.0/include c:\program files\mingw\bin\../lib/gcc/mingw32/4.5.0/include-fixed End of search list. COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-std=c99' '-o' 'complexbug3.exe' '-mtune=i386' '-march=i386' c:/program files/mingw/bin/../libexec/gcc/mingw32/4.5.0/cc1.exe -fpreprocessed complexbug3.i -quiet -dumpbase complexbug3.c -mtune=i386 -march=i386 -auxbase complexbug3 -Wall -std=c99 -version -o complexbug3.s GNU C (GCC) version 4.5.0 (mingw32) compiled by GNU C version 4.5.0, GMP version 5.0.1, MPFR version 2.4.1, MPC version 0.8.1 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU C (GCC) version 4.5.0 (mingw32) compiled by GNU C version 4.5.0, GMP version 5.0.1, MPFR version 2.4.1, MPC version 0.8.1 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 6773400e8bc9df4b012089071ac4c86b COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-std=c99' '-o' 'complexbug3.exe' '-mtune=i386' '-march=i386' c:/program files/mingw/bin/../lib/gcc/mingw32/4.5.0/../../../../mingw32/bin/as.exe -o complexbug3.o complexbug3.s COMPILER_PATH=c:/program files/mingw/bin/../libexec/gcc/mingw32/4.5.0/;c:/program files/mingw/bin/../libexec/gcc/;c:/program files/mingw/bin/../lib/gcc/mingw32/4.5.0/../../../../mingw32/bin/ LIBRARY_PATH=c:/program files/mingw/bin/../lib/gcc/mingw32/4.5.0/;c:/program files/mingw/bin/../lib/gcc/;c:/program files/mingw/bin/../lib/gcc/mingw32/4.5.0/../../../../mingw32/lib/;c:/program files/mingw/bin/../lib/gcc/mingw32/4.5.0/../../../ COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-std=c99' '-o' 'complexbug3.exe' '-mtune=i386' '-march=i386' c:/program files/mingw/bin/../libexec/gcc/mingw32/4.5.0/collect2.exe -Bdynamic -o complexbug3.exe c:/program files/mingw/bin/../lib/gcc/mingw32/4.5.0/../../../crt2.o c:/program files/mingw/bin/../lib/gcc/mingw32/4.5.0/crtbegin.o -Lc:/program files/mingw/bin/../lib/gcc/mingw32/4.5.0 -Lc:/program files/mingw/bin/../lib/gcc -Lc:/program files/mingw/bin/../lib/gcc/mingw32/4.5.0/../../../../mingw32/lib -Lc:/program files/mingw/bin/../lib/gcc/mingw32/4.5.0/../../.. complexbug3.o -lmingw32 -lgcc_eh -lgcc -lmoldname -lmingwex -lmsvcrt -luser32 -lkernel32 -ladvapi32 -lshell32 -lmingw32 -lgcc_eh -lgcc -lmoldname -lmingwex -lmsvcrt c:/program files/mingw/bin/../lib/gcc/mingw32/4.5.0/crtend.o The result of executing complexbug3.exe is mathematically incorrect: (0.2 - I*0.3)*(0.3 - I*0.9) = (0.06, -0.09)
[Bug target/47473] [4.5/4.6 Regression] Incorrect computation with complex numbers when using -std=c99
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47473 Richard Guenther changed: What|Removed |Added Target||i?86-*-* Status|UNCONFIRMED |NEW Known to work||4.4.4 Keywords||wrong-code Last reconfirmed||2011.01.26 11:26:29 Component|c |target Ever Confirmed|0 |1 Summary|Incorrect computation with |[4.5/4.6 Regression] |complex numbers when using |Incorrect computation with |-std=c99|complex numbers when using ||-std=c99 Target Milestone|--- |4.5.3 Known to fail||4.5.0, 4.5.2, 4.6.0 --- Comment #1 from Richard Guenther 2011-01-26 11:26:29 UTC --- Confirmed on i?86-linux. Seems to be a problem with libgcc __mulxc3, linking with the libgcc from 4.4 makes it work for the failing releases.
[Bug lto/47423] Many testsuite failures caused by missing gxx_visibility_sj0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47423 Richard Guenther changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED --- Comment #4 from Richard Guenther 2011-01-26 11:29:46 UTC --- Author: rguenth Date: Wed Jan 26 11:29:42 2011 New Revision: 169284 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169284 Log: 2011-01-26 Richard Guenther PR lto/47423 * cgraphbuild.c (record_eh_tables): Record reference to personality function. Modified: trunk/gcc/ChangeLog trunk/gcc/cgraphbuild.c --- Comment #5 from Richard Guenther 2011-01-26 11:30:58 UTC --- Fixed.
[Bug other/47467] [4.6 Regression] hwint.h:239:3: error: implicit declaration of function 'abs'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47467 --- Comment #2 from Richard Guenther 2011-01-26 11:39:21 UTC --- Ah. gcc/ada/targext.c fails to include config.h.
[Bug c/47470] Less-optimized Code Size when using Optimizations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47470 --- Comment #2 from Tomer Levi 2011-01-26 11:43:36 UTC --- Hi, The attached assembly was produced on the following machine: taln36-Amit<1015> gcc -v Reading specs from /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.1/specs Configured with: ./configure -prefix=/usr/ : (reconfigured) ./configure : (reconfigured) ./configure : (reconfigured) ./configure Thread model: single gcc version 3.1 In specific, i'm using CR16 architecture, which is based on GCC 3.3.2 (compiler backend is not under GNU, only Binutils). However, the behavior i'm describing is not related to the backend. I have no GCC 4.* installed, hence do not know whether the described behavior is reproducible using the latest compiler. I'll appreciate if you can verify this. BTW, is my assumption regarding loop pre-header is correct? If so, is there any way to avoid it, thus to save code size? Thanks.
[Bug other/47467] [4.6 Regression] hwint.h:239:3: error: implicit declaration of function 'abs'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47467 Richard Guenther changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #3 from Richard Guenther 2011-01-26 11:53:54 UTC --- Author: rguenth Date: Wed Jan 26 11:53:51 2011 New Revision: 169285 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169285 Log: 2011-01-26 Richard Guenther PR bootstrap/47467 * targext.c: Include config.h. * gcc-interface/Make-lang.in (ada/targext.o): Add $(CONFIG_H) dependency. Modified: trunk/gcc/ada/ChangeLog trunk/gcc/ada/gcc-interface/Make-lang.in trunk/gcc/ada/targext.c --- Comment #4 from Richard Guenther 2011-01-26 11:54:08 UTC --- Fixed.
[Bug c/47470] Less-optimized Code Size when using Optimizations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47470 --- Comment #3 from Mikael Pettersson 2011-01-26 12:23:03 UTC --- (In reply to comment #2) > Hi, > The attached assembly was produced on the following machine: > > taln36-Amit<1015> gcc -v > Reading specs from /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.1/specs > Configured with: ./configure -prefix=/usr/ : (reconfigured) ./configure : > (reconfigured) ./configure : (reconfigured) ./configure > Thread model: single > gcc version 3.1 Do that for your cross-gcc to cr16 instead.
[Bug fortran/45586] [4.6 Regression] ICE non-trivial conversion at assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586 --- Comment #43 from Michael Matz 2011-01-26 12:39:04 UTC --- Yep. With my patch the saner looking new_person->service.education.person.ss = *ss; statement is generated. It's possible that class containers actually contain something as first component that shouldn't be looked up, then the condition would be reversed, or that meanwhile the parent type is always reachable via the first component. The latter is definitely the case for types that don't have is_class set.
[Bug c/47470] Less-optimized Code Size when using Optimizations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47470 --- Comment #4 from Tomer Levi 2011-01-26 12:47:14 UTC --- The cross-gcc compiler i'm using is hooking the default GNU verbose message, hence i can not tell how GCC was exactly configured. As i alredy said, the issue is reproducible on native GCC (i686-pc-linux-gnu), so the target i'm using is not necessarily relevant here. I'm just looking for a way to alter the compiler's behavior. I think the cross-target is configured as follows: ../$(GCC_DIR)/configure --target=cr16c --enable-languages=c,c++ --disable-checking --prefix=$(PREFIX) --with-as=$(PREFIX)/bin/crasm --with-ld=$(PREFIX)/bin/crld --with-headers=$(PREFIX)/include
[Bug c/47470] Less-optimized Code Size when using Optimizations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47470 --- Comment #5 from Richard Guenther 2011-01-26 12:50:57 UTC --- Try -fno-loop-optimize (or -fno-loop-optimize2 if that is already available).
[Bug c/47470] Less-optimized Code Size when using Optimizations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47470 --- Comment #6 from Tomer Levi 2011-01-26 13:00:17 UTC --- Hi Richard, Thanks for your prompt reply. Actually, -fno-loop-optimize was the first thing i've tried when facing this issue. However, the generated code is even worse than using -Os alone. The loop pre-header still appears, meaning dual comparison. -fno-loop-optimize2 is not supported under GCC 3.3.2.
[Bug fortran/47474] New: Wrong code with allocatable scalar, allocatable components as function result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47474
Summary: Wrong code with allocatable scalar, allocatable
components as function result
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bur...@gcc.gnu.org
CC: ja...@gcc.gnu.org
Blocks: 47455
Found as part of PR 47455. For the following program
function find_y() result(res)
type(tx), allocatable :: res
! do something sensible such as "allocate(res)"
end function find_y
the dump looks as follows
find_y ()
{
struct tx * res;
res.i.data = 0B; /* WRONG. */
res = 0B;
/* some code. */
return res;
}
If one does not use a RESULT variable but "find_y" as result variable, the dump
looks as follows:
find_y ()
{
__result_find_y.i.data = 0B; /* Note: 1. */
return __result_find_y;
}
Note 1: Unless "find_y" is used (e.g. "allocate(find_y)") the function is
generated with an empty body.
For some reason, the example program below does not crash here with gfortran
4.5/4.6, but the dump is wrong and I am sure it can cause problems in certain
cases. The example of bug 47455 comment 4 does crash - and I believe(d) that it
is due to this bug.
program test
type :: tx
integer, dimension(:), allocatable :: i
end type tx
type(tx) :: x
x = find_y()
if (allocated(x%i)) call abort()
contains
function find_y() result(res)
type(tx), allocatable :: res
allocate(res)
end function find_y
end program test
[Bug c/47470] Less-optimized Code Size when using Optimizations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47470 --- Comment #7 from Tomer Levi 2011-01-26 13:16:16 UTC --- Hi, I was able to test the behavior on GCC 3.4.5 (native): Here, the -fno-loop-optimize (and -fno-loop-optimize2) generate an optimized code as expected. Unfortunately, i don't have a GCC 3.3.2 native installation, hence i can't verify whether the behavior i'm seeing using my cross-gcc is due to the frontend or backend.
[Bug target/42894] [4.5/4.6 Regression] Invalid rtl sharing in Thumb1.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42894
--- Comment #17 from Jakub Jelinek 2011-01-26
13:21:46 UTC ---
Simplified testcase:
extern __thread int t;
void
foo (int a)
{
t = a;
}
Looking at it in detail, not sure if the bug isn't earlier.
Seems the expander isn't extra careful about rtl sharing issues and relies on
subsequent unsharing of everything. Except that unshare_all_rtl doesn't look
at constant pool expressions.
So, a fix could be something like:
--- expr.c.jj 2011-01-18 08:44:29.0 +0100
+++ expr.c 2011-01-26 13:29:34.644796679 +0100
@@ -3398,7 +3398,7 @@ emit_move_insn (rtx x, rtx y)
&& (set = single_set (last_insn)) != NULL_RTX
&& SET_DEST (set) == x
&& ! rtx_equal_p (y_cst, SET_SRC (set)))
-set_unique_reg_note (last_insn, REG_EQUAL, y_cst);
+set_unique_reg_note (last_insn, REG_EQUAL, copy_rtx (y_cst));
return last_insn;
}
or e.g.:
--- varasm.c.jj2011-01-25 12:58:41.0 +0100
+++ varasm.c2011-01-26 14:07:50.635389932 +0100
@@ -3518,7 +3518,7 @@ force_const_mem (enum machine_mode mode,
pool->offset &= ~ ((align / BITS_PER_UNIT) - 1);
desc->next = NULL;
- desc->constant = tmp.constant;
+ desc->constant = copy_rtx (tmp.constant);
desc->offset = pool->offset;
desc->hash = hash;
desc->mode = mode;
(the latter is IMHO better). Both fix this ICE. Perhaps if
avoid_constant_pool_reference callers want to use the result in insn stream
they need to unshare it again (at least if they use it more than once), not
sure if avoid_constant_pool_reference itself shoudl do the copy_rtx or just if
callers should take care of it. Jeff, what do you think about this?
I've tried if copy_rtx_if_shared couldn't be itself taught about unsharing the
constants, i.e. that we wouldn't unnecessarily unshare if it wasn't used
anywhere else, but it gets quite complicated because SYMBOL_REFs should be
shared, yet we want to recurse just once on their &SYMBOL_REF_CONSTANT
(x)->constant for CONSTANT_POOL_REFERENCE_P. In copy_rtx_if_shared it can be
coded, but not sure what to do about mark_used_flags. I think the varasm.c
patch above shouldn't be a big deal, most constants in the constant pool can be
actually shared and thus copy_rtx on them is a nop.
[Bug c/47470] Less-optimized Code Size when using Optimizations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47470 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #8 from Richard Guenther 2011-01-26 13:37:50 UTC --- You can also try -fno-thread-jumps, but really we don't care about 3.x anymore and for example 4.5.1 creates reasonable code for me on i?86-linux. > gcc-4.5 -c t.c -m32 -Os > size t.o textdata bss dec hex filename 50 0 0 50 32 t.o > gcc-3.3 -c t.c -m32 -Os > size t.o textdata bss dec hex filename 70 0 0 70 46 t.o > gcc-3.3 -c t.c -m32 > size t.o textdata bss dec hex filename 73 0 0 73 49 t.o Thus closing as fixed.
[Bug target/47473] [4.5/4.6 Regression] Incorrect computation with complex numbers when using -std=c99
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47473
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek 2011-01-26
13:42:50 UTC ---
Unincluded testcase:
int
main (void)
{
long double _Complex w = 0.2L - 0.3iL;
w = w * (0.3L - (0.0F + 1.0iF) * 0.9L);
__builtin_printf("(0.2 - I*0.3)*(0.3 - I*0.9) = (%g, %g)\n", (double)
__real__ w, (double) __imag__ w);
return 0;
}
On x86_64-linux the results look correct.
Using
w = w * (0.3L - 0.9iL);
instead works too. And the results I get don't depend on libgcc version used
(4.4 behaves like 4.6).
[Bug target/46878] V850 ICE in in maybe_add_or_update_dep_1, at sched-deps.c:854
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46878 Jeffrey A. Law changed: What|Removed |Added CC||joel at gcc dot gnu.org --- Comment #17 from Jeffrey A. Law 2011-01-26 14:10:28 UTC --- *** Bug 47459 has been marked as a duplicate of this bug. ***
[Bug rtl-optimization/47459] [4.6 regression] ICE in maybe_add_or_update_dep_1, at sched-deps.c:854
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47459 Jeffrey A. Law changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||law at redhat dot com Resolution||DUPLICATE --- Comment #2 from Jeffrey A. Law 2011-01-26 14:10:28 UTC --- Duplicate of 46878 which DJ is working on. *** This bug has been marked as a duplicate of bug 46878 ***
[Bug target/46878] V850 ICE in in maybe_add_or_update_dep_1, at sched-deps.c:854
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46878 Jeffrey A. Law changed: What|Removed |Added Known to fail||4.6.0 --- Comment #18 from Jeffrey A. Law 2011-01-26 14:12:53 UTC --- Note we're seeing this failure on m68k as well and it's a regression.
[Bug target/46878] V850 ICE in in maybe_add_or_update_dep_1, at sched-deps.c:854
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46878 Jeffrey A. Law changed: What|Removed |Added Priority|P3 |P2
[Bug rtl-optimization/46878] V850 ICE in in maybe_add_or_update_dep_1, at sched-deps.c:854
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46878 Jeffrey A. Law changed: What|Removed |Added Keywords||ice-on-valid-code Component|target |rtl-optimization Target Milestone|--- |4.6.0
[Bug tree-optimization/47237] [4.3/4.4/4.5/4.6 Regression] builtin_apply_args broken WRT local ABI changes.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47237 Jan Hubicka changed: What|Removed |Added Status|ASSIGNED|WAITING --- Comment #2 from Jan Hubicka 2011-01-26 14:06:23 UTC --- Author: hubicka Date: Wed Jan 26 14:06:20 2011 New Revision: 169290 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169290 Log: PR target/47237 * cgraph.h (cgraph_local_info): New field can_change_signature. * ipa-cp.c (ipcp_update_callgraph): Only compute args_to_skip if callee signature can change. (ipcp_estimate_growth): Call sequence simplify only if calle signature can change. (ipcp_insert_stage): Only compute args_to_skip if signature can change. (cgraph_function_versioning): We can not change signature of functions that don't allow that. * lto-cgraph.c (lto_output_node): Stream local.can_change_signature. (lto_input_node): Likewise. * ipa-inline.c (compute_inline_parameters): Compute local.can_change_signature. * ipa-split.c (visit_bb): Never split away APPLY_ARGS. * tree-sra.c (ipa_sra_preliminary_function_checks): Give up on functions that can not change signature. * i386.c (ix86_function_regparm, ix86_function_sseregparm, init_cumulative_args): Do not use local calling conventions for functions that can not change signature. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr47237.c Modified: trunk/gcc/cgraph.c trunk/gcc/cgraph.h trunk/gcc/cgraphunit.c trunk/gcc/config/i386/i386.c trunk/gcc/ipa-cp.c trunk/gcc/ipa-inline.c trunk/gcc/ipa-split.c trunk/gcc/lto-cgraph.c trunk/gcc/tree-sra.c --- Comment #3 from Jan Hubicka 2011-01-26 14:07:05 UTC --- Author: hubicka Date: Wed Jan 26 14:07:02 2011 New Revision: 169291 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169291 Log: PR target/47237 * gcc.c-torture/execute/pr47237.c: New testcase. * cgraph.h (cgraph_local_info): New field can_change_signature. * ipa-cp.c (ipcp_update_callgraph): Only compute args_to_skip if callee signature can change. (ipcp_estimate_growth): Call sequence simplify only if calle signature can change. (ipcp_insert_stage): Only compute args_to_skip if signature can change. (cgraph_function_versioning): We can not change signature of functions that don't allow that. * lto-cgraph.c (lto_output_node): Stream local.can_change_signature. (lto_input_node): Likewise. * ipa-inline.c (compute_inline_parameters): Compute local.can_change_signature. * ipa-split.c (visit_bb): Never split away APPLY_ARGS. * tree-sra.c (ipa_sra_preliminary_function_checks): Give up on functions that can not change signature. * i386.c (ix86_function_regparm, ix86_function_sseregparm, init_cumulative_args): Do not use local calling conventions for functions that can not change signature. Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog --- Comment #4 from Jan Hubicka 2011-01-26 14:17:28 UTC --- I've commited patch fixing the testcase. H.J., can you please confirm that the LTO 32bit faiulres are gone for you?
[Bug tree-optimization/47190] [4.5/4.6 Regression] ICE: in function_and_variable_visibility, at ipa.c:934 with static weakref variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47190 Jan Hubicka changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #3 from Jan Hubicka 2011-01-26 14:03:58 UTC --- Author: hubicka Date: Wed Jan 26 14:03:54 2011 New Revision: 169288 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169288 Log: PR tree-optimization/47190 * cgraphunit.c (process_common_attributes): New function. (process_function_and_variable_attributes): Use it. * gcc.dg/attr-weakref-3.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/attr-weakref-3.c Modified: trunk/gcc/ChangeLog trunk/gcc/cgraphunit.c trunk/gcc/testsuite/ChangeLog --- Comment #4 from Jan Hubicka 2011-01-26 14:19:55 UTC --- Fixed.
[Bug middle-end/40979] induct benchmark 60% slower when compiled with -fgraphite-identity
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40979 --- Comment #10 from Jack Howarth 2011-01-26 14:20:18 UTC --- (In reply to comment #9) > This pr is not fixed at revision 169261 (gfc). AFAIU -ftree-loop-linear is now > implemented through graphite. This leads to a sort of regression with respect > to revision 169227(gfc6): > > [macbook] lin/test% gfc -Ofast -ftree-loop-linear induct.f90 > [macbook] lin/test% time a.out > /dev/null > 22.380u 0.023s 0:22.40 100.0%0+0k 0+0io 0pf+0w > [macbook] lin/test% gfc6 -Ofast -ftree-loop-linear induct.f90 > [macbook] lin/test% time a.out > /dev/null > 13.978u 0.019s 0:13.99 99.9%0+0k 0+0io 0pf+0w Note that -fgraphite-identity still triggers a large number of failures in the vect.exp testsuite when defaulted on at -O2... http://gcc.gnu.org/ml/gcc-testresults/2011-01/msg02005.html so the regression in induct.f90 isn't unique.
[Bug tree-optimization/47237] [4.3/4.4/4.5/4.6 Regression] builtin_apply_args broken WRT local ABI changes.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47237 --- Comment #5 from H.J. Lu 2011-01-26 14:26:08 UTC --- (In reply to comment #4) > I've commited patch fixing the testcase. H.J., can you please confirm that the > LTO 32bit faiulres are gone for you? Sure.
[Bug middle-end/46949] [4.6 regression] ICE when weakref is used on a definition (internal compiler error: in function_and_variable_visibility, at ipa.c:904)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46949 Jan Hubicka changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.01.26 14:29:32 CC||hubicka at gcc dot gnu.org AssignedTo|unassigned at gcc dot |hubicka at gcc dot gnu.org |gnu.org | Summary|ICE when weakref is used on |[4.6 regression] ICE when |a definition (internal |weakref is used on a |compiler error: in |definition (internal |function_and_variable_visib |compiler error: in |ility, at ipa.c:904)|function_and_variable_visib ||ility, at ipa.c:904) Ever Confirmed|0 |1 --- Comment #1 from Jan Hubicka 2011-01-26 14:29:32 UTC --- Confirmed. Mine.
[Bug lto/43467] LTO error "bytecode stream: trying to read 0 bytes after the end of the input buffer"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43467 Jan Hubicka changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #6 from Jan Hubicka 2011-01-26 14:40:34 UTC --- Given the shape of 4.5 LTO, I would propose this for WONTFIX.
[Bug bootstrap/46856] [4.6 regression] internal compiler error in final_scan_insn breaks m68k-linux bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46856 --- Comment #6 from Mikael Pettersson 2011-01-26 14:43:34 UTC --- The loop in reload_combine_recognize_const_pattern contains this check: /* If the add clobbers another hard reg in parallel, don't move it past a real set of this hard reg. */ if (must_move_add && clobbered_regno >= 0 && reg_state[clobbered_regno].real_store_ruid >= use_ruid) break; Since the moved add is a cc0 setter, it seems reasonable to check here that it's not moved past another cc0 setter. Replacing the previous patch with the following also restores bootstrap (testsuite still running): --- gcc-4.6-20110115/gcc/postreload.c.~1~ 2010-12-21 15:51:42.0 +0100 +++ gcc-4.6-20110115/gcc/postreload.c 2011-01-18 20:26:39.0 +0100 @@ -1008,6 +1008,11 @@ reload_combine_recognize_const_pattern ( if (must_move_add && clobbered_regno >= 0 && reg_state[clobbered_regno].real_store_ruid >= use_ruid) break; +#if defined(HAVE_cc0) + /* Unbreak m68k, see PR bootstrap/46856. */ + if (must_move_add && sets_cc0_p (PATTERN (use_insn))) + break; +#endif gcc_assert (reg_state[regno].store_ruid <= use_ruid); /* Avoid moving a use of ADDREG past a point where it is stored. */
[Bug lto/46652] undefined reference to '__udivdi3' with -flto -fuse-linker-plugin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46652 Jan Hubicka changed: What|Removed |Added CC||dave.korn.cygwin at gmail ||dot com, hubicka at gcc dot ||gnu.org --- Comment #5 from Jan Hubicka 2011-01-26 14:45:25 UTC --- Gold was updated to handle this well for binutils 2.11.1, so H.J.'s branch. We still have issues with mainline GNU LD. Dave, what about getting this fixed the gold way?
[Bug tree-optimization/47190] [4.5/4.6 Regression] ICE: in function_and_variable_visibility, at ipa.c:934 with static weakref variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47190 H.J. Lu changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Comment #5 from H.J. Lu 2011-01-26 14:45:49 UTC --- Any plan for backport? If not, we should reset target milestone.
[Bug lto/46652] undefined reference to '__udivdi3' with -flto -fuse-linker-plugin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46652 --- Comment #6 from Jan Hubicka 2011-01-26 14:46:40 UTC --- Gold was updated to handle this well for binutils 2.11.1, so H.J.'s branch. We still have issues with mainline GNU LD. Dave, what about getting this fixed the gold way?
[Bug lto/46948] [4.6 Regression] Undefined reference errors, LTO, and visibility
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46948 Jan Hubicka changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||hubicka at gcc dot gnu.org Resolution||INVALID --- Comment #2 from Jan Hubicka 2011-01-26 14:49:02 UTC --- This is documented feature. See "Hidden symbols used from non-link time objects now have to be explicitly annotated with externally_visible when the linker plugin is not used." at changes.html W/o handling hidden visibility the "optimistic" way, we would need extra attributes to make LTO effective w/o plugin on shared libs (since -fwhole-program + externally_visible flag is not too handy there given that most programs was decorated the other way arround with hidden visibilities).
[Bug rtl-optimization/46878] [4.6 regression] V850 ICE in in maybe_add_or_update_dep_1, at sched-deps.c:854
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46878 Mikael Pettersson changed: What|Removed |Added CC||mikpe at it dot uu.se --- Comment #19 from Mikael Pettersson 2011-01-26 14:50:28 UTC --- (In reply to comment #18) > Note we're seeing this failure on m68k as well and it's a regression. Could it be related to PR46856 (a HAVE_cc0 postreload regression from r162270 that's breaking m68k-linux)?
[Bug tree-optimization/47190] [4.5 Regression] ICE: in function_and_variable_visibility, at ipa.c:934 with static weakref variable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47190 Jan Hubicka changed: What|Removed |Added Summary|[4.5/4.6 Regression] ICE: |[4.5 Regression] ICE: in |in |function_and_variable_visib |function_and_variable_visib |ility, at ipa.c:934 with |ility, at ipa.c:934 with|static weakref variable |static weakref variable | --- Comment #6 from Jan Hubicka 2011-01-26 14:55:55 UTC --- I am surprised that this ICEs at 4.5, too, since I was under impression that the sanity check was introduced in 4.6 timeframe. Anyway, backporting is easy, so I will commit it to 4.5 branch if it is approved for so. Removing 4.6 from regression list.
[Bug c++/47475] New: Static member function template of class variadic template can't be called from the inside
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47475
Summary: Static member function template of class variadic
template can't be called from the inside
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: flo.gouj...@orange.fr
GCC 4.5 and 4.6 can't compile the following piece of code, which seems valid:
template
struct test;
template<>
struct test<>
{
template
static void f()
{
}
};
template
struct test
{
template
static void f()
{
test::f(); //compiler error here
}
};
Here is the compiler error message:
|| /usr/local/bin/g++ -c main.cpp -W -Wall -pedantic -std=c++0x
|| main.cpp: In static member function ‘static void test::f()’:
main.cpp|19 col 19| error: expected primary-expression before ‘>’ token
main.cpp|19 col 21| error: expected primary-expression before ‘)’ token
|| make: *** [main.o] Error 1
However, GCC doesn't complain with this:
int main()
{
test::f();
}
[Bug rtl-optimization/44469] [4.5/4.6 Regression] internal compiler error: in fixup_reorder_chain, at cfglayout.c:797
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44469 Eric Botcazou changed: What|Removed |Added CC||ebotcazou at gcc dot ||gnu.org AssignedTo|rth at gcc dot gnu.org |ebotcazou at gcc dot ||gnu.org --- Comment #7 from Eric Botcazou 2011-01-26 15:02:49 UTC --- Testing a fix.
[Bug fortran/47474] Wrong code with allocatable scalar, allocatable components as function result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47474
--- Comment #1 from Tobias Burnus 2011-01-26
15:04:53 UTC ---
Patch. The order was wrong; additionally, if there is an allocatable RESULT
variable, it seems to get zero initialized via sym->value or similarly. Thus
the sym->result == result check prevents that two "res = 0B;" lines get added.
--- a/gcc/fortran/trans-decl.c
+++ b/gcc/fortran/trans-decl.c
@@ -4602,16 +4716,18 @@ gfc_generate_function_code (gfc_namespace * ns)
&& sym->attr.function
&& !sym->attr.pointer)
{
- if (sym->ts.type == BT_DERIVED
- && sym->ts.u.derived->attr.alloc_comp)
+ if (sym->attr.allocatable && sym->attr.dimension == 0
+ && sym->result == sym)
+ gfc_add_modify (&init, result, fold_convert (TREE_TYPE (result),
+null_pointer_node));
+ else if (sym->ts.type == BT_DERIVED
+ && sym->ts.u.derived->attr.alloc_comp
+ && !sym->attr.allocatable)
{
rank = sym->as ? sym->as->rank : 0;
tmp = gfc_nullify_alloc_comp (sym->ts.u.derived, result, rank);
gfc_add_expr_to_block (&init, tmp);
}
- else if (sym->attr.allocatable && sym->attr.dimension == 0)
- gfc_add_modify (&init, result, fold_convert (TREE_TYPE (result),
-null_pointer_node));
}
if (result == NULL_TREE)
[Bug c/47473] [4.5/4.6 Regression] Incorrect computation with complex numbers when using -std=c99
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47473 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Component|target |c AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | --- Comment #3 from Jakub Jelinek 2011-01-26 15:10:07 UTC --- Mine.
[Bug c/47473] [4.5/4.6 Regression] Incorrect computation with complex numbers when using -std=c99
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47473 --- Comment #4 from H.J. Lu 2011-01-26 15:14:10 UTC --- It is caused by revision 147281: http://gcc.gnu.org/ml/gcc-cvs/2009-05/msg00255.html
[Bug c/47473] [4.5/4.6 Regression] Incorrect computation with complex numbers when using -std=c99
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47473 --- Comment #5 from Jakub Jelinek 2011-01-26 15:19:56 UTC --- Created attachment 23132 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23132 gcc46-pr47473.patch Untested fix.
[Bug lto/46652] undefined reference to '__udivdi3' with -flto -fuse-linker-plugin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46652 Dave Korn changed: What|Removed |Added CC||davek at gcc dot gnu.org --- Comment #7 from Dave Korn 2011-01-26 15:19:43 UTC --- (In reply to comment #6) > Gold was updated to handle this well for binutils 2.11.1, so H.J.'s branch. > We still have issues with mainline GNU LD. Dave, what about getting this > fixed > the gold way? Seems worth investigating. I'll take a look at it starting tomorrow sometime.
[Bug target/42894] [4.5/4.6 Regression] Invalid rtl sharing in Thumb1.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42894 --- Comment #18 from Jakub Jelinek 2011-01-26 15:34:38 UTC --- Created attachment 23133 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23133 gcc46-pr42894.patch The varasm.c alternative (untested).
[Bug middle-end/47379] fwprop1 generates bad codes for x32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47379 H.J. Lu changed: What|Removed |Added CC||amodra at gmail dot com, ||ubizjak at gmail dot com --- Comment #3 from H.J. Lu 2011-01-26 15:39:05 UTC --- This regression may be introduced by revision 151022: http://gcc.gnu.org/ml/gcc-cvs/2009-08/msg00704.html Propagate zero extended register is bad for x86-64.
[Bug c++/47476] New: [4.6 Regression] [C++0x] ICE in potential_constant_expression_1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47476
Summary: [4.6 Regression] [C++0x] ICE in
potential_constant_expression_1
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: c++
AssignedTo: ja...@gcc.gnu.org
ReportedBy: ja...@gcc.gnu.org
int
foo (int a, int b)
{
const bool c ((a != 0) == (b != 26));
return c;
}
ICEs with -std=c++0x with:
rh672156.ii:4:38: sorry, unimplemented: unexpected ast of kind truth_xor_expr
rh672156.ii:4:38: internal compiler error: in potential_constant_expression_1,
at cp/semantics.c:7709
[Bug c++/47476] [4.6 Regression] [C++0x] ICE in potential_constant_expression_1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47476 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.01.26 16:21:06 Known to work||4.5.2 Target Milestone|--- |4.6.0 Ever Confirmed|0 |1 Known to fail||4.6.0 --- Comment #1 from Jakub Jelinek 2011-01-26 16:21:06 UTC --- Works in 4.5.
[Bug rtl-optimization/46878] [4.6 regression] V850 ICE in in maybe_add_or_update_dep_1, at sched-deps.c:854
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46878 --- Comment #20 from Jeffrey A. Law 2011-01-26 14:56:14 UTC --- -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/26/11 07:51, mikpe at it dot uu.se wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46878 > > Mikael Pettersson changed: > >What|Removed |Added > > CC||mikpe at it dot uu.se > > --- Comment #19 from Mikael Pettersson 2011-01-26 > 14:50:28 UTC --- > (In reply to comment #18) >> Note we're seeing this failure on m68k as well and it's a regression. > > Could it be related to PR46856 (a HAVE_cc0 postreload regression from r162270 > that's breaking m68k-linux)? It's related in the sense that both are problems with cc0 targets, but I doubt the underlying root cause is the same. jeff -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNQDYBAAoJEBRtltQi2kC7r+cH/28xx5O9b7ll8SqYuNMwAIQP vJEStmdjxFEP84DOXd7WPPPyW4qwdEfy2ufFCgorX9MYbyNkxAYGcT96CQUX5jVU z/u+69tzrLwDwcNQ75tLb+THJVwiyUCIz52bNdXo2rHWKGy2yXM+97zdhnBmSNoA Vrr+bLnESl0WiDFxdwlSJALTAEXyRaj4iXR+LR8yN/ewt1bsTt4hIaMmyKcNLuV+ ASOnhFl4x/q+QoURdj9Fd8d2taLVGbKtCeZkPl4nktTp6NvQl4vGBeKgZkHNkZPU RITPyew6a3ISICFNeXlsDjbAnToJQcPoa187AcSlwOLCLdoES53B/qUEZdlZHDc= =uQnW -END PGP SIGNATURE- --- Comment #21 from Jeffrey A. Law 2011-01-26 15:23:15 UTC --- -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/25/11 16:42, dj at redhat dot com wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46878 > > DJ Delorie changed: > >What|Removed |Added > > Attachment #23074|0 |1 > is obsolete|| > > --- Comment #16 from DJ Delorie 2011-01-25 23:41:53 > UTC --- > Created attachment 23126 > --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23126 > alternate patch 3 > > Another patch attempt. In this case, we add a check for the implied > dependency > created by a cc0 setter/user pair to insn_a_feeds_b() so that try_combine() > knows that the cc0 setter is needed if the user is needed. I think you're on the right track here. I want to look at it a bit more, but this might be "it". FWIW, this code was a relatively recent addition to combine to support four insn combinations and just happens to be the code I was concerned might not be cc0-safe. jeff -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNQDxTAAoJEBRtltQi2kC7DqEH/jTegxTzt00RTBmi9pfN77TY 4XdhGv8KZsiFsiEp+IsBdQWhY7xJ12nHwjrBGqz72hDDSoYMflrceIhYqhvPqs3E BzIGmsccr5s+LD/qBQi8bqENOxlADytFia8QpRn22s17v1VhLnk321pFHvS2552G RDASg+ZPnYwrQL9dSKNQ4DKN/W3sTSGe3wLjpSYlhUp4jZ3MjLCMhkLAWaRZ8tWi Q+SfJz5a9bX8sgGCG1Utio0kEhqLYzkgxvgNJoi04059WWuB6uwlsWGcjbd23UTA hjnPRFxpetJp4En7NCOW2eo+2AC97NM909aXwAnvJWUBezDSYZu8fhSbE1rQrjA= =lw6z -END PGP SIGNATURE- --- Comment #22 from Jeffrey A. Law 2011-01-26 16:40:32 UTC --- Patch attempt #3 is OK. Please keep an eye out for complains about cc0 targets not creating loop (dbra) insns. That's my only worry. I don't think it's going to be a problem, but I can't completely rule it out. Thanks for your patience, Jeff
[Bug c++/47475] [C++0x] Static member function template of class variadic template can't be called from the inside
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47475 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #1 from Jonathan Wakely 2011-01-26 16:41:26 UTC --- The diagnostic isn't very good, but the code is invalid, it should be: test::template f();
[Bug rtl-optimization/47477] New: [4.6 regression] Sub-optimal mov at end of method
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47477
Summary: [4.6 regression] Sub-optimal mov at end of method
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: tony.popple...@gmail.com
Host: Linux x86-64
Whilst investigating PR35926, I noticed a slight inefficiency in code generated
by 4.6.0 (20110115) versus that of 4.5.1.
Duplicating the C code here from that PR for easy reference:
typedef struct toto_s *toto_t;
toto_t add (toto_t a, toto_t b) {
int64_t tmp = (int64_t)(intptr_t)a + ((int64_t)(intptr_t)b&~1L);
return (toto_t)(intptr_t) tmp;
}
The ASM generated by 4.6.0 with flags -O3 is:
.file "PR35926.c"
.text
.p2align 4,,15
.globl add
.type add, @function
add:
.LFB0:
.cfi_startproc
pushl %ebx
.cfi_def_cfa_offset 8
.cfi_offset 3, -8
movl12(%esp), %eax
movl8(%esp), %ecx
popl%ebx
.cfi_def_cfa_offset 4
.cfi_restore 3
andl$-2, %eax
addl%eax, %ecx < order of regs inverted
movl%ecx, %eax < resulting in unnecessary movl
ret
.cfi_endproc
.LFE0:
.size add, .-add
.ident "GCC: (GNU) 4.6.0 20110115 (experimental)"
.section.note.GNU-stack,"",@progbits
In 4.5.1, the last bit is one instruction shorter, with just:
addl%ecx, %eax
ret
A bug search revealed a similar sounding PR44249, however that is a regression
in 4.5 too apparently, yet this only affects 4.6.
[Bug c++/47476] [4.6 Regression] [C++0x] ICE in potential_constant_expression_1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47476 --- Comment #2 from Jakub Jelinek 2011-01-26 16:43:21 UTC --- Created attachment 23134 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23134 gcc46-pr47476.patch Untested fix.
[Bug rtl-optimization/47459] [4.6 regression] ICE in maybe_add_or_update_dep_1, at sched-deps.c:854
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47459 --- Comment #3 from Jeffrey A. Law 2011-01-26 16:43:43 UTC --- Joel, can you verify the fix for 46878 fixes his problem on the m68k. I'm pretty sure it will, but an independent verification would be good. Thanks, Jeff
[Bug c++/47475] [C++0x] Static member function template of class variadic template can't be called from the inside
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47475
--- Comment #2 from Jonathan Wakely 2011-01-26
16:47:53 UTC ---
Note that this is not related to variadic templates, this gives the same error
using no C++0x features:
template
struct test;
template<>
struct test
{
template
static void f()
{
}
};
template
struct test
{
template
static void f()
{
test::f(); //compiler error here
}
};
[Bug c++/47475] [C++0x] Static member function template of class variadic template can't be called from the inside
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47475 --- Comment #3 from flo.goujeon at orange dot fr 2011-01-26 16:54:18 UTC --- Oh, so that is the purpose of the 'template' keyword in nested-name-specifier. That's tricky. Thank you Jonathan, and sorry about this invalid report.
[Bug fortran/47474] Wrong code with allocatable scalar, allocatable components as function result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47474 --- Comment #2 from Tobias Burnus 2011-01-26 16:58:28 UTC --- Submitted patch: http://gcc.gnu.org/ml/fortran/2011-01/msg00235.html
[Bug rtl-optimization/46856] [4.6 regression] internal compiler error in final_scan_insn breaks m68k-linux bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46856 Jeffrey A. Law changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.01.26 17:16:52 CC||law at redhat dot com Component|bootstrap |rtl-optimization AssignedTo|unassigned at gcc dot |law at redhat dot com |gnu.org | Ever Confirmed|0 |1 --- Comment #7 from Jeffrey A. Law 2011-01-26 17:16:52 UTC --- More correctly, you can never move any insn between an explicit cc0 setter and cc0 user on a cc0 target. Regardless, I think you've nailed this one down. The comment needs some minor work. Rather than referring to a PR, we strongly prefer to describe why the code works the way it does in the code itself. We do this so that someone reading this code later can quickly understand its relevance without having to fire up a browser to read the bug database. Something as simple as "do not separate a cc0 setter and cc0 user" is sufficient. You should also submit the testcase for the regression suite. Just name it pr46856.c and put it in gcc/testsuite/gcc.c-torture/compile I don't see a login for you on gcc.gnu.org, so I'm going to assume you don't have commit privs. I'll go ahead and make the cleanups mentioned above and submit the patch. You can review the submission so that you know proper form if you choose to submit patches again in the future.
[Bug fortran/47472] Rules printed by -M option contains duplicate slash when -J option is used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47472 --- Comment #2 from Tobias Burnus 2011-01-26 17:17:04 UTC --- Draft patch completely untested (not even compiled): --- a/gcc/fortran/options.c +++ b/gcc/fortran/options.c @@ -463,9 +463,10 @@ gfc_handle_module_path_options (const char *arg) gfc_option.module_dir = (char *) gfc_getmem (strlen (arg) + 2); strcpy (gfc_option.module_dir, arg); - strcat (gfc_option.module_dir, "/"); gfc_add_include_path (gfc_option.module_dir, true, false); + + strcat (gfc_option.module_dir, "/"); }
[Bug c++/47478] New: internal compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47478 Summary: internal compiler error Product: gcc Version: 4.4.5 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: aleaver...@gmail.com This file compiles just fine with earlier versions of G++. The compiler error appears at the end of a function which is the last function in the file. $ g++ -v Using built-in specs. Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.4.4-14ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.4 --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 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --disable-werror --with-arch-32=i686 --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.5 (Ubuntu/Linaro 4.4.4-14ubuntu5) ... Command line: $ g++ -save-temps -o build/src/release/linux/2.6/64/x86/gcc/protocols/loophash/LoopHashMap.os -c -std=c++98 -pipe -ffor-scope -W -Wall -pedantic -Wno-long-long -O3 -ffast-math -funroll-loops -finline-functions -finline-limit=2 -s -Wno-unused-variable -fPIC -DNDEBUG -Isrc -Iexternal/include -Isrc/platform/linux/64/gcc -Isrc/platform/linux/64 -Isrc/platform/linux -Iexternal/boost_1_38_0 -I/usr/local/include -I/usr/include src/protocols/loophash/LoopHashMap.cc g++: warning: -pipe ignored because -save-temps specified In file included from src/protocols/loophash/LoopHashMap.cc:18: src/protocols/loophash/LoopHashMap.hh:120: warning: type qualifiers ignored on function return type src/protocols/loophash/LoopHashMap.cc:360: warning: type qualifiers ignored on function return type In file included from external/boost_1_38_0/boost/unordered_map.hpp:17, from src/protocols/loophash/LoopHashMap.hh:22, from src/protocols/loophash/LoopHashMap.cc:18: external/boost_1_38_0/boost/unordered/detail/hash_table_impl.hpp: In member function ‘typename boost::unordered_detail::hash_types_equivalent_keys, Key, Hash, Pred, Alloc>::iterator boost::unordered_multimap::insert(const std::pair&) [with Key = long unsigned int, T = long unsigned int, Hash = protocols::match::bin_index_hasher, Pred = std::equal_to, Alloc = std::allocator >]’: external/boost_1_38_0/boost/unordered/detail/hash_table_impl.hpp:101: warning: ‘’ may be used uninitialized in this function external/boost_1_38_0/boost/unordered/detail/hash_table_impl.hpp:210: note: ‘’ was declared here src/protocols/loophash/LoopHashMap.cc: In member function ‘void protocols::loophash::LoopHashMap::read_db(std::string, std::pair, std::map, std::allocator > >&)’: src/protocols/loophash/LoopHashMap.cc:436: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions.
[Bug testsuite/47479] New: make -j 12 RUNTESTFLAGS="--target_board 'unix{-m32,}'" isn't parallelized
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47479
Summary: make -j 12 RUNTESTFLAGS="--target_board 'unix{-m32,}'"
isn't parallelized
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com
CC: ja...@redhat.com
On Linux/x86-64 with 12 cores,
make -j 12 check RUNTESTFLAGS="--target_board 'unix{-m32,}'"
takes 1 hour and 44 minutes while
make -j 12 check
only takes 20 minutes. I got
[hjl@gnu-34 bld]$ ls gcc/testsuite
g++ gcc gfortran objc
[hjl@gnu-34 bld]$
vs
[hjl@gnu-34 bld]$ ls gcc/testsuite
g++ g++2 gcc1 gcc3 gcc5 gfortran gfortran2 objc
g++1 gcc gcc2 gcc4 gcc6 gfortran1 gfortran3 objc1
[hjl@gnu-34 bld]$
[Bug c++/47478] internal compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47478 --- Comment #1 from Andrew Leaver-Fay 2011-01-26 17:30:58 UTC --- Created attachment 23135 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23135 -save-temps file (.ii) that produces this crash (too big to upload without bzipping it -- sorry!)
[Bug testsuite/47479] make -j 12 RUNTESTFLAGS="--target_board 'unix{-m32,}'" isn't parallelized
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47479
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1 from Jakub Jelinek 2011-01-26
17:38:48 UTC ---
Just use RUNTESTFLAGS='--target_board=unix\{-m32,\}'
which is parallelized.
[Bug rtl-optimization/42502] [4.4/4.5 Regression] Poor register allocation in very simple code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42502 Eric Botcazou changed: What|Removed |Added CC||ebotcazou at gcc dot ||gnu.org Summary|[4.4/4.5/4.6 Regression]|[4.4/4.5 Regression] Poor |Bad register allocation in |register allocation in very |a very simple code |simple code Known to fail|| --- Comment #8 from Eric Botcazou 2011-01-26 17:49:06 UTC --- Essentially fixed on the mainline.
[Bug target/46997] new ia64 vector instructions are broken on HP-UX (big-endian)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46997 --- Comment #2 from Steve Ellcey 2011-01-26 17:50:05 UTC --- Author: sje Date: Wed Jan 26 17:49:56 2011 New Revision: 169296 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169296 Log: 2011-01-26 Steve Ellcey PR target/46997 * config/ia64/vect.md (mulv2si3): Enable and fix for TARGET_BIG_ENDIAN. (*mux2): Ditto. (vec_extract_evenodd_help): Ditto. (vec_extract_evenv4hi): Ditto. (vec_extract_oddv4hi): Ditto. (vec_interleave_lowv2si): Ditto. (vec_interleave_highv2si): Ditto. (vec_extract_evenv2si): Ditto. (vec_extract_oddv2si: Ditto. (vec_pack_trunc_v2si): Ditto. Modified: trunk/gcc/ChangeLog trunk/gcc/config/ia64/vect.md
[Bug testsuite/47479] make -j 12 RUNTESTFLAGS="--target_board 'unix{-m32,}'" isn't parallelized
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47479
--- Comment #2 from H.J. Lu 2011-01-26 17:51:36
UTC ---
(In reply to comment #1)
> Just use RUNTESTFLAGS='--target_board=unix\{-m32,\}'
> which is parallelized.
Is there a way to paralelize --target_board 'unix{-m32,}'?
[Bug lto/43467] LTO error "bytecode stream: trying to read 0 bytes after the end of the input buffer"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43467 Dmitry Gorbachev changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Comment #7 from Dmitry Gorbachev 2011-01-26 17:55:57 UTC --- .
[Bug rtl-optimization/47270] [4.4/4.5/4.6 Regression] GCC produces unnecessary code on -O2 and -O3 levels
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47270 Dmitry Gorbachev changed: What|Removed |Added Keywords||missed-optimization Summary|[4.4/4.5/4.6 Regression]|[4.4/4.5/4.6 Regression] |GCC produces|GCC produces unnecessary |unnecessary/wrong code on |code on -O2 and -O3 levels |-O2 and -O3 levels | --- Comment #2 from Dmitry Gorbachev 2011-01-26 18:03:33 UTC --- Ah, yes; changed the summary.
[Bug driver/47480] New: GCC driver names a resolution file after the last argument to the linker
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47480
Summary: GCC driver names a resolution file after the last
argument to the linker
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: trivial
Priority: P3
Component: driver
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: d.g.gorbac...@gmail.com
$ echo 'int main(void){}' > main.c
$ gcc -flto main.c -Wl,-s -save-temps
[...]
$ echo *.res
main.res
$ gcc -flto -c main.c
$ gcc -flto main.o -Wl,-s -save-temps
[...]
$ echo *.res
-s.res main.res
It looks ugly...
[Bug target/44031] [4.4/4.5 Regression] ice in subst_reloads, at reload.c:6327
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44031 Eric Botcazou changed: What|Removed |Added CC||ebotcazou at gcc dot ||gnu.org Known to work||4.6.0 Target Milestone|4.6.0 |4.4.6 Summary|[4.4/4.5/4.6 Regression]|[4.4/4.5 Regression] ice in |ice in subst_reloads, at|subst_reloads, at |reload.c:6327 |reload.c:6327 Known to fail||4.5.3 --- Comment #7 from Eric Botcazou 2011-01-26 18:13:17 UTC --- Works on the mainline, still fails on the 4.5 branch.
[Bug tree-optimization/47382] [4.6 Regression] g++.dg/ipa/devirt-d-1.C FAILs with -finline-functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47382 Martin Jambor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #4 from Martin Jambor 2011-01-26 18:21:06 UTC --- Fixed. I have filed PR 47462 for the xfailed testcase.
[Bug c++/47478] internal compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47478 --- Comment #2 from Andrew Leaver-Fay 2011-01-26 18:21:36 UTC --- I'd love a suggestion on how the code could be changed so that I no longer get this segfault.
[Bug middle-end/47466] c++ __builtin_expect() regression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47466 --- Comment #1 from Guillaume Morin 2011-01-26 18:26:34 UTC --- A recent 4.6 snapshot shows the same issue .file"foo.cpp" .text .p2align 4,,15 .globltest_expect(EnumStruct const&) .typetest_expect(EnumStruct const&), @function test_expect(EnumStruct const&): .LFB4: .cfi_startproc subq$8, %rsp .cfi_def_cfa_offset 16 movsbl(%rdi), %edx xorl%eax, %eax testl%edx, %edx je.L2 cmpl$1, %edx je.L2 callunlikelyCall() movl$1, %eax .L2: addq$8, %rsp .cfi_def_cfa_offset 8 ret .cfi_endproc .LFE4: .sizetest_expect(EnumStruct const&), .-test_expect(EnumStruct const&) .p2align 4,,15 .globltest_expect2(EnumStruct const&) .typetest_expect2(EnumStruct const&), @function test_expect2(EnumStruct const&): .LFB5: .cfi_startproc subq$8, %rsp .cfi_def_cfa_offset 16 movsbl(%rdi), %edx xorl%eax, %eax testl%edx, %edx jne.L10 .L7: addq$8, %rsp .cfi_remember_state .cfi_def_cfa_offset 8 ret .L10: .cfi_restore_state subl$1, %edx je.L7 .p2align 4,,5 callunlikelyCall() movl$1, %eax jmp.L7 .cfi_endproc .LFE5: .sizetest_expect2(EnumStruct const&), .-test_expect2(EnumStruct const&) .ident"GCC: (Debian 20110116-1) 4.6.0 20110116 (experimental) [trunk revision 168860]" .section.note.GNU-stack,"",@progbits
[Bug tree-optimization/47228] [4.6 Regression] wrong code with loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47228 Martin Jambor changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |jamborm at gcc dot gnu.org |gnu.org | --- Comment #5 from Martin Jambor 2011-01-26 18:28:17 UTC --- OK, let me have a look at it then...
[Bug fortran/47455] [4.6 Regression][OOP] internal compiler error: in fold_convert_loc, at fold-const.c:2028
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47455 --- Comment #5 from Tobias Burnus 2011-01-26 18:47:00 UTC --- Created attachment 23136 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23136 Test case (hopefully correct) Updated test case, hopefully correct. Fails with gfortran due to this PR - and with ifort 11.1 and crayftn due to other compiler bugs; thus, I could not properly test it. The result with the patch is kind of OK for the pointer version (find_x): this%x = this%find_x(that, .false.) is translated into: *this->_data->x = *this->_vptr->find_x ((struct __class_class_t_T *) this, &that, &C.1605); so far so good. But for a normal assignment, allocatable components require an allocate + deep copy with memcpy. For the allocatable, there is an additional issue: this%y = this%find_y() is translated into this->_data->y = *this->_vptr->find_y ((struct __class_class_t_T *) this); At a glance that looks OK. However, it immediately segfaults. One thing which and fails immediately (segfault) - though, I do not see why it segfaults.
[Bug testsuite/47479] make -j 12 RUNTESTFLAGS="--target_board 'unix{-m32,}'" isn't parallelized
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47479
--- Comment #3 from H.J. Lu 2011-01-26 19:11:31
UTC ---
I tried RUNTESTFLAGS="--target_board 'unix\{-m32,\}'". It doesn't
look like parallelized:
[hjl@gnu-32 gcc]$ ls build-x86_64-linux/gcc/testsuite
g++ gcc gfortran objc
[hjl@gnu-32 gcc]$
[Bug c++/47478] internal compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47478 Jonathan Wakely changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2011.01.26 19:13:11 Ever Confirmed|0 |1 --- Comment #3 from Jonathan Wakely 2011-01-26 19:13:11 UTC --- confirmed for 4.4.3 I get an ICE with g++ LoopHashMap.ii -O2 -funroll-loops -finline-functions -finline-limit=488 but not with g++ LoopHashMap.ii -O2 -funroll-loops -finline-functions -finline-limit=487 (the only difference is the inline-limit) (In reply to comment #2) > I'd love a suggestion on how the code could be changed so that I no longer get > this segfault. use a lower value for -finline-limit
[Bug debug/45454] [4.6 Regression] ICE: in verify_target_availability, at sel-sched.c:1614
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45454 Alexandre Oliva changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #8 from Alexandre Oliva 2011-01-26 19:58:20 UTC --- Oops, actually marked as fixed this time.
[Bug target/42894] [4.5/4.6 Regression] Invalid rtl sharing in Thumb1.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42894 --- Comment #19 from Jakub Jelinek 2011-01-26 20:04:55 UTC --- Fixed up patch posted: http://gcc.gnu.org/ml/gcc-patches/2011-01/msg01916.html (one } was missing in the testcase).
[Bug c/47473] [4.5/4.6 Regression] Incorrect computation with complex numbers when using -std=c99
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47473 --- Comment #6 from Jakub Jelinek 2011-01-26 20:07:02 UTC --- Author: jakub Date: Wed Jan 26 20:06:57 2011 New Revision: 169299 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169299 Log: PR c/47473 * c-lex.c (interpret_float): If CPP_N_IMAGINARY, ensure EXCESS_PRECISION_EXPR is created with COMPLEX_TYPE instead of REAL_TYPE. * gcc.dg/torture/pr47473.c: New test. Added: trunk/gcc/testsuite/gcc.dg/torture/pr47473.c Modified: trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-lex.c trunk/gcc/testsuite/ChangeLog
[Bug c/47473] [4.5 Regression] Incorrect computation with complex numbers when using -std=c99
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47473 Jakub Jelinek changed: What|Removed |Added Known to work||4.6.0 Summary|[4.5/4.6 Regression]|[4.5 Regression] Incorrect |Incorrect computation with |computation with complex |complex numbers when using |numbers when using -std=c99 |-std=c99| Known to fail|4.6.0 | --- Comment #7 from Jakub Jelinek 2011-01-26 20:08:40 UTC --- Fixed on the trunk so far.
[Bug tree-optimization/47228] [4.6 Regression] wrong code with loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47228 --- Comment #6 from Martin Jambor 2011-01-26 20:28:37 UTC --- Created attachment 23137 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23137 untested patch
[Bug middle-end/47481] New: i386-rtems* Ada ICE at reload1.c:2105
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47481
Summary: i386-rtems* Ada ICE at reload1.c:2105
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: j...@gcc.gnu.org
This is definitely a regression since 4.5.2.
/users/joel/test-gcc/b-gccada-i386/./gcc/xgcc
-B/users/joel/test-gcc/b-gccada-i386/./gcc/ -nostdinc
-B/users/joel/test-gcc/b-gccada-i386/i386-rtems4.11/newlib/ -isystem
/users/joel/test-gcc/b-gccada-i386/i386-rtems4.11/newlib/targ-include -isystem
/users/joel/test-gcc/gcc-svn/newlib/libc/include
-B/users/joel/test-gcc/install-svn/i386-rtems4.11/bin/
-B/users/joel/test-gcc/install-svn/i386-rtems4.11/lib/ -isystem
/users/joel/test-gcc/install-svn/i386-rtems4.11/include -isystem
/users/joel/test-gcc/install-svn/i386-rtems4.11/sys-include-c -g -O2
-msoft-float -W -Wall -gnatpg -msoft-float a-tiunio.ads -o a-tiunio.o
make[6]: *** [a-nllefu.o] Error 1
make[6]: *** Waiting for unfinished jobs
a-ngelfu.adb: In function
'Ada.Numerics.Long_Long_Complex_Elementary_Functions.Elementary_Functions.Cos.2xnn':
a-ngelfu.adb:533:8: error: unable to find a register to spill in class 'CREG'
a-ngelfu.adb:533:8: error: this is the insn:
(insn 22 18 23 2 (parallel [
(set (reg:SI 74)
(const_int 0 [0]))
(set (reg:SI 6 bp [72])
(plus:SI (ashift:SI (reg:SI 74)
(const_int 2 [0x2]))
(reg:SI 6 bp [72])))
(set (reg:SI 3 bx [73])
(plus:SI (ashift:SI (reg:SI 74)
(const_int 2 [0x2]))
(reg:SI 3 bx [73])))
(set (mem:BLK (reg:SI 6 bp [72]) [0 S12 A8])
(mem/c:BLK (reg:SI 3 bx [73]) [0 S12 A128]))
(use (reg:SI 74))
]) a-ngelfu.adb:532 677 {*rep_movsi}
(expr_list:REG_UNUSED (reg:SI 74)
(expr_list:REG_UNUSED (reg:SI 3 bx [73])
(expr_list:REG_UNUSED (reg:SI 6 bp [72])
(nil)
+===GNAT BUG DETECTED==+
| 4.6.0 20110126 (experimental) [trunk revision 169296] (i386-pc-rtems4.11) GCC
error:|
| in spill_failure, at reload1.c:2105 |
| Error detected around a-ngelfu.adb:533:8 |
| Please submit a bug report; see http://gcc.gnu.org/bugs.html.|
| Use a subject line meaningful to you and us to track the bug.|
| Include the entire contents of this bug box in the report. |
| Include the exact gcc or gnatmake command that you entered. |
| Also include sources listed below in gnatchop format |
| (concatenated together with no headers between files). |
+==+
[Bug other/47467] [4.6 Regression] hwint.h:239:3: error: implicit declaration of function 'abs'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47467 Joel Sherrill changed: What|Removed |Added Status|RESOLVED|REOPENED CC||joel at gcc dot gnu.org Resolution|FIXED | --- Comment #5 from Joel Sherrill 2011-01-26 20:45:17 UTC --- (In reply to comment #4) > Fixed. Unfortunately, this fix broke cross builds. :( /users/joel/test-gcc/b-gccada-i386/./gcc/xgcc -B/users/joel/test-gcc/b-gccada-i386/./gcc/ -nostdinc -B/users/joel/test-gcc/b-gccada-i386/i386-rtems4.11/newlib/ -isystem /users/joel/test-gcc/b-gccada-i386/i386-rtems4.11/newlib/targ-include -isystem /users/joel/test-gcc/gcc-svn/newlib/libc/include -B/users/joel/test-gcc/install-svn/i386-rtems4.11/bin/ -B/users/joel/test-gcc/install-svn/i386-rtems4.11/lib/ -isystem /users/joel/test-gcc/install-svn/i386-rtems4.11/include -isystem /users/joel/test-gcc/install-svn/i386-rtems4.11/sys-include-c -DCROSS_DIRECTORY_STRUCTURE -DIN_GCC `echo -g -O2 -fexceptions -DIN_RTS -DHAVE_GETIPINFO -mtune=i486 |sed -e 's/-pedantic//g' -e 's/-Wtraditional//g'` \ -I. -I.. -I../.. -I/users/joel/test-gcc/gcc-svn/gcc/ada -I/users/joel/test-gcc/gcc-svn/gcc/../include -I/users/joel/test-gcc/gcc-svn/gcc \ targext.c -o targext.o In file included from targext.c:37:0: /users/joel/test-gcc/gcc-svn/gcc/system.h:369:23: fatal error: sys/mman.h: No such file or directory Apparently targext.c is compiled both cross and native. RTEMS does not have sys/mman.h. config.h indicates that it is present. I dropped targext.c from the target library list and got far enough to get an ICE on something else. I am building another target now. Is targext.c really supposed to be part of LIBGNAT_SRCS for the target or is this just a host side compiler helper?
[Bug rtl-optimization/44469] [4.5/4.6 Regression] internal compiler error: in fixup_reorder_chain, at cfglayout.c:797
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44469 --- Comment #8 from Eric Botcazou 2011-01-26 21:12:01 UTC --- Author: ebotcazou Date: Wed Jan 26 21:11:57 2011 New Revision: 169304 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169304 Log: PR rtl-optimization/44469 * cfgcleanup.c (try_optimize_cfg): Iterate in CFG layout mode too after removing trivially dead basic blocks. Added: trunk/gcc/testsuite/gcc.c-torture/compile/20110126-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/cfgcleanup.c trunk/gcc/testsuite/ChangeLog
Vai alga 4090 USD menesi tevi interesee?
Hello! Tev telefona numurs izmainiijies? Man paradijas reals risinajums Tavam problemam, tapec gribeju piezvanit, bet telefons izslegts. Skaidrs, lai vai tur kas, man viss super, jo es dabuju fantastiski labu darbu, kas ir vienkarshaks par vienkarshu un 3825 USD menesi bez problemam man atlec. Vai nu piezvani man, vai ieej http://www.kastens.lv tur ir gan video, gan apraksti, kas un kaa jaadara!
