[Bug libobjc/26794] Checking for gthread causes configure script to fail
--- Comment #19 from issac dot trotts at gmail dot com 2006-03-22 08:25 --- Subject: Re: Checking for gthread causes configure script to fail On 22 Mar 2006 06:55:53 -, pinskia at gcc dot gnu dot org <[EMAIL PROTECTED]> wrote: > > > --- Comment #18 from pinskia at gcc dot gnu dot org 2006-03-22 06:55 > --- > (In reply to comment #17) > > Subject: Re: Checking for gthread causes configure script to fail > > > > I did this: > > > > $ cd ~/downloads/gcc-3.4.6 > > $ ./configure --enable-threads && make > > $ cd libobjc > > $ ./configure > > Oh that is the issue, libobjc is configured automatically and is done > correctly > from the toplevel so you messing up by not following the instructions. > > All you need to do to configure GCC and build all of GCC is: > > $ cd ~/downloads/gcc-3.4.6 > > $ ./configure --enable-threads && make > > Though really you should be configuring in a different directory than the > source directory. OK, I just read the directions in the INSTALL directory and came up with this: cd ~/downloads mkdir objdir cd objdir ../gcc-3.4.6/configure --enable-languages=c,objc --enable-threads --enable-objc-gc make bootstrap It configured and built without any problems. Thanks very much for your help, and sorry about the false alarm. Issac -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26794
[Bug tree-optimization/15911] VRP/DOM does not like TRUTH_AND_EXPR
--- Comment #17 from rguenth at gcc dot gnu dot org 2006-03-22 09:00 --- Yes, this sounds very reasonable. Is there a chance you can take a look and provide a rough implementation? I can take on the ball and try to fix remaining issues - but as I'm not familiar with the VRP pass a patch to start with would be helpful in this sense. Thanks! Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15911
[Bug c++/26788] optimization of expression templates not as performant as g++ 4.0.2
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-03-22 09:12 --- If the salias-max-implicit-fields setting helps you then this is a PTA issue. I never hit PTA issues with the expression templates in POOMA, so it might be interesting to get a testcase for this. A testcase is also necessary to do anything about it. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Keywords||alias, missed-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26788
[Bug rtl-optimization/26780] Build fails while making ../../../unxlngi6.pro/slo/cellsuno.obj on LFS6.1, kernel 2.6.14.3
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-03-22 09:17 --- Use 'dmesg' to see if the kernel ran oom. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26780
[Bug target/26776] A stack frame can't be recovered when using large auto variable area.
--- Comment #3 from inaoka dot kazuhiro at renesas dot com 2006-03-22 09:48 --- 4.0.3 has a same problem. 4.1.0 has no problem. The following was a patch. http://gcc.gnu.org/ml/gcc-patches/2005-07/msg00533.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26776
[Bug target/26775] a stack pointer is not recovered correctly when using alloca.
--- Comment #4 from inaoka dot kazuhiro at renesas dot com 2006-03-22 09:49 --- 4.0.3 and 4.1.0 have a same problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26775
[Bug tree-optimization/25737] ACATS tests c974001 and c974013 do not terminate with struct aliasing enabled
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2006-03-22 09:53 --- s-taasde.adb:Time_Enqueue is miscompiled at -O2, more specifically: Q := Timer_Queue.Succ; while Q.Resume_Time < T loop Q := Q.Succ; end loop; -- Q is the block that has Resume_Time equal to or greater than -- T. After the insertion we want Q to be the successor of D. D.Succ := Q; D.Pred := Q.Pred; D.Pred.Succ := D; Q.Pred := D; -- If the new element became the head of the queue, -- signal the Timer_Server to wake up. if Timer_Queue.Succ = D then Timer_Attention := True; STPO.Wakeup (Timer_Server_ID, ST.Timer_Server_Sleep); end if; FRE thinks that it can propagate the value Timer_Queue.Succ has at the top of the code down to the conditional of the test at the bottom. Of course that's not true since the assignment game in the middle can clobber it. I'm further digging but does this ring a bell to you, Richard? TIA. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ebotcazou at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-02-05 10:28:53 |2006-03-22 09:53:52 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25737
[Bug tree-optimization/25737] ACATS tests c974001 and c974013 do not terminate with struct aliasing enabled
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2006-03-22 10:05 --- > I'm further digging but does this ring a bell to you, Richard? I guess we should have a few V_MAY_DEFs for SFT.115, right? # VUSE ; q_17 = system__tasking__async_delays__timer_queue.succ; # q_1 = PHI ; :; # VUSE ; D.1231_18 = q_1->resume_time; if (D.1231_18 >= t_13) goto ; else goto ; :; # VUSE ; q_26 = q_1->succ; q_27 = q_26; goto (); :; # SMT.120_58 = V_MAY_DEF ; d_12->succ = q_1; # VUSE ; D.1233_19 = q_1->pred; # SMT.120_59 = V_MAY_DEF ; d_12->pred = D.1233_19; # VUSE ; D.1234_20 = d_12->pred; # SMT.120_60 = V_MAY_DEF ; D.1234_20->succ = d_12; # SMT.120_61 = V_MAY_DEF ; q_1->pred = d_12; # VUSE ; D.1235_21 = system__tasking__async_delays__timer_queue.succ; if (D.1235_21 == d_12) goto ; else goto ; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25737
[Bug tree-optimization/25737] ACATS tests c974001 and c974013 do not terminate with struct aliasing enabled
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2006-03-22 10:28 --- Hum... perhaps I'm naive, but what's the point of creating SFTs for addressable variables? What's the mechanism that is supposed to add V_MAY_DEFs for SFTs of such variables when V_MAY_DEFs are added for the variables? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25737
[Bug ada/26796] [4.2 Regression] ACATS ICE c34002a c52005 spurious storage_error
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2006-03-22 10:32 --- Not present on 20/03: http://gcc.gnu.org/ml/gcc-testresults/2006-03/msg01368.html Present on 21/03: http://gcc.gnu.org/ml/gcc-testresults/2006-03/msg01395.html -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-03-22 10:32:16 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26796
[Bug ada/26797] [4.2 Regression] ACATS c35507m cd2a23e cxh1001 wrong code
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2006-03-22 10:33 --- Not present on 21/03: http://gcc.gnu.org/ml/gcc-testresults/2006-03/msg01395.html Present on 22/03: http://gcc.gnu.org/ml/gcc-testresults/2006-03/msg01449.html -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-03-22 10:33:25 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26797
[Bug c++/26788] optimization of expression templates not as performant as g++ 4.0.2
--- Comment #5 from roebel at ircam dot fr 2006-03-22 11:13 --- Created an attachment (id=11090) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11090&action=view) Results file for testcase As you requested I provide a testcase. It consists of 2 shell scripts that run the different compilers and then run the testcase. The testcase has two cases and two compilation modes: switch 1 compiled with -DHAND it gives hand optimized pointer only version compiled with -DMATMTL it gives the equivalent expression templates version switch 2 compiled with -DBENCH=1 it calculates an addition of three vectors compiled with -DBENCH=2 it calculates an addition of three vectors with some scalar multiplications The name of the excutable will indicate the experiment by two final characters H1 stands for hand optimized first benchmark, M2 stands for matmtl second benchmark ... The two scripts comp.sh and master.sh run the whole experiment: comp.sh runs the experiment for a single compiler and a user supplied set of vector sizes. Note, that each experiment always uses 1 vector element operations. By means of the vector size the amount of overhead can be controlled. master.sh runs comp.sh with a single compiler and the vector size arguments 5 and 1000 Results are produced with ./master.sh 2>&1 | tee mout egrep "#|user" mout First result is that gcc 4.1.0 with --param salias-max-implicit-fields=50 is a real success. As you see the compile time does not change "at least for this testcase" but the performance is identical to the pointer only case second result is that for gcc 4.1.0 with default parameter set we get performance worse then gcc 4.0.2 especially for small vectors (large overhead). The larger the vectors become the more gcc 4.1.0 approaches 4.0.2 ### # g++ 4.0.2 the reference ### #compile times user0m0.702s user0m0.697s user0m1.066s user0m1.077s #run times : vector size 5 # benchmarkredH1 user0m0.295s # benchmarkredM1 user0m0.307s # benchmarkredH2 user0m0.381s # benchmarkredM2 user0m0.412s #run times : vector size 1000 # benchmarkredH1 user0m0.230s # benchmarkredM1 user0m0.243s # benchmarkredH2 user0m0.287s # benchmarkredM2 user0m0.370s # g++ 4.1.0 default ### #compile times user0m0.747s user0m0.752s user0m1.211s user0m1.227s #run times : vector size 5 # benchmarkredH1 user0m0.264s # benchmarkredM1 user0m0.519s # benchmarkredH2 user0m0.347s # benchmarkredM2 user0m1.211s #run times : vector size 1000 # benchmarkredH1 user0m0.222s # benchmarkredM1 user0m0.286s # benchmarkredH2 user0m0.298s # benchmarkredM2 user0m0.375s # g++ 4.1.0 salias=50 ### #compile times user0m0.753s user0m0.741s user0m1.225s user0m1.239s #run times : vector size 5 # benchmarkredH1 user0m0.262s # benchmarkredM1 user0m0.307s # benchmarkredH2 user0m0.344s # benchmarkredM2 user0m0.313s #run times : vector size 1000 # benchmarkredH1 user0m0.223s # benchmarkredM1 user0m0.234s # benchmarkredH2 user0m0.299s # benchmarkredM2 user0m0.260s -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26788
[Bug tree-optimization/21829] [4.1/4.2 Regression] missed jump threading after unroller
--- Comment #9 from richard dot guenther at gmail dot com 2006-03-22 11:14 --- Subject: Re: [4.1/4.2 Regression] missed jump threading after unroller On 3/21/06, Jeffrey A Law <[EMAIL PROTECTED]> wrote: > It turns out this specialized PHI optimization pass is as effective > as running copy-prop and CCP on PHI nodes after DOM. Better yet, it > is a teeny tiny slowdown compared to just running the stripped down > copyprop. ie, for an almost unmeasurable slowdown we can do both > constant and copy propagation instead of just copy propagation. This patch caused a compile-time regression from 139s to 143s, resp. 192s to 197s (leafify) accounted by increases of operand scan / SSA incremental and tree CCP times for compiling tramp3d. Also memory usage during compiling went up from 655494 kB to 660626kB (this may be due to the VRP patch, though). Runtime of tramp3d did not improve but regress slightly (but that might be in the noise - we'll see). For this simple cleanup pass can you try updating SSA form manually please? Thanks, Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21829
[Bug c++/26788] optimization of expression templates not as performant as g++ 4.0.2
--- Comment #6 from roebel at ircam dot fr 2006-03-22 11:14 --- Created an attachment (id=11091) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11091&action=view) master shell script for comments see 11090: Results file for testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26788
[Bug c++/26788] optimization of expression templates not as performant as g++ 4.0.2
--- Comment #7 from roebel at ircam dot fr 2006-03-22 11:15 --- Created an attachment (id=11092) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11092&action=view) single experiment shell script for comments see 11090: Results file for testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26788
[Bug c++/26788] optimization of expression templates not as performant as g++ 4.0.2
--- Comment #8 from roebel at ircam dot fr 2006-03-22 11:16 --- Created an attachment (id=11093) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11093&action=view) testcase source file for comments see 11090: Results file for testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26788
[Bug tree-optimization/25737] ACATS tests c974001 and c974013 do not terminate with struct aliasing enabled
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-03-22 11:17 --- Danny might have an idea and/or time to look at this. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||dberlin at gcc dot gnu dot ||org Keywords||alias http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25737
[Bug tree-optimization/25737] ACATS tests c974001 and c974013 do not terminate with struct aliasing enabled
--- Comment #6 from rguenth at gcc dot gnu dot org 2006-03-22 11:19 --- I guess (only guess!) that the types differe in a way that aliasing does not see them clobbered by means of type based alias analysis. Can you try if -fno-strict-aliasing fixes it? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25737
[Bug c++/26799] New: Type deduction of a pointer-to-member
Dear all,
I would like to post a bug report for the GNU C/C++ compiler 3.3-e500.
We use the compiler to generate code for a PowerPC processor.
Used invokation line for the GNU C++ compiler:
ccppc -c -x c++ -ansi -Wall -Werror -mcpu=8540 -fverbose-asm -mbig
-fmerge-templates -mmultiple -mno-string -mstrict-align -O3
-fno-exceptions -fno-rtti -fno-builtin-printf
-I
-D
X.CPP -oX.O
// file X.CPP
void g (void*);
struct ABC
{
template
ABC (void (T_::* ptrFunc)(), U_& refObj)
{
T_* pObj = &refObj;
g (pObj); // <--- line 9
}
};
struct DEF
{
void f () const;
};
DEF def;
ABC abc(&DEF::f, def);
The compiler gives the following error message:
X.CPP: In constructor `ABC::ABC(void (T_::*)(), U_&) [with T_ = const DEF,
U_ = DEF]':
X.CPP:19: instantiated from here
X.CPP:9: error: invalid conversion from `const void*' to `void*'
The compilation of the code above fails but for a wrong reason: it should fail
because the pointer to function f has type 'void (DEF::*)() const' and there
is no constructor available whose first parameter fits the mentioned type.
But the GNU compiler erronously deduces the type 'void (const DEF::*)()' for
the first constructor parameter as the error message shows.
Kind regards
W. Roehrl
--
Summary: Type deduction of a pointer-to-member
Product: gcc
Version: 3.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: wolfgang dot roehrl at gi-de dot com
GCC build triplet: sparc-sun-solaris2.5.1
GCC host triplet: i386-pc-mingw32
GCC target triplet: powerpc-wrs-vxworks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26799
[Bug c++/26788] optimization of expression templates not as performant as g++ 4.0.2
--- Comment #9 from rguenth at gcc dot gnu dot org 2006-03-22 11:39 --- This is another case of find_used_portions missing explicit uses due to C++ and lots of inlining without any cleanup after that. And inserting cleanup being difficult because structure-aliasing pass running before going into SSA. A forwprop pass before it would do wonders here. Danny - any plans to look at making salias pass work on SSA form? With inlining on SSA like on IPA branch this looks necessary anyway (Honza simply moved the pass to before (final) inlining, which will make the situation just worse). -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||dberlin at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26788
[Bug c++/26788] optimization of expression templates not as performant as g++ 4.0.2
--- Comment #10 from roebel at ircam dot fr 2006-03-22 11:55 --- Not that I understand what you just said, but, I wanted to mention, that in contrast to my initial email the data I just sent indicates a small performance penalty of about 25% for g++ 4.0.2 for large vectors on a pentium 4 (that are the results I've sent) while there is no such penalty for large vectors on a pentium m. On a pentium m g++ 4.0.2 works as well as g++ 4.1.0 on pentium 4 with the --param salias...=50. Unfortunately, I dont have gcc 4.1.0 on my pentium m machine thanks, Axel -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26788
[Bug c/26800] New: ARM: creates 'strd' instructions for unaligned addresses
gcc creates 'strd' instructions which are accessing non-double-word
aligned addresses. This is forbidden accordingly ARM Reference Manual
and causes an alignment exception:
| 10.6.14 STRD
| However, the address of the first of the two words is required to be
| doubleword-aligned (that is, the address must be divisible by 8).
Example:
$ cat foo.c
struct A {
unsigned inta;
unsigned long long l;
};
int main()
{
extern struct A volatile*a;
a->l = 0;
}
$ arm-xscale-linux-gnu-gcc -c -Os -mabi=aapcs -march=armv5te ./foo.c
$ objdump -d foo.o
foo.o: file format elf32-littlearm
Disassembly of section .text:
:
0: e59f3010ldr r3, [pc, #16] ; 18 <.text+0x18>
4: e3a0mov r0, #0 ; 0x0
8: e5933000ldr r3, [r3]
c: e3a01000mov r1, #0 ; 0x0
10: e1c300f8strdr0, [r3, #8]
14: e12fff1ebx lr
18: andeq r0, r0, r0
AAPCS requires only a 4-Byte alignment for data pointers, so the
external 'a' might point to a non-8 divisible address. The resulting
address at 10: is non-8 divisible too and will cause an alignment
exception.
-
$ $C-gcc -v
Using built-in specs.
Target: arm-xscale-linux-gnu
Configured with: ../configure --prefix=/usr --build=i686-redhat-linux-gnu
--host=i686-redhat-linux-gnu --target=arm-xscale-linux-gnu
--with-sysroot=/usr/arm-xscale-linux-gnu/sys-root --disable-__cxa_atexit
--enable-target-optspace --with-gnu-ld --disable-nls --infodir=/usr/share/info
--mandir=/usr/share/man --enable-version-specific-runtime-libs
--enable-languages=c,c++,java,objc --enable-shared --enable-threads
--disable-multilib --with-cpu=xscale --enable-cxx-flags=-mcpu=xscale
-fomit-frame-pointer
Thread model: posix
gcc version 4.1.0
--
Summary: ARM: creates 'strd' instructions for unaligned addresses
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: enrico dot scholz at informatik dot tu-chemnitz dot de
GCC build triplet: i686-redhat-linux-gnu
GCC host triplet: i686-redhat-linux-gnu
GCC target triplet: arm-xscale-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26800
[Bug c/26800] ARM: creates 'strd' instructions for unaligned addresses
--- Comment #1 from rearnsha at gcc dot gnu dot org 2006-03-22 12:15 --- Invalid. The AAPCS requires 8-byte alignment of double-word objects (and, recursively any object containing such an object). Your struct contains a long long, which is a double-word object. See http://www.arm.com/products/DevTools/ABI.html for details. -- rearnsha at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26800
[Bug c/18050] -Wsequence-point reports false positives
--- Comment #6 from rguenth at gcc dot gnu dot org 2006-03-22 12:19 ---
Another one:
int foo(int i)
{
i = ++i;
return i;
}
I think the point is we should not warn for pre-increment, only post-increment.
Or can someone come up with a testcase that has undefined evaluation order just
by using pre-increment? One with two pre-increments:
int foo(void)
{
int i = 1;
i = (++i == 2) + ++i;
return i;
}
This is certainly undefined. But with one pre-increment only?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18050
[Bug c/18050] -Wsequence-point reports false positives
--- Comment #7 from joseph at codesourcery dot com 2006-03-22 12:26 --- Subject: Re: -Wsequence-point reports false positives On Wed, 22 Mar 2006, rguenth at gcc dot gnu dot org wrote: > i = ++i; Modified twice between sequence points, so undefined behavior. > I think the point is we should not warn for pre-increment, only > post-increment. > Or can someone come up with a testcase that has undefined evaluation order > just > by using pre-increment? One with two pre-increments: It's undefined behavior, not undefined evaluation order. Pre-increment returns the new value, but that doesn't mean the new value is stored until the following sequence point. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18050
[Bug fortran/26801] New: -fbounds-check generates segfault
Attached program generates a segfault when compiled with bounds-check enabled. There is nothing strange in the code that I can see (though of course I might be proven wrong). [EMAIL PROTECTED] sfilippo]$ gfortran -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc-4.2-20060318/configure --prefix=/usr/local/gfortran Thread model: posix gcc version 4.2.0 20060318 (experimental) [EMAIL PROTECTED] sfilippo]$ gfortran -o assoc assoc.f90 [EMAIL PROTECTED] sfilippo]$ ./assoc F T F F T T [EMAIL PROTECTED] sfilippo]$ gfortran -o assoc assoc.f90 -fbounds-check [EMAIL PROTECTED] sfilippo]$ ./assoc F T Segmentation fault (core dumped) -- Summary: -fbounds-check generates segfault Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sfilippone at uniroma2 dot it GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26801
[Bug c++/26084] ICE (segfault) on C++ OpenMP code
--- Comment #13 from rth at gcc dot gnu dot org 2006-03-22 12:33 --- Mine. -- rth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|dnovillo at gcc dot gnu dot |rth at gcc dot gnu dot org |org | Status|REOPENED|ASSIGNED Last reconfirmed|2006-02-07 12:12:34 |2006-03-22 12:33:27 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26084
[Bug fortran/26801] -fbounds-check generates segfault
--- Comment #1 from sfilippone at uniroma2 dot it 2006-03-22 12:34 --- Created an attachment (id=11094) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11094&action=view) test case Note: the code segfaults even if the first do loop (before allocating the %a components) is commented out. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26801
[Bug middle-end/26084] ICE (segfault) on C++ OpenMP code
--- Comment #14 from rth at gcc dot gnu dot org 2006-03-22 12:50 --- Subject: Bug 26084 Author: rth Date: Wed Mar 22 12:50:45 2006 New Revision: 112283 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112283 Log: PR middle-end/26084 * except.c (duplicate_eh_regions_0): New. (duplicate_eh_region_1): Duplicate the children of the node as well as the node itself. Link them up properly. (duplicate_eh_region_2): Merge into ... (duplicate_eh_regions): ... here. Take copy_region argument, and copy only a sub-tree if asked. Simplify copying and fixup. (eh_region_outer_p): New. * except.h (duplicate_eh_regions): Update decl. (eh_region_outer_p): Declare. * omp-low.c (lower_omp_single): Fix eh region placement wrt OMP_RETURN. (lower_omp_master): Likewise. (lower_omp_ordered): Likewise. * tree-cfg.c (struct move_stmt_d): Add new_label_map. (move_stmt_r): Use it to remap labels. Handle recursion vs remap_decls_p properly. (move_block_to_fn): Pass in new_label_map. Remap RESX_EXPR. (find_outermost_region_in_block): New. (new_label_mapper): New. (move_sese_region_to_fn): Copy eh information to the new function properly. * tree-inline.c (copy_cfg_body): Update for new duplicate_eh_regions argument. * tree-pretty-print.c (dump_generic_node): Dump RESX_EXPR region number. Modified: trunk/gcc/ChangeLog trunk/gcc/except.c trunk/gcc/except.h trunk/gcc/omp-low.c trunk/gcc/tree-cfg.c trunk/gcc/tree-inline.c trunk/gcc/tree-pretty-print.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26084
[Bug middle-end/26084] ICE (segfault) on C++ OpenMP code
--- Comment #15 from rth at gcc dot gnu dot org 2006-03-22 12:53 --- Fixed. -- rth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26084
[Bug c/18050] -Wsequence-point reports false positives
--- Comment #8 from rguenth at gcc dot gnu dot org 2006-03-22 12:53 --- Sure - but this doesn't matter in this case. And 6.5.3.1 tells you "The expression ++E is equivalent to (E+=1)." 6.5.16 says "The side effect of updating the stored value of the left operand shall occur between the previous and the next sequence point." For i = ++i; this means we have i = (i += 1); where for i += 1 the next sequence point is the i = ... assigment? Of course for the particular testcase the ordering of the two stores does not matter. Would int i=0; i = ++i + 1; be able to result in i == 1? I don't think so as per 6.5.16. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18050
[Bug c/18050] -Wsequence-point reports false positives
--- Comment #9 from schwab at suse dot de 2006-03-22 13:08 --- (In reply to comment #8) > i = (i += 1); > > where for i += 1 the next sequence point is the i = ... assigment? The next sequence point is the semicolon. > Of course for the particular testcase the ordering of the two stores > does not matter. Would int i=0; i = ++i + 1; be able to result in > i == 1? Yes, the side effects of = and ++ can be performed in either order. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18050
[Bug libfortran/26802] New: gfortran.dg/pr16597.f90 leaves behind a file
The existing testcase gfortran.dg/pr16597.f90 leaves behind a file named
fort.99 and should not do so. (If you run the entire testsuite, you have to
run the testcase manually to see fort.99 because later tests reuse the same
filename and delete it.)
Looking at the code, the last time the file is opened, it uses STATUS='scratch'
so in theory the file should be deleted. Adding status='delete' to the last
close statement has no effect.
! { dg-do run }
! pr 16597
! libgfortran
! reading a direct access record after it was written did
! not always return the correct data.
program gfbug4
implicit none
integer strlen
parameter(strlen = 4)
integer iunit
characterstring *4
iunit = 99
open (UNIT=iunit,FORM='unformatted',ACCESS='direct',RECL=strlen)
write (iunit, rec=1) 'ABCD'
read (iunit, rec=1) string
close (iunit)
if (string.ne.'ABCD') call abort
open
(UNIT=iunit,FORM='unformatted',ACCESS='direct',STATUS='scratch',RECL=strlen)
write (iunit, rec=1) 'ABCD'
read (iunit, rec=1) string
close (iunit)
if (string.ne.'ABCD') call abort
end
--
Summary: gfortran.dg/pr16597.f90 leaves behind a file
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libfortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ghazi at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26802
[Bug tree-optimization/21829] [4.1/4.2 Regression] missed jump threading after unroller
--- Comment #10 from law at redhat dot com 2006-03-22 14:01 --- Subject: Re: [4.1/4.2 Regression] missed jump threading after unroller On Wed, 2006-03-22 at 12:14 +0100, Richard Guenther wrote: > On 3/21/06, Jeffrey A Law <[EMAIL PROTECTED]> wrote: > > It turns out this specialized PHI optimization pass is as effective > > as running copy-prop and CCP on PHI nodes after DOM. Better yet, it > > is a teeny tiny slowdown compared to just running the stripped down > > copyprop. ie, for an almost unmeasurable slowdown we can do both > > constant and copy propagation instead of just copy propagation. > > This patch caused a compile-time regression from 139s to 143s, resp. > 192s to 197s (leafify) accounted by increases of operand scan / SSA > incremental > and tree CCP times for compiling tramp3d. Also memory usage during compiling > went up from 655494 kB to 660626kB (this may be due to the VRP patch, though). > > Runtime of tramp3d did not improve but regress slightly (but that > might be in the > noise - we'll see). > > For this simple cleanup pass can you try updating SSA form manually please? I'm more than happy to look at it; however, be aware that if you're seeing increased time in CCP then either you're seeing some truly bizzarre secondary effect or your testing methodology is suspect. The patch did not affect CCP. In fact, the changes only affect passes which run *after* CCP in the optimization pipeline. Jeff -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21829
[Bug libfortran/26802] gfortran.dg/pr16597.f90 leaves behind a file
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2006-03-22 14:03 --- Not a bug. The first OPEN has neither FILE nor STATUS='SCRATCH' specifier, so it creates a file named fort.99 in the cwd. This is the expected behaviour. The testcase should probably have a STATUS='SCRATCH' added. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26802
[Bug tree-optimization/26804] New: Alias Time explosion
Alias analysis is taking a long time now. I seem to have narrowed it down to this patch: http://gcc.gnu.org/ml/gcc-patches/2006-01/msg00908.html running cpgram.ii shows a regression: before patch: tree alias analysis : 2.49 ( 7%) usr 0.25 ( 5%) sys 6.13 ( 5%) wall 4971 kB ( 1%) ggc TOTAL : 36.90 4.72 130.34 467341 kB after patch: tree alias analysis : 59.00 (63%) usr 0.40 ( 7%) sys 70.43 (36%) wall 4957 kB ( 1%) ggc TOTAL : 94.13 5.43 193.85 468339 kB on a 386 linux machine bootstrapped with checking disabled. cpgram.ii needs to be compiled with -fpermissive -O2 -- Summary: Alias Time explosion Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: amacleod at redhat dot com GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26804
[Bug tree-optimization/26804] Alias Time explosion
--- Comment #1 from amacleod at redhat dot com 2006-03-22 14:17 --- Created an attachment (id=11095) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11095&action=view) large c++ include file. cpgram.ii which compiles with -fpermissive -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26804
[Bug fortran/26769] TRANSPOSE() requires _gfortran_transpose_i10 for REAL(10) arrays
-- tkoenig at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tkoenig at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-03-20 19:33:30 |2006-03-22 14:37:04 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26769
[Bug middle-end/26084] ICE (segfault) on C++ OpenMP code
--- Comment #16 from martin at mpa-garching dot mpg dot de 2006-03-22 14:37 --- (In reply to comment #15) > Fixed. Unfortunately the unreduced testcase still fails with -O: /scratch>g++ -O -v -fopenmp bug.ii Using built-in specs. Target: i686-pc-linux-gnu Configured with: /scratch/gcc/configure --quiet --prefix=/afs/mpa/data/martin/ugcc --enable-languages=c++,fortran --with-gmp=/usr/local/appl/gmp-4.1.4 --enable-checking=release --without-makeinfo --disable-tls Thread model: posix gcc version 4.2.0 20060322 (experimental) /afs/mpa/data/martin/ugcc/libexec/gcc/i686-pc-linux-gnu/4.2.0/cc1plus -fpreprocessed bug.ii -quiet -dumpbase bug.ii -mtune=generic -auxbase bug -O -version -fopenmp -o /tmp/ccaWAsuo.s GNU C++ version 4.2.0 20060322 (experimental) (i686-pc-linux-gnu) compiled by GNU C version 4.2.0 20060322 (experimental). GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 3f3a7467532fa739fdc8d9d9e4c52ff9 /afs/mpa/data/martin/planck/LevelS/Healpix_cxx/alm_map_tools.cc: In function 'void alm2map_der1(const Alm >&, const std::vector >&, T*, T*, T*) [with T = float]': /afs/mpa/data/martin/planck/LevelS/Healpix_cxx/alm_map_tools.cc:644: internal compiler error: in add_stmt_to_eh_region_fn, at tree-eh.c:100 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. Should I open a new PR, or should this one be reopened? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26084
[Bug tree-optimization/26804] Alias Time explosion
--- Comment #2 from dberlin at gcc dot gnu dot org 2006-03-22 14:58 --- Mine -- dberlin at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dberlin at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-03-22 14:58:36 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26804
[Bug tree-optimization/21829] [4.1/4.2 Regression] missed jump threading after unroller
--- Comment #11 from richard dot guenther at gmail dot com 2006-03-22
15:06 ---
Subject: Re: [4.1/4.2 Regression] missed jump threading after unroller
On 3/22/06, Jeffrey A Law <[EMAIL PROTECTED]> wrote:
> On Wed, 2006-03-22 at 12:14 +0100, Richard Guenther wrote:
> > On 3/21/06, Jeffrey A Law <[EMAIL PROTECTED]> wrote:
> > > It turns out this specialized PHI optimization pass is as effective
> > > as running copy-prop and CCP on PHI nodes after DOM. Better yet, it
> > > is a teeny tiny slowdown compared to just running the stripped down
> > > copyprop. ie, for an almost unmeasurable slowdown we can do both
> > > constant and copy propagation instead of just copy propagation.
> >
> > This patch caused a compile-time regression from 139s to 143s, resp.
> > 192s to 197s (leafify) accounted by increases of operand scan / SSA
> > incremental
> > and tree CCP times for compiling tramp3d. Also memory usage during
> > compiling
> > went up from 655494 kB to 660626kB (this may be due to the VRP patch,
> > though).
> >
> > Runtime of tramp3d did not improve but regress slightly (but that
> > might be in the
> > noise - we'll see).
> >
> > For this simple cleanup pass can you try updating SSA form manually please?
> I'm more than happy to look at it; however, be aware that if you're
> seeing increased time in CCP then either you're seeing some truly
> bizzarre secondary effect or your testing methodology is suspect.
> The patch did not affect CCP. In fact, the changes only affect
> passes which run *after* CCP in the optimization pipeline.
struct tree_opt_pass pass_phi_only_cprop =
{
"phicprop", /* name */
gate_dominator, /* gate */
eliminate_degenerate_phis,/* execute */
NULL, /* sub */
NULL, /* next */
0,/* static_pass_number */
TV_TREE_CCP, /* tv_id */
PROP_cfg | PROP_ssa | PROP_alias, /* properties_required */
0,/* properties_provided */
PROP_smt_usage, /* properties_destroyed */
0,/* todo_flags_start */
TODO_cleanup_cfg | TODO_dump_func
| TODO_ggc_collect | TODO_verify_ssa
| TODO_verify_stmts | TODO_update_smt_usage
| TODO_update_ssa, /* todo_flags_finish */
0 /* letter */
};
see tv_id - so I guess increased CCP times are expected.
Richard.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21829
[Bug libstdc++/26777] sync_with_stdio(false) triggers bug with sgetc and pubseekoff
--- Comment #5 from paolo at gcc dot gnu dot org 2006-03-22 15:13 --- Subject: Bug 26777 Author: paolo Date: Wed Mar 22 15:13:46 2006 New Revision: 112286 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112286 Log: 2006-03-22 Paolo Carlini <[EMAIL PROTECTED]> PR libstdc++/26777 * include/bits/fstream.tcc (basic_filebuf<>::_M_seek): Check the return value of _M_file.seekoff. * testsuite/27_io/basic_filebuf/seekoff/char/26777.cc: New. Added: trunk/libstdc++-v3/testsuite/27_io/basic_filebuf/seekoff/char/26777.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/fstream.tcc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26777
[Bug libstdc++/26777] sync_with_stdio(false) triggers bug with sgetc and pubseekoff
--- Comment #6 from pcarlini at suse dot de 2006-03-22 15:15 --- Fixed for 4.2.0. -- pcarlini at suse dot de changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26777
[Bug c++/26799] Type deduction of a pointer-to-member
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-22 15:35 --- I get a different error message on the mainline: t7.cc:19: error: no matching function for call to ‘ABC::ABC(void (DEF::*)()const, DEF&)’ t7.cc:4: note: candidates are: ABC::ABC(const ABC&) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26799
[Bug c++/26799] Type deduction of a pointer-to-member
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-22 15:36 --- Fixed in 4.0.0, the error message is the same as in comment #1. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26799
[Bug tree-optimization/21829] [4.1/4.2 Regression] missed jump threading after unroller
--- Comment #12 from law at redhat dot com 2006-03-22 15:36 --- Subject: Re: [4.1/4.2 Regression] missed jump threading after unroller On Wed, 2006-03-22 at 16:06 +0100, Richard Guenther wrote: > ; > > see tv_id - so I guess increased CCP times are expected. Nuts. I should have made a separate tv_id. I'll fix that shortly. I probably won't be able to look at the compile-time regression for your testcase until Friday. jeff -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21829
[Bug libstdc++/6702] requirements for wchar_t support are too restrictive for Solaris
--- Comment #19 from gcc-bklyn at sneakemail dot com 2006-03-22 16:04 --- This bug appears to have recurred in gcc 4.1.0. I have no wide string or iostream support on my brand-spanking-new versionof gcc, when this all worked fine with gcc 3.4.3. -- gcc-bklyn at sneakemail dot com changed: What|Removed |Added CC||gcc-bklyn at sneakemail dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6702
[Bug libstdc++/6702] requirements for wchar_t support are too restrictive for Solaris
--- Comment #20 from pcarlini at suse dot de 2006-03-22 16:11 --- (In reply to comment #19) > This bug appears to have recurred in gcc 4.1.0. I have no wide string or > iostream support on my brand-spanking-new versionof gcc, when this all worked > fine with gcc 3.4.3. But frankly I suspect something is wrong in your setup, because people are regularly posting succesful testresults for Solaris with >~ 3000 passes (-> wchar_t is enabled). Just have a look to gcc-testresults. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6702
[Bug libstdc++/6702] requirements for wchar_t support are too restrictive for Solaris
--- Comment #21 from pcarlini at suse dot de 2006-03-22 16:23 --- Humm, maybe Solaris < 2.10 is affected... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6702
[Bug tree-optimization/26806] New: ICE at gcc/tree-gimple.c:269
The capacita benchmark, part of the polyhedron benchmark suite, fails with the
ICE in the summary. BT:
#0 0x080d0276 in is_gimple_reg_type (type=0x0) at
../../trunk/gcc/tree-gimple.c:269
#1 0x080d0519 in is_gimple_val (t=0xb7852fa4) at
../../trunk/gcc/tree-gimple.c:368
#2 0x083e60c0 in verify_expr (tp=0xb7ba5728, walk_subtrees=0xbfa13e08,
data=0x0)
at ../../trunk/gcc/tree-cfg.c:3469
#3 0x08363911 in walk_tree (tp=0xb7ba5728, func=0x83e5c20 ,
data=0x0,
pset=0x0) at ../../trunk/gcc/tree.c:7306
#4 0x083ed9f7 in verify_stmts () at ../../trunk/gcc/tree-cfg.c:3506
#5 0x083ff8c9 in verify_ssa (check_modified_stmt=1 '\001')
at ../../trunk/gcc/tree-ssa.c:643
#6 0x0837f1ca in execute_todo (flags=8375) at ../../trunk/gcc/passes.c:794
#7 0x0837f42a in execute_one_pass (pass=0x8690d48) at
../../trunk/gcc/passes.c:884
#8 0x0837f587 in execute_pass_list (pass=0x8690d48) at
../../trunk/gcc/passes.c:909
#9 0x0837f59b in execute_pass_list (pass=0x85cea00) at
../../trunk/gcc/passes.c:910
#10 0x080cfb93 in tree_rest_of_compilation (fndecl=0xb7b4ce80)
at ../../trunk/gcc/tree-optimize.c:418
#11 0x083cc8b2 in cgraph_expand_function (node=0xb7b53a80)
at ../../trunk/gcc/cgraphunit.c:1102
#12 0x083cdccb in cgraph_optimize () at ../../trunk/gcc/cgraphunit.c:1167
#13 0x0809ce2f in gfc_be_parse_file (set_yydebug=0)
at ../../trunk/gcc/fortran/f95-lang.c:302
#14 0x08350676 in toplev_main (argc=3, argv=0xbfa14084) at
../../trunk/gcc/toplev.c:999
#15 0xb7d9dea2 in __libc_start_main () from /lib/tls/i686/cmov/libc.so.6
#16 0x0804af01 in _start () at ../sysdeps/i386/elf/start.S:119
(gdb) up 7
#7 0x0837f42a in execute_one_pass (pass=0x8690d48) at
../../trunk/gcc/passes.c:884
884 execute_todo (todo_after | pass->todo_flags_finish);
(gdb) print *pass
$1 = {name = 0x85acd37 "phicprop", gate = 0x8428830 ,
execute = 0x842adc0 , sub = 0x0, next = 0x85dc900,
static_pass_number = 58, tv_id = 43, properties_required = 584,
properties_provided = 0, properties_destroyed = 2048, todo_flags_start = 0,
todo_flags_finish = 8375, letter = 0 '\0'}
Undisclosed sources on IRC tell me that this bug is due to the new pass Jeff
has contributed.
--
Summary: ICE at gcc/tree-gimple.c:269
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: law at redhat dot com
ReportedBy: jb at gcc dot gnu dot org
GCC host triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26806
[Bug middle-end/26807] New: FAIL: gcc.dg/torture/pr24626-1.c -O2 (test for excess errors)
At -O2 and above, Executing on host: /home/dave/gnu/gcc-4.2/objdir/gcc/xgcc -B/home/dave/gnu/gcc-4 .2/objdir/gcc/ /home/dave/gnu/gcc-4.2/gcc/gcc/testsuite/gcc.dg/torture/pr24626-1 .c -O2 -fno-show-column -S -o pr24626-1.s(timeout = 300) /home/dave/gnu/gcc-4.2/gcc/gcc/testsuite/gcc.dg/torture/pr24626-1.c: In function 'F1': /home/dave/gnu/gcc-4.2/gcc/gcc/testsuite/gcc.dg/torture/pr24626-1.c:27: internal compiler error: in check_cfg, at haifa-sched.c:4590 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. compiler exited with status 1 output is: /home/dave/gnu/gcc-4.2/gcc/gcc/testsuite/gcc.dg/torture/pr24626-1.c: In function 'F1': /home/dave/gnu/gcc-4.2/gcc/gcc/testsuite/gcc.dg/torture/pr24626-1.c:27: internal compiler error: in check_cfg, at haifa-sched.c:4590 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. FAIL: gcc.dg/torture/pr24626-1.c -O2 (test for excess errors) -- Summary: FAIL: gcc.dg/torture/pr24626-1.c -O2 (test for excess errors) Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: hppa-unknown-linux-gnu GCC host triplet: hppa-unknown-linux-gnu GCC target triplet: hppa-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26807
[Bug tree-optimization/26806] ICE at gcc/tree-gimple.c:269
--- Comment #1 from jb at gcc dot gnu dot org 2006-03-22 17:10 --- Created an attachment (id=11097) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11097&action=view) Testcase Testcase that demonstrates the ICE. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26806
[Bug middle-end/26807] [4.2 Regression] FAIL: gcc.dg/torture/pr24626-1.c -O2 (test for excess errors)
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Keywords||ice-on-valid-code Summary|FAIL: |[4.2 Regression] FAIL: |gcc.dg/torture/pr24626-1.c |gcc.dg/torture/pr24626-1.c |-O2 (test for excess |-O2 (test for excess |errors) |errors) Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26807
[Bug middle-end/26807] [4.2 Regression] FAIL: gcc.dg/torture/pr24626-1.c -O2 (test for excess errors)
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-22 17:19 --- I bet this was caused by the IA64 scheduler improvements on 2006-03-16. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26807
[Bug libstdc++/6702] requirements for wchar_t support are too restrictive for Solaris
--- Comment #22 from gcc-bklyn at sneakemail dot com 2006-03-22 17:20 --- (In reply to comment #21) > Humm, maybe Solaris < 2.10 is affected... I am indeed on 2.8. What more can I do to debug this? I'll attach sparc-sun-solaris2.8/libstdc++-v3/config.log. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6702
[Bug tree-optimization/26806] [4.2 Regression] ICE at gcc/tree-gimple.c:269
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||law at redhat dot com AssignedTo|law at redhat dot com |unassigned at gcc dot gnu ||dot org Keywords||ice-on-valid-code Summary|ICE at gcc/tree-gimple.c:269|[4.2 Regression] ICE at ||gcc/tree-gimple.c:269 Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26806
[Bug libstdc++/6702] requirements for wchar_t support are too restrictive for Solaris
--- Comment #23 from gcc-bklyn at sneakemail dot com 2006-03-22 17:23 --- Created an attachment (id=11098) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11098&action=view) gcc 4.1.0 sparc-sun-solaris2.8/libstdc++-v3/config.log Gcc 4.1.0 config.log from /sparc-sun-solaris2.8/libstdc++-v3/config.log -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6702
[Bug tree-optimization/26806] [4.2 Regression] ICE at gcc/tree-gimple.c:269
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-22 17:27 --- Confirmed, shorter testcase: module solv_cap integer, private, save :: Ng1=0, Ng2=0 contains subroutine FourirG(G) real, intent(in out), dimension(0:,0:) :: G complex, allocatable, dimension(:,:) :: t allocate( t(0:2*Ng1-1,0:2*Ng2-1) ) t(0:Ng1,0:Ng2-1)= G(:,0:Ng2-1) ! Fill one quadrant (one extra row) t(0:Ng1,Ng2:2*Ng2-1) = G(:,Ng2:1:-1)! This quadrant using symmetry end subroutine FourirG end module solv_cap -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-03-22 17:27:29 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26806
[Bug libstdc++/6702] requirements for wchar_t support are too restrictive for Solaris
--- Comment #24 from ebotcazou at gcc dot gnu dot org 2006-03-22 17:40 --- Confirmed on Solaris 7, 8 and 9, everything is fine on Solaris 10. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6702
[Bug libstdc++/26810] New: error when building cross-compiler
I successfully compiled binutils-2.16, configured gcc, and binutils, with --target=sparc64-sun-solaris-2.9 --with-headers=$path_to_headers --with-libs=$path_to_libs, but when I give the command "make all", this happens: ... >checking for ISO C99 support in ... no >checking wctype.h usability... yes >checking wctype.h presence... yes >checking for wctype.h... yes >checking for ISO C99 support in ... no >checking for fully enabled ISO C99 support... no >checking for enabled long long specializations... yes >checking for enabled wchar_t specializations... yes >configure: Debug build flags set to -g3 -O0 >checking for additional debug build... no >checking for extra compiler flags for building... >checking for thread model used by GCC... posix >checking iconv.h usability... yes >checking iconv.h presence... yes >checking for iconv.h... yes >checking langinfo.h usability... yes >checking langinfo.h presence... yes >checking for langinfo.h... yes >checking for iconv in -liconv... configure: error: Link tests are not allowed >>after GCC_NO_EXECUTABLES. >make[1]: *** [configure-target-libstdc++-v3] Error 1 >make[1]: Leaving directory `/home/filipe/sparc64/build-gcc' >make: *** [all] Error 2 -- Summary: error when building cross-compiler Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: scoton at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26810
[Bug rtl-optimization/25569] [4.2 Regression] FAIL: gfortran.dg/g77/20010610.f -O3 -fomit-frame-pointer -funroll-loops
--- Comment #13 from law at redhat dot com 2006-03-22 18:01 --- Fixed via today's checkin to loop-unroll.c -- law at redhat dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25569
[Bug tree-optimization/15911] VRP/DOM does not like TRUTH_AND_EXPR
--- Comment #18 from law at redhat dot com 2006-03-22 18:13 --- Subject: Re: VRP/DOM does not like TRUTH_AND_EXPR On Wed, 2006-03-22 at 09:00 +, rguenth at gcc dot gnu dot org wrote: > > --- Comment #17 from rguenth at gcc dot gnu dot org 2006-03-22 09:00 > --- > Yes, this sounds very reasonable. Is there a chance you can take a look and > provide a rough implementation? I can take on the ball and try to fix > remaining issues - but as I'm not familiar with the VRP pass a patch to start > with would be helpful in this sense. I've actually got a good hunk of a rough implementation the biggest thing that is missing is pruning of ASSERT_EXPRs for names which are not used in the subgraph. Fixing that is actually nontrivial, so we may just approximate it with pruning based on how many times the LHS is used. With any luck I'll be far enough along that I can start the regression testing when I hop on the airplane this evening. jeff -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15911
[Bug tree-optimization/26806] [4.2 Regression] ICE at gcc/tree-gimple.c:269
--- Comment #3 from law at redhat dot com 2006-03-22 18:14 --- Subject: Re: [4.2 Regression] ICE at gcc/tree-gimple.c:269 On Wed, 2006-03-22 at 17:27 +, pinskia at gcc dot gnu dot org wrote: > > --- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-22 17:27 > --- > Confirmed, shorter testcase: > module solv_cap > integer, private, save :: Ng1=0, Ng2=0 > contains > subroutine FourirG(G) > real, intent(in out), dimension(0:,0:) :: G > complex, allocatable, dimension(:,:) :: t > allocate( t(0:2*Ng1-1,0:2*Ng2-1) ) > t(0:Ng1,0:Ng2-1)= G(:,0:Ng2-1) ! Fill one quadrant (one extra > row) > t(0:Ng1,Ng2:2*Ng2-1) = G(:,Ng2:1:-1)! This quadrant using symmetry > end subroutine FourirG > end module Options/flags? I've been unable to reproduce this. jeff -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26806
[Bug tree-optimization/26795] [4.2 Regression] ACATS ICE c37213d on x86 in valid_in_set, at tree-ssa-pre.c:1579
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-22 18:16 ---
VIEW_CONVERT_EXPR(*B$P_ARRAYD.2768_872)[B92b.67D.2585_1027]{lb:
1 sz: 4}
We have a VIEW_CONVERT_EXPR here is ok, the assert is broken.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26795
[Bug tree-optimization/26806] [4.2 Regression] ICE at gcc/tree-gimple.c:269
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-03-22 18:19 --- (In reply to comment #3) > Options/flags? I've been unable to reproduce this. Just -O2. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added GCC host triplet|i686-pc-linux-gnu | GCC target triplet||i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26806
[Bug ada/26797] [4.2 Regression] ACATS c35507m cd2a23e cxh1001 failures
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2006-03-22 18:48 --- The 3 failures have been introduced by the following change: 2006-03-21 Jeff Law <[EMAIL PROTECTED]> * tree-vrp.c (extract_range_from_unary_expr): Derive ranges for type conversions of a VR_VARYING source to a wider type. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||law at gcc dot gnu dot org Summary|[4.2 Regression] ACATS |[4.2 Regression] ACATS |c35507m cd2a23e cxh1001 |c35507m cd2a23e cxh1001 |wrong code |failures http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26797
[Bug middle-end/26807] [4.2 Regression] FAIL: gcc.dg/torture/pr24626-1.c -O2 (test for excess errors)
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2006-03-22 18:49 --- Subject: Re: [4.2 Regression] FAIL: gcc.dg/torture/pr24626-1.c -O2 (test for excess errors) > I bet this was caused by the IA64 scheduler improvements on 2006-03-16. That's probably a good candidate. Results at Wed Mar 15 00:20:13 UTC 2006 (revision 112075M) are ok: http://gcc.gnu.org/ml/gcc-testresults/2006-03/msg01027.html Results at Fri Mar 17 16:26:46 UTC 2006 (revision 112175M) have the bug: http://gcc.gnu.org/ml/gcc-testresults/2006-03/msg01211.html. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26807
[Bug tree-optimization/26795] [4.2 Regression] ACATS ICE c37213d on x86 in valid_in_set, at tree-ssa-pre.c:1579
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-03-22 18:54 ---
The problem is that is the following:
Created value VH.637 for VIEW_CONVERT_EXPR(*_init$P_ARRAY_101)[A28b.23_725]{lb:
1 sz: 4} vuses: (HEAP.76_1012)
That should have been two split up into two VH's.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26795
[Bug tree-optimization/26795] [4.2 Regression] ACATS ICE c37213d on x86 in valid_in_set, at tree-ssa-pre.c:1579
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-03-22 18:56 ---
(In reply to comment #3)
> The problem is that is the following:
> Created value VH.637 for VIEW_CONVERT_EXPR c37213d__E27b__S31b___C_PAD[D.1589:D.1591]>(*_init$P_ARRAY_101)[A28b.23_725]{lb:
> 1 sz: 4} vuses: (HEAP.76_1012)
Actually 3, and it creates the VH's:
Created value VH.635 for *VH.570 vuses: (HEAP.76_1012)
Created value VH.636 for VIEW_CONVERT_EXPR(VH.635) vuses: (HEAP.76_1012)
Created value VH.637 for VIEW_CONVERT_EXPR(*_init$P_ARRAY_101)[A28b.23_725]{lb:
1 sz: 4} vuses: (HEAP.76_1012)
But does not replace it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26795
[Bug libfortran/19303] Unformatted record header is 4-bytes on 32-bit targets
--- Comment #22 from tkoenig at gcc dot gnu dot org 2006-03-22 19:09 --- Subject: Bug 19303 Author: tkoenig Date: Wed Mar 22 19:09:11 2006 New Revision: 112290 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112290 Log: 2006-03-22 Thomas Koenig <[EMAIL PROTECTED]> PR fortran/19303 * gfortran.h (gfc_option_t): Add record_marker. * lang.opt: Add -frecord-marker=4 and -frecord-marker=8. * trans-decl.c: Add gfor_fndecl_set_record_marker. (gfc_build_builtin_function_decls): Set gfor_fndecl_set_record_marker. (gfc_generate_function_code): If we are in the main program and -frecord-marker was provided, call set_record_marker. * options.c (gfc_handle_option): Add handling for -frecord-marker=4 and -frecord-marker=8. * invoke.texi: Document -frecord-marker. 2006-03-22 Thomas Koenig <[EMAIL PROTECTED]> PR fortran/19303 * libgfortran.h (compile_options_t): Add record_marker. * runtime/compile_options.c (set_record_marker): New function. * io/open.c: If we have four-byte record markers, use GFC_INTEGER_4_HUGE as default record length. * io/file_pos.c (unformatted_backspace): Handle different size record markers. * io/transfer.c (us_read): Likewise. (us_write): Likewise. (next_record_r): Likewise. (write_us_marker): Likewise. (next_record_w): Likewise. 2006-03-22 Thomas Koenig <[EMAIL PROTECTED]> PR fortran/19303 * gfortran.dg/record_marker_1.f90: New test case. * gfortran.dg/record_marker_2.f: New test case. * gfortran.dg/record_marker_3.f90: New test case. Added: trunk/gcc/testsuite/gfortran.dg/record_marker_1.f90 trunk/gcc/testsuite/gfortran.dg/record_marker_2.f trunk/gcc/testsuite/gfortran.dg/record_marker_3.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/invoke.texi trunk/gcc/fortran/lang.opt trunk/gcc/fortran/options.c trunk/gcc/fortran/trans-decl.c trunk/gcc/testsuite/ChangeLog trunk/libgfortran/ChangeLog trunk/libgfortran/io/file_pos.c trunk/libgfortran/io/open.c trunk/libgfortran/io/transfer.c trunk/libgfortran/libgfortran.h trunk/libgfortran/runtime/compile_options.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19303
[Bug libstdc++/21405] Template inlines have global visibility
--- Comment #18 from cristipp at excite dot com 2006-03-22 19:10 --- (In reply to comment #17) > see the solution in 24660 I'm not sure I understand correctly: are all C++ template libraries supposed to add 24660-style machinery? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21405
[Bug tree-optimization/26795] [4.2 Regression] ACATS ICE c37213d on x86 in valid_in_set, at tree-ssa-pre.c:1579
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-03-22 19:19 --- The problem is the follow if is being hit: 2941 /* If OP is a constant that has overflowed, do not value number 2942 this expression. */ 2943 if (CONSTANT_CLASS_P (op) 2944 && TREE_OVERFLOW (op)) Which means we don't get a VH correctly for this statement. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26795
[Bug tree-optimization/26795] [4.2 Regression] ACATS ICE c37213d on x86 in valid_in_set, at tree-ssa-pre.c:1579
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-03-22 19:26 --- I think I have a fix, removing this condition as this condition predates the change for overflow constants being gimple invariant. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-03-22 19:26:41 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26795
[Bug ada/26796] [4.2 Regression] ACATS ICE c34002a c52005 spurious storage_error
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2006-03-22 19:27 --- The 2 failures have been introduced by the following change: 2006-03-20 Jeff Law <[EMAIL PROTECTED]> * tree-pass.h (pass_phi_only_copy_prop): Delete. (pass_phi_only_cprop): Declare. * passes.c (init_optimization_passes): Replace pass_phi_only_copy_prop with phi_only_cprop * tree-ssa-dom.c (degenerate_phi_result): New function. (remove_stmt_or_phi, get_lhs_or_phi_result): Likewise. (get_rhs_or_phi_arg, propagate_rhs_into_lhs): Likewise. (eliminate_const_or_copy, eliminate_degenerate_phis_1): Likewise. (eliminate_degenerate_phis): Likewise. (pass_phi_only_cprop): New pass descriptor. * tree-ssa-copy.c (init_copy_prop): Lose PHIS_ONLY argument and support code. Callers updated. (execute_copy_prop, do_copy_prop): Likewise and corresponding changes. (store_copy_prop): Likewise. (do_phi_only_copy_prop, pass_phi_only_copy_prop): Remove. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||law at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26796
[Bug driver/22600] Exit code should be different from 1 for internal compiler error
--- Comment #10 from reichelt at gcc dot gnu dot org 2006-03-22 19:36 --- Subject: Bug 22600 Author: reichelt Date: Wed Mar 22 19:36:22 2006 New Revision: 112292 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112292 Log: PR driver/22600 * system.h (ICE_EXIT_CODE): New macro. * diagnostic.c (diagnostic_count_diagnostic): Exit with ICE_EXIT_CODE. (diagnostic_action_after_output): Likewise. * gcc.c (fatal_ice): New function. (execute): Use it instead of fatal. (fancy_abort): Likewise. * doc/invoke.texi (-pass-exit-codes): Document return code for ICEs. * fortran/error.c (gfc_fatal_error): Return ICE_EXIT_CODE instead of 4. Modified: trunk/gcc/ChangeLog trunk/gcc/diagnostic.c trunk/gcc/doc/invoke.texi trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/error.c trunk/gcc/gcc.c trunk/gcc/system.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22600
[Bug c++/26811] New: aix 5.1 won't compile mysql
Making all in mysys if gcc -pipe -mcpu=power -Wa,-many -DDEFAULT_BASEDIR=\"/usr/local/mysql\" -DDATADIR="\"/usr/local/mysql /var\"" -DDEFAULT_CHARSET_HOME="\"/usr/local/mysql\"" -DSHAREDIR="\"/usr/local/mysql/share/mysql\"" -DDEFAULT _HOME_ENV=MYSQL_HOME -DDEFAULT_GROUP_SUFFIX_ENV=MYSQL_GROUP_SUFFIX -DHAVE_CONFIG_H -I. -I. -I.. -I../include -I../include -I. -O3 -DDBUG_OFF-MT default.o -MD -MP -MF ".deps/default.Tpo" -c -o default.o default.c; then mv -f ".deps/default.Tpo" ".deps/default.Po"; else rm -f ".deps/default.Tpo"; exit 1; fi In file included from mysys_priv.h:17, from default.c:37: ../include/my_global.h:472: warning: weak declaration of '__cxa_pure_virtual' not supported default.c: In function 'search_default_file_with_ext': default.c:577: internal compiler error: in get_indirect_ref_operands, at tree-ssa-operands.c:1449 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. make: 1254-004 The error code from the last command is 1. Stop. make: 1254-004 The error code from the last command is 1. Stop. make: 1254-004 The error code from the last command is 2. Stop. -- Summary: aix 5.1 won't compile mysql Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: cprincipato at dialamerica dot com GCC host triplet: AIX 5.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26811
[Bug fortran/17298] gfortran ICE: Not Implemented: Scalarization of non-elemental intrinsic: __transfer1
--- Comment #11 from pault at gcc dot gnu dot org 2006-03-22 20:00 --- Subject: Bug 17298 Author: pault Date: Wed Mar 22 20:00:17 2006 New Revision: 112293 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112293 Log: 2006-03-22 Paul Thomas <[EMAIL PROTECTED]> PR fortran/17298 *trans-intrinsic.c (gfc_conv_intrinsic_array_transfer): New function to implement array valued TRANSFER intrinsic. (gfc_conv_intrinsic_function): Call the new function if TRANSFER and non-null se->ss. (gfc_walk_intrinsic_function): Treat TRANSFER as one of the special cases by calling gfc_walk_intrinsic_libfunc directly. 2006-03-22 Paul Thomas <[EMAIL PROTECTED]> PR fortran/17298 * gfortran.dg/transfer_array_intrinsic_1.f90: New test. * gfortran.dg/transfer_array_intrinsic_2.f90: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/transfer_array_intrinsic_1.f90 branches/gcc-4_1-branch/gcc/testsuite/gfortran.dg/transfer_array_intrinsic_2.f90 Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/trans-intrinsic.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17298
[Bug fortran/17298] gfortran ICE: Not Implemented: Scalarization of non-elemental intrinsic: __transfer1
--- Comment #12 from pault at gcc dot gnu dot org 2006-03-22 20:02 --- Fixed on trank and 4.1. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17298
[Bug fortran/26769] TRANSPOSE() requires _gfortran_transpose_i10 for REAL(10) arrays
--- Comment #3 from tkoenig at gcc dot gnu dot org 2006-03-22 20:06 --- Created an attachment (id=11099) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11099&action=view) patch This patch adds the appropriate _r10 versions. It also includes the reversal of automake to 1.9.3 (which may or may not be included in the final patch). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26769
[Bug testsuite/26813] New: Testsuite does not check for ICEs
The testsuite does not check for ICEs. Therefore, ICEs often go unnoticed
when they happen in a line that is marked with { dg-error "" }.
(See e.g. PR 24128, PR 26739, PR 26740 and several others).
Btw, this is somewhat similar to
PR 25241 "DejaGNU does not distinguish between errors and warnings".
With the patch for PR 22600 in place, at least three frontends
(C, C++, Fortran) have different exit codes for ICEs (4) and regular
errors (<4). So this is a first step to be able to identify ICEs in the
testsuite.
There are two remaining problems:
* First, the driver passes the exit status of the frontend only when
the command line option -pass-exit-codes is given.
So we either have to supply this option automagically in the testsuite
or make it the default.
* The second problem is in target_compile.
This function currently does not return the exit status of the compiler,
but a different status.
Well, there's a completely different approach: One can test for ICEs by
inspecting the error messages more closely. But that is more error-prone
than checking the exit status.
--
Summary: Testsuite does not check for ICEs
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: testsuite
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26813
[Bug driver/22600] Exit code should be different from 1 for internal compiler error
--- Comment #11 from reichelt at gcc dot gnu dot org 2006-03-22 20:14 --- Fixed in mainline. I.e. the C and C++ frontend now return "4" if an ICE occurred, and a code less than 4 if a regular error occurred. (The Fortran frontend has been doing this already.) In order to see the exit code one has to pass the option -pass-exit-codes to the driver (gcc, g++ or gfortran). Unfortunatly the testsuite doesn't make use of the new exit codes yet. This problem is tracked in PR 26813. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22600
[Bug c++/26811] aix 5.1 won't compile mysql
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-22 20:54 --- Fixed in 4.0.1. *** This bug has been marked as a duplicate of 21173 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26811
[Bug tree-optimization/21173] [4.0/4.1 regression] miscompiled pointer subtraction broke Linux kernel
--- Comment #39 from pinskia at gcc dot gnu dot org 2006-03-22 20:54 --- *** Bug 26811 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||cprincipato at dialamerica ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21173
[Bug testsuite/26813] Testsuite does not check for ICEs
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-22 21:00 --- Confirmed, I was going to link the llibjava testing bug but you already found it :). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26813
[Bug ada/26796] [4.2 Regression] ACATS ICE c34002a c52005 spurious storage_error
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26796
[Bug ada/26797] [4.2 Regression] ACATS c35507m cd2a23e cxh1001 failures
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26797
[Bug libstdc++/26810] error when building cross-compiler
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-22 21:09 --- Look at config.log in libstdc++ subdirectory to see why it fails. The error message is misleading. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26810
[Bug fortran/26801] -fbounds-check generates segfault
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-22 21:22 --- Confirmed, but I don't see could not figure out why the segfault is there. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC host triplet|i686-pc-linux-gnu | GCC target triplet|i686-pc-linux-gnu | Keywords||wrong-code Last reconfirmed|-00-00 00:00:00 |2006-03-22 21:22:10 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26801
[Bug tree-optimization/26795] [4.2 Regression] ACATS ICE c37213d on x86 in valid_in_set, at tree-ssa-pre.c:1579
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-03-22 21:39 --- Full testing of my patch is happening right now. It worked for this testcase just fine. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26795
[Bug c++/26789] [4.1/4.2 regression] ICE on incomplete struct with -fmudflap
--- Comment #3 from reichelt at gcc dot gnu dot org 2006-03-22 21:42 --- Subject: Bug 26789 Author: reichelt Date: Wed Mar 22 21:42:34 2006 New Revision: 112296 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112296 Log: PR mudflap/26789 * tree-mudflap.c (mf_xform_derefs_1): Return early on error_mark_node. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-mudflap.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26789
[Bug c++/26790] ICE with -fmudflap returning an incomplete struct
--- Comment #3 from reichelt at gcc dot gnu dot org 2006-03-22 21:45 --- Subject: Bug 26790 Author: reichelt Date: Wed Mar 22 21:45:13 2006 New Revision: 112298 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112298 Log: PR mudflap/26790 * tree-mudflap.c (mudflap_finish_file): Skip erroneous objects. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-mudflap.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26790
[Bug c++/26789] [4.1 regression] ICE on incomplete struct with -fmudflap
--- Comment #4 from reichelt at gcc dot gnu dot org 2006-03-22 21:58 --- Fixed on mainline. The testcase is still missing, though. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.1/4.2 regression] ICE on |[4.1 regression] ICE on |incomplete struct with -|incomplete struct with - |fmudflap|fmudflap http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26789
Bug report - unrecognizable insn
Hi All, Bug encountered building X. Probably already reported but I couldn't find any reference. I did google... Commandline.. make World CROSSCOMPILEDIR=/usr/local/arm-linux/bin X version XFree86-4.5.0, first 3 source archives only. Following instructions for configuring as per http://www.handhelds.org/minihowto/building-x.html at least the host.def and make command, tweaked for my cross tools installation. [EMAIL PROTECTED]:~$ arm-xscale-linux-gnu-gcc -v Reading specs from /usr/local/arm-linux/gcc-3.4.4-glibc-2.3.5/arm-xscale-linux-gnu/lib/gcc/arm-xscale-linux-gnu/3.4.4/specs Configured with: /usr/src/arm-linux/crosstool-0.38/build/arm-xscale-linux-gnu/gcc-3.4.4-glibc-2.3.5/gcc-3.4.4/configure --target=arm-xscale-linux-gnu --host=i686-host_pc-linux-gnu --prefix=/usr/local/arm-linux/gcc-3.4.4-glibc-2.3.5/arm-xscale-linux-gnu --with-cpu=xscale --enable-cxx-flags=-mcpu=xscale --with-headers=/usr/local/arm-linux/gcc-3.4.4-glibc-2.3.5/arm-xscale-linux-gnu/arm-xscale-linux-gnu/include --with-local-prefix=/usr/local/arm-linux/gcc-3.4.4-glibc-2.3.5/arm-xscale-linux-gnu/arm-xscale-linux-gnu --disable-nls --enable-threads=posix --enable-symvers=gnu --enable-__cxa_atexit --enable-languages=c,c++ --enable-shared --enable-c99 --enable-long-long Thread model: posix gcc version 3.4.4 [EMAIL PROTECTED]:~$ make[3]: Entering directory `/usr/src/arm-linux/apps/XFree86/build/programs/Xserver/GL/mesa/swrast' rm -f s_depth.o /usr/local/arm-linux/bin/`echo /usr/local/arm-linux/bin/arm-xscale-linux-gnu-gcc|sed "s%.*/%%"` -c -O2 -fsigned-char -I../../../../../extras/Mesa/src/mesa -I../../../../../extras/Mesa/src/mesa/main -I../../../../../extras/Mesa/src/mesa/glapi -I../../../../../extras/Mesa/src/mesa/shader -I../../../../../extras/Mesa/src/mesa/swrast -I../../../../../extras/Mesa/src/mesa/swrast_setup -I../../../../../extras/Mesa/include -I../../../../../programs/Xserver/include -I../../../../../exports/include/X11 -I../../../../../programs/Xserver/GL/include -I../../../../../programs/Xserver/GL/glx -I../../../../../lib/GL/include -I../../../../../programs/Xserver/hw/xfree86 -I../../../../../exports/include -I../../../../.. -I../../../../../exports/include -Dlinux -D__arm__ -D_POSIX_SOURCE -D_BSD_SOURCE -D_GNU_SOURCE -DX_LOCALE -DSHAPE -DXINPUT -DXKB -DLBX -DXAPPGROUP -DXCSECURITY -DTOGCUP -DXF86BIGFONT -DDPMSExtension -DPIXPRIV -DPANORAMIX -DRENDER -DRANDR -DGCCUSESGAS -DAVOID_GLYPHBLT -DPIXPRIV -DSINGLEDEPTH -DXFreeXDGA -DXvExtension-DXFree86LOADER -DXFree86Server-DXF86VIDMODE -DXvMCExtension -DSMART_SCHEDULE -DBUILDDEBUG -DXResExtension -DX_BYTE_ORDER=X_LITTLE_ENDIAN -DNDEBUG -DNEED_STRLCAT -DFUNCPROTO=15 -DNARROWPROTO -DGLXEXT -DGLX_USE_MESA s_depth.c s_depth.c: In function `_swrast_depth_test_span': s_depth.c:1362: error: unrecognizable insn: (insn 5699 1829 1835 209 s_depth.c:820 (set (reg:HI 2 r2) (mem:HI (plus:SI (mult:SI (reg/v:SI 5 r5 [orig:557 i ] [557]) (const_int 4 [0x4])) (reg/v/f:SI 8 r8 [orig:85 z ] [85])) [3 S4 A32])) -1 (nil) (nil)) s_depth.c:1362: internal compiler error: in extract_insn, at recog.c:2083 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. make[3]: *** [s_depth.o] Error 1 make[3]: Leaving directory `/usr/src/arm-linux/apps/XFree86/build/programs/Xserver/GL/mesa/swrast' Need any more info? Have fun! Regards, James.
[Bug c++/26790] ICE with -fmudflap returning an incomplete struct
--- Comment #4 from reichelt at gcc dot gnu dot org 2006-03-22 22:00 --- Fixed on mainline. The testcase is still missing, though. Will probably also be fixed on the 4.1 branch, since the patch is required for a complete fix of PR 26790 which is a 4.1/4.2 regression. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |reichelt at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26790
[Bug c++/24173] [4.0/4.1/4.2 regression] ICE with garbage collection
--- Comment #16 from jonz at gcc dot gnu dot org 2006-03-22 22:12 --- Subject: Bug 24173 Author: jonz Revision: 112262 Modified property: svn:log Modified: svn:log at Wed Mar 22 22:11:55 2006 -- --- svn:log (original) +++ svn:log Wed Mar 22 22:11:55 2006 @@ -1,3 +1,4 @@ +Radar 4458276 PR c++/24173 * decl.c (duplicate_decls): Don't rely on DECL_TEMPLATE_INFO after clobbering newdecl. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24173
[Bug target/26776] A stack frame can't be recovered when using large auto variable area.
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-03-22 23:03 --- Fixed in 4.1.0 then. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26776
[Bug target/26775] a stack pointer is not recovered correctly when using alloca.
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-03-22 23:04 --- Changing back to new then. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-03-22 23:04:41 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26775
[Bug bootstrap/26814] New: Can't build a 64-bit C compiler on darwin-ppc
Configured and built with #!/bin/tcsh /bin/rm -rf *; ../configure --prefix=/pkgs/gcc-4.1.0 --with-gmp=/sw/ --with-mpfr=/sw/ --with-as=/usr/local/odcctools-20060123/bin/as --with-ld=/usr/local/odcctools-20060123/bin/ld --enable-languages=c; make -j 8 bootstrap BOOT_CFLAGS='-mcpu=970 -m64 -O2 -g' >& build.log Bootstrap fails with stage1/xgcc -Bstage1/ -B/pkgs/gcc-4.1.0/powerpc-apple-darwin8.5.0/bin/ -mcpu=970 -m64 -O2 -g -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wold-style-definition -Wmissing-format-attribute -DHAVE_CONFIG_H -DGENERATOR_FILE -o build/genmodes \ build/genmodes.o build/errors.o ../build-powerpc-apple-darwin8.5.0/libiberty/libiberty.a ld64 failed: in ../build-powerpc-apple-darwin8.5.0/libiberty/libiberty.a(hashtab.o), not a valid ppc64 mach-o file which seems to be right: gcc -c -DHAVE_CONFIG_H -g -O2 -I/sw//include -I/sw//include -I. -I../../../libiberty/../include -W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../../libiberty/hashtab.c -o hashtab.o -- Summary: Can't build a 64-bit C compiler on darwin-ppc Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: lucier at math dot purdue dot edu GCC build triplet: powerpc-apple-darwin8.5.0 GCC host triplet: powerpc-apple-darwin8.5.0 GCC target triplet: powerpc-apple-darwin8.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26814
[Bug bootstrap/26814] Can't build a 64-bit C compiler on darwin-ppc
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-22 23:23 --- This is the same issue as the follow patch tries to solve: http://gcc.gnu.org/ml/gcc-patches/2006-02/msg01604.html So it is not just PPC-darwin. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26814
[Bug bootstrap/26814] Can't build a 64-bit C compiler on darwin-ppc
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2006-03-22 23:24 --- If you start with a 32-bit compiler, the correct sequence of operations is: CC="gcc -m64" $srcdir/configure --prefix=/pkgs/gcc-4.1.0 --with-gmp=/sw/ --with-mpfr=/sw/ --with-as=/usr/local/odcctools-20060123/bin/as --with-ld=/usr/local/odcctools-20060123/bin/ld --enable-languages=c make bootstrap -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26814
