[Bug lto/49700] New: LTO compile time hog
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49700 Summary: LTO compile time hog Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassig...@gcc.gnu.org ReportedBy: joost.vandevond...@pci.uzh.ch Using LTO a CP2K compile can take several hours and a lot of memory. I have been able to extract the following time report, but what is the best way to make a testcase ? -save-temps yielded the cp2k.sopt.ltrans29.ltrans.o file, but is anything more needed ? gfortran @/dev/shm/vondele/ccGyXn6S.args Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/data03/vondele/gnu/gcc_trunk/install/libexec/gcc/x86_64-unknown-linux-gnu/4.7.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc/configure --prefix=/data03/vondele/gnu/gcc_trunk/install --enable-languages=c,c++,fortran --disable-multilib --enable-plugins --enable-cloog-backend=isl --with-ppl=/data03/vondele/gnu/ppl-0.11/install --with-cloog=/data03/vondele/gnu/cloog-0.16.1/install/ --with-libelf=/data03/vondele/gnu/libelf-0.8.13/install --with-plugin-ld=ld.gold Thread model: posix gcc version 4.7.0 20110709 (experimental) [trunk revision 176072] (GCC) COLLECT_GCC_OPTIONS='-c' '-v' '-save-temps' '-ftime-report' '-u' 'se-linker-plugin' '-O3' '-march=native' '-funroll-loops' '-ffast-math' '-ffree-form' '-D' '__GFORTRAN' '-D' '__FFTSG' '-D' '__FFTW3' '-D' '__LIBINT' '-I' '/ext/software/64/gfortran-suite/include' '-D' '__COMPILE_ARCH="gfortran-test13"' '-D' '__COMPILE_DATE="Sun Jul 10 14:22:33 CEST 2011"' '-D' '__COMPILE_HOST="pcihopt3"' '-D' '__COMPILE_LASTCVS="/qs_scf.F/1.527/Sat Jul 9 07:18:08 2011//"' '-L/users/vondele/LAPACK/' '-L/ext/software/64/gfortran-suite/lib' '-shared-libgcc' '-dumpdir' '/data03/vondele/cp2k_gcc/cp2k/makefiles/../exe/gfortran-test13/' '-dumpbase' 'cp2k.sopt.ltrans29' '-fltrans' '-o' 'cp2k.sopt.ltrans29.ltrans.o' /data03/vondele/gnu/gcc_trunk/install/libexec/gcc/x86_64-unknown-linux-gnu/4.7.0/lto1 -march=amdfam10 -mcx16 -msahf -mno-movbe -mno-aes -mno-pclmul -mpopcnt -mabm -mno-lwp -mno-fma -mno-fma4 -mno-xop -mno-bmi -mno-tbm -mno-avx -mno-sse4.2 -mno-sse4.1 --param l1-cache-size=64 --param l1-cache-line-size=64 --param l2-cache-size=512 -mtune=amdfam10 -quiet -dumpdir /data03/vondele/cp2k_gcc/cp2k/makefiles/../exe/gfortran-test13/ -dumpbase cp2k.sopt.ltrans29 -auxbase-strip cp2k.sopt.ltrans29.ltrans.o -O3 -version -ftime-report -funroll-loops -ffast-math -ffree-form -fltrans @/dev/shm/vondele/ccuRF1W6 -o cp2k.sopt.ltrans29.s GNU GIMPLE (GCC) version 4.7.0 20110709 (experimental) [trunk revision 176072] (x86_64-unknown-linux-gnu) compiled by GNU C version 4.7.0 20110709 (experimental) [trunk revision 176072], GMP version 4.3.2, MPFR version 2.4.2, MPC version 0.8.2 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 GNU GIMPLE (GCC) version 4.7.0 20110709 (experimental) [trunk revision 176072] (x86_64-unknown-linux-gnu) compiled by GNU C version 4.7.0 20110709 (experimental) [trunk revision 176072], GMP version 4.3.2, MPFR version 2.4.2, MPC version 0.8.2 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Execution times (seconds) phase setup : 0.00 ( 0%) usr 0.00 ( 0%) sys 0.02 ( 0%) wall 1250 kB ( 0%) ggc phase parsing :5086.93 (100%) usr 9.45 (100%) sys5213.35 (100%) wall 1072513 kB (100%) ggc phase generate : 0.00 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 0 kB ( 0%) ggc garbage collection : 4.16 ( 0%) usr 0.02 ( 0%) sys 4.22 ( 0%) wall 0 kB ( 0%) ggc ipa lto gimple in : 0.13 ( 0%) usr 0.01 ( 0%) sys 0.16 ( 0%) wall 26100 kB ( 2%) ggc ipa lto decl in : 0.86 ( 0%) usr 0.01 ( 0%) sys 0.89 ( 0%) wall 7027 kB ( 1%) ggc ipa pure const : 0.03 ( 0%) usr 0.00 ( 0%) sys 0.03 ( 0%) wall 11 kB ( 0%) ggc cfg construction: 0.62 ( 0%) usr 0.00 ( 0%) sys 0.63 ( 0%) wall 3820 kB ( 0%) ggc cfg cleanup : 2.89 ( 0%) usr 0.00 ( 0%) sys 2.91 ( 0%) wall 4416 kB ( 0%) ggc CFG verifier: 49.95 ( 1%) usr 0.00 ( 0%) sys 50.28 ( 1%) wall 0 kB ( 0%) ggc trivially dead code : 0.88 ( 0%) usr 0.00 ( 0%) sys 0.90 ( 0%) wall 0 kB ( 0%) ggc df scan insns : 0.20 ( 0%) usr 0.00 ( 0%) sys 0.23 ( 0%) wall 20 kB ( 0%) ggc df multiple defs: 0.34 ( 0%) usr 0.00 ( 0%) sys 0.34 ( 0%) wall 0 kB ( 0%) ggc df reaching defs: 60.58 ( 1%) usr 1.10 (12%) sys 62.35 ( 1%) wall 0 kB ( 0%) ggc df live regs: 13.28 ( 0%) usr 0.04 ( 0%) sys 13.56 ( 0%) wall 0 kB ( 0%) ggc df live&initialized regs: 5.43 ( 0%) usr 0.00 ( 0%) sys 5.59 ( 0%) wall 0 kB ( 0%) ggc df use-def / def-use chains: 1.16 ( 0%) usr 0.01 ( 0%) sys 1.25 ( 0%) wall 0 kB ( 0%) ggc df
[Bug middle-end/49699] Aligned load on unaligned address
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49699 H.J. Lu changed: What|Removed |Added Component|target |middle-end --- Comment #1 from H.J. Lu 2011-07-11 03:13:16 UTC --- It looks like a middle-end bug.
[Bug target/44707] operand requires impossible reload
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44707 --- Comment #11 from Jack Howarth 2011-07-11 03:08:07 UTC --- Created attachment 24735 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24735 assembly for pr44707.c from powerpc-apple-darwin9
[Bug target/44707] operand requires impossible reload
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44707 --- Comment #10 from Jack Howarth 2011-07-11 03:07:34 UTC --- Created attachment 24734 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24734 preprocessed source for pr44707.c from powerpc-apple-darwin9
[Bug target/44707] operand requires impossible reload
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44707 Jack Howarth changed: What|Removed |Added CC||howarth at nitro dot ||med.uc.edu --- Comment #9 from Jack Howarth 2011-07-11 03:03:55 UTC --- On powerpc-apple-darwin9, this fails under gcc-4.6.1 as... Executing on host: /sw/src/fink.build/gcc46-4.6.1-1000/darwin_objdir/gcc/xgcc -B/sw/src/fink.build/gcc46-4.6.1-1000/darwin_objdir/gcc/ -O1 -w -c -m32 -o pr44707.o /sw/src/fink.build/gcc46-4.6.1-1000/gcc-4.6.1/gcc/testsuite/gcc.c-torture/compile/pr44707.c (timeout = 300) /var/tmp//ccZ2tK1u.s:15:non-relocatable subtraction expression, "_w" minus "L001$pb"^M /var/tmp//ccZ2tK1u.s:15:symbol: "_w" can't be undefined in a subtraction expression^M /var/tmp//ccZ2tK1u.s:14:non-relocatable subtraction expression, "_w" minus "L001$pb"^M /var/tmp//ccZ2tK1u.s:14:symbol: "_w" can't be undefined in a subtraction expression^M /var/tmp//ccZ2tK1u.s:13:non-relocatable subtraction expression, "_v" minus "L001$pb"^M /var/tmp//ccZ2tK1u.s:13:symbol: "_v" can't be undefined in a subtraction expression^M /var/tmp//ccZ2tK1u.s:12:non-relocatable subtraction expression, "_v" minus "L001$pb"^M /var/tmp//ccZ2tK1u.s:12:symbol: "_v" can't be undefined in a subtraction expression^M compiler exited with status 1 which may be an assembler issue remembering that darwin is using the rather old... Apple Inc version cctools-698.1~1, GNU assembler version 1.38
[Bug tree-optimization/49601] [4.7 Regression] ICE at ipa-inline-analysis.c:1188
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49601 Alan Modra changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.07.11 02:55:49 CC||amodra at gmail dot com Ever Confirmed|0 |1 --- Comment #2 from Alan Modra 2011-07-11 02:55:49 UTC --- Confirmed with powerpc64 20110706
[Bug target/49699] New: Aligned load on unaligned address
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49699
Summary: Aligned load on unaligned address
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com
CC: ubiz...@gmail.com
[hjl@gnu-6 tmp]$ cat a.c
#include
struct foo
{
__m128 x;
} __attribute__ ((aligned(8)));
extern struct foo x;
__m128
foo ()
{
return x.x;
}
[hjl@gnu-6 tmp]$ gcc -msse2 -O a.c -S
[hjl@gnu-6 tmp]$ cat a.s
.file"a.c"
.text
.globlfoo
.typefoo, @function
foo:
.LFB516:
.cfi_startproc
movapsx(%rip), %xmm0
ret
.cfi_endproc
.LFE516:
.sizefoo, .-foo
.ident"GCC: (GNU) 4.6.0 20110530 (Red Hat 4.6.0-9)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-6 tmp]$
[Bug target/48803] arm: Bad assembler produced by bit extract/shift
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48803 Michael Hope changed: What|Removed |Added CC||michael.hope at linaro dot ||org --- Comment #2 from Michael Hope 2011-07-11 00:19:52 UTC --- Part of the difference is that 4.5 inlines the other functions and 4.6 doesn't. Adding an __attribute__((always_inline)) to both gives the following: For 4.5, main is: main: movwr3, #22136 movtr3, 4660 and r3, r0, r3 cbnzr3, .L10 mvn r3, #15 lslsr2, r0, r3 ubfxr0, r0, #30, #10 and r3, r0, #768 lsrsr0, r2, #24 orr r0, r3, r0 bx lr .L10: ubfxr3, r0, #22, #2 lsrsr0, r0, #24 lslsr3, r3, #8 orr r0, r3, r0 bx lr For 4.6 it becomes: main: movwr3, #22136 movtr3, 4660 andsr3, r3, r0 cbz r3, .L13 ubfxr3, r0, #22, #2 lsrsr0, r0, #24 lslsr3, r3, #8 .L12: orrsr0, r0, r3 bx lr .L13: mov r0, r3 b .L12
[Bug target/39212] ice for AVR target: unable to find a register to spill in class 'POINTER_REGS'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39212 Georg-Johann Lay changed: What|Removed |Added Keywords||ice-on-valid-code CC||gjl at gcc dot gnu.org Known to work||4.5.2, 4.6.1 Known to fail|| --- Comment #5 from Georg-Johann Lay 2011-07-10 21:13:46 UTC --- Eric, can I close this for 4.6.2?
[Bug target/39633] [avr] loop bug: missing 8-bit comparison (*cmpqi)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39633 Georg-Johann Lay changed: What|Removed |Added Target Milestone|--- |4.6.2
[Bug target/46779] wrong code generation for array access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46779 Georg-Johann Lay changed: What|Removed |Added Status|NEW |RESOLVED Known to work||4.6.2, 4.7.0 Resolution||FIXED Known to fail||4.6.1 --- Comment #14 from Georg-Johann Lay 2011-07-10 20:57:18 UTC --- Closed as FIXED for 4.6.2
[Bug other/49665] 'defined in discarded section' link failures on cpu2006 benchmarks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49665 --- Comment #6 from Markus Trippelsdorf 2011-07-10 19:08:14 UTC --- Another thing you might check is to revert the commit pointed out here: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49533#c5 and see if this makes any difference.
[Bug other/49665] 'defined in discarded section' link failures on cpu2006 benchmarks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49665 Pat Haugen changed: What|Removed |Added Component|c++ |other --- Comment #5 from Pat Haugen 2011-07-10 18:43:28 UTC --- The problems still exist in r176125, although looks like a couple from soplex went away but a couple new ones for omnetpp showed up. soplex: `soplex::SPxBasis::~SPxBasis()' referenced in section `.data.rel.ro._ZTVN6soplex8SPxBasisE[vtable for soplex::SPxBasis]' of spxbasis.o: defined in discarded section `.group' of spxbasis.o `soplex::SPxLP::~SPxLP()' referenced in section `.data.rel.ro._ZTVN6soplex5SPxLPE[vtable for soplex::SPxLP]' of spxlp.o: defined in discarded section `.grou p' of spxlp.o omnetpp: `cStdDev::~cStdDev()' referenced in section `.data.rel.ro._ZTV7cStdDev[vtable for cStdDev]' of libs/sim/cstat.o: defined in discarded section `.group' of libs/sim/cstat.o `cStatistic::~cStatistic()' referenced in section `.data.rel.ro._ZTV10cStatistic[vtable for cStatistic]' of libs/sim/std/netpack.o: defined in discarded section `.group' of libs/sim/std/netpack.o `cEqdHistogramBase::~cEqdHistogramBase()' referenced in section `.data.rel.ro._ZTV17cEqdHistogramBase[vtable for cEqdHistogramBase]' of libs/sim/std/netpack.o: defined in discarded section `.group' of libs/sim/std/netpack.o
[Bug fortran/49690] [4.6/4.7 regression] ICE in gfc_typenode_for_spec, at fortran/trans-types.c:1019
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49690 Tobias Burnus changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #8 from Tobias Burnus 2011-07-10 18:30:00 UTC --- FIXED on the trunk and on the 4.6 branch (for 4.6.2). Thanks, Matthias, for the GCC bugreport - and thanks to Alastair for the original bugreport (at bugs.debian.org).
[Bug fortran/49690] [4.6/4.7 regression] ICE in gfc_typenode_for_spec, at fortran/trans-types.c:1019
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49690 --- Comment #7 from Tobias Burnus 2011-07-10 18:27:17 UTC --- Author: burnus Date: Sun Jul 10 18:27:12 2011 New Revision: 176126 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=176126 Log: 2011-07-10 Tobias Burnus PR fortran/49690 * intrinsic.c (add_functions): Use BT_VOID for 2nd argument of * SIGNAL. 2011-07-10 Tobias Burnus PR fortran/49690 * gfortran.dg/intrinsic_signal.f90: New. Added: branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/intrinsic_signal.f90 Modified: branches/gcc-4_6-branch/gcc/fortran/ChangeLog branches/gcc-4_6-branch/gcc/fortran/intrinsic.c branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
[Bug target/44707] operand requires impossible reload
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44707 David Fang changed: What|Removed |Added CC||fang at csl dot cornell.edu --- Comment #8 from David Fang 2011-07-10 17:34:25 UTC --- Hi, I see this test failing on powerpc-darwin8 (I know, not a critical platform). http://gcc.gnu.org/ml/gcc-testresults/2011-07/msg01092.html What information can I provide from my test runs?
[Bug fortran/49698] Unmanageable compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49698 --- Comment #1 from Fran Martinez Fadrique 2011-07-10 17:30:21 UTC --- Created attachment 24733 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24733 Base type used in the module generating the error
[Bug fortran/49698] New: Unmanageable compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49698 Summary: Unmanageable compiler error Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: fmarti...@gmv.com Created attachment 24732 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24732 The file where the error is generated at line 1495 The submitted code generates the following error that I cannot debug with the provided information. t_element_pure_vector_ftl.f90: In function ‘ftl_vector_init’: t_element_pure_vector_ftl.f90:1495:0: error: type mismatch in binary expression integer(kind=8) integer(kind=8) integer(kind=4) num.25 = num.25 + 1; t_element_pure_vector_ftl.f90:1495: confused by earlier errors, bailing out The compiler options are -g -std=f2003 -fprofile-arcs -ftest-coverage -fbacktrace -fbounds-check -fno-range-check -fconvert=big-endian -Wall This code compiles and runs properly with intel 11, 12 and g95
[Bug lto/49697] New: read permission of LTO intermediate files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49697 Summary: read permission of LTO intermediate files Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassig...@gcc.gnu.org ReportedBy: joost.vandevond...@pci.uzh.ch not sure if this is a bug, but LTO generates intermediate files in $TMPDIR that are readable by all -rw-r--r-- cleUTZi.ltrans17.ltrans.o instead of the usual -rw--- for other gcc files that appear in $TMPDIR
[Bug fortran/49690] [4.6/4.7 regression] ICE in gfc_typenode_for_spec, at fortran/trans-types.c:1019
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49690 --- Comment #6 from Tobias Burnus 2011-07-10 14:28:51 UTC --- Author: burnus Date: Sun Jul 10 14:28:48 2011 New Revision: 176121 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=176121 Log: 2011-07-10 Tobias Burnus PR fortran/49690 * intrinsic.c (add_functions): Use BT_VOID for 2nd argument of * SIGNAL. 2011-07-10 Tobias Burnus PR fortran/49690 * gfortran.dg/intrinsic_signal.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/intrinsic_signal.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/intrinsic.c trunk/gcc/testsuite/ChangeLog
[Bug c++/49691] ICE in cp_parser_late_return_type_opt, at cp/parser.c:15562
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49691 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #4 from Jason Merrill 2011-07-10 14:25:31 UTC --- Fixed.
[Bug c++/49691] ICE in cp_parser_late_return_type_opt, at cp/parser.c:15562
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49691 --- Comment #3 from Jason Merrill 2011-07-10 14:24:06 UTC --- Author: jason Date: Sun Jul 10 14:24:03 2011 New Revision: 176120 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=176120 Log: PR c++/49691 * parser.c (cp_parser_late_return_type_opt): Check quals parameter rather than current_class_type to determine whether to set 'this'. (cp_parser_direct_declarator): Pass -1 to quals if member_p is false. (cp_parser_init_declarator): Pass down member_p. Added: trunk/gcc/testsuite/g++.dg/cpp0x/regress/regress6.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/parse/crash45.C trunk/gcc/testsuite/g++.dg/template/crash38.C trunk/gcc/testsuite/g++.dg/template/crash64.C
[Bug tree-optimization/49695] conditional moves for stores
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49695
--- Comment #3 from revital.eres at linaro dot org 2011-07-10 13:41:07 UTC ---
> > the memory location we write to.
> hmmm... after reading Sebastian Pop's paper from the last summit ("Improving
> GCC’s auto-vectorization with if-conversion and loop
> flattening for AMD’s Bulldozer processors") it's seems that we need to grantee
> that point1->arr[i].val is writable when the condition is false which we can
> not prove in this case. So that's not a bug, I apologize for the noise.
Continuing reading the paper I see that under the 'If-conversion without
restrictions' section there is a technique that allows to apply if-conversion
in the above case by writing to artificial object that has been
created by the compiler when the condition is false. I assume this method is
not implemented in trunk yet.
[Bug tree-optimization/49695] conditional moves for stores
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49695
--- Comment #2 from revital.eres at linaro dot org 2011-07-10 12:50:31 UTC ---
(In reply to comment #0)
> for (i = 0; i < point1->len; i++)
> {
> if (point1->arr[i].val)
> {
> point1->arr[i].val ^= (unsigned long long) res;
> }
> }
> For the above loop if-conversion is not been done in the tree level (compiled
> with trunk -r176116). Seemingly this case is similar to the one in PR27313.
> When using -ftree-loop-if-convert-stores I get 'tree could trap...' message
> although I'm not sure why as there is a read in every iteration of the loop to
> the memory location we write to.
hmmm... after reading Sebastian Pop's paper from the last summit ("Improving
GCC’s auto-vectorization with if-conversion and loop
flattening for AMD’s Bulldozer processors") it's seems that we need to grantee
that point1->arr[i].val is writable when the condition is false which we can
not prove in this case. So that's not a bug, I apologize for the noise.
[Bug c++/49587] Code generation error with dynamic libraries.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49587 Jarryd Beck changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||DUPLICATE --- Comment #6 from Jarryd Beck 2011-07-10 12:20:26 UTC --- It is definitely a duplicate of bug 49538 which is fixed now, and my problem is fixed. So I am marking this as resolved. *** This bug has been marked as a duplicate of bug 49538 ***
[Bug c++/49538] [4.7 regression] Revision 175341 causes segfaults
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49538 --- Comment #10 from Jarryd Beck 2011-07-10 12:20:26 UTC --- *** Bug 49587 has been marked as a duplicate of this bug. ***
[Bug fortran/49562] [4.6/4.7 Regression] [OOP] assigning value to type-bound function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49562 janus at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #11 from janus at gcc dot gnu.org 2011-07-10 11:52:35 UTC --- Fixed on trunk and 4.6. Closing. Also: Thanks for reporting, Hans-Werner!
[Bug fortran/49562] [4.6/4.7 Regression] [OOP] assigning value to type-bound function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49562 --- Comment #10 from janus at gcc dot gnu.org 2011-07-10 11:50:09 UTC --- Author: janus Date: Sun Jul 10 11:50:04 2011 New Revision: 176117 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=176117 Log: 2011-07-10 Janus Weil PR fortran/49562 * expr.c (gfc_check_vardef_context): Handle type-bound procedures. 2011-07-10 Janus Weil PR fortran/49562 * gfortran.dg/typebound_proc_23.f90: New. Added: branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/typebound_proc_23.f90 Modified: branches/gcc-4_6-branch/gcc/fortran/ChangeLog branches/gcc-4_6-branch/gcc/fortran/expr.c branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
[Bug target/49696] New: ICE on mips when compiling drizzle
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49696 Summary: ICE on mips when compiling drizzle Product: gcc Version: 4.6.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: aurel...@aurel32.net Host: mips-unknown-linux-gnu Target: mips-unknown-linux-gnu Build: mips-unknown-linux-gnu Created attachment 24731 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24731 Testcase to reproduce the issue When building drizzle on mips, g++ crash with an internal compiler error. The problem is reproducible with versions 4.4, 4.5 and 4.6, but not with version 4.3 (I didn't test earlier versions). I have attached a reduced testcase. $ g++ -c ./testcase-min.ii ./testcase-min.ii: In member function 'drizzled::internal::gcc_traits::value_type drizzled::internal::gcc_traits::fetch(const volatile value_type*) const volatile [with T = bool, D = bool, drizzled::internal::gcc_traits::value_type = bool]': ./testcase-min.ii:12:5: error: unrecognizable insn: (insn 16 15 17 3 (parallel [ (set (reg:SI 205) (mem/v:SI (reg:SI 200) [-1 S4 A32])) (set (mem/v:SI (reg:SI 200) [-1 S4 A32]) (unspec_volatile:SI [ (reg:SI 203) (reg:SI 204) (plus:SI (reg:SI 205) (const_int 0 [0])) ] UNSPEC_SYNC_OLD_OP_12)) (clobber (scratch:SI)) ]) ./testcase-min.ii:11 -1 (nil)) ./testcase-min.ii:12:5: internal compiler error: in extract_insn, at recog.c:2109 Please submit a full bug report, with preprocessed source if appropriate.
[Bug target/39633] [avr] loop bug: missing 8-bit comparison (*cmpqi)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39633
--- Comment #11 from Georg-Johann Lay 2011-07-10
10:15:11 UTC ---
It's bug in avr.c:notice_update_cc() because for shift offset=7 cc0 is set as
if it contained meaningful state:
case CC_CLOBBER:
/* Insn doesn't leave CC in a usable state. */
CC_STATUS_INIT;
/* Correct CC for the ashrqi3 with the shift count as CONST_INT != 6 */
set = single_set (insn);
if (set)
{
rtx src = SET_SRC (set);
if (GET_CODE (src) == ASHIFTRT
&& GET_MODE (src) == QImode)
{
rtx x = XEXP (src, 1);
if (GET_CODE (x) == CONST_INT
&& INTVAL (x) > 0
&& INTVAL (x) != 6)
{
cc_status.value1 = SET_DEST (set);
cc_status.flags |= CC_OVERFLOW_UNUSABLE;
}
}
}
break;
[Bug tree-optimization/49695] conditional moves for stores
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49695 --- Comment #1 from revital.eres at linaro dot org 2011-07-10 10:05:07 UTC --- Created attachment 24730 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24730 Testcase which contains the loop
[Bug tree-optimization/49695] New: conditional moves for stores
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49695
Summary: conditional moves for stores
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: revital.e...@linaro.org
for (i = 0; i < point1->len; i++)
{
if (point1->arr[i].val)
{
point1->arr[i].val ^= (unsigned long long) res;
}
}
For the above loop if-conversion is not been done in the tree level (compiled
with trunk -r176116). Seemingly this case is similar to the one in PR27313.
When using -ftree-loop-if-convert-stores I get 'tree could trap...' message
although I'm not sure why as there is a read in every iteration of the loop to
the memory location we write to.
Similar case appears in SPEC2006/libquantum.
Here's a snippet from .ifcvt file:
:
pretmp.6_33 = point1_3(D)->arr;
:
# i_27 = PHI
i.0_6 = (unsigned int) i_27;
D.3689_7 = i.0_6 * 8;
D.3690_8 = pretmp.6_33 + D.3689_7;
D.3691_9 = D.3690_8->val;
if (D.3691_9 != 0)
goto ;
else
goto ;
:
D.3694_20 = (long long unsigned int) res_19(D);
D.3695_21 = D.3694_20 ^ D.3691_9;
D.3690_8->val = D.3695_21;
:
i_22 = i_27 + 1;
if (i_22 < D.3696_29)
goto ;
else
goto ;
:
goto ;
[Bug libgomp/42616] OMP'ed loop inside pthread leads to crash.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42616 PcX changed: What|Removed |Added CC||xunxun1982 at gmail dot com --- Comment #12 from PcX 2011-07-10 10:03:48 UTC --- (In reply to comment #11) > FWIW, using mingw.org's gcc-4.5.2 release, the test passes: > > $ g++ -fopenmp omp_test.c -o omp_test -lpthread > $ ./omp_test.exe > OMP : All looks good > > Relevant installation data: > gcc-core-4.5.2-1-mingw32-bin > gcc-c++-4.5.2-1-mingw32-bin > libgcc-4.5.2-1-mingw32-dll-1 > libstdc++-4.5.2-1-mingw32-dll-6 > libgomp-4.5.2-1-mingw32-dll-1 > mingwrt-3.18-mingw32-dll > mingwrt-3.18-mingw32-dev > w32api-3.17-2-mingw32-dev > pthreads-w32-2.8.0-3-mingw32-dev > libpthread-2.8.0-3-mingw32-dll-2 > > I believe this is because TLS support was added to the mingw(32) runtime in > late Jan 2010, thanks to Kai's work: > http://thread.gmane.org/gmane.comp.gnu.mingw.devel/3550 > > (Although a full compiler suite, and mingw runtime, with TLS support was not > officially released until March 2010) I don't thinks so. Because mingw64 crt also contains TLS support written by Kai, but mingw64 crt also use the code to crash.
[Bug fortran/49562] [4.6/4.7 Regression] [OOP] assigning value to type-bound function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49562 --- Comment #9 from janus at gcc dot gnu.org 2011-07-10 09:31:31 UTC --- (In reply to comment #8) > Janus, what's the status of this PR? > I think only backporting is missing, is that correct? Right. I'm just about to apply the backport ...
[Bug testsuite/49694] FAIL: gnat.dg/specs/debug1.ads scan-assembler-times byte\t0x1\t# DW_AT_artificial 4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49694 Mikael Pettersson changed: What|Removed |Added CC||mikpe at it dot uu.se --- Comment #1 from Mikael Pettersson 2011-07-10 08:53:44 UTC --- debug1.ads failed in the same way on armv5tel-linux-gnueabi with 4.7-20110702.
[Bug target/39633] [avr] loop bug: missing 8-bit comparison (*cmpqi)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39633
--- Comment #10 from Georg-Johann Lay 2011-07-10
08:29:04 UTC ---
Created attachment 24729
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24729
Minimal test case
Here is a minimal testcase:
char c;
void func_1 (char a)
{
a = a >> 7;
if (a)
c = a;
}
Code with 4.6.1 -Os -dp -S -mmcu=atmega88:
func_1:
lsl r24 ; 6ashrqi3/5[length = 2]
sbc r24,r24
breq .L1 ; 8branch[length = 1]
sts c,r24 ; 10*movqi/3[length = 2]
.L1:
ret ; 20return[length = 1]
[Bug c++/44609] Invalid template code causes infinite loop of error messages
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44609 Jason Merrill changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #7 from Jason Merrill 2011-07-10 05:32:10 UTC --- This isn't actually an infinite loop; it's a sequence of recursive instantiations which hit an error in each instantiation of the same function. Eventually it will hit the maximum template instantiation depth and stop, but that takes a very long time with the default -ftemplate-depth. It probably makes sense not to continue to instantiate a template after one instantiation has produced an error.
