Re: [cond-optab] svn branch created, looking for reviews for the "cleanup" parts
> Paolo, > > bootstrap finished OK on alpha, regression test results are at [1]. > There are unrelated errors with "random" libc++ tests and HJ's PR39323 > testcase. Do not mind the timeouts. Great -- my testsuite comparison also finished with not a single difference, which is good. Paolo
Re: [RFC] Get rid of awkward semantics for subtypes
> I wonder what this exception in VRP looks like? I wasn't specifically referring to an exception in VRP. I think that, when checks are off, it would be sufficient for gigi to emit sort of assertions for arguments on function entry (like your VRP patch did) and for return values on function calls; VRP would then just propagate them. Could ASSERT_EXPR be used for this purpose, i.e. could it be made a first class GENERIC (or GIMPLE) expression that front-ends could emit (during gimplification)? > I also wonder if adding a test to the gimplifier that all integral typed > DECL types have NULL TREE_TYPE and TYPE_MIN/MAX_VALUE according to their > TYPE_PRECISION would pass with your changes (there may be such odd cases > with other frontends ...). Note that the changes don't eliminate subtypes (gigi generates the same GENERIC code), their actual bounds are only made private to gigi and their visible bounds set to that of the base type; IOW there is no lowering pass, except for the gimplification that will remove unnecessary casts. I think that the invariant should be that all integral types that appear in the code (types for declarations and expressions) have maximal bounds for their precision; "range" types should only be descriptive. -- Eric Botcazou
Re: The gcc-in-cxx branch now completes bootstrap
Curious. I ran both g++ variants in oprofile, and then compared the generated assembler code for the most critical functions. The top 1 function in both cases is pointer_set_insert, and there the assembler code is 100% identical (module one choice between r14 and r15). The second most critical function in the gcc-in-cxx build is walk_tree_1, which is only place 4 in mainline gcc. There the code seems to be identical, too, except for code layout: The compiler arranges the code in a different order, and apparently has different a different branch prediction. The non-branching code is nearly identical, too. The "hottest" assembler instructions in walk_tree_1 are memory accesses, apparently the mainline version causes slightly less cache misses or better prediction? (my interpretation, not measured yet) I am a bit unsure how to proceed. The gcc-in-cxx assembler code looks ok, as it is nearly identical to the mainline code. The main differences are in the code/branch layout, and I wouldn't know how to debug this. Thomas
Re: [RFC] Get rid of awkward semantics for subtypes
On Sun, Apr 12, 2009 at 9:37 AM, Eric Botcazou wrote: >> I wonder what this exception in VRP looks like? > > I wasn't specifically referring to an exception in VRP. I think that, when > checks are off, it would be sufficient for gigi to emit sort of assertions > for arguments on function entry (like your VRP patch did) and for return > values on function calls; VRP would then just propagate them. > > Could ASSERT_EXPR be used for this purpose, i.e. could it be made a first > class GENERIC (or GIMPLE) expression that front-ends could emit (during > gimplification)? Yes, we could do that. Though a simpler form may be preferable, like directly specifying a constant range/anti-range instead of encoding these in (multiple) ASSERT_EXPRs. I will think of something. As for Ada - both function entry and exit constraints will be checked by the caller/callee, correct? So that once you inline VRP should be able to derive the ranges from existing checks? Thus - a IPA VRP pass should be able to verify these properties across functions? >> I also wonder if adding a test to the gimplifier that all integral typed >> DECL types have NULL TREE_TYPE and TYPE_MIN/MAX_VALUE according to their >> TYPE_PRECISION would pass with your changes (there may be such odd cases >> with other frontends ...). > > Note that the changes don't eliminate subtypes (gigi generates the same > GENERIC code), their actual bounds are only made private to gigi and their > visible bounds set to that of the base type; IOW there is no lowering pass, > except for the gimplification that will remove unnecessary casts. > > I think that the invariant should be that all integral types that appear in > the code (types for declarations and expressions) have maximal bounds for > their precision; "range" types should only be descriptive. Yes, I agree. I volunteer to prepare a verification pass that asserts this property during gimplification. Thanks, Richard.
Re: The gcc-in-cxx branch now completes bootstrap
On Sun, Apr 12, 2009 at 9:56 AM, Thomas Neumann wrote: > Curious. I ran both g++ variants in oprofile, and then compared the > generated assembler code for the most critical functions. > > The top 1 function in both cases is pointer_set_insert, and there the > assembler code is 100% identical (module one choice between r14 and r15). > > The second most critical function in the gcc-in-cxx build is walk_tree_1, > which is only place 4 in mainline gcc. > There the code seems to be identical, too, except for code layout: The > compiler arranges the code in a different order, and apparently has > different a different branch prediction. The non-branching code is nearly > identical, too. > The "hottest" assembler instructions in walk_tree_1 are memory accesses, > apparently the mainline version causes slightly less cache misses or better > prediction? (my interpretation, not measured yet) > > I am a bit unsure how to proceed. The gcc-in-cxx assembler code looks ok, as > it is nearly identical to the mainline code. The main differences are in the > code/branch layout, and I wouldn't know how to debug this. I suggest to compare against trunk at the latest merge point for gcc-in-cxx (which was likely before the alias-improvements branch merge which brought quite some changes in the tree verifiers and improved compile-time overall). Or just ask Ian to merge again from trunk ... Richard. > Thomas > > > >
Re: [gnat] reuse of ASTs already constructed
Picking up an old thread, http://gcc.gnu.org/ml/gcc/2003-03/msg00281.html On Tue, 4 Mar 2003, Geert Bosch wrote: > [...] > Best would be to first post a design overview, > before doing a lot of work in order to prevent spending time > on implementing something that may turn out to have fundamental > problems. I've done a little experimenting to get a feel for this. I've looked at the work done toward the GCC compile server but decided that I want to concentrate on GNAT trees (whereas the compile server targets the GNU trees.) Also I am aiming somewhat lower - not making a separate compile server process but rather extending gnat1 to handle multiple files in a single invocation. The current GNAT code makes a strong assumption that there be only one main unit, and this Main_Unit be located at index 0 of Lib.Units.Table (see procedure Lib.Load.Load_Main_Source). I am currently looking at having each main unit supplied on the gnat1 command line overwrite the Main_Unit in the Units table. What do you think of this approach? The attached patch sets the stage for passing multiple source files to a single gnat1 invocation. (Beware, this is a rough cut. Best use "svn diff --diff-cmd diff -x -uw" after applying as there are many changes that only affect indentation.) Thanks, Oliver gnat1_multi_source_compile-0.diff.gz Description: GNU Zip compressed data
Re: cleanup tests failing on MIPS64
The same tests now fail on hppa. This is PR 39651. I'm fairly certain this was introduced by the following change: 2009-03-28 Jan Hubicka Merge from pretty-ipa: 2009-03-27 Jan Hubicka * cgraph.c (dump_cgraph_node): Add replace output flag by process. ... On Sat, 11 Apr 2009, Adam Nemet wrote: > Adam Nemet writes: > > For two testresults now the cleanup tests are failing in both gcc and g++: > > > > http://gcc.gnu.org/ml/gcc-testresults/2009-04/msg01031.html > > http://gcc.gnu.org/ml/gcc-testresults/2009-04/msg00592.html > > > > I waited for another testresults because there were some bug fixes in this > > area after the eh changes. > > > > Does somebody know what's going on? I'll look at it otherwise. > > I am not exactly sure what has exposed this but the bug seems to be old. > can_throw_external in except.c does not look at the branch delay slot (second > entry in a SEQUENCE) to determine whether the insn may throw or not. > > In gcc.dg/cleanup-8.c for example after inlining fn3, the trapping store is > moved to the delay slot of abort, which is a nothrow function so we decide > that fn2 can't throw and then ultimately remove the eh region around fn1 in > fn0. The same could occur on hppa. Dave -- J. David Anglin dave.ang...@nrc-cnrc.gc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6602)
Re: cleanup tests failing on MIPS64
John David Anglin writes: > The same tests now fail on hppa. This is PR 39651. I'm fairly certain > this was introduced by the following change: I put this PR in the checkin that was just approved on gcc-patc...@. Please close the bug if it fixes the failures on hppa too. Adam
Re: [RFC] Get rid of awkward semantics for subtypes
> Yes, we could do that. Though a simpler form may be preferable, like > directly specifying a constant range/anti-range instead of encoding these > in (multiple) ASSERT_EXPRs. > > I will think of something. Thanks. > As for Ada - both function entry and exit constraints will be checked by > the caller/callee, correct? So that once you inline VRP should be able > to derive the ranges from existing checks? Thus - a IPA VRP pass should > be able to verify these properties across functions? No, the model used by GNAT is "lazy" validity checks: the various validity checks are emitted just before uses of the value that are deemed sufficiently dangerous, as controlled by -gnatVx. Parameter and return values are not checked, unless explicitly requested. VRP should be able to derive ranges when checks are present, but we would also need to be able to force ranges at will when checks are not present. -- Eric Botcazou
gcc-4.3-20090412 is now available
Snapshot gcc-4.3-20090412 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20090412/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.3 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_3-branch revision 145989 You'll find: gcc-4.3-20090412.tar.bz2 Complete GCC (includes all of below) gcc-core-4.3-20090412.tar.bz2 C front end and core compiler gcc-ada-4.3-20090412.tar.bz2 Ada front end and runtime gcc-fortran-4.3-20090412.tar.bz2 Fortran front end and runtime gcc-g++-4.3-20090412.tar.bz2 C++ front end and runtime gcc-java-4.3-20090412.tar.bz2 Java front end and runtime gcc-objc-4.3-20090412.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.3-20090412.tar.bz2The GCC testsuite Diffs from 4.3-20090405 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.3 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.
