gcc 4.0.1 testsuite failures on sparc64-linux: 22 unexpected g++ failures
(See also thread on unexpected gcc errors) This is on Aurora SPARC Linux release 2.0 (Kashmir FC3) UltraSparc I (SpitFire) 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.sparcv9 glibc-2.3.3-99.sparc64 glibc-devel-2.3.3-99.sparc glibc-devel-2.3.3-99.sparc64 glibc-headers-2.3.3-99.sparc64 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.sparc libstdc++-3.4.2-6.fc3.sparc64 libstdc++-devel-3.4.2-6.fc3.sparc libstdc++-devel-3.4.2-6.fc3.sparc64 make-3.80-5.sparc nptl-devel-2.3.3-99.sparcv9 tcl-8.4.7-2.sparc LAST_UPDATED: Obtained from CVS: -rgcc_4_0_1_release Native configuration is sparc64-unknown-linux-gnu Setting LD_LIBRARY_PATH to .:/usr/local/src/branch/objdir64/sparc64-linux/./libstdc++-v3/src/.libs:/usr/local/src/branch/objdir64/gcc:.:/usr/local/src/branch/objdir64/sparc64-linux/./libstdc++-v3/src/.libs:/usr/local/src/branch/objdir64/gcc:/usr/local/src/branch/objdir64/gcc /usr/local/src/branch/objdir64/gcc/testsuite/g++-bprob-1.x01: symbol lookup error: /usr/local/src/branch/objdir64/gcc/testsuite/g++-bprob-1.x01: undefined symbol: FAIL: g++.dg/bprob/g++-bprob-1.C execution,-g -fprofile-arcs Setting LD_LIBRARY_PATH to .:/usr/local/src/branch/objdir64/sparc64-linux/./libstdc++-v3/src/.libs:/usr/local/src/branch/objdir64/gcc:.:/usr/local/src/branch/objdir64/sparc64-linux/./libstdc++-v3/src/.libs:/usr/local/src/branch/objdir64/gcc:/usr/local/src/branch/objdir64/gcc /usr/local/src/branch/objdir64/gcc/testsuite/g++-bprob-1.x11: symbol lookup error: /usr/local/src/branch/objdir64/gcc/testsuite/g++-bprob-1.x11: undefined symbol: FAIL: g++.dg/bprob/g++-bprob-1.C execution,-O0 -fprofile-arcs Setting LD_LIBRARY_PATH to .:/usr/local/src/branch/objdir64/sparc64-linux/./libstdc++-v3/src/.libs:/usr/local/src/branch/objdir64/gcc:.:/usr/local/src/branch/objdir64/sparc64-linux/./libstdc++-v3/src/.libs:/usr/local/src/branch/objdir64/gcc:/usr/local/src/branch/objdir64/gcc /usr/local/src/branch/objdir64/gcc/testsuite/g++-bprob-1.x11: symbol lookup error: /usr/local/src/branch/objdir64/gcc/testsuite/g++-bprob-1.x11: undefined symbol: FAIL: g++.dg/bprob/g++-bprob-1.C execution,-O0 -fprofile-arcs Setting LD_LIBRARY_PATH to .:/usr/local/src/branch/objdir64/sparc64-linux/./libstdc++-v3/src/.libs:/usr/local/src/branch/objdir64/gcc:.:/usr/local/src/branch/objdir64/sparc64-linux/./libstdc++-v3/src/.libs:/usr/local/src/branch/objdir64/gcc:/usr/local/src/branch/objdir64/gcc /usr/local/src/branch/objdir64/gcc/testsuite/g++-bprob-1.x21: symbol lookup error: /usr/local/src/branch/objdir64/gcc/testsuite/g++-bprob-1.x21: undefined symbol: FAIL: g++.dg/bprob/g++-bprob-1.C execution,-O1 -fprofile-arcs Setting LD_LIBRARY_PATH to .:/usr/local/src/branch/objdir64/sparc64-linux/./libstdc++-v3/src/.libs:/usr/local/src/branch/objdir64/gcc:.:/usr/local/src/branch/objdir64/sparc64-linux/./libstdc++-v3/src/.libs:/usr/local/src/branch/objdir64/gcc:/usr/local/src/branch/objdir64/gcc /usr/local/src/branch/objdir64/gcc/testsuite/g++-bprob-1.x31: symbol lookup error: /usr/local/src/branch/objdir64/gcc/testsuite/g++-bprob-1.x31: undefined symbol: FAIL: g++.dg/bprob/g++-bprob-1.C execution,-O2 -fprofile-arcs Setting LD_LIBRARY_PATH to .:/usr/local/src/branch/objdir64/sparc64-linux/./libstdc++-v3/src/.libs:/usr/local/src/branch/objdir64/gcc:.:/usr/local/src/branch/objdir64/sparc64-linux/./libstdc++-v3/src/.libs:/usr/local/src/branch/objdir64/gcc:/usr/local/src/branch/objdir64/gcc /usr/local/src/branch/objdir64/gcc/testsuite/g++-bprob-1.x41: symbol lookup error: /usr/local/src/branch/objdir64/gcc/testsuite/g++-bprob-1.x41: undefined symbol: FAIL: g++.dg/bprob/g++-bprob-1.C execution,-O3 -fprofile-arcs Setting LD_LIBRARY_PATH to .:/usr/local/src/branch/objdir64/sparc64-linux/./libstdc++-v3/src/.libs:/usr/local/src/branch/objdir64/gcc:.:/usr/local/src/branch/objdir64/sparc64-linux/./libstdc++-v3/src/.libs:/usr/local/src/branch/objdir64/gcc:/usr/local/src/branch/objdir64/gcc /usr/local/src/branch/objdir64/gcc/testsuite/g++-bprob-1.x51: symbol lookup error: /usr/local/src/branch/objdir64/gcc/testsuite/g++-bprob-1.x51: undefined symbol: FAIL: g++.dg/bprob/g++-bprob-1.C execution,-O3 -g -fprofile-arcs Setting LD_LIBRARY_PATH to .:/usr/local/src/branch/objdir64/sparc64-linux/./libstdc++-v3/src/.libs:/usr/local/src/branch/objdir64/gcc:.:/usr/local/src/branch/objdir64/sparc64-linux/./libstdc++-v3/src/.libs:/usr/local/src/branch/objdir64/gcc:/usr/local/src/branch/objdir64/gcc /usr/local/src/branch/objdir64/gcc/testsuite/g++-bprob-1.x61: symbol lookup error: /usr/local/src/branch/objdir64/gcc/testsuite/g++-bprob-1.x61: undefined symbol:
Re: gcc 4.0.1 testsuite failures on sparc64-linux: 59 unexpected gcc failures
> FAIL: gcc.misc-tests/bprob-1.c execution,-g -fprofile-arcs > UNRESOLVED: gcc.misc-tests/bprob-1.c compilation, -g > -fbranch-probabilities UNRESOLVED: gcc.misc-tests/bprob-1.c execution, > -g -fbranch-probabilities FAIL: gcc.misc-tests/bprob-1.c execution,-O0 > -fprofile-arcs > UNRESOLVED: gcc.misc-tests/bprob-1.c compilation, -O0 > -fbranch-probabilities UNRESOLVED: gcc.misc-tests/bprob-1.c execution, > -O0 -fbranch-probabilities FAIL: gcc.misc-tests/bprob-1.c execution, > -O1 -fprofile-arcs > UNRESOLVED: gcc.misc-tests/bprob-1.c compilation, -O1 > -fbranch-probabilities UNRESOLVED: gcc.misc-tests/bprob-1.c execution, > -O1 -fbranch-probabilities FAIL: gcc.misc-tests/bprob-1.c execution, > -O2 -DPERFTIME -fprofile-arcs UNRESOLVED: gcc.misc-tests/bprob-1.c > compilation, -O2 -DPERFTIME > -fbranch-probabilities > UNRESOLVED: gcc.misc-tests/bprob-1.c execution,-O2 -DPERFTIME > -fbranch-probabilities > FAIL: gcc.misc-tests/bprob-1.c execution,-O3 -DPERFTIME -fprofile-arcs > UNRESOLVED: gcc.misc-tests/bprob-1.c compilation, -O3 -DPERFTIME > -fbranch-probabilities > UNRESOLVED: gcc.misc-tests/bprob-1.c execution,-O3 -DPERFTIME > -fbranch-probabilities > FAIL: gcc.misc-tests/bprob-1.c execution,-O3 -g -DPERFTIME > -fprofile-arcs UNRESOLVED: gcc.misc-tests/bprob-1.c compilation, -O3 -g > -DPERFTIME -fbranch-probabilities > UNRESOLVED: gcc.misc-tests/bprob-1.c execution,-O3 -g -DPERFTIME > -fbranch-probabilities > FAIL: gcc.misc-tests/bprob-1.c execution,-Os -fprofile-arcs > UNRESOLVED: gcc.misc-tests/bprob-1.c compilation, -Os > -fbranch-probabilities UNRESOLVED: gcc.misc-tests/bprob-1.c execution, > -Os -fbranch-probabilities FAIL: gcc.misc-tests/bprob-2.c execution,-g > -fprofile-arcs > UNRESOLVED: gcc.misc-tests/bprob-2.c compilation, -g > -fbranch-probabilities UNRESOLVED: gcc.misc-tests/bprob-2.c execution, > -g -fbranch-probabilities FAIL: gcc.misc-tests/bprob-2.c execution,-O0 > -fprofile-arcs > UNRESOLVED: gcc.misc-tests/bprob-2.c compilation, -O0 > -fbranch-probabilities UNRESOLVED: gcc.misc-tests/bprob-2.c execution, > -O0 -fbranch-probabilities FAIL: gcc.misc-tests/bprob-2.c execution, > -O1 -fprofile-arcs > UNRESOLVED: gcc.misc-tests/bprob-2.c compilation, -O1 > -fbranch-probabilities UNRESOLVED: gcc.misc-tests/bprob-2.c execution, > -O1 -fbranch-probabilities FAIL: gcc.misc-tests/bprob-2.c execution, > -O2 -DPERFTIME -fprofile-arcs UNRESOLVED: gcc.misc-tests/bprob-2.c > compilation, -O2 -DPERFTIME > -fbranch-probabilities > UNRESOLVED: gcc.misc-tests/bprob-2.c execution,-O2 -DPERFTIME > -fbranch-probabilities > FAIL: gcc.misc-tests/bprob-2.c execution,-O3 -DPERFTIME -fprofile-arcs > UNRESOLVED: gcc.misc-tests/bprob-2.c compilation, -O3 -DPERFTIME > -fbranch-probabilities > UNRESOLVED: gcc.misc-tests/bprob-2.c execution,-O3 -DPERFTIME > -fbranch-probabilities > FAIL: gcc.misc-tests/bprob-2.c execution,-O3 -g -DPERFTIME > -fprofile-arcs UNRESOLVED: gcc.misc-tests/bprob-2.c compilation, -O3 -g > -DPERFTIME -fbranch-probabilities > UNRESOLVED: gcc.misc-tests/bprob-2.c execution,-O3 -g -DPERFTIME > -fbranch-probabilities > FAIL: gcc.misc-tests/bprob-2.c execution,-Os -fprofile-arcs > UNRESOLVED: gcc.misc-tests/bprob-2.c compilation, -Os > -fbranch-probabilities UNRESOLVED: gcc.misc-tests/bprob-2.c execution, > -Os -fbranch-probabilities FAIL: gcc.misc-tests/bprob-1.c execution,-g > -ftree-based-profiling -fprofile-arcs > UNRESOLVED: gcc.misc-tests/bprob-1.c compilation, -g > -ftree-based-profiling -fbranch-probabilities > UNRESOLVED: gcc.misc-tests/bprob-1.c execution,-g > -ftree-based-profiling -fbranch-probabilities > FAIL: gcc.misc-tests/bprob-1.c execution,-O0 > -ftree-based-profiling -fprofile-arcs > UNRESOLVED: gcc.misc-tests/bprob-1.c compilation, -O0 > -ftree-based-profiling -fbranch-probabilities > UNRESOLVED: gcc.misc-tests/bprob-1.c execution,-O0 > -ftree-based-profiling -fbranch-probabilities > FAIL: gcc.misc-tests/bprob-1.c execution,-O1 > -ftree-based-profiling -fprofile-arcs > UNRESOLVED: gcc.misc-tests/bprob-1.c compilation, -O1 > -ftree-based-profiling -fbranch-probabilities > UNRESOLVED: gcc.misc-tests/bprob-1.c execution,-O1 > -ftree-based-profiling -fbranch-probabilities > FAIL: gcc.misc-tests/bprob-1.c execution,-O2 -DPERFTIME > -ftree-based-profiling -fprofile-arcs > UNRESOLVED: gcc.misc-tests/bprob-1.c compilation, -O2 -DPERFTIME > -ftree-based-profiling -fbranch-probabilities > UNRESOLVED: gcc.misc-tests/bprob-1.c execution,-O2 -DPERFTIME > -ftree-based-profiling -fbranch-probabilities > FAIL: gcc.misc-tests/bprob-1.c execution,-O3 -DPERFTIME > -ftree-based-profiling -fprofile-arcs > UNRESOLVED: gcc.misc-tests/bprob-1.c compilation, -O3 -DPERFTIME > -ftree-based-profiling -fbranch-probabilities > UNRESOLVED: gcc.misc-tests/bprob-1.c execution,-O3 -DPERFTIME > -ftree-based-profiling -fbranch-pro
Re: gcc 4.0.1 testsuite failures on sparc64-linux: 59 unexpected gcc failures
On 7/12/05, Eric Botcazou <[EMAIL PROTECTED]> wrote: > > FAIL: gcc.misc-tests/bprob-1.c execution,-g -fprofile-arcs > > UNRESOLVED: gcc.misc-tests/bprob-1.c compilation, -g > > -fbranch-probabilities UNRESOLVED: gcc.misc-tests/bprob-1.c execution, > > -g -fbranch-probabilities FAIL: gcc.misc-tests/bprob-1.c execution,-O0 > > -fprofile-arcs > > UNRESOLVED: gcc.misc-tests/bprob-1.c compilation, -O0 > > -fbranch-probabilities UNRESOLVED: gcc.misc-tests/bprob-1.c execution, > > -O0 -fbranch-probabilities FAIL: gcc.misc-tests/bprob-1.c execution, > > -O1 -fprofile-arcs > > UNRESOLVED: gcc.misc-tests/bprob-1.c compilation, -O1 > > -fbranch-probabilities UNRESOLVED: gcc.misc-tests/bprob-1.c execution, > > -O1 -fbranch-probabilities FAIL: gcc.misc-tests/bprob-1.c execution, > > -O2 -DPERFTIME -fprofile-arcs UNRESOLVED: gcc.misc-tests/bprob-1.c > > compilation, -O2 -DPERFTIME > > -fbranch-probabilities > > UNRESOLVED: gcc.misc-tests/bprob-1.c execution,-O2 -DPERFTIME > > -fbranch-probabilities > > FAIL: gcc.misc-tests/bprob-1.c execution,-O3 -DPERFTIME -fprofile-arcs > > UNRESOLVED: gcc.misc-tests/bprob-1.c compilation, -O3 -DPERFTIME > > -fbranch-probabilities > > UNRESOLVED: gcc.misc-tests/bprob-1.c execution,-O3 -DPERFTIME > > -fbranch-probabilities > > FAIL: gcc.misc-tests/bprob-1.c execution,-O3 -g -DPERFTIME > > -fprofile-arcs UNRESOLVED: gcc.misc-tests/bprob-1.c compilation, -O3 -g > > -DPERFTIME -fbranch-probabilities > > UNRESOLVED: gcc.misc-tests/bprob-1.c execution,-O3 -g -DPERFTIME > > -fbranch-probabilities > > FAIL: gcc.misc-tests/bprob-1.c execution,-Os -fprofile-arcs > > UNRESOLVED: gcc.misc-tests/bprob-1.c compilation, -Os > > -fbranch-probabilities UNRESOLVED: gcc.misc-tests/bprob-1.c execution, > > -Os -fbranch-probabilities FAIL: gcc.misc-tests/bprob-2.c execution,-g > > -fprofile-arcs > > UNRESOLVED: gcc.misc-tests/bprob-2.c compilation, -g > > -fbranch-probabilities UNRESOLVED: gcc.misc-tests/bprob-2.c execution, > > -g -fbranch-probabilities FAIL: gcc.misc-tests/bprob-2.c execution,-O0 > > -fprofile-arcs > > UNRESOLVED: gcc.misc-tests/bprob-2.c compilation, -O0 > > -fbranch-probabilities UNRESOLVED: gcc.misc-tests/bprob-2.c execution, > > -O0 -fbranch-probabilities FAIL: gcc.misc-tests/bprob-2.c execution, > > -O1 -fprofile-arcs > > UNRESOLVED: gcc.misc-tests/bprob-2.c compilation, -O1 > > -fbranch-probabilities UNRESOLVED: gcc.misc-tests/bprob-2.c execution, > > -O1 -fbranch-probabilities FAIL: gcc.misc-tests/bprob-2.c execution, > > -O2 -DPERFTIME -fprofile-arcs UNRESOLVED: gcc.misc-tests/bprob-2.c > > compilation, -O2 -DPERFTIME > > -fbranch-probabilities > > UNRESOLVED: gcc.misc-tests/bprob-2.c execution,-O2 -DPERFTIME > > -fbranch-probabilities > > FAIL: gcc.misc-tests/bprob-2.c execution,-O3 -DPERFTIME -fprofile-arcs > > UNRESOLVED: gcc.misc-tests/bprob-2.c compilation, -O3 -DPERFTIME > > -fbranch-probabilities > > UNRESOLVED: gcc.misc-tests/bprob-2.c execution,-O3 -DPERFTIME > > -fbranch-probabilities > > FAIL: gcc.misc-tests/bprob-2.c execution,-O3 -g -DPERFTIME > > -fprofile-arcs UNRESOLVED: gcc.misc-tests/bprob-2.c compilation, -O3 -g > > -DPERFTIME -fbranch-probabilities > > UNRESOLVED: gcc.misc-tests/bprob-2.c execution,-O3 -g -DPERFTIME > > -fbranch-probabilities > > FAIL: gcc.misc-tests/bprob-2.c execution,-Os -fprofile-arcs > > UNRESOLVED: gcc.misc-tests/bprob-2.c compilation, -Os > > -fbranch-probabilities UNRESOLVED: gcc.misc-tests/bprob-2.c execution, > > -Os -fbranch-probabilities FAIL: gcc.misc-tests/bprob-1.c execution,-g > > -ftree-based-profiling -fprofile-arcs > > UNRESOLVED: gcc.misc-tests/bprob-1.c compilation, -g > > -ftree-based-profiling -fbranch-probabilities > > UNRESOLVED: gcc.misc-tests/bprob-1.c execution,-g > > -ftree-based-profiling -fbranch-probabilities > > FAIL: gcc.misc-tests/bprob-1.c execution,-O0 > > -ftree-based-profiling -fprofile-arcs > > UNRESOLVED: gcc.misc-tests/bprob-1.c compilation, -O0 > > -ftree-based-profiling -fbranch-probabilities > > UNRESOLVED: gcc.misc-tests/bprob-1.c execution,-O0 > > -ftree-based-profiling -fbranch-probabilities > > FAIL: gcc.misc-tests/bprob-1.c execution,-O1 > > -ftree-based-profiling -fprofile-arcs > > UNRESOLVED: gcc.misc-tests/bprob-1.c compilation, -O1 > > -ftree-based-profiling -fbranch-probabilities > > UNRESOLVED: gcc.misc-tests/bprob-1.c execution,-O1 > > -ftree-based-profiling -fbranch-probabilities > > FAIL: gcc.misc-tests/bprob-1.c execution,-O2 -DPERFTIME > > -ftree-based-profiling -fprofile-arcs > > UNRESOLVED: gcc.misc-tests/bprob-1.c compilation, -O2 -DPERFTIME > > -ftree-based-profiling -fbranch-probabilities > > UNRESOLVED: gcc.misc-tests/bprob-1.c execution,-O2 -DPERFTIME > > -ftree-based-profiling -fbranch-probabilities > > FAIL: gcc.misc-tests/bprob-1.c execution,-O3 -DPERFTIME > > -ftree-based-profiling -fprofile-arcs > > UNRESOLVED: gcc.misc-tests/bprob-1.c
[ATTN: Steering Committee] Management of new ports
Hello, there seems to be a problem with the management of new ports. - Documentation is inappropriate. There is a picky checklist to follow, but it does not cover the interesting things, that is the list of de-facto technical standards that we expect new ports to follow (with respect to incomplete transition). For instance, most maintainers have expressed negative feelings toward integrating new ports using cc0, or with define_peephole, or with ASM prologues/epilogues. I have proposed a patch in the past to document this and it has been rejected on the basis that there is no official statement on this. I think that the SC should take a position on how to resolve this issue (see below for my suggestion), otherwise we are going to really annoy people. - At this point, there are at least three pending new ports, one of which have not been reviewed for 9 months already. The only comments they have received are the usual generic comments like "document every function and arguments", or "you need a copyright assignments and you should volunteer to maintain this". Once these nitpicks are done, the patch goes unreviewed forever. I believe we are losing valuable contributions with this behaviour. The only new port that went in is Blackfin, because it was contributed by a GWP which was allowed to commit it without waiting for the review. - I read several times messages by users which believe that GCC is changing trend, going towards supporting only a handful of very common systems, instead of being a generic compiler open to every small platform the open source community needs to support. I do not believe this is the official mission statement of GCC, but the fact that some users *start* to believe this should make the SC think that maybe we need to be more open towards new ports. I'm kindly asking the SC: 1) An official statement about whether GCC is going to still accept every new port which is technically fit and actively maintained, or is now going to restrict the number of targets to the few most important systems for maintenance reasons. 2) An official up-to-date list of technical requirements for a new port to be accepted. 3) Some sort of formal procedure which gives some basic guarantees that new ports are going to be reviewed and eventually accepted. For instance, one solution could be auto-approval for new ports which follow the new technical list and with active maintainers, if the patch went unreviewed for some months. I think it could be a good idea to appoint a new maintainer in charge for new ports, at least to do the leg-work (checklist validation of the port) and to provide some official feedback to the contributors. Thanks. -- Giovanni Bajo
Re: Some notes on the Wiki
Kurt Wall wrote: On Mon, Jul 11, 2005 at 04:27:58PM -0400, Daniel Berlin took 34 lines to write: On Mon, 2005-07-11 at 13:09 -0700, Robert Thorpe wrote: Also, a web-browser is much slower than an info-browser, especially when doing searchs. You must be close to the only user i've met who uses the info browser :) We haven't met, but I use the info browser. :-) I used to hate it but finally decided that since texi was the format that existed, I might as well suck it up and learn to use it. I learned how to use it more than a decade ago when I was playing with gcc-2.3.3 on my Amiga :-) Can't say I really really like it, but at least you can quickly search through the whole file, which isn't so easy with most browsers when you have multiple pages of HTML documentation. Bernd
Re: Returned post for [EMAIL PROTECTED] (fwd)
Gabriel Dos Reis wrote: On Fri, 8 Jul 2005, Gerald Pfeifer wrote: | On Fri, 8 Jul 2005, Gabriel Dos Reis wrote: | > Is it true that nobody wanted to approved GCC-3.3.6 release | > announcement? :-/ FWIW, I don't recall getting the request-for-approval message. But, it's also possible that I just missed it. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: Some notes on the Wiki
Original Message > From: Daniel Berlin <[EMAIL PROTECTED]> > Sent: Monday, July 11, 2005 1:28 PM > To: [EMAIL PROTECTED] > Subject: Re: Some notes on the Wiki > > On Mon, 2005-07-11 at 13:09 -0700, Robert Thorpe wrote: > > > I believe the Wiki is an invaluable documentation tool, precisely > > > because it allows such an unencumbered contribution process. > > > > > > I agree. I wasn't suggesting that the Wiki has no value, but rather > > > that it's not a substitute for the more formal documentation. Were it > > > not for copyright issues, one could view the Wiki as an ongoing draft > > > process for the documentation. > > > > A comment from a user... > > > > Please, please, please don't move GCC internals documentation to a Wiki. > > > Nobody has suggested that we wouldn't ship docs. Great > > Even to users the internals documentation is useful. It's useful when > > trying to find out why GCC is doing the things it does with the code given > > to it, it indicates where to look to find things in the source. > > > This would be much harder if it were a wiki, in particular finding > > information on the version of GCC you're using would be much more difficult. > > However, this isn't true. The wiki stores every version of a page. We > could make sure we know what versions of the wiki pages refer to what > releases, and link them accordingly. Please do that if you're going to use the wiki seriously for lots of docs. > > Also, a web-browser is much slower than an info-browser, especially when > > doing searchs. > > You must be close to the only user i've met who uses the info browser :) When I said "an info-browser" I meant info-browsers in general, not standalone info in particular. Both Emacs and stand-alone info are fast (I think the Vim one is too). I use Emacs Info, but the standalone browser is useful on Cygwin; it means you don't need to install Emacs just to read the cygwin docs. Anyway, it doesn't matter much if your going to keep the docs in texi format, people who want pdf's or html can generate those formats.
RE: attribute initialized
Original Message
>From: Joe Buck
>Sent: 11 July 2005 20:07
> On Mon, Jul 11, 2005 at 08:07:20PM +0200, Sylvester Diehl wrote:
>> why doesn't gcc (-Wall -Wuninitalized -O) detect
>> an uninialized variable passed by reference
>> decleared as const * ?
>
> There are no uninitialized variables in your program. For the
> kind of access checking you seem to be asking for, you'll need
> something like valgrind or mudflap.
>
>> int foo(int const *p)
>> {
>> static int sum = 0;
>>
>> sum += *p;
>> return sum;
>> }
>
> it happens that the memory that p points to is unitialized, but
> that is not what -Wuninitialized does. Similarly, in
>
>> int main(int argc, char **argv)
>> {
>> int k;
>>
>> return printf("%d\n", foo(&k));
>> }
>
> there are no uninitialized variables, as the address of k is
> perfectly well defined.
Indeed so, but I think Sylvester's point is that given that foo takes a
const pointer, the compiler could theoretically know that foo cannot
legitimately make any use of (dereference) the pointer value being passed
and could perhaps issue a warning.
Myself, I was surprised that the inliner didn't catch on to what was going
on and complain. I would have expected that, but it didn't even at O3.
cheers,
DaveK
--
Can't think of a witty .sigline today
Re: attribute initialized
"Dave Korn" <[EMAIL PROTECTED]> writes: >>From: Joe Buck >> >> there are no uninitialized variables, as the address of k is >> perfectly well defined. > > Indeed so, but I think Sylvester's point is that given that foo > takes a const pointer, the compiler could theoretically know that > foo cannot legitimately make any use of (dereference) the pointer > value being passed and could perhaps issue a warning. However, it can store the pointer somewhere and dereference it later, when it points to something initialized. But a low-priority warning might be useful, one would have to experiment with how many false positives this gives. > Myself, I was surprised that the inliner didn't catch on to what > was going on and complain. I would have expected that, but it > didn't even at O3. It does for me with mainline. -- Falk
RE: attribute initialized
Original Message >From: [EMAIL PROTECTED] >Sent: 12 July 2005 10:56 > "Dave Korn" writes: > >> Myself, I was surprised that the inliner didn't catch on to what >> was going on and complain. I would have expected that, but it >> didn't even at O3. > > It does for me with mainline. Ah, there ya go. I tested 3.4.4. cheers, DaveK -- Can't think of a witty .sigline today
gcc 4.0.1 testsuite failures on sparc64-linux: 11 unexpected libstdc++ failures
(See also thread on unexpected gcc, g++, and libstdc++ check-abi errors) This is on Aurora SPARC Linux release 2.0 (Kashmir FC3) UltraSparc I (SpitFire) 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.sparcv9 glibc-2.3.3-99.sparc64 glibc-devel-2.3.3-99.sparc glibc-devel-2.3.3-99.sparc64 glibc-headers-2.3.3-99.sparc64 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.sparc libstdc++-3.4.2-6.fc3.sparc64 libstdc++-devel-3.4.2-6.fc3.sparc libstdc++-devel-3.4.2-6.fc3.sparc64 make-3.80-5.sparc nptl-devel-2.3.3-99.sparcv9 tcl-8.4.7-2.sparc LAST_UPDATED: Obtained from CVS: -rgcc_4_0_1_release Native configuration is sparc64-unknown-linux-gnu === libstdc++ tests === Running target unix FAIL: abi_check WARNING: program timed out. XPASS: 26_numerics/cmath/c99_classification_macros_c.cc (test for excess errors) FAIL: 27_io/basic_filebuf/close/char/4879.cc execution test FAIL: 27_io/basic_filebuf/close/char/9964.cc execution test FAIL: 27_io/basic_filebuf/imbue/char/13171-2.cc execution test FAIL: 27_io/basic_filebuf/imbue/wchar_t/14975-2.cc execution test FAIL: 27_io/basic_filebuf/underflow/char/10097.cc execution test XPASS: 27_io/fpos/14320-1.cc execution test FAIL: 27_io/objects/char/7.cc execution test FAIL: 27_io/objects/char/9661-1.cc execution test FAIL: 27_io/objects/wchar_t/7.cc execution test FAIL: 27_io/objects/wchar_t/9661-1.cc execution test FAIL: ext/array_allocator/2.cc execution test === libstdc++ Summary === # of expected passes3632 # of unexpected failures11 # of unexpected successes 2 # of expected failures 12 and from the log fiel (apart from the check abi, posted separately): Setting LD_LIBRARY_PATH to :/usr/local/src/branch/objdir64/gcc:/usr/local/src/branch/objdir64/sparc64-linux/./libstdc++-v3/src/.libs::/usr/local/src/branch/objdir64/gcc:/usr/local/src/branch/objdir64/sparc64-linux/./libstdc++-v3/src/.libs:/usr/local/src/branch/objdir64/gcc terminate called after throwing an instance of 'std::runtime_error' what(): could not initialize semaphore FAIL: 27_io/basic_filebuf/close/char/4879.cc execution test Setting LD_LIBRARY_PATH to :/usr/local/src/branch/objdir64/gcc:/usr/local/src/branch/objdir64/sparc64-linux/./libstdc++-v3/src/.libs::/usr/local/src/branch/objdir64/gcc:/usr/local/src/branch/objdir64/sparc64-linux/./libstdc++-v3/src/.libs:/usr/local/src/branch/objdir64/gcc terminate called after throwing an instance of 'std::runtime_error' what(): could not initialize semaphore FAIL: 27_io/basic_filebuf/close/char/9964.cc execution test Setting LD_LIBRARY_PATH to :/usr/local/src/branch/objdir64/gcc:/usr/local/src/branch/objdir64/sparc64-linux/./libstdc++-v3/src/.libs::/usr/local/src/branch/objdir64/gcc:/usr/local/src/branch/objdir64/sparc64-linux/./libstdc++-v3/src/.libs:/usr/local/src/branch/objdir64/gcc terminate called after throwing an instance of 'std::runtime_error' what(): could not initialize semaphore FAIL: 27_io/basic_filebuf/imbue/char/13171-2.cc execution test Setting LD_LIBRARY_PATH to :/usr/local/src/branch/objdir64/gcc:/usr/local/src/branch/objdir64/sparc64-linux/./libstdc++-v3/src/.libs::/usr/local/src/branch/objdir64/gcc:/usr/local/src/branch/objdir64/sparc64-linux/./libstdc++-v3/src/.libs:/usr/local/src/branch/objdir64/gcc terminate called after throwing an instance of 'std::runtime_error' what(): could not initialize semaphore FAIL: 27_io/basic_filebuf/imbue/wchar_t/14975-2.cc execution test Setting LD_LIBRARY_PATH to :/usr/local/src/branch/objdir64/gcc:/usr/local/src/branch/objdir64/sparc64-linux/./libstdc++-v3/src/.libs::/usr/local/src/branch/objdir64/gcc:/usr/local/src/branch/objdir64/sparc64-linux/./libstdc++-v3/src/.libs:/usr/local/src/branch/objdir64/gcc terminate called after throwing an instance of 'std::runtime_error' what(): could not initialize semaphore FAIL: 27_io/basic_filebuf/underflow/char/10097.cc execution test Setting LD_LIBRARY_PATH to :/usr/local/src/branch/objdir64/gcc:/usr/local/src/branch/objdir64/sparc64-linux/./libstdc++-v3/src/.libs::/usr/local/src/branch/objdir64/gcc:/usr/local/src/branch/objdir64/sparc64-linux/./libstdc++-v3/src/.libs:/usr/local/src/branch/objdir64/gcc terminate called after throwing an instance of 'std::runtime_error' what(): could not initialize semaphore FAIL: 27_io/objects/char/7.cc execution test Setting LD_LIBRARY_PATH to :/usr/local/src/branch/objdir64/gcc:/usr/local/src/branch/objdir64/sparc64-linux/./libstdc++-v3/src/.libs::/usr/local/src/branch/objdir64/gcc:/usr/local/src/branch/objdir64/sparc64-linux/./libstdc++-v3/src/.libs:/usr/loca
PR22336 (was: Problem with tree-ssa-loop-ivopts.c:get_computation-cost)
If no one is suggesting an alternative, tested on x86 and x86_64-linux where it restores bootstrap (at last :), ok to commit? We're down to 6 ACATS FAIL on x86_64 and 8 on x86: http://gcc.gnu.org/ml/gcc-testresults/2005-07/msg00654.html http://gcc.gnu.org/ml/gcc-testresults/2005-07/msg00653.html common: 18818: cd10002 (run) stream attributes 18819: cdd2a02 (run, works at -O0 everywhere) works with -O2 -fno-tree-sra 22333: c34007p c34007r c45282b (run) spurious discriminant CONSTRAINT_ERROR x86 only: 18659: c32001e c64105b c95086b (ICE x86, ppc, ia64, works on x86_64, pass everywhere at -O0) works with -O2 -fno-tree-sra x86_64 only: 20548: c52103x (run) segfault at runtime on x86_64 and hppa Laurent 2005-07-12 Richard Kenner <[EMAIL PROTECTED]> Laurent GUERBY <[EMAIL PROTECTED]> PR tree-optimization/22336 * function.c (record_block_change): Check for cfun->ib_boundaries_block. Index: function.c === RCS file: /cvs/gcc/gcc/gcc/function.c,v retrieving revision 1.635 diff -u -r1.635 function.c --- function.c 7 Jul 2005 21:04:31 - 1.635 +++ function.c 10 Jul 2005 19:06:10 - @@ -5502,6 +5502,9 @@ if (!block) return; + if(!cfun->ib_boundaries_block) +return; + last_block = VARRAY_TOP_TREE (cfun->ib_boundaries_block); VARRAY_POP (cfun->ib_boundaries_block); n = get_max_uid (); On Tue, 2005-07-05 at 10:31 +0200, Laurent GUERBY wrote: > This is http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22212 > and is the problem blocking Ada bootstrap on x86_64-linux, > it would be great to move forward on this. > > Laurent > > On Thu, 2005-06-30 at 18:18 -0400, Richard Kenner wrote: > > This function generates RTL from an expression to see how many RTL insns > > it is. But this causes a problem compiling the Ada ACATS test cxa4006. > > > > The problem is when part of the expression has a location. In that > > case, record_block_change is called and that relies on > > cfun->ib_boundaries_block being set. But it isn't because we aren't > > expanding stuff "for real". A kludge would be to test that field, but > > what's the proper way? > > > > Also, seq_cost really should be looking at next_real_insn, not NEXT_INSN, > > since any notes shouldn't be counted. > >
Re: gcc 4.0.1 testsuite failures on sparc64-linux: 59 unexpected gcc failures
On 7/12/05, Christian Joensson <[EMAIL PROTECTED]> wrote: > On 7/12/05, Eric Botcazou <[EMAIL PROTECTED]> wrote: > > Joe Buck reports the same problems on SPARC/Solaris: > > http://gcc.gnu.org/ml/gcc-testresults/2005-07/msg00633.html > > > > According to my testing, the fix is to upgrade to GNU Binutils 2.16 or > > 2.16.1. > > you wouldn't happen to know if binutils-2.15.94.0.2.2-2.1 (from fedora > core development) would suffice? or anyone else?? or even binutils-2.15.92.0.2-5.1 from fedora core 3 updates? -- Cheers, /ChJ
Re: gcc 4.0.1 testsuite failures on sparc64-linux: 59 unexpected gcc failures
On Tue, Jul 12, 2005 at 12:20:16PM +0200, Christian Joensson wrote: > On 7/12/05, Christian Joensson <[EMAIL PROTECTED]> wrote: > > On 7/12/05, Eric Botcazou <[EMAIL PROTECTED]> wrote: > > > > Joe Buck reports the same problems on SPARC/Solaris: > > > http://gcc.gnu.org/ml/gcc-testresults/2005-07/msg00633.html > > > > > > According to my testing, the fix is to upgrade to GNU Binutils 2.16 or > > > 2.16.1. > > > > you wouldn't happen to know if binutils-2.15.94.0.2.2-2.1 (from fedora > > core development) would suffice? or anyone else?? > > or even binutils-2.15.92.0.2-5.1 from fedora core 3 updates? That version works for me on x86_64. The minimum binutils for libstdc++ is now 2.15.90.0.1.1, I don't know about the rest of GCC. jon
Re: PR22336 (was: Problem with tree-ssa-loop-ivopts.c:get_computation-cost)
Hello, > If no one is suggesting an alternative, tested on x86 and x86_64-linux > where it restores bootstrap (at last :), ok to commit? I think the patch is fine (although of course I cannot approve it). The more proper fix would be to never expand such expressions from ivopts; I have a patch for this, but it needs more testing and benchmarking. Zdenek > We're down to 6 ACATS FAIL on x86_64 and 8 on x86: > > http://gcc.gnu.org/ml/gcc-testresults/2005-07/msg00654.html > http://gcc.gnu.org/ml/gcc-testresults/2005-07/msg00653.html > > common: > 18818: cd10002 (run) stream attributes > 18819: cdd2a02 (run, works at -O0 everywhere) works with -O2 -fno-tree-sra > 22333: c34007p c34007r c45282b (run) spurious discriminant CONSTRAINT_ERROR > > x86 only: > 18659: c32001e c64105b c95086b (ICE x86, ppc, ia64, works on x86_64, pass > everywhere at -O0) works with -O2 -fno-tree-sra > > x86_64 only: > 20548: c52103x (run) segfault at runtime on x86_64 and hppa > > Laurent > > 2005-07-12 Richard Kenner <[EMAIL PROTECTED]> > Laurent GUERBY <[EMAIL PROTECTED]> > > PR tree-optimization/22336 > * function.c (record_block_change): Check for > cfun->ib_boundaries_block. > > > Index: function.c > === > RCS file: /cvs/gcc/gcc/gcc/function.c,v > retrieving revision 1.635 > diff -u -r1.635 function.c > --- function.c 7 Jul 2005 21:04:31 - 1.635 > +++ function.c 10 Jul 2005 19:06:10 - > @@ -5502,6 +5502,9 @@ >if (!block) > return; > > + if(!cfun->ib_boundaries_block) > +return; > + >last_block = VARRAY_TOP_TREE (cfun->ib_boundaries_block); >VARRAY_POP (cfun->ib_boundaries_block); >n = get_max_uid (); > > > On Tue, 2005-07-05 at 10:31 +0200, Laurent GUERBY wrote: > > This is http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22212 > > and is the problem blocking Ada bootstrap on x86_64-linux, > > it would be great to move forward on this. > > > > Laurent > > > > On Thu, 2005-06-30 at 18:18 -0400, Richard Kenner wrote: > > > This function generates RTL from an expression to see how many RTL insns > > > it is. But this causes a problem compiling the Ada ACATS test cxa4006. > > > > > > The problem is when part of the expression has a location. In that > > > case, record_block_change is called and that relies on > > > cfun->ib_boundaries_block being set. But it isn't because we aren't > > > expanding stuff "for real". A kludge would be to test that field, but > > > what's the proper way? > > > > > > Also, seq_cost really should be looking at next_real_insn, not NEXT_INSN, > > > since any notes shouldn't be counted. > > > >
Re: gcc 4.0.1 testsuite failures on sparc64-linux: 59 unexpected gcc failures
Hello, On Tue, 12 Jul 2005, Jonathan Wakely wrote: On Tue, Jul 12, 2005 at 12:20:16PM +0200, Christian Joensson wrote: On 7/12/05, Christian Joensson <[EMAIL PROTECTED]> wrote: On 7/12/05, Eric Botcazou <[EMAIL PROTECTED]> wrote: Joe Buck reports the same problems on SPARC/Solaris: http://gcc.gnu.org/ml/gcc-testresults/2005-07/msg00633.html According to my testing, the fix is to upgrade to GNU Binutils 2.16 or 2.16.1. you wouldn't happen to know if binutils-2.15.94.0.2.2-2.1 (from fedora core development) would suffice? or anyone else?? or even binutils-2.15.92.0.2-5.1 from fedora core 3 updates? That version works for me on x86_64. The minimum binutils for libstdc++ is now 2.15.90.0.1.1, I don't know about the rest of GCC. does this also apply to other than sparc platforms? I'm cunfused by your note about x86_64, since I'm not able to find any notes about minimal binutils 2.15.90.0.1.1 version required for libstdc++ build on AMD64 linux. Especially: http://gcc.gnu.org/install/specific.html notes more recent binutils version than 2.15 release only in case of *-*-solaris2* configuration. Thanks, Karel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com
Re: gcc 4.0.1 testsuite failures on sparc64-linux: 59 unexpected gcc failures
On Tue, Jul 12, 2005 at 01:23:23PM +0200, Karel Gardas wrote: > > Hello, > > On Tue, 12 Jul 2005, Jonathan Wakely wrote: > > >On Tue, Jul 12, 2005 at 12:20:16PM +0200, Christian Joensson wrote: > > > >>On 7/12/05, Christian Joensson <[EMAIL PROTECTED]> wrote: > >>>On 7/12/05, Eric Botcazou <[EMAIL PROTECTED]> wrote: > >> > Joe Buck reports the same problems on SPARC/Solaris: > http://gcc.gnu.org/ml/gcc-testresults/2005-07/msg00633.html > > According to my testing, the fix is to upgrade to GNU Binutils 2.16 or > 2.16.1. > >>> > >>>you wouldn't happen to know if binutils-2.15.94.0.2.2-2.1 (from fedora > >>>core development) would suffice? or anyone else?? > >> > >>or even binutils-2.15.92.0.2-5.1 from fedora core 3 updates? > > > >That version works for me on x86_64. > > > >The minimum binutils for libstdc++ is now 2.15.90.0.1.1, I don't know > >about the rest of GCC. > > does this also apply to other than sparc platforms? I'm cunfused by your I believe that version applies to x86 linux and x86-64 linux. I don't know about Sparc linux. The only hard fact I can confirm first-hand is that the latest binutils from FC3 updates works for me on x86_64. > note about x86_64, since I'm not able to find any notes about minimal > binutils 2.15.90.0.1.1 version required for libstdc++ build on AMD64 > linux. Especially: > > http://gcc.gnu.org/install/specific.html > > notes more recent binutils version than 2.15 release only in case of > *-*-solaris2* configuration. Yes, I know. I'm in the process of updating the libstdc++ docs here, which are very out of date: http://gcc.gnu.org/onlinedocs/libstdc++/install.html#prereqs I will also have to add something to the main config docs to say that libstdc++ (and other runtime libs) may have more specific requirements, so check the relevant docs. jon
libstdc++ required binutils version [was: Re: gcc 4.0.1 testsuite failures on sparc64-linux: 59 unexpected gcc failures]
On Tue, 12 Jul 2005, Jonathan Wakely wrote: On Tue, 12 Jul 2005, Jonathan Wakely wrote: On Tue, Jul 12, 2005 at 12:20:16PM +0200, Christian Joensson wrote: On 7/12/05, Christian Joensson <[EMAIL PROTECTED]> wrote: On 7/12/05, Eric Botcazou <[EMAIL PROTECTED]> wrote: Joe Buck reports the same problems on SPARC/Solaris: http://gcc.gnu.org/ml/gcc-testresults/2005-07/msg00633.html According to my testing, the fix is to upgrade to GNU Binutils 2.16 or 2.16.1. you wouldn't happen to know if binutils-2.15.94.0.2.2-2.1 (from fedora core development) would suffice? or anyone else?? or even binutils-2.15.92.0.2-5.1 from fedora core 3 updates? That version works for me on x86_64. The minimum binutils for libstdc++ is now 2.15.90.0.1.1, I don't know about the rest of GCC. does this also apply to other than sparc platforms? I'm cunfused by your I believe that version applies to x86 linux and x86-64 linux. I don't know about Sparc linux. The only hard fact I can confirm first-hand is that the latest binutils from FC3 updates works for me on x86_64. Interesting! Please have a look at: http://gcc.gnu.org/ml/gcc-testresults/2005-07/msg00602.html those are test results from 4.0.1 release compiled on debian 3.1/AMD64 (pure64 bit). This debian is using binutils 2.15: silence:~$ as --version GNU assembler 2.15 Copyright 2002 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License. This program has absolutely no warranty. This assembler was configured for a target of `x86_64-linux'. silence:~$ silence:~$ ld --version GNU ld version 2.15 Copyright 2002 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License. This program has absolutely no warranty. silence:~$ and IMHO testresults look quite good except abi_check, don't they? i.e. do you mean updating binutils will resolve abi_check issue in libstdc++ testsuite? Thanks, Karel -- Karel Gardas [EMAIL PROTECTED] ObjectSecurity Ltd. http://www.objectsecurity.com
Re: libstdc++ required binutils version [was: Re: gcc 4.0.1 testsuite failures on sparc64-linux: 59 unexpected gcc failures]
On Tue, Jul 12, 2005 at 01:55:11PM +0200, Karel Gardas wrote: > On Tue, 12 Jul 2005, Jonathan Wakely wrote: > > >>On Tue, 12 Jul 2005, Jonathan Wakely wrote: > >> > >>>The minimum binutils for libstdc++ is now 2.15.90.0.1.1, I don't know > >>>about the rest of GCC. > >> > >>does this also apply to other than sparc platforms? I'm cunfused by your > > > >I believe that version applies to x86 linux and x86-64 linux. I don't > >know about Sparc linux. The only hard fact I can confirm first-hand is > >that the latest binutils from FC3 updates works for me on x86_64. > > Interesting! Please have a look at: > http://gcc.gnu.org/ml/gcc-testresults/2005-07/msg00602.html > > those are test results from 4.0.1 release compiled on debian 3.1/AMD64 > (pure64 bit). This debian is using binutils 2.15: [snip] > and IMHO testresults look quite good except abi_check, don't they? i.e. do > you mean updating binutils will resolve abi_check issue in libstdc++ > testsuite? I'd assume yes, based on Benjamin's statement here: http://gcc.gnu.org/ml/libstdc++/2005-06/msg00132.html But I don't know what's really causing the abi_check failure. I've CC'd the libstdc++ list so I hope one of the v3 guys will be able to answer that for you. jon
Re: PR22336 (was: Problem with tree-ssa-loop-ivopts.c:get_computation-cost)
I think the patch is fine (although of course I cannot approve it). I, as it's author, do not. But, as I keep saying, I don't know what the proper fix is. The more proper fix would be to never expand such expressions from ivopts; What are "such expressions"?
Re: PR22336 (was: Problem with tree-ssa-loop-ivopts.c:get_computation-cost)
Hello, > I think the patch is fine (although of course I cannot approve it). > > I, as it's author, do not. But, as I keep saying, I don't know what > the proper fix is. preventing record_block_change from working in this situation seems a quite clean solution to me; of course, not expanding expressions with TREE_BLOCK set (when determining their cost) at all would be better, but somewhat more complicated. > The more proper fix would be to never expand such expressions from ivopts; > > What are "such expressions"? Expressions with TREE_BLOCK set; i.e. those coming from the compiled program. Zdenek
bootstrap build results for GCC 4.0.1
config.guess reports: armv4l-unknown-linux-gnu
gcc -v reports:
Using built-in specs.
Target: armv4l-unknown-linux-gnu
Configured with: ../gcc-4.0.1/configure --with-cpu=strongarm
--with-pic --prefix=/home/random/gcc4 --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
--enable-bootstrap --enable-languages=c,c++,java,objc
Thread model: posix
gcc version 4.0.1
I enabled the languages C, C++, Java, and ObjectiveC, as you can see
from the configure flags above.
The distribution I'm using is a customized Linux From Scratch on a
Netwinder 2100 from Rebel Computing, with Linux 2.6.10, glibc from CVS
HEAD as of 2004-06-21, binutils 2.15.91.0.1, and gcc 3.4.1. glibc,
binutils, and gcc all had some ARM-specific patches that I got from
Dan Kegel's crosstool.
I needed to make one small change to get the bootstrap build of 4.0.1
to complete: initially, compilation of gcc/java/jcf-write.c failed in
stage2 complaining of an unused variable in the following block
(around line 2236):
else
{
tree type = TREE_TYPE(exp);
emit_load (arg, state);
}
I deleted the "tree type = TREE_TYPE(exp)" line and that corrected the problem.
Cheers,
bn
[gomp] mainline merge as of 2007-07-12
Bootstrapped on x86.
Some tests in gcc.c-torture rely on undefined behaviour?
Hi,
I've been looking at the gcc.c-torture tests, it seems some of them rely
on undefined behaviour. For example, 920612-1.c looks like this:
f(j)int j;{return++j>0;}
main(){if(f((~0U)>>1))abort();exit(0);}
AIUI, this passes the largest possible positive integer to f(), which then
increments it, causing signed overflow, the result of which is undefined.
The test passes if signed overflow wraps.
930529-1.c is similar -- again the maximum positive integer is
incremented.
20020508-2.c has the following code (abridged):
#ifndef CHAR_BIT
#define CHAR_BIT 8
#endif
#define ROR(a,b) (((a) >> (b)) | ((a) << ((sizeof (a) * CHAR_BIT) - (b
#define INT_VALUE ((int)0x1234)
#define SHIFT1 4
int i = INT_VALUE;
int shift1 = SHIFT1;
if (ROR (i, shift1) != ROR (INT_VALUE, SHIFT1))
abort ();
Similarly, the left-shifting in ROR causes signed integer overflow (I
think) and so ROR relies on undefined behaviour. 20020508-3.c is similar.
My question is: what exactly is gcc.c-torture testing? It seems to be
testing more than just C standard compliance, but also certain
undefined-but-desired behaviours, such as wrap-on-signed-overflow (at
least in some cases). Is that right? If so, other C compilers could be
correct with respect to the C standard but not pass all the tests. I
couldn't find any kind of README or description about the tests that
covered this point, so I'd appreciate any explanations.
Thanks.
Nick
more on duplicate decls
I have been trying to cleanup the location where the persistent ipa information is stored. The original way that I did this was that I had a field in the var_ann structure that pointed to the ipa_information. Now that danny has reorganized the decls, the plan was to just add a field to the function_decl. Danny has suggested that if I was going to add such a field, it should be a pointer to the cgraph_node and then store the persistent ipa information there. I noticed that if I did this, there should be a lot of stuff that could fall away. There would be no need to have the hash table that points from function_decls to cgraph nodes as well as there was no need for the master_clone field since the cgraph node that the decl pointed to would be just this good. All of this sounds great... smaller, faster. This has not gone as easy as I had hoped. Danny found the first stumbling block yesterday that the c decl merging needed to be enhanced. The second bug appears to be harder. In c++, there really can be multiple function_decls with the same uid. The kludge to handle them is documented in cp/name-lookup.c around line 670 and one test case to generate them is in gcc/testsuite/g++.dg/opt/inline2.C. There are several ways to go about fixing this: One is to just abandon my fix and let others (such as the code sourcery people deal with it when they go to build a real symbol table.) It seems like a better way is to build a table of merges that need to be done and find some place after the c++ front end is finished but before the cgraph gets built and do one scan of the code and replace all of the offending decls. Does such a location exist? Is this the correct plan? Kenny
Pointers in comparison expressions
Can a pointer appear in a C/C++ relational expression which doesn't test the
equality (or the inequality) of that pointer with respect to another pointer?
For example, are the comparisons in the following program legal code?
/* test.c */
#include
int main(int argc, char* argv[])
{
void *a, *b;
int aa, bb;
a = &aa;
b = &bb;
printf("a: %p, b: %p\n", a, b);
if (a < b)
printf("a < b\n");
else
printf("a >= b\n");
if (b < a)
printf("b < a\n");
else
printf("b >= a\n");
return 0;
}
The execution of the compiled program produces an output like this:
a: 0xb55c, b: 0xb558
a >= b
b < a
I have compiled this program with gcc and g++, versions 3.4.4 and 4.0.1, and
(the prehistoric) egcs 2.91.66. None of these compilers has issued any
warning or error. I have compiled the program above whit these options: -Wall
--ansi --pedantic .
These are the version information about the compilers:
Reading specs from /usr/local/lib/gcc/i686-pc-linux-gnu/3.4.4/specs
Configured with: ../gcc-3.4.4/configure --srcdir=../gcc-3.4.4
--mandir=/usr/local/share/man --infodir=/usr/local/share/info
--enable-threads --enable-languages=c,c++,f77,java,objc --prefix=/usr/local
--with-cpu=pentium2 --with-tune=k8 --enable-__cxa_atexit --with-x
--enable-java-awt=gtk
Thread model: posix
gcc version 3.4.4
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.0.1/configure --srcdir=../gcc-4.0.1
--mandir=/usr/local/share/man --infodir=/usr/local/share/info
--enable-threads --enable-languages=c,c++,f95,java,objc --prefix=/usr/local
--with-cpu=pentium2 --with-tune=k8 --enable-__cxa_atexit --with-x
--enable-java-awt=gtk
Thread model: posix
gcc version 4.0.1
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.66/specs
gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)
I think that even if the use of relational operators other than '==' and '!='
is legal with pointers, the compiler should issue a warning (when the option
-Wall is used), as it does for assignment, used as truth values, not
surrounded with parentheses.
Thanks in advance for your reply.
Regards,
Mirco Lorenzoni
P.S.
I'm not a list subscriber. Send me a copy of your reply, please.
Re: Pointers in comparison expressions
> I think that even if the use of relational operators other than '==' and '!=' > is legal with pointers, the compiler should issue a warning (when the option > -Wall is used), as it does for assignment, used as truth values, not > surrounded with parentheses. Why? It's legal, it's useful, and used. --Dan
Re: Some tests in gcc.c-torture rely on undefined behaviour?
On Tue, Jul 12, 2005 at 09:41:22AM -0500, Nicholas Nethercote wrote:
> I've been looking at the gcc.c-torture tests, it seems some of them rely
> on undefined behaviour. For example, 920612-1.c looks like this:
>
> f(j)int j;{return++j>0;}
> main(){if(f((~0U)>>1))abort();exit(0);}
Wow. It appears that it would be legal for a C compiler to optimize f() to
int f(int j) { return 1;}
since the compiler is entitled to assume that overflow does not occur.
Just the same, I don't think we necessarily want to take advantage of
every degree of freedom the standards give us (at least, not by default).
(Oh, crap; I see a massive thread re-emerging).
Re: Some tests in gcc.c-torture rely on undefined behaviour?
On Tue, 12 Jul 2005, Nicholas Nethercote wrote:
> Similarly, the left-shifting in ROR causes signed integer overflow (I think)
> and so ROR relies on undefined behaviour. 20020508-3.c is similar.
To quote implement-c.texi:
GCC does not use the latitude given in C99 only to treat certain
aspects of signed @samp{<<} as undefined, but this is subject to
change.
Unless there is a shift by >= the width of the (promoted) type, this code
is defined for GNU C. In any case, it is defined for gnu89 mode even if
we start treating this as undefined in C99 mode; see pr7284-1.c.
> My question is: what exactly is gcc.c-torture testing? It seems to be
That GNU C code compiles or executes as expected for GNU C.
> testing more than just C standard compliance, but also certain
> undefined-but-desired behaviours, such as wrap-on-signed-overflow (at least in
> some cases). Is that right? If so, other C compilers could be correct with
Such tests are in general bugs. You'd have to ask Torbjorn about what the
original purpose of the old parts of c-torture was, as that may have
differed from the current GCC testsuite, but invalid tests should be
removed (or, perhaps better, moved to gcc.c-torture/compile) or have
relevant options such as -fwrapv added.
Note that gcc.c-torture/compile correctly contains many tests involving
undefined behavior at runtime which implementations are required to
translate in case the problem code is never executed. These serve to test
that e.g. uninitialized variables do not crash the compiler.
> respect to the C standard but not pass all the tests. I couldn't find any
The GCC testsuite is a testsuite for GCC only, not for other compilers.
--
Joseph S. Myers http://www.srcf.ucam.org/~jsm28/gcc/
[EMAIL PROTECTED] (personal mail)
[EMAIL PROTECTED] (CodeSourcery mail)
[EMAIL PROTECTED] (Bugzilla assignments and CCs)
RE: Pointers in comparison expressions
Original Message >From: Daniel Berlin >Sent: 12 July 2005 17:33 >> I think that even if the use of relational operators other than '==' and >> '!=' is legal with pointers, the compiler should issue a warning (when >> the option -Wall is used), as it does for assignment, used as truth >> values, not surrounded with parentheses. > > Why? > It's legal, it's useful, and used. > > --Dan Just to enlarge upon Dan's comment: Since pointer subtraction is well defined, and it returns an int, then ... int *a, *b; if (a < b) dosomething (); ... is just the same as ... int *a, *b; if ((b - a) >= 0) dosomething (); ... so do you think the compiler should warn about _all_ pointer arithmetic? cheers, DaveK -- Can't think of a witty .sigline today
Re: Pointers in comparison expressions
Mirco Lorenzoni wrote:
>Can a pointer appear in a C/C++ relational expression which doesn't test the
>equality (or the inequality) of that pointer with respect to another pointer?
>For example, are the comparisons in the following program legal code?
>
>/* test.c */
>#include
>
>int main(int argc, char* argv[])
>{
> void *a, *b;
> int aa, bb;
>
> a = &aa;
> b = &bb;
>
>
>
Actually I'm fairly certain at this point this program stops being legal
code, as (I believe) you can only compare pointers which are from the
same allocation (be that an array, malloc, etc).
However, comparing pointers with < is something I do all the time when
writing various kinds of algorithms. For what reason would you want to
see it warned about?
Chris
Re: libstdc++ required binutils version [was: Re: gcc 4.0.1 testsuite failures on sparc64-linux: 59 unexpected gcc failures]
Jonathan Wakely wrote: The minimum binutils for libstdc++ is now 2.15.90.0.1.1, I don't know about the rest of GCC. ... and IMHO testresults look quite good except abi_check, don't they? i.e. do you mean updating binutils will resolve abi_check issue in libstdc++ testsuite? I'd assume yes, based on Benjamin's statement here: http://gcc.gnu.org/ml/libstdc++/2005-06/msg00132.html Does 2.16 satisfy the minimum requirement? This should be clearly spelled out in the doc. 2.15.90.0.1.1 is linux-only. - Dan -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html
Failure building Ada on i686-pc-mingw32
Development environment: i686-pc-mingw32 on Windows 2000 Pro SP4 (Athlon processor) MinGW 3.2.0 (gcc 3.4.2 mingw-special) Msys 1.0.10 ../gcc-4.0.1/configure --verbose --with-gcc --with-gnu-ld --with-gnu-as --host=mingw32 --target=mingw32 --prefix=/mingwlocal --enable-threads --disable-nls --disable-win32-registry --disable-shared --enable-sjlj-exceptions --enable-languages=c,ada Ada fails in stage1; the offender is gnatbind.exe. It crashes even if invoked with no command-line arguments. Gdb provides the following information: (gdb) run Starting program: C:\gcc401install\gccbuild\gcc\stage1/gnatbind.exe Program received signal SIGSEGV, Segmentation fault. 0x004034b7 in __gnat_install_SEH_handler (ER=0x) at ../../gcc-4.0.1/gcc/ada/seh_init.c:219 219 ((int *)ER)[0] = (int)ptr; /* previous handler */ (gdb)
RFC: improving estimate_num_insns
In looking at the function inliner, I did some analysis of the correctness of estimate_num_insns (from tree-inline.c), as this measurement is critical to the inlining heuristics. Here is the overview of what I found on the functions in two sample files from the FAAD2 AAC library (measured at -O3 with inlining disabled): syntax.c avg.avg. std. targetratio errordeviation arm-none 2.88 57% 2.37 darwin-ppc3.17 55% 2.50 linux-x86 2.72 55% 2.06 huffman.c avg.avg. std. targetratio errordeviation arm-none 3.2756% 2.37 darwin-ppc4.1953% 2.88 linux-x86 3.4256% 2.39 fn. differential = actual bytes / estimated insns avg. ratio = average (fn. differential) of all functions fn. error = max (fn. differential, avg. ratio) / min (fn. differential, avg. ratio) avg. error = average (fn. error) of all functions std. deviation = standard deviation (fn. differential) across all functions Note that by choosing these metrics, my intent was to isolate the consistency of the differential from the magnitude of the differential. In other words, the goal was to have estimates that were a consistent ratio to the actual results, whatever that ratio may be. Thinking that there may be room for improvement on this, I tried this same experiment with a couple of adjustments to estimate_num_insns: - Instead of ignoring constants, assign them a weight of 2 instructions (one for the constant itself and one to load into memory) - Instead of ignoring dereferences, assign a weight of 2 to an array reference and 1 for a pointer dereference - Instead of ignoring case labels, assign them a weight of 2 instructions (to represent the cost of control logic to get there) With these modifications (tree-estimate.patch), I see the following results: syntax.c avg.avg. std. targetratio errordeviation arm-none 1.6829% 0.67 darwin-ppc1.8429% 0.69 linux-x86 1.6226% 0.55 huffman.c avg.avg. std. targetratio errordeviation arm-none 1.7526% 0.52 darwin-ppc2.3124% 0.69 linux-x86 1.9525% 0.67 Which appears to be a significant improvement in the accuracy of estimate_num_insns. However, note that since the avg. ratio has decreased significantly (estimates have gone up because we're counting things that were ignored before), any heuristics that are based on instruction counts will have effectively decreased by ~25-50%. To compensate for that, I bumped up any constants that are based on instruction estimates by 50% each (see inl-costs.patch). With both of these changes in place, I ran some simple SPEC2000 integer benchmarks (not fine-tuned, not reportable) and saw the following impact on performance (positive is better): darwin-ppc linux-x86 linux-arm* gzip -4.7%+11.7% +1.3% vpr -0.7%-1.1% - mcf -0.3%+1.1% - crafty-0.8%+1.8% - parser-- - eon -4.4%+0.3% - perlbmk +0.4%0.0% -1.1% gap -+1.0% -2.9% vortex+4.1%0.0% 0.0% bzip2 +1.2%+1.1% -1.3% twolf -0.5%-2.9% -1.2% - = unable to obtain a valid result * linux-arm results are based on a subset of SPEC data and command- line options for use on a 32MB embedded board -- not even close to the full SPEC suite. For what it's worth, code size is equal to or smaller for all benchmarks across all platforms. So, here are the open issues I see at this point: 1. It appears that this change to estimate_num_instructions generates a much better estimate of actual code size. However, the benchmark results are ambiguous. Is this patch worth considering as-is? 2. Increasing instruction weights causes the instruction-based values (e.g., --param max-inline-insns-auto) to be effectively lower. However, changing these constants/defaults as in the second patch will cause a semantic change to anyone who is setting these values at the command line. Is that change acceptable? I do realize that this area is one that will eventually be likely best served by target-dependent routines (and constants), however I also see a significant benefit to all targets in fixing the default implementation first. Thoughts? Advice? Thanks - Josh Josh Conner tree-estimate.patch Description: Binary data inl-costs.patch Description: Binary data
Homepage: Update of page "Releases"
The page http://gcc.gnu.org/releases.html should be updated. - Entries of recent releases GCC 4.0.0 and GCC 4.0.1 are missing. In addition the headline of the table should be changed to: "Please refer to our development plan for releases past 4.0.1 and future releases." Sincerely, F. Fritsche
Re: Some tests in gcc.c-torture rely on undefined behaviour?
"Joseph S. Myers" <[EMAIL PROTECTED]> writes: > Such tests are in general bugs. You'd have to ask Torbjorn about what the > original purpose of the old parts of c-torture was, as that may have > differed from the current GCC testsuite, but invalid tests should be > removed (or, perhaps better, moved to gcc.c-torture/compile) or have > relevant options such as -fwrapv added. The original purpose was simply to collect programs which caused the compiler to fail. When he saw a bug report with a test case, he collected the test case, reduced it, and added it to the torture tests. The tests were simply run at various optimization levels. Tests which caused the compiler to crash were put in compile, tests which showed a miscompilation visible at run time were put in execute. I would guess that 920612-1.c, at least, could just be changed to use unsigned int, and it would continue to test whatever bug it was testing when it was originally added. Ian
Re: Some tests in gcc.c-torture rely on undefined behaviour?
On Tue, Jul 12, 2005 at 11:39:18AM -0700, Ian Lance Taylor wrote: > I would guess that 920612-1.c, at least, could just be changed to use > unsigned int, and it would continue to test whatever bug it was > testing when it was originally added. > The problem is somewhat more widespread now with the tree optimizers. In particular with old test cases. Some of these cases are essentially optimized into empty functions by the time we get into the RTL passes. We would have to audit them all and add enough external functions, volatile markers or what-have-you to have them survive until RTL. Not sure if it's worth it.
Re: Some tests in gcc.c-torture rely on undefined behaviour?
Diego Novillo <[EMAIL PROTECTED]> writes: > The problem is somewhat more widespread now with the tree > optimizers. In particular with old test cases. Some of these > cases are essentially optimized into empty functions by the time > we get into the RTL passes. Hmmm, yeah. > We would have to audit them all and add enough external > functions, volatile markers or what-have-you to have them survive > until RTL. Not sure if it's worth it. I'm sure it isn't. Clearly test cases which we now understand to be invalid should be changed or removed. Other than that, I would vote for leaving them alone. Unless people are concerned about the number of tests we have. (To speed up running the testsuite it would probably be more useful in any case to put some time into running test cases in parallel on native systems. Tcl has enough support for processes that this shouldn't be very hard. It would mostly be a bookkeeping issue, I think.) Ian
Error building 4.0.1: input.h: No such file...
I built 4.0.0 last week and thought I would update to 4.0.1. While building 401 I got the following error: -- gcc -c -g -DENABLE_CHECKING -DENABLE_ASSERT_CHECKING -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wno-error -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I/d/developer/src/gcc-4.0.1/gcc -I/d/developer/src/gcc-4.0.1/gcc/build -I/d/developer/src/gcc-4.0.1/gcc/../include -I/d/developer/src/gcc-4.0.1/gcc/../libcpp/include -I/usr/local/gmp-4.1.4/include \ -o build/gengtype-yacc.o /d/developer/src/gcc-4.0.1/gcc/gengtype-yacc.c gcc -g -DENABLE_CHECKING -DENABLE_ASSERT_CHECKING -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition-DHAVE_CONFIG_H -DGENERATOR_FILE -s -o build/gengtype.exe \ build/gengtype.o build/gengtype-lex.o build/gengtype-yacc.o \ build/errors.o ../build-i686-pc-mingw32/libiberty/libiberty.a build/gengtype.exe /d/developer/src/gcc-4.0.1/gcc/input.h: No such file or directory make[2]: *** [s-gtype] Error 1 make[2]: Leaving directory `/d/developer/projects/chinook_lib/gcc/build/gcc' make[1]: *** [stage1_build] Error 2 make[1]: Leaving directory `/d/developer/projects/chinook_lib/gcc/build/gcc' make: *** [bootstrap] Error 2 -- The file exists in that location so I'm not sure what to do with this. I'm building on winxp pro, GCC 3.4.1 using Msys. Config line: -- ../gcc-4.0.1/configure \ --prefix=/mingw \ --with-gcc \ --with-gnu-ld \ --with-gnu-as \ --enable-threads \ --disable-shared \ --disable-nls \ --enable-languages=c,c++,f95 \ --disable-win32-registry \ --with-gmp=/usr/local/gmp-4.1.4 Make cmd: -- make \ CFLAGS="-O2 -march=i686 -fomit-frame-pointer" \ CXXFLAGS="-mthreads -O2 -march=i686 -fomit-frame-pointer" \ LIBCFLAGS="-O2" \ LIBCXXFLAGS="-O2 -fno-implicit-templates" \ LDFLAGS="-s" \ bootstrap Any suggestions? Thank you Chris
Re: Error building 4.0.1: input.h: No such file...
Chris Garrett wrote: I built 4.0.0 last week and thought I would update to 4.0.1. While building 401 I got the following error: -- gcc -c -g -DENABLE_CHECKING -DENABLE_ASSERT_CHECKING -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wno-error -DHAVE_CONFIG_H -DGENERATOR_FILE-I. -Ibuild -I/d/developer/src/gcc-4.0.1/gcc -I/d/developer/src/gcc-4.0.1/gcc/build -I/d/developer/src/gcc-4.0.1/gcc/../include -I/d/developer/src/gcc-4.0.1/gcc/../libcpp/include -I/usr/local/gmp-4.1.4/include \ -o build/gengtype-yacc.o /d/developer/src/gcc-4.0.1/gcc/gengtype-yacc.c gcc -g -DENABLE_CHECKING -DENABLE_ASSERT_CHECKING -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition-DHAVE_CONFIG_H -DGENERATOR_FILE -s -o build/gengtype.exe \ build/gengtype.o build/gengtype-lex.o build/gengtype-yacc.o \ build/errors.o ../build-i686-pc-mingw32/libiberty/libiberty.a build/gengtype.exe /d/developer/src/gcc-4.0.1/gcc/input.h: No such file or directory make[2]: *** [s-gtype] Error 1 make[2]: Leaving directory `/d/developer/projects/chinook_lib/gcc/build/gcc' make[1]: *** [stage1_build] Error 2 make[1]: Leaving directory `/d/developer/projects/chinook_lib/gcc/build/gcc' make: *** [bootstrap] Error 2 -- The file exists in that location so I'm not sure what to do with this. I'm building on winxp pro, GCC 3.4.1 using Msys. Config line: -- ../gcc-4.0.1/configure \ --prefix=/mingw \ --with-gcc \ --with-gnu-ld \ --with-gnu-as \ --enable-threads \ --disable-shared \ --disable-nls \ --enable-languages=c,c++,f95 \ --disable-win32-registry \ --with-gmp=/usr/local/gmp-4.1.4 Make cmd: -- make \ CFLAGS="-O2 -march=i686 -fomit-frame-pointer" \ CXXFLAGS="-mthreads -O2 -march=i686 -fomit-frame-pointer" \ LIBCFLAGS="-O2" \ LIBCXXFLAGS="-O2 -fno-implicit-templates" \ LDFLAGS="-s" \ bootstrap this patch should sort you out Index: gcc/c-incpath.c === RCS file: /cvs/gcc/gcc/gcc/c-incpath.c,v retrieving revision 1.21 diff -c -3 -p -r1.21 c-incpath.c *** gcc/c-incpath.c23 Jan 2005 15:05:27 -1.21 --- gcc/c-incpath.c23 Feb 2005 19:39:49 - *** add_path (char *path, int chain, int cxx *** 331,343 cpp_dir *p; #if defined (HAVE_DOS_BASED_FILE_SYSTEM) ! /* Convert all backslashes to slashes. The native CRT stat() ! function does not recognize a directory that ends in a backslash ! (unless it is a drive root dir, such "c:\"). Forward slashes, ! trailing or otherwise, cause no problems for stat(). */ ! char* c; ! for (c = path; *c; c++) ! if (*c == '\\') *c = '/'; #endif p = xmalloc (sizeof (cpp_dir)); --- 331,348 cpp_dir *p; #if defined (HAVE_DOS_BASED_FILE_SYSTEM) ! /* Remove unnecessary trailing slashes. On some versions of MS ! Windows, trailing _forward_ slashes cause no problems for stat(). ! On newer versions, stat() does not recognise a directory that ends ! in a '\\' or '/', unless it is a drive root dir, such as "c:/", ! where it is obligatory. */ ! int pathlen = strlen (path); ! char* end = path + pathlen - 1; ! /* Preserve the lead '/' or lead "c:/". */ ! char* start = path + (pathlen > 2 && path[1] == ':' ? 3 : 1); ! ! for (; end > start && IS_DIR_SEPARATOR (*end); end--) ! *end = 0; #endif p = xmalloc (sizeof (cpp_dir));
Re: RFC: improving estimate_num_insns
On Tuesday 12 July 2005 19:56, Josh Conner wrote: > In looking at the function inliner, I did some analysis of the > correctness of estimate_num_insns (from tree-inline.c), as this > measurement is critical to the inlining heuristics. You don't say what compiler you used for these measurements. I suppose you used mainline? > Here is the > overview of what I found on the functions in two sample files from > the FAAD2 AAC library (measured at -O3 with inlining disabled): I think you should look at a lot more code than this. > Thinking that there may be room for improvement on this, I tried this > same experiment with a couple of adjustments to estimate_num_insns: > - Instead of ignoring constants, assign them a weight of 2 > instructions (one for the constant itself and one to load into memory) Why the load into memory, you mean constants that must be loaded from the constant pool? I guess the cost for the constant itself depends on whether it is a legitimate constant or not, and how it is loaded, and this is all very target specific. But a cost greater than 0 probably makes sense. It would be nice if you retain the comment about constants in the existing code somehow. The cost of constants is not trivial, and you should explain your choice better in a comment. > - Instead of ignoring dereferences, assign a weight of 2 to an array > reference and 1 for a pointer dereference Makes sense. > - Instead of ignoring case labels, assign them a weight of 2 > instructions (to represent the cost of control logic to get there) This depends on how the switch statement is expanded, e.g. to a binary decision tree, or to a table jump, or to something smaller than that. So again (like everything else, sadly) this is highly target-specific and even context-specific. I'd think a cost of 2 is too pessimistic in most cases. You could look at the code in stmt.c to see how switch statements are expanded. Maybe there is a cheap test you can do to make CASE_LABELs free for very small switch statements (i.e. the ones which should never hold you back from inlining the function containing them ;-). > For what it's worth, code size is equal to or smaller for all > benchmarks across all platforms. What about the compile time? > So, here are the open issues I see at this point: > 1. It appears that this change to estimate_num_instructions generates > a much better estimate of actual code size. However, the benchmark > results are ambiguous. Is this patch worth considering as-is? I would say you'd at least have to look into the ppc gzip and eon regressions before this is acceptable. But it is not my decision to make, of course. > 2. Increasing instruction weights causes the instruction-based values > (e.g., --param max-inline-insns-auto) to be effectively lower. > However, changing these constants/defaults as in the second patch > will cause a semantic change to anyone who is setting these values at > the command line. Is that change acceptable? This has constantly changed from one release to the next since GCC 3.3, so I don't think this should be a problem. > I do realize that this area is one that will eventually be likely > best served by target-dependent routines (and constants), however I > also see a significant benefit to all targets in fixing the default > implementation first. I don't really think we want to make too many things target-dependent. This whole estimate is just that: An estimate. And it's not intended to be absolute. It is just a relative measure of cost. There are IMHO very few trees that should have target-dependent inline cost estimates. OK, that mas the thoughts part... > Thoughts? Advice? ...on to advice then. First of all, I think you should handle ARRAY_RANGE_REF and ARRAY_REF the same. And you probably should make BIT_FIELD_REF more expensive, and maybe make its cost depend on which bit you're addressing (you can see that in operands 1 and 2 of the BIT_FIELD_REF). Its current cost of just 1 is probably too optimistic, just like the other cases you are trying to address with this patch. Second, you may want to add a target hook to return the cost of target builtins. Even builtins that expand to just one instruction are now counted as 16 insns plus the cost of the arguments list. This badly hurts when you use e.g. SSE intrinsics. It's probably not an issue for the benchmark you looked at now, but maybe you want to look into it anyway, while you're at it. Third, > (measured at -O3 with inlining disabled): Then why not just -O2 with inlining disabled? Now you have enabled loop unswitching, which is known to sometimes significantly increase code size. Fourth, look at _much_ more code than this. I would especially look at a lot more C++ code, which is where our inliner heuristics can really dramatically improve or destroy performance. See Richard Guenther's inline heuristics tweaks from earlier this year, in the thread starting here: http://gcc.gnu.org/ml/gcc-p
Re: Some notes on the Wiki
On Jul 11, 2005, Daniel Berlin <[EMAIL PROTECTED]> wrote: > In fact, a lot of projects don't even bother to distribute anything but > HTML docs anymore (regardless of how they browse it). And that's a pity, because it's a bit of a pain to turn the output of grep -r regexp docs/HTML into something the browser will display properly, especially when there are multiple hits. The stand-alone info tool just rules at that; it's invaluable to search GCC docs like that. Having dozens of web pages instead would make such searches intolerable. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org}
64-bit on A64 running 32-bit
If I am running Windows XP or some regular 32-bit Linux distribution, can I still use gcc 3.4.x to compile a 64-bit A64 version of my code? I have a program that uses 64-bit integers heavily, and I would like it to utilize 64-bit mode in A64, even if this A64 is running a 32-bit OS. Is this possible? Or is 32-bit and 64-bit entirely different "modes" on A64? /David
Re: Pointers in comparison expressions
"Dave Korn" <[EMAIL PROTECTED]> writes: > Since pointer subtraction is well defined, and it returns an int, then ... > > int *a, *b; > > if (a < b) > dosomething (); > > ... is just the same as ... > > int *a, *b; > > if ((b - a) >= 0) > dosomething (); This may not work correctly if ((char*) b - (char*) a) % sizeof int != 0 (which can happen if __alignof__ int < sizeof int). 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: Failure building Ada on i686-pc-mingw32
> Ada fails in stage1; the offender is gnatbind.exe. It crashes even if invoked with no command-line arguments. > Gdb provides the following information: > > > ( gdb) run > Starting program: C:\gcc401install\gccbuild\gcc\stage1/gnatbind.exe >Program received signal SIGSEGV, > Segmentation fault. > 0x004034b7 in __gnat_install_SEH_handler (ER=0x) > at ../../gcc-4.0.1/gcc/ada/seh_init.c:219 > 219 ((int *)ER)[0] = (int)ptr; /* previous handler */ Known bug, fixed on trunk but not on 4.0 branch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20226 Danny
Re: 64-bit on A64 running 32-bit
On Tue, Jul 12, 2005 at 10:58:17PM +0200, David Rasmussen wrote: > Is this possible? Or is 32-bit and 64-bit entirely different "modes" on A64? No it isn't possible. Yes, they are different modes. r~
Re: 64-bit on A64 running 32-bit
On 12 Jul 2005, at 21:58, David Rasmussen wrote: If I am running Windows XP or some regular 32-bit Linux distribution, can I still use gcc 3.4.x to compile a 64-bit A64 version of my code? I have a program that uses 64-bit integers heavily, and I would like it to utilize 64-bit mode in A64, even if this A64 is running a 32-bit OS. Is this possible? Or is 32-bit and 64-bit entirely different "modes" on A64? /David They are different modes -- you need an OS that can transition to the 64 bit modes, so that's Windows 64 bit or a 64-bit Linux distribution, for example. -- Adam
Re: Pointers in comparison expressions
On Tue, Jul 12, 2005 at 05:54:00PM +0100, Dave Korn wrote: > Original Message > >From: Daniel Berlin > >Sent: 12 July 2005 17:33 > > >> I think that even if the use of relational operators other than '==' and > >> '!=' is legal with pointers, the compiler should issue a warning (when > >> the option -Wall is used), as it does for assignment, used as truth > >> values, not surrounded with parentheses. > > > > Why? > > It's legal, it's useful, and used. > > > > --Dan > > > Just to enlarge upon Dan's comment: > > Since pointer subtraction is well defined, and it returns an int, then ... > > int *a, *b; > > if (a < b) > dosomething (); > > ... is just the same as ... > > int *a, *b; > > if ((b - a) >= 0) > dosomething (); > > ... so do you think the compiler should warn about _all_ pointer arithmetic? Pointer subtraction is only well defined if both pointers point to elements in the same array (or one past the end of the array). Otherwise the behaviour is undefined. Relational operators between pointers are only defined if both pointers either point to elements in the same array (or one past the end of the array), or to members of the same structure. Otherwise the result is undefined. Thus, if you have code like: int aa,bb; int *a, *b; a=&aa; b=&bb; Then expressions like "(a>b)" or "(a-b)" both have undefined behaviour, while if you had code like int aa[2]; int *a, *b; a=&(aa[0]); b=&(aa[1]); Then the expressions "(a>b)" and "(a-b") are both well defined (and will have the values 0 and 1 respectively.) If the compiler is certain that the pointers do not point into the same array or structure (as in my first example above) it is probably a good idea to give a warning, but it should not warn for the legal cases (as in my second example.) -- Erik Trulsson [EMAIL PROTECTED]
Re: Pointers in comparison expressions
On Tue, Jul 12, 2005 at 11:42:23PM +0200, Erik Trulsson wrote: > Pointer subtraction is only well defined if both pointers point to elements > in the same array (or one past the end of the array). Otherwise the > behaviour is undefined. While this is correct, there are certain cases that the standard leaves undefined but that nevertheless can be useful; for example, pointer subtraction can be used to estimate the amount of stack in use (of course, it is necessary to know if the stack grows upward or downward). Similarly, in an OS kernel, comparing pointers may make sense. > If the compiler is certain that the pointers do not point into the same > array or structure (as in my first example above) it is probably a good > idea to give a warning, but it should not warn for the legal cases (as in my > second example.) I'd say that would be only useful in terms of a more general analysis that implements bounds checking. Given reliable analysis that finds suspicious pointer comparisons, most users would be more interested in the implicit comparison of a pointer with the boundaries of the array it corresponds to.
Re: Pointers in comparison expressions
On Tue, Jul 12, 2005 at 03:08:54PM -0700, Joe Buck wrote: > On Tue, Jul 12, 2005 at 11:42:23PM +0200, Erik Trulsson wrote: > > Pointer subtraction is only well defined if both pointers point to elements > > in the same array (or one past the end of the array). Otherwise the > > behaviour is undefined. > > While this is correct, there are certain cases that the standard leaves > undefined but that nevertheless can be useful; for example, pointer > subtraction can be used to estimate the amount of stack in use (of > course, it is necessary to know if the stack grows upward or downward). > > Similarly, in an OS kernel, comparing pointers may make sense. Yes, there are some situations where it can be useful to compare pointers to different objects, but then you need to make sure that the compiler you use actually supports that. I believe most C compilers support it in practice, but few, if any, have actually documented it as a supported extension to C. -- Erik Trulsson [EMAIL PROTECTED]
Re: Pointers in comparison expressions
Erik Trulsson <[EMAIL PROTECTED]> writes: > On Tue, Jul 12, 2005 at 03:08:54PM -0700, Joe Buck wrote: >> On Tue, Jul 12, 2005 at 11:42:23PM +0200, Erik Trulsson wrote: >> > Pointer subtraction is only well defined if both pointers point to elements >> > in the same array (or one past the end of the array). Otherwise the >> > behaviour is undefined. >> >> While this is correct, there are certain cases that the standard leaves >> undefined but that nevertheless can be useful; for example, pointer >> subtraction can be used to estimate the amount of stack in use (of >> course, it is necessary to know if the stack grows upward or downward). >> >> Similarly, in an OS kernel, comparing pointers may make sense. > > Yes, there are some situations where it can be useful to compare pointers > to different objects, but then you need to make sure that the compiler you > use actually supports that. > > I believe most C compilers support it in practice, but few, if any, have > actually documented it as a supported extension to C. I don't think we should, either. People who want to do this can just cast both pointers to size_t. -- Falk
Re: Pointers in comparison expressions
On Wed, Jul 13, 2005 at 12:28:47AM +0200, Erik Trulsson wrote: > On Tue, Jul 12, 2005 at 03:08:54PM -0700, Joe Buck wrote: > > On Tue, Jul 12, 2005 at 11:42:23PM +0200, Erik Trulsson wrote: > > > Pointer subtraction is only well defined if both pointers point to > > > elements > > > in the same array (or one past the end of the array). Otherwise the > > > behaviour is undefined. > > > > While this is correct, there are certain cases that the standard leaves > > undefined but that nevertheless can be useful; for example, pointer > > subtraction can be used to estimate the amount of stack in use (of > > course, it is necessary to know if the stack grows upward or downward). > > > > Similarly, in an OS kernel, comparing pointers may make sense. > > Yes, there are some situations where it can be useful to compare pointers > to different objects, but then you need to make sure that the compiler you > use actually supports that. No, you don't need to check. You are confusing standards legalese with industrial practice. You are currently running a computer that depends on such code (whether you run Unix, Linux, BSD, or Windows). In any case, the C standard together with the portable ABI standard that gcc and compatible compilers conform to suffice to guarantee that you can write code that will compare arbitrary pointers safely. Such code is, of course, non-portable, which means that it needs to be tested with each compiler and OS used. The only compilers where there is an issue with pointer comparison are the various memory models for 16-bit segmented architectures (e.g. 16-bit Windows), and even those compilers provide "huge pointers" because sometimes it is necessary to compare pointers beyond the guarantees made by the C standard.
Re: AMD 64 Problem with assembling
On Sat, Jul 09, 2005 at 10:23:14PM +0200, Florian Michel wrote:
>
> Hello,
>
> I have a question concerning successfully assembling and linking the
> following assembly program on a linux AMD 64 machine:
>
> #cpuid2.s View the CPUID Vendor ID string using C library calls
> .section .datatext
> output:
> .asciz "The processor Vendor ID is '%s'\n"
> .section .bss
> .lcomm buffer, 12
> .section .text
> .globl main
> main:
> movl $0, %eax
> cpuid
> movl $buffer, %edi
> movl %ebx, (%edi)
> movl %edx, 4(%edi)
> movl %ecx, 8(%edi)
> push $buffer
> push $output
> call printf
> addl $8, %esp
> push $0
> call exit
>
> This part of a book on assembly programming I am reading.
>
> Compile and Link: gcc -o cpuid2 cpuid2.s
> When running cpuid2 it crashes with a segmentation fault.
> Which switches do I have to add to call gcc?
>
> Thanks a lot!
If you are running on a Linux AMD 64 machine, the default compiler is 64 bit,
which uses a different calling sequence than the traditional 32-bit x86 world.
The above code however is 32 bit. Use the -m32 option.
However, rather than write in assembler, you should use the asm extension to
get the asm code you need. This works on both 32 and 64 bit modes:
#include
int main(int argc, char *argv[])
{
int edx;
int ebx;
int ecx;
union {
int i[4];
char c[16];
} u;
__asm__ ("cpuid"
: "=b" (ebx), "=d" (edx), "=c" (ecx)
: "a" (0));
u.i[0] = ebx;
u.i[1] = edx;
u.i[2] = ecx;
u.i[3] = 0;
printf ("The processor Vendor ID is '%s'\n", u.c);
return 0;
}
--
Michael Meissner
email: [EMAIL PROTECTED]
http://www.the-meissners.org
Re: Where does the C standard describe overflow of signed integers?
On Mon, Jul 11, 2005 at 09:58:36AM -0500, Nicholas Nethercote wrote: > Hi, > > There was recently a very long thread about the overflow behaviour of > signed integers in C. Apparently this is undefined according to the C > standard. I searched the standard on this matter, and while I did find > some paragraphs that described how unsigned integers must wrap around upon > overflow, I couldn't find anything explicit about signed integers. Can > someone point me to the relevant part(s) of the standard? I don't have time to dig out all of the relevant sections, but I was on the ANSI X3J11 committee that defined the C standard from its beginning through the release of the C90 international standard (and some of the C99 work, though I left the committee before a lot of the changes were made). It did come up for discussion, but the committee did decide to leave it undefined, since there were C compilers for some different machines that did not just silently truncate. >From memory, there was one vendor with a machine that had signed magnitude integers. There was a vendor with a machine that had one's complement integers. I suspect at least one vendor used instructions that caused an overflow trap for signed arithmetic. -- Michael Meissner email: [EMAIL PROTECTED] http://www.the-meissners.org
Re: Pointers in comparison expressions
On Wed, Jul 13, 2005 at 12:38:11AM +0200, Falk Hueffner wrote: > Erik Trulsson <[EMAIL PROTECTED]> writes: > > I believe most C compilers support it in practice, but few, if any, have > > actually documented it as a supported extension to C. > > I don't think we should, either. People who want to do this can just > cast both pointers to size_t. If you want to be pedantic, that's not portable; in particular, it will break for some of the memory models used with 16-bit Windows (if you never had to program those, thank your favorite deity). The reason is that, in those modes, different objects can be in different segments, but pointers are only 16 bit. Casting them to size_t won't make them compare correctly or reliably. But for the kind of uses I was describing, that's not a problem: you first cast the pointers into "huge pointers", which are 32 bit, and those huge pointers can be compared reliably. (Complicating the picture were "far pointers", which might be equal but not compare equal if there are overlapping segments). The conclusion is that a direct pointer comparison is just as good as casting to size_t first.
Re: Pointers in comparison expressions
On Tue, Jul 12, 2005 at 06:25:45PM +0200, Mirco Lorenzoni wrote:
> Can a pointer appear in a C/C++ relational expression which doesn't test the
> equality (or the inequality) of that pointer with respect to another pointer?
> For example, are the comparisons in the following program legal code?
>
> /* test.c */
> #include
>
> int main(int argc, char* argv[])
> {
> void *a, *b;
> int aa, bb;
>
> a = &aa;
> b = &bb;
>
> printf("a: %p, b: %p\n", a, b);
> if (a < b)
> printf("a < b\n");
> else
> printf("a >= b\n");
>
> if (b < a)
> printf("b < a\n");
> else
> printf("b >= a\n");
> return 0;
> }
No, this is not legal. Relational tests between pointers is only allowed by
the ISO C standard if the two pointers point into the same array, or if a
pointer points to exactly one byte beyond the array.
>
> P.S.
> I'm not a list subscriber. Send me a copy of your reply, please.
Ummm, I don't understand how you expect to get replies if you don't monitor the
list.
--
Michael Meissner
email: [EMAIL PROTECTED]
http://www.the-meissners.org
Re: Pointers in comparison expressions
On Wed, Jul 13, 2005 at 12:38:11AM +0200, Falk Hueffner wrote: > Erik Trulsson <[EMAIL PROTECTED]> writes: > > > On Tue, Jul 12, 2005 at 03:08:54PM -0700, Joe Buck wrote: > >> On Tue, Jul 12, 2005 at 11:42:23PM +0200, Erik Trulsson wrote: > >> > Pointer subtraction is only well defined if both pointers point to > >> > elements > >> > in the same array (or one past the end of the array). Otherwise the > >> > behaviour is undefined. > >> > >> While this is correct, there are certain cases that the standard leaves > >> undefined but that nevertheless can be useful; for example, pointer > >> subtraction can be used to estimate the amount of stack in use (of > >> course, it is necessary to know if the stack grows upward or downward). > >> > >> Similarly, in an OS kernel, comparing pointers may make sense. > > > > Yes, there are some situations where it can be useful to compare pointers > > to different objects, but then you need to make sure that the compiler you > > use actually supports that. > > > > I believe most C compilers support it in practice, but few, if any, have > > actually documented it as a supported extension to C. > > I don't think we should, either. People who want to do this can just > cast both pointers to size_t. Note, it is not guaranteed that size_t is big enough to hold a pointer. In particular, cast your minds back to when we had 16 and 32-bit x86 code, and some compilers had different memory models like near/far (which was the case when the C90 standard was defined). Size_t could be 16-bits, since the compiler would not allow any item bigger than 32K to be created, but pointers could have the segment pointer as well as the bottom 16-bits. If a compiler knew size_t was restricted to 16 bits, it could eliminate code to normalize the pointer before doing the comparison, and just do a simple subtraction. -- Michael Meissner email: [EMAIL PROTECTED] http://www.the-meissners.org
Re: Pointers in comparison expressions
Joe Buck <[EMAIL PROTECTED]> writes: > On Wed, Jul 13, 2005 at 12:38:11AM +0200, Falk Hueffner wrote: >> Erik Trulsson <[EMAIL PROTECTED]> writes: >> > I believe most C compilers support it in practice, but few, if any, have >> > actually documented it as a supported extension to C. >> >> I don't think we should, either. People who want to do this can just >> cast both pointers to size_t. > > If you want to be pedantic, that's not portable; in particular, it > will break for some of the memory models used with 16-bit Windows You're missing my point; size_t was just an example, whoever does this will know what the correct type is for their system. All I'm saying is that we shouldn't go to the trouble to document and kick along some language extension, maybe even miss some optimization because of it, when there's a perfectly fine alternative to it for the user. -- Falk
gcc-3.4-20050712 is now available
Snapshot gcc-3.4-20050712 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/3.4-20050712/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 3.4 CVS branch with the following options: -rgcc-ss-3_4-20050712 You'll find: gcc-3.4-20050712.tar.bz2 Complete GCC (includes all of below) gcc-core-3.4-20050712.tar.bz2 C front end and core compiler gcc-ada-3.4-20050712.tar.bz2 Ada front end and runtime gcc-g++-3.4-20050712.tar.bz2 C++ front end and runtime gcc-g77-3.4-20050712.tar.bz2 Fortran 77 front end and runtime gcc-java-3.4-20050712.tar.bz2 Java front end and runtime gcc-objc-3.4-20050712.tar.bz2 Objective-C front end and runtime gcc-testsuite-3.4-20050712.tar.bz2The GCC testsuite Diffs from 3.4-20050705 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-3.4 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: Pointers in comparison expressions
On Wed, Jul 13, 2005 at 01:28:14AM +0200, Falk Hueffner wrote: > Joe Buck <[EMAIL PROTECTED]> writes: > > If you want to be pedantic, that's not portable; in particular, it > > will break for some of the memory models used with 16-bit Windows > > You're missing my point; size_t was just an example, whoever does this > will know what the correct type is for their system. I'm afraid that my grey hairs give me an advantage here. You're missing my point; *there is no correct size*! In segmented memory models, the pointers are only offsets in the current segment; casting them to any integer type you choose simply will not work. Casting to size_t (or any other integral type large enough to hold the pointer) never gives any advantage over comparing the pointers directly.
Re: RFC: improving estimate_num_insns
On Jul 12, 2005, at 1:07 PM, Steven Bosscher wrote: You don't say what compiler you used for these measurements. I suppose you used mainline? Yes, I am working with the mainline. I think you should look at a lot more code than this. OK - I stopped because I was seeing fairly consistent results. However, since both of these files were from the same source base, I can see how this may not be representative. I'll try some more examples from different source code, including C++. Thinking that there may be room for improvement on this, I tried this same experiment with a couple of adjustments to estimate_num_insns: - Instead of ignoring constants, assign them a weight of 2 instructions (one for the constant itself and one to load into memory) Why the load into memory, you mean constants that must be loaded from the constant pool? I guess the cost for the constant itself depends on whether it is a legitimate constant or not, and how it is loaded, and this is all very target specific. But a cost greater than 0 probably makes sense. Good point - I was thinking of constant pools when I wrote that, even though that isn't always the case. It would be nice if you retain the comment about constants in the existing code somehow. The cost of constants is not trivial, and you should explain your choice better in a comment. I'm not sure which comment you mean - the one from my email, or the one that was originally in the source code? - Instead of ignoring case labels, assign them a weight of 2 instructions (to represent the cost of control logic to get there) This depends on how the switch statement is expanded, e.g. to a binary decision tree, or to a table jump, or to something smaller than that. So again (like everything else, sadly) this is highly target-specific and even context-specific. I'd think a cost of 2 is too pessimistic in most cases. Do you mean that 2 is too high? I actually got (slightly) better statistical results with a cost of 3, but I had the same reaction (that it was too pessimistic), which is why I settled on 2. You could look at the code in stmt.c to see how switch statements are expanded. Maybe there is a cheap test you can do to make CASE_LABELs free for very small switch statements (i.e. the ones which should never hold you back from inlining the function containing them ;-). I'll look into this. For what it's worth, code size is equal to or smaller for all benchmarks across all platforms. What about the compile time? Oh no! I didn't measure this. I will have a look. So, here are the open issues I see at this point: 1. It appears that this change to estimate_num_instructions generates a much better estimate of actual code size. However, the benchmark results are ambiguous. Is this patch worth considering as-is? I would say you'd at least have to look into the ppc gzip and eon regressions before this is acceptable. But it is not my decision to make, of course. Makes sense. I'll see what kind of time I can put into this. 2. Increasing instruction weights causes the instruction-based values (e.g., --param max-inline-insns-auto) to be effectively lower. However, changing these constants/defaults as in the second patch will cause a semantic change to anyone who is setting these values at the command line. Is that change acceptable? This has constantly changed from one release to the next since GCC 3.3, so I don't think this should be a problem. Whew... Thoughts? Advice? ...on to advice then. First of all, I think you should handle ARRAY_RANGE_REF and ARRAY_REF the same. And you probably should make BIT_FIELD_REF more expensive, and maybe make its cost depend on which bit you're addressing (you can see that in operands 1 and 2 of the BIT_FIELD_REF). Its current cost of just 1 is probably too optimistic, just like the other cases you are trying to address with this patch. Great - thanks for the suggestions, I'll try these changes as well and see if I get even better correlation. Second, you may want to add a target hook to return the cost of target builtins. Even builtins that expand to just one instruction are now counted as 16 insns plus the cost of the arguments list. This badly hurts when you use e.g. SSE intrinsics. It's probably not an issue for the benchmark you looked at now, but maybe you want to look into it anyway, while you're at it. OK, I'll look into this. Third, (measured at -O3 with inlining disabled): Then why not just -O2 with inlining disabled? Now you have enabled loop unswitching, which is known to sometimes significantly increase code size. Well, I thought that inlining estimates were most likely to be relevant at O3, and so I should include as many other optimizations as were likely to be performed alongside inlining, even though this may make it more difficult to get accurate estimates. Fourth, look at _much_ more code than this. I w
Re: RFC: improving estimate_num_insns
First of all, I think you should handle ARRAY_RANGE_REF and ARRAY_REF the same. I don't think so. The latter is a memory reference while the former is more like a NOP_EXPR: it's basically just creating a new array, which can then either be indexed or pointed to.
Re: Some tests in gcc.c-torture rely on undefined behaviour?
On Tue, 12 Jul 2005, Joseph S. Myers wrote: My question is: what exactly is gcc.c-torture testing? It seems to be That GNU C code compiles or executes as expected for GNU C. Is there a definition for GNU C? implement-c.texi and extend.texi have some information about this, are there any other sources? Thanks. Nick
Re: more on duplicate decls
Kenneth Zadeck wrote: The kludge to handle them is documented in cp/name-lookup.c around line 670 Ugh. IMO, the right thing here is that there should be only one FUNCTION_DECL for a given function, ever, period. Default arguments are not part of "the function" in C++; they are an aspect of particular declarations of the function. The problem we're having is that we associate them with the FUNCTION_DECL, rather than with the bindings (mappings from names to FUNCTION_DECLs). Unfortunately, fixing that properly is a rather large change. It seems like a better way is to build a table of merges that need to be done and find some place after the c++ front end is finished but before the cgraph gets built and do one scan of the code and replace all of the offending decls. After the C++ front end is done, it would be OK to canoanicalize all FUNCTION_DECLs with a single UID into one. A stupid way of doing that would be to just walk the entire translation unit, and whenever you find a reference to a non-canonical copy of the FUNCTION_DECL, re-point it at the right one. The C++ front end always operates in unit-at-a-time mode, so, yes, you could do this when the C++ front end is finished. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: The origin of scalar evolutions?
Robert van Engelen wrote:
>
> 1. After reading the paper, we concluded that the scalar evolutions are
> actually a restricted polynomial form of chains of recurrences by
> Bachmann and Zima [6,8]. Is this true? Or is there an essential
> difference with multi-variate chains of recurrences [7]? Does the
> "scalar evolutions" name suggest something else beyond the recurrence
> forms. Are we missing a crucial point?
>
a = {1, +, a}
b = {3, +, [1, 2]}
c = {-, +, +}
d = {abstract_value, +, abstract_value}
are not chains of recurrences. More generally chains of recurrences
use integer or real coefficients, whereas coefficients of scalar
evolutions are over any abstract domain.
a is a mixer (exponential), b is an envelope (interval coefficients),
c is a monotonic evolution (coefficients in {+, -}). The name of
scalar evolutions is not that far from the name "monotonic evolution"
used by Peng Wu, and it seemed appropriate to be used for the general
concept (you're free to disagree with my choice for using this name).
> With respect to our first question, we felt that the use of a new name
> for an existing technique is confusing. For example, by calling a
> "matrix" from linear algebra a "scalar square" we do not change its
> semantics. The (algebraic) operations on matrices are still the same.
> So are the operations on scalar evolutions the same as those on chains
> of recurrences. Janson's classic "History of Art" has apt advice: "It
> has always been easier to invent new labels than to create a movement
> in art that truly deserves a new name."
Do you know why in natural languages we have so many synonyms? Well,
because otherwise poets would compose very poor texts. Poets like to
play with the phonetics of the words because they can express their
moods in the phonemes. Restricting the number of words that point to
the same (or close) semantics would restrict the ability of writers.
Anyway, this is way off topic for this mailing list.
> 2. What is the difference between the SSA-based algorithm described in
> the paper and the G-SSA form proposed in 1995 by Tu and Padua [9].
Not the same. You're rebuilding a higher level tree from the
gimple-ssa form, but then you use abstract domains for representing
some of the difficult evolutions. Analyzers are like poetry: there
always will be room for something new because they are not comparable;
they just fill a missing topic.
>
> 3. Do you compute recurrence forms for pointer variables? If so, what
> is the difference compared to the method described in our 2001 paper
> [2]?
Daniel has already replied to this one and many other questions
(thanks Daniel).
>
> 4. The "peeled" forms are described as "wrap around" forms in the paper
> but do not seem to handle true wrap around variable. How do you handle
> wrap around variables, i.e. those that have the form:
> k = 9;
> for (i=0; i < 10; i++)
> { a[k] = ...
> k = i;
> }
> Can you please explain?
>
In SSA form the previous program is written:
loop_1
c = phi (0, d)
d = c + 1
e = phi (9, c)
a[e] = ...
endloop_1
so you have the following evolutions:
c = {0, +, 1}_1
d = {1, +, 1}_1
e = (9, {0, +, 1}_1)_1
e is a wrap around, whose first value when entering in the loop is 9,
followed in the next iterations by 0, 1, 2, ...
As Daniel has pointed out, this extension sleeps in the lno-branch.
We will consider this extension useful for mainline only the day when
some optimizer will show a net improvement that justifies the extra
burden of maintaining the code.
I also have decided to restrict the polynomials to a degree less or
equal than 2 (affine evolutions) because all the other constructs are
just pure nonsense, and not used by any optimizer or other analyzer.
It's too bad that I have not restricted the analyzer earlier based on
the suggestions from Zdenek Dvorak.
Sebastian
