GCC 4.0 Freeze
Please treat the GCC 4.0 branch as frozen as of this time. All non-documentation changes now need my explicit approval. I'll spin prerelease bits soon. Thanks, -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
GCC 4.0 Ada Status Report (2005-04-09)
Hi, fromm gcc-testresults here is where we stand on 4.0/Ada after the tree-sra Ada patch. I'm looking for results for platforms where I believe Ada could work: powerpc-linux powerpc-darwin x86-cygwin (may be in -mno-cygwin too?) sparc-solaris So if you have access to one of these platforms, please try enabling Ada, send results to gcc-testresults, and send me in compressed form the file gcc/testsuite/ada/acats/acats.log, I'll do the bugzilla filing for FAIL. Laurent no FAIL: sparc-linux s390-linux x86-linux x86_64-linux FAIL: cxa5012 s390x-linux FAIL: cxb5002 hppa-unknown-linux-gnu FAIL: c940013 FAIL: cb41002 FAIL: cxg1005 The following issues are unfiled in bugzilla (I've no recent enough acats.log files): ia64-linux FAIL: c36204d FAIL: c954012 FAIL: c9a009a FAIL: c9a009c FAIL: c9a009h FAIL: c9a010a FAIL: cb4009a hppa2.0w-hp-hpux11.11 FAIL: c393a06 FAIL: c52104k FAIL: c974005 FAIL: cc3120a FAIL: ce3806d FAIL: ce3806e FAIL: ce3810a FAIL: cxa4034 FAIL: cxaa008 FAIL: cxaa009 FAIL: cxaca01
Re: GCC 4.0 Ada Status Report (2005-04-09)
> no FAIL: > sparc-linux > s390-linux > x86-linux sparc-sun-solaris is clean, for all supported versions of Solaris, except maybe 10. > x86_64-linux > FAIL: cxa5012 I think this one is an artifact (sometimes an error is reported when chopping/building/running the test). x86_64-linux is clean too. -- Eric Botcazou
Re: GCC 4.0 Ada Status Report (2005-04-09)
On Sat, 2005-04-09 at 11:54 +0200, Eric Botcazou wrote:
> > no FAIL:
> > sparc-linux
> > s390-linux
> > x86-linux
>
> sparc-sun-solaris is clean, for all supported versions of Solaris, except
> maybe 10.
Ok thanks for the information!
> > x86_64-linux
> > FAIL: cxa5012
>
> I think this one is an artifact (sometimes an error is reported when
> chopping/building/running the test). x86_64-linux is clean too.
Unfortunately this is a real core dump while running the test on my
machine (glibc-2.3.3-118 SuSE 9.2) at -O2 or -O0, and this does not
reproduce under GDB, see below. I don't know about valgrind on x86_64,
is it available?
I also get from time to time "chopping/building/running exe not found"
errors, I've never understood why it happens. May be the following
could help.
*** run_all.sh.~1.18.~ 2005-02-28 12:55:04.0 +0100
--- run_all.sh 2005-04-09 12:15:32.186180141 +0200
***
*** 256,261
--- 256,264
echo "RUN $binmain" >> $dir/acats.log
cd $dir/run
+ if [ ! -x $dir/tests/$chapter/$i/$binmain ]; then
+ sync
+ fi
target_run $dir/tests/$chapter/$i/$binmain >
$dir/tests/$chapter/$i/${i}.log 2>&1
cd $dir/tests/$chapter/$i
cat ${i}.log >> $dir/acats.log
Laurent
[EMAIL
PROTECTED]:~/work/gcc/build/build-20050408T093139/gcc/testsuite/ada/acats/tests/cxa/cxa5012>
gnatmake -f -O0 -g -I../../../support/ ./cxa5012.adb
gcc -c -I./ -O0 -g -I../../../support/ -I- ./cxa5012.adb
cxa5012.adb:140:07: warning: "TC_Count" is never assigned a value
gcc -c -I./ -O0 -g -I../../../support/ -I- ../../../support/impdef.adb
gcc -c -I./ -O0 -g -I../../../support/ -I- ../../../support/report.adb
gnatbind -aO./ -I../../../support/ -I- -x cxa5012.ali
gnatlink cxa5012.ali -g
[EMAIL
PROTECTED]:~/work/gcc/build/build-20050408T093139/gcc/testsuite/ada/acats/tests/cxa/cxa5012>
./cxa5012
,.,. CXA5012 ACATS 2.5 05-04-09 12:07:41
CXA5012 Check the effect of Procedures Save and Reset, and
Functions Image and Value from the
Ada.Numerics.Discrete_Random and Float_Random packages.
Segmentation fault
[EMAIL
PROTECTED]:~/work/gcc/build/build-20050408T093139/gcc/testsuite/ada/acats/tests/cxa/cxa5012>
gdb ./cxa5012
GNU gdb 6.2.1
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "x86_64-suse-linux"...Using host libthread_db
library "/lib64/tls/libthread_db.so.1".
(gdb) r
Starting program:
/home/guerby/work/gcc/build/build-20050408T093139/gcc/testsuite/ada/acats/tests/cxa/cxa5012/cxa5012
,.,. CXA5012 ACATS 2.5 05-04-09 12:07:50
CXA5012 Check the effect of Procedures Save and Reset, and
Functions Image and Value from the
Ada.Numerics.Discrete_Random and Float_Random packages.
- CXA5012 Constraint_Error raised by Function
Ada.Numerics.Discrete_Random.Value when provided a
string input that does not represent the state of a
random number generator.
CXA5012 PASSED .
Program exited normally.
(gdb) q
Re: GCC 4.0 Ada Status Report (2005-04-09)
> Ok thanks for the information!
I'll post formal results for Solaris 2.5.1, 2.6, 7, 8 and 9 later today.
> > > x86_64-linux
> > > FAIL: cxa5012
> >
> > I think this one is an artifact (sometimes an error is reported when
> > chopping/building/running the test). x86_64-linux is clean too.
>
> Unfortunately this is a real core dump while running the test on my
> machine (glibc-2.3.3-118 SuSE 9.2) at -O2 or -O0, and this does not
> reproduce under GDB, see below.
It passes for me on SuSE 9.2 Professional (glibc-2.3.3-118 too). But this
could be an uninitialized variable.
> I don't know about valgrind on x86_64, is it available?
Work In Progress I think.
> I also get from time to time "chopping/building/running exe not found"
> errors, I've never understood why it happens. May be the following
> could help.
>
> *** run_all.sh.~1.18.~2005-02-28 12:55:04.0 +0100
> --- run_all.sh2005-04-09 12:15:32.186180141 +0200
> ***
> *** 256,261
> --- 256,264
>
> echo "RUN $binmain" >> $dir/acats.log
> cd $dir/run
> + if [ ! -x $dir/tests/$chapter/$i/$binmain ]; then
> + sync
> + fi
> target_run $dir/tests/$chapter/$i/$binmain >
> $dir/tests/$chapter/$i/${i}.log 2>&1 cd $dir/tests/$chapter/$i
> cat ${i}.log >> $dir/acats.log
Thanks, I'll test.
--
Eric Botcazou
Canonical form of the RTL CFG for an IF-THEN-ELSE block?
Hi,
We would like to know if there is some way to find the true and false
branches of a conditional jump in RTL. In the tree CFG, we have two
edge flags for that, EDGE_{TRUE,FALSE}_VALUE, but those flags have no
meaning for the RTL CFG. So our question is, is there some other way
to tell what edge will be taken in a conditional jump if the condition
is true?
It seems that some passes assume a canonical form of IF-THEN-ELSE even
on RTL. From ifcvt.c:find_if_header:
/* The THEN edge is canonically the one that falls through. */
if (then_edge->flags & EDGE_FALLTHRU)
;
else if (else_edge->flags & EDGE_FALLTHRU)
{
edge e = else_edge;
else_edge = then_edge;
then_edge = e;
}
else
/* Otherwise this must be a multiway branch of some sort. */
return NULL;
On the other hand, in cfgexpand.c:expand_gimple_cond_expr we have,
false_edge->flags |= EDGE_FALLTHRU;
and loop-unswitch.c assumes that the BRANCH_EDGE is the true_edge:
true_edge = BRANCH_EDGE (unswitch_on_alt);
false_edge = FALLTHRU_EDGE (unswitch_on);
So which is it? Is BRANCH_EDGE always taken if the condition is true,
or FALLTHRU_EDGE, or do you have to look at the condition to know?
Who knows an answer? :-)
Gr.
Steven
Re: Q: C++ FE emitting assignments to global read-only symbols?
I agree, in principle. The C++ FE should not set TREE_READONLY on variables that require dynanmic initialization. Until now, that's not been a problem, and it does result in better code. But, it's now becoming a problem, and we have others way to get good code coming down the pipe. Note that we had the same problem with the Ada FE a while ago.
Re: Q: C++ FE emitting assignments to global read-only symbols?
It would be good to have a way to mark things as "write once, then readonly" IMO. It's very common, and you can do some of the same optimizations on such things that you can do on true Readonly objects. We used to do this in RTL and it caused all sorts of problems. One is that supposed you have such a variable in a function and then you inline the function into a loop. Now all of a sudden, it's written more than once.
Re: Canonical form of the RTL CFG for an IF-THEN-ELSE block?
> Hi,
>
> We would like to know if there is some way to find the true and false
> branches of a conditional jump in RTL. In the tree CFG, we have two
> edge flags for that, EDGE_{TRUE,FALSE}_VALUE, but those flags have no
> meaning for the RTL CFG. So our question is, is there some other way
> to tell what edge will be taken in a conditional jump if the condition
> is true?
>
> It seems that some passes assume a canonical form of IF-THEN-ELSE even
> on RTL. From ifcvt.c:find_if_header:
>
> /* The THEN edge is canonically the one that falls through. */
> if (then_edge->flags & EDGE_FALLTHRU)
> ;
> else if (else_edge->flags & EDGE_FALLTHRU)
> {
> edge e = else_edge;
> else_edge = then_edge;
> then_edge = e;
> }
> else
> /* Otherwise this must be a multiway branch of some sort. */
> return NULL;
>
> On the other hand, in cfgexpand.c:expand_gimple_cond_expr we have,
>
> false_edge->flags |= EDGE_FALLTHRU;
>
> and loop-unswitch.c assumes that the BRANCH_EDGE is the true_edge:
>
> true_edge = BRANCH_EDGE (unswitch_on_alt);
> false_edge = FALLTHRU_EDGE (unswitch_on);
>
> So which is it? Is BRANCH_EDGE always taken if the condition is true,
> or FALLTHRU_EDGE, or do you have to look at the condition to know?
> Who knows an answer? :-)
:) It depends on how the conditional is constructed.
If you use get_condition the edge taken when conditional is true is
always BRANCH_EDGE if some exists (it is possible to have conditional
jump to the following instruction where you have only one edge with
EDGE_FALLTHRU flag).
Otherwise you have to look into conditional jump RTL yourself to figure
out if it has form
(set (pc) (if_then_else (cond) (pc) (label_ref xxx))
or
(set (pc) (if_then_else (cond) (label_ref xxx) (pc))
In the first case we are taking barnch edge when conditional is false.
Honza
>
> Gr.
> Steven
Re: GCC 4.0 Ada Status Report (2005-04-09)
> > FAIL: cxa5012 > > I think this one is an artifact (sometimes an error is reported when > chopping/building/running the test). x86_64-linux is clean too. Unfortunately this is a real core dump while running the test on my machine (glibc-2.3.3-118 SuSE 9.2) at -O2 or -O0, and this does not reproduce under GDB, see below. I don't know about valgrind on x86_64, is it available? Indeed I see it as a Heisenbug too. This tiny test case also shows it for me: with Ada.Numerics.Float_Random; with Ada.Numerics.Discrete_Random; with ImpDef; use Ada.Numerics; procedure CXA5012 is subtype Discrete_Range is Integer range 1..10_000; package Discrete_Pack is new Discrete_Random(Discrete_Range); DState_1 : Discrete_Pack.State; Not_A_State : constant String := ImpDef.Non_State_String; begin DState_1 := Discrete_Pack.Value(ImpDef.Non_State_String); end CXA5012; It's almost certainly a problem in exception dispatching.
Can't build gcc cvs trunk 20050409 gnat tools on sparc-linux: tree check: accessed operand 2 of view_convert_expr with 1 operands in visit_assignment, at tree-ssa-ccp.c:1074
Aurora SPARC Linux release 2.0 (Kashmir FC3) UltraSparc IIi (Sabre) sun4u: binutils-2.15.92.0.2-5.sparc bison-1.875c-2.sparc dejagnu-1.4.4-2.noarch expect-5.42.1-1.sparc gcc-3.4.2-6.fc3.sparc gcc4-4.0.0-0.8sparc.sparc glibc-2.3.3-99.sparc64 glibc-2.3.3-99.sparcv9 glibc-devel-2.3.3-99.sparc glibc-devel-2.3.3-99.sparc64 glibc-headers-2.3.3-99.sparc64 glibc-headers-2.3.3-99.sparc glibc-kernheaders-2.6-20sparc.sparc gmp-4.1.4-3sparc.sparc gmp-4.1.4-3sparc.sparc64 gmp-devel-4.1.4-3sparc.sparc gmp-devel-4.1.4-3sparc.sparc64 kernel-2.6.11-1.1166sp1.sparc64 package kernel-devel is not installed package kernel-smp is not installed libgcc-3.4.2-6.fc3.sparc libgcc-3.4.2-6.fc3.sparc64 libstdc++-3.4.2-6.fc3.sparc64 libstdc++-3.4.2-6.fc3.sparc libstdc++-devel-3.4.2-6.fc3.sparc64 libstdc++-devel-3.4.2-6.fc3.sparc make-3.80-5.sparc nptl-devel-2.3.3-99.sparcv9 tcl-8.4.7-2.sparc LAST_UPDATED: Sat Apr 9 12:34:15 UTC 2005 ../../xgcc -B../../ -c -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -fno-common -gnatpg -gnata -I- -I../rts -I. -I/usr/local/src/trunk/gcc/gcc/ada /usr/local/src/trunk/gcc/gcc/ada/make.adb -o make.o +===GNAT BUG DETECTED==+ | 4.1.0 20050409 (experimental) (sparc-unknown-linux-gnu) GCC error: | | tree check: accessed operand 2 of view_convert_expr with 1 operands | |in visit_assignment, at tree-ssa-ccp.c:1074 | | Error detected at make.adb:7263:23 | | Please submit a bug report; see http://gcc.gnu.org/bugs.html.| | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact gcc or gnatmake command that you entered. | | Also include sources listed below in gnatchop format | | (concatenated together with no headers between files). | +==+ Please include these source files with error report Note that list may not be accurate in some cases, so please double check that the problem can still be reproduced with the set of files listed. /usr/local/src/trunk/gcc/gcc/ada/make.adb /usr/local/src/trunk/gcc/gcc/ada/make.ads /usr/local/src/trunk/gcc/gcc/ada/table.ads /usr/local/src/trunk/gcc/gcc/ada/types.ads /usr/local/src/trunk/gcc/gcc/ada/ali.ads /usr/local/src/trunk/gcc/gcc/ada/casing.ads /usr/local/src/trunk/gcc/gcc/ada/gnatvsn.ads /usr/local/src/trunk/gcc/gcc/ada/rident.ads /usr/local/src/trunk/gcc/gcc/ada/ali-util.ads /usr/local/src/trunk/gcc/gcc/ada/csets.ads /usr/local/src/trunk/gcc/gcc/ada/debug.ads /usr/local/src/trunk/gcc/gcc/ada/fmap.ads /usr/local/src/trunk/gcc/gcc/ada/fname.ads /usr/local/src/trunk/gcc/gcc/ada/fname-sf.ads /usr/local/src/trunk/gcc/gcc/ada/fname-uf.ads /usr/local/src/trunk/gcc/gcc/ada/hostparm.ads /usr/local/src/trunk/gcc/gcc/ada/makeusg.ads /usr/local/src/trunk/gcc/gcc/ada/makeutl.ads /usr/local/src/trunk/gcc/gcc/ada/osint.ads /usr/local/src/trunk/gcc/gcc/ada/prj.ads /usr/local/src/trunk/gcc/gcc/ada/scans.ads /usr/local/src/trunk/gcc/gcc/ada/uintp.ads /usr/local/src/trunk/gcc/gcc/ada/alloc.ads /usr/local/src/trunk/gcc/gcc/ada/urealp.ads /usr/local/src/trunk/gcc/gcc/ada/mlib.ads /usr/local/src/trunk/gcc/gcc/ada/mlib-prj.ads /usr/local/src/trunk/gcc/gcc/ada/mlib-tgt.ads /usr/local/src/trunk/gcc/gcc/ada/mlib-utl.ads /usr/local/src/trunk/gcc/gcc/ada/namet.ads /usr/local/src/trunk/gcc/gcc/ada/opt.ads /usr/local/src/trunk/gcc/gcc/ada/osint-m.ads /usr/local/src/trunk/gcc/gcc/ada/output.ads /usr/local/src/trunk/gcc/gcc/ada/prj-com.ads /usr/local/src/trunk/gcc/gcc/ada/prj-env.ads /usr/local/src/trunk/gcc/gcc/ada/prj-pars.ads /usr/local/src/trunk/gcc/gcc/ada/prj-util.ads /usr/local/src/trunk/gcc/gcc/ada/sfn_scan.ads /usr/local/src/trunk/gcc/gcc/ada/sinput.ads /usr/local/src/trunk/gcc/gcc/ada/sinput-p.ads /usr/local/src/trunk/gcc/gcc/ada/snames.ads /usr/local/src/trunk/gcc/gcc/ada/switch.ads /usr/local/src/trunk/gcc/gcc/ada/switch-m.ads /usr/local/src/trunk/gcc/gcc/ada/targparm.ads /usr/local/src/trunk/gcc/gcc/ada/tempdir.ads /usr/local/src/trunk/gcc/gcc/ada/table.adb /usr/local/src/trunk/gcc/gcc/ada/tree_io.ads /usr/local/src/trunk/gcc/gcc/ada/prj-env.adb raised TYPES.UNRECOVERABLE_ERROR : comperr.adb:381 make[3]: *** [make.o] Error 1 make[3]: Leaving directory `/usr/local/src/trunk/objdir32/gcc/ada/tools' make[2]: *** [gnattools-native] Error 2 make[2]: Leaving directory `/usr/local/src/trunk/objdir32/gnattools' make[1]: *** [all-gnattools] Error 2 make[1]: Leaving directory `/usr/local/src/trunk/objdir32' make: *** [bubblestrap] Error 2 Anh ideas? -- Cheers, /ChJ
Re: Canonical form of the RTL CFG for an IF-THEN-ELSE block?
Jan Hubicka wrote:
Hi,
We would like to know if there is some way to find the true and false
branches of a conditional jump in RTL. In the tree CFG, we have two
edge flags for that, EDGE_{TRUE,FALSE}_VALUE, but those flags have no
meaning for the RTL CFG. So our question is, is there some other way
to tell what edge will be taken in a conditional jump if the condition
is true?
It seems that some passes assume a canonical form of IF-THEN-ELSE even
on RTL. From ifcvt.c:find_if_header:
/* The THEN edge is canonically the one that falls through. */
if (then_edge->flags & EDGE_FALLTHRU)
;
else if (else_edge->flags & EDGE_FALLTHRU)
{
edge e = else_edge;
else_edge = then_edge;
then_edge = e;
}
else
/* Otherwise this must be a multiway branch of some sort. */
return NULL;
On the other hand, in cfgexpand.c:expand_gimple_cond_expr we have,
false_edge->flags |= EDGE_FALLTHRU;
and loop-unswitch.c assumes that the BRANCH_EDGE is the true_edge:
true_edge = BRANCH_EDGE (unswitch_on_alt);
false_edge = FALLTHRU_EDGE (unswitch_on);
So which is it? Is BRANCH_EDGE always taken if the condition is true,
or FALLTHRU_EDGE, or do you have to look at the condition to know?
Who knows an answer? :-)
:) It depends on how the conditional is constructed.
If you use get_condition the edge taken when conditional is true is
always BRANCH_EDGE if some exists (it is possible to have conditional
jump to the following instruction where you have only one edge with
EDGE_FALLTHRU flag).
Otherwise you have to look into conditional jump RTL yourself to figure
out if it has form
(set (pc) (if_then_else (cond) (pc) (label_ref xxx))
or
(set (pc) (if_then_else (cond) (label_ref xxx) (pc))
In the first case we are taking barnch edge when conditional is false.
It seems there are two approaches to solving this problem, constructive
and preservative. According to danny, the constructive approach is
what is used in the rtl level if-conversion and is dead slow. In the
preservative approach, you keep the markings that are inserted from the
tree code and track their changes as the rtl gets modified. This
assumes that we do not throw away the cfg right before rtl generation,
which may be a big assumption or at least you add notes in the rtl that
preserves this information for later reconstruction.
I have to admit that I am always a fan of preserving information rather
than reconstructing it. This need to just keep rescanning the
intermediate representation over and over again is a big flaw in gcc and
contributes adversely to the performance.
kenny
Honza
Gr.
Steven
Re: Can't build gcc cvs trunk 20050409 gnat tools on sparc-linux: tree check: accessed operand 2 of view_convert_expr with 1 operands in visit_assignment, at tree-ssa-ccp.c:1074
Christian Joensson <[EMAIL PROTECTED]> writes: > +===GNAT BUG DETECTED==+ > | 4.1.0 20050409 (experimental) (sparc-unknown-linux-gnu) GCC error: | > | tree check: accessed operand 2 of view_convert_expr with 1 operands | > |in visit_assignment, at tree-ssa-ccp.c:1074 | That appears to be a long standing bug introduced by this patch: 2004-11-28 Richard Kenner <[EMAIL PROTECTED]> PR/18664 * tree-ssa-operands.c (build_ssa_operands, case MODIFY_EXPR): Ignore a VIEW_CONVERT_EXPR on LHS when deciding if must or may def. * tree-ssa-ccp.c (visit_assignment): If LHS is a VIEW_CONVERT_EXPR, add an inverse VIEW_CONVERT_EXPR to const_val. It contains this line: orig_lhs = TREE_OPERAND (orig_lhs, 1); But orig_lhs is a VIEW_CONVERT_EXPR which has only one operand. It's not clear whether this patch is actually connected to PR18664 at all. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: GCC 4.0 Freeze
On Saturday 09 April 2005 9:02 am, Mark Mitchell wrote: > Please treat the GCC 4.0 branch as frozen as of this time. All > non-documentation changes now need my explicit approval. I've reported a bug on gcc-help list, but nooone seem to be interested in. That's really sad, because I rely on this thing I reported as a `potential` bug :((( Regards, Christian Parpart. -- Netiquette: http://www.ietf.org/rfc/rfc1855.txt 16:26:43 up 17 days, 5:33, 0 users, load average: 0.49, 0.56, 0.53 pgpJGPbJMfCBe.pgp Description: PGP signature
Re: Can't build gcc cvs trunk 20050409 gnat tools on sparc-linux: tree check: accessed operand 2 of view_convert_expr with 1 operands in visit_assignment, at tree-ssa-ccp.c:1074
It contains this line: orig_lhs = TREE_OPERAND (orig_lhs, 1); But orig_lhs is a VIEW_CONVERT_EXPR which has only one operand. That's certainly a typo. But I recall that that code has to go anyway.
Re: GCC 4.0 Freeze
On Sat, Apr 09, 2005 at 04:27:52PM +0200, Christian Parpart wrote: > I've reported a bug on gcc-help list, but nooone seem to be interested in. > Bugs ought to be reported at http://gcc.gnu.org/bugzilla. Diego.
Re: GCC 4.0 Ada Status Report (2005-04-09)
On Sat, Apr 09, 2005 at 12:18:09PM +0200, Laurent GUERBY wrote: > Unfortunately this is a real core dump while running the test on my > machine (glibc-2.3.3-118 SuSE 9.2) at -O2 or -O0, and this does not > reproduce under GDB, see below. I don't know about valgrind on x86_64, > is it available? Nope. Your best bet would be to turn up ulimit -c and look at a core dump. -- Daniel Jacobowitz CodeSourcery, LLC
Re: GCC 4.0 Freeze
On Saturday 09 April 2005 4:42 pm, Diego Novillo wrote: > On Sat, Apr 09, 2005 at 04:27:52PM +0200, Christian Parpart wrote: > > I've reported a bug on gcc-help list, but nooone seem to be interested > > in. > > Bugs ought to be reported at http://gcc.gnu.org/bugzilla. I was asking a bit shy on the other list, because I wasn't that sure that this is *really* a bug. that's why I was first asking on the list right before pushing on bugzilla. However, noone ever replied (except myself). Christian Parpart. -- Netiquette: http://www.ietf.org/rfc/rfc1855.txt 16:52:12 up 17 days, 5:58, 1 user, load average: 0.89, 0.53, 0.46 pgpcr3Gl0bcxa.pgp Description: PGP signature
[Ada] PR18847 Ada.Numerics.xx_Random.Value does not handle junk strings
Ok the bug is trivial once I peek into the core dump:
(gdb) f 0
#0 0x004212e5 in cxa5012__test_block__discrete_pack__value.779
() at a-nudira.adb:237
237 while Coded_State (Stop) /= ',' loop
(gdb) l
232 Start : Positive := Coded_State'First;
233 Stop : Positive := Coded_State'First;
234 Outs : State;
235
236begin
237 while Coded_State (Stop) /= ',' loop
238 Stop := Stop + 1;
239 end loop;
240
241 Outs.X1 := Int'Value (Coded_State (Start .. Stop - 1));
The tests explicitely pass a junk string to
Ada.Numerics.Discrete_Random.Value and the loop above just goes until
something bad happens if it doesn't find a ',' soon enough.
The Ada RM says:
<<
A.5.2 Random Number Generation
[...]
Bounded (Run-Time) Errors
40.1/1 {8652/0050} {It is a bounded error to invoke Value with a string that
is not the image of any generator state.
{Program_Error (raised by failure of run-time check)}
{Constraint_Error (raised by failure of run-time check)} If the error is
detected, Constraint_Error or Program_Error is raised. Otherwise, a call to
Reset with the resulting state will produce a generator such that calls to
Random with this generator will produce a sequence of values of the
appropriate subtype, but which might not be random in character. That is, the
sequence of values might not fulfill the implementation requirements of this
subclause.}
>>
I will submit a patch that raises Constraint_Error in corner cases of
this function for both a-nudira.adb and a-nuflra.adb (which has the same
bug). Robert I assume this what we want?
Obviously low priority, this can wait after 4.0.0.
Laurent
On Sat, 2005-04-09 at 10:51 -0400, Daniel Jacobowitz wrote:
> On Sat, Apr 09, 2005 at 12:18:09PM +0200, Laurent GUERBY wrote:
> > Unfortunately this is a real core dump while running the test on my
> > machine (glibc-2.3.3-118 SuSE 9.2) at -O2 or -O0, and this does not
> > reproduce under GDB, see below. I don't know about valgrind on x86_64,
> > is it available?
>
> Nope. Your best bet would be to turn up ulimit -c and look at a core
> dump.
>
Re: Inline round for IA64
On Thu, Apr 07, 2005 at 08:08:15AM -0400, Geert Bosch wrote: > These issues can be fixed by not adding/subtracting 0.5, but Pred (0.5). An interesting idea. Usually I see libraries switch to chopped rounding instead, which also avoids the problem described. r~
Re: Q: C++ FE emitting assignments to global read-only symbols?
> Richard Kenner wrote: >>It would be good to have a way to mark things as "write once, then >>readonly" IMO. It's very common, and you can do some of the same >>optimizations on such things that you can do on true Readonly objects. > > We used to do this in RTL and it caused all sorts of problems. > > One is that supposed you have such a variable in a function and then > you inline the function into a loop. Now all of a sudden, it's written > more than once. Wouldn't the ability to differentiate between the following be a good thing: - constant variables (which need to be dynamically allocated & initialized) vs. - static constants (which don't need to be dynamically allocated/initialized themselves, but may be accessed to initialize non-static constants or variables, representing compile time defined static data.) (As it would certainly be necessary if a target needed to treat their accesses differently based on how/where their values were stored. And would correspondingly be necessary to preserve the ability to differentiate any indirect references to them as may be specified, passed, or returned as arguments from function calls.)
Re: [Ada] PR18847 Ada.Numerics.xx_Random.Value does not handle junk strings
Ok the bug is trivial once I peek into the core dump: No, you're missing it, I think. When you're in GDB, what it does is raises an explicit constraint error due to Int'Value, which is what's expected. However, for some reason when not under GDB, the handling of the exception causes some SIGSEGV.
Re: [Ada] PR18847 Ada.Numerics.xx_Random.Value does not handle junk strings
On Sat, 2005-04-09 at 13:22 -0400, Richard Kenner wrote: > Ok the bug is trivial once I peek into the core dump: > > No, you're missing it, I think. When you're in GDB, what it does is > raises an explicit constraint error due to Int'Value, which is what's > expected. However, for some reason when not under GDB, the handling > of the exception causes some SIGSEGV. The line shown in GDB is before the Int'Value. But you're partially right in the case of Discrete_Random since it is generic, checks are on, and an exception should happen on the first loop when Stop reaches Coded_State'Last+1 (a-nudira.adb:237) and may be mishandled but I'm unable to find trace of that with gdb on the core (I don't much about GDB possibilities on a core file). For Float_Random, it's not generic and so compiled with checks off in the RTS, and the code has a latent buffer overflow bug. Laurent
GCC 4.0 Ada Status Report (2005-04-09)
Laurent GUERBY writes: > Hi, fromm gcc-testresults here is where we stand on 4.0/Ada after > the tree-sra Ada patch. I'm looking for results for platforms where I > believe Ada could work: > > powerpc-linux http://gcc.gnu.org/ml/gcc-testresults/2005-03/msg01875.html
Re: GCC 4.0 Ada Status Report (2005-04-09)
Thanks, Andreas Jaeger just sent a more recent run: http://gcc.gnu.org/ml/gcc-testresults/2005-04/msg00631.html === acats Summary === # of expected passes2320 # of unexpected failures0 Native configuration is powerpc64-suse-linux-gnu Just perfect :) Laurent On Sat, 2005-04-09 at 21:39 +0200, Matthias Klose wrote: > Laurent GUERBY writes: > > Hi, fromm gcc-testresults here is where we stand on 4.0/Ada after > > the tree-sra Ada patch. I'm looking for results for platforms where I > > believe Ada could work: > > > > powerpc-linux > > http://gcc.gnu.org/ml/gcc-testresults/2005-03/msg01875.html >
Re: GCC 4.0 Ada Status Report (2005-04-09)
> http://gcc.gnu.org/ml/gcc-testresults/2005-03/msg01875.html A bit outdated. Most of them should be gone as of today. -- Eric Botcazou
Re: Major bootstrap time regression on March 30
On Thu, 2005-04-07 at 17:57 -0700, James E Wilson wrote: > On Thu, 2005-04-07 at 17:34, Diego Novillo wrote: > > Another thing, has our library code base (libjava, libstdc++) > > grown significantly lately? > > I was doing full builds, except for Ada. I should have mentioned that. > Ada doesn't get configured by default, and I haven't bothered to check > why. I probably forgot to install the Ada compiler package. Even if you installed the Ada compiler package you still would have to add ada to the configure line to build it. This decision was taken a while ago, I guess to be revisited at some point (main problem were hanging Ada tests, but some patches were proposed for this issue). > So I think this is a possibility only if the Ada library got suddenly > bigger and slower to compile, and if you are including Ada in your > builds. I bootstrap c,ada, make check, make install and I've seen no change on head in the past few weeks, it's around 1h36 on my Athlon 64 3000+. === GCCBOOT start === 2005-03-24 08:47:35 === GCCBOOT done === 2005-03-24 10:23:34 === GCCBOOT start === 2005-03-29 19:22:52 === GCCBOOT done === 2005-03-29 20:59:06 === GCCBOOT start === 2005-04-01 23:33:44 === GCCBOOT done === 2005-04-02 01:10:50 === GCCBOOT start === 2005-04-03 21:49:12 === GCCBOOT done === 2005-04-03 23:25:48 Laurent
Re: Can't build gcc cvs trunk 20050409 gnat tools on sparc-linux: tree check: accessed operand 2 of view_convert_expr with 1 operands in visit_assignment, at tree-ssa-ccp.c:1074
On Sat, 2005-04-09 at 10:28 -0400, Richard Kenner wrote: > It contains this line: > > orig_lhs = TREE_OPERAND (orig_lhs, 1); > > But orig_lhs is a VIEW_CONVERT_EXPR which has only one operand. > > That's certainly a typo. But I recall that that code has to go anyway. I'm seeing the failure on x86-linux too: stage1/xgcc -Bstage1/ -B/home/guerby/work/gcc/install/install-20050410T003153/i686-pc-linux-gnu/bin/ -c -O2 -g -fomit-frame-pointer -gnatpg -gnata -I--I. -Iada -I/home/guerby/work/gcc/version-head/gcc/ada /home/guerby/work/gcc/version-head/gcc/ada/errout.adb -o ada/errout.o +===GNAT BUG DETECTED==+ | 4.1.0 20050409 (experimental) (i686-pc-linux-gnu) GCC error: | | tree check: accessed operand 2 of view_convert_expr with 1 operands | |in visit_assignment, at tree-ssa-ccp.c:1074 | | Error detected at errout.adb:2563:1 | Should I replace ",1" by ",0" or is something more ambitious needed? Laurent
Re: Can't build gcc cvs trunk 20050409 gnat tools on sparc-linux: tree check: accessed operand 2 of view_convert_expr with 1 operands in visit_assignment, at tree-ssa-ccp.c:1074
Laurent GUERBY <[EMAIL PROTECTED]> writes: > Should I replace ",1" by ",0" or is something more ambitious needed? I tried that on ia64, and the result was a miscompiled stage2 compiler. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
gcc-4.0-20050409 is now available
Snapshot gcc-4.0-20050409 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.0-20050409/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.0 CVS branch with the following options: -rgcc-ss-4_0-20050409 You'll find: gcc-4.0-20050409.tar.bz2 Complete GCC (includes all of below) gcc-core-4.0-20050409.tar.bz2 C front end and core compiler gcc-ada-4.0-20050409.tar.bz2 Ada front end and runtime gcc-fortran-4.0-20050409.tar.bz2 Fortran front end and runtime gcc-g++-4.0-20050409.tar.bz2 C++ front end and runtime gcc-java-4.0-20050409.tar.bz2 Java front end and runtime gcc-objc-4.0-20050409.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.0-20050409.tar.bz2The GCC testsuite Diffs from 4.0-20050402 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.0 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: Semi-Latent Bug in tree vectorizer
On Fri, Apr 08, 2005 at 10:52:02AM -0600, Jeffrey A Law wrote:
> When we vectorize the store we copy the virtual operands from the
> original statement to the new vectorized statement via this code:
>
> /* Copy the V_MAY_DEFS representing the aliasing of the original array
> element's definition to the vector's definition then update the
> defining statement. The original is being deleted so the same
> SSA_NAMEs can be used. */
> copy_virtual_operands (*vec_stmt, stmt);
> v_may_defs = STMT_V_MAY_DEF_OPS (*vec_stmt);
> nv_may_defs = NUM_V_MAY_DEFS (v_may_defs);
>
> for (i = 0; i < nv_may_defs; i++)
> {
> tree ssa_name = V_MAY_DEF_RESULT (v_may_defs, i);
> SSA_NAME_DEF_STMT (ssa_name) = *vec_stmt;
> }
>
> This is safe if and only if the the operand scanning code will compute
> the same V_MAY_DEFS for the original scalar statement and the new
> vectorized statement. ie, *D.1470 must have the same aliasing
> properties as *vect_px.17.
>
Right. Both the vectorizer and ivopts have the side-effect of
refining aliasing information. Therefore, blindly copying
virtual operands is not correct.
Could you try this patch? It fixes your test case and doesn't
produce new regressions in the vectorizer tests. It's not
bootstrapped nor tested otherwise.
The idea is that we should treat both the vectorized statement
and the old statement separately. The virtual defs from the old
statement are going away and the new one is getting brand new
symbols exposed. That's why we mark them separately.
Thanks. Diego.
Index: tree-vect-transform.c
===
RCS file: /cvs/gcc/gcc/gcc/tree-vect-transform.c,v
retrieving revision 2.10
diff -d -u -p -r2.10 tree-vect-transform.c
--- tree-vect-transform.c 9 Apr 2005 01:37:27 - 2.10
+++ tree-vect-transform.c 10 Apr 2005 03:20:33 -
@@ -855,8 +855,8 @@ vectorizable_store (tree stmt, block_stm
enum machine_mode vec_mode;
tree dummy;
enum dr_alignment_support alignment_support_cheme;
- v_may_def_optype v_may_defs;
- int nv_may_defs, i;
+ ssa_op_iter iter;
+ tree def;
/* Is vectorizable store? */
@@ -918,15 +918,14 @@ vectorizable_store (tree stmt, block_stm
element's definition to the vector's definition then update the
defining statement. The original is being deleted so the same
SSA_NAMEs can be used. */
- copy_virtual_operands (*vec_stmt, stmt);
- v_may_defs = STMT_V_MAY_DEF_OPS (*vec_stmt);
- nv_may_defs = NUM_V_MAY_DEFS (v_may_defs);
+ mark_new_vars_to_rename (*vec_stmt);
- for (i = 0; i < nv_may_defs; i++)
-{
- tree ssa_name = V_MAY_DEF_RESULT (v_may_defs, i);
- SSA_NAME_DEF_STMT (ssa_name) = *vec_stmt;
-}
+ /* The new vectorized statement will have better aliasing
+ information, so some of the virtual definitions of the old
+ statement will likely disappear from the IL. Mark them to have
+ their SSA form updated. */
+ FOR_EACH_SSA_TREE_OPERAND (def, stmt, iter, SSA_OP_VMAYDEF)
+mark_sym_for_renaming (SSA_NAME_VAR (def));
return true;
}
Index: testsuite/gcc.dg/vect/20050409-1.c
=======
RCS file: testsuite/gcc.dg/vect/20050409-1.c
diff -N testsuite/gcc.dg/vect/20050409-1.c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ testsuite/gcc.dg/vect/20050409-1.c 10 Apr 2005 03:20:35 -
@@ -0,0 +1,24 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target vect_float } */
+
+typedef char achar __attribute__ ((__aligned__(16)));
+int main1 ()
+{
+ struct {
+achar *p;
+achar *q;
+ } s;
+ int i;
+ achar x[16];
+ achar cb[16];
+ s.p = x;
+ i = 0;
+ do
+{
+ s.p[i] = cb[i];
+ i++;
+} while (i < 16);
+
+ if (s.p[0])
+abort ();
+}
Re: Can't build gcc cvs trunk 20050409 gnat tools on sparc-linux: tree check: accessed operand 2 of view_convert_expr with 1 operands in visit_assignment, at tree-ssa-ccp.c:1074
Laurent GUERBY <[EMAIL PROTECTED]> writes: > On Sat, 2005-04-09 at 10:28 -0400, Richard Kenner wrote: >> It contains this line: >> >> orig_lhs = TREE_OPERAND (orig_lhs, 1); >> >> But orig_lhs is a VIEW_CONVERT_EXPR which has only one operand. >> >> That's certainly a typo. But I recall that that code has to go anyway. > > I'm seeing the failure on x86-linux too: > > stage1/xgcc -Bstage1/ > -B/home/guerby/work/gcc/install/install-20050410T003153/i686-pc-linux-gnu/bin/ > -c -O2 -g -fomit-frame-pointer -gnatpg -gnata -I--I. -Iada > -I/home/guerby/work/gcc/version-head/gcc/ada > /home/guerby/work/gcc/version-head/gcc/ada/errout.adb -o ada/errout.o > +===GNAT BUG DETECTED==+ > | 4.1.0 20050409 (experimental) (i686-pc-linux-gnu) GCC error: | > | tree check: accessed operand 2 of view_convert_expr with 1 operands | > |in visit_assignment, at tree-ssa-ccp.c:1074 | > | Error detected at errout.adb:2563:1 | And on x86_64-linux-gnu I see now: stage1/xgcc -Bstage1/ -B/opt/gcc/4.1-devel/x86_64-suse-linux-gnu/bin/ -c -g -O2 -gnatpg -gnata -I- -I. -Iada -I/cvs/gcc/gcc/ada /cvs/gcc/gcc/ada/ada.ads -o ada/ada.o +===GNAT BUG DETECTED==+ | 4.1.0 20050409 (experimental) (x86_64-suse-linux-gnu) Segmentation fault | | Error detected at ada.ads:17:1 | | Please submit a bug report; see http://gcc.gnu.org/bugs.html.| | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact gcc or gnatmake command that you entered. | | Also include sources listed below in gnatchop format | | (concatenated together with no headers between files). | +==+ Andreas -- Andreas Jaeger, [EMAIL PROTECTED], http://www.suse.de/~aj SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 pgpJiRuPFgxJV.pgp Description: PGP signature
