Re: How to write testcase with two warnings on one line?
Quoting Feng Wang <[EMAIL PROTECTED]>:
> Hi,
>
> I want to write a testcase. The compiler gives two separated warnings on one
> statement. How to write this with Dejagnu?
I don't think this is possible if both warnings are issued for the same location
(which is probably not something we want). If the loci are different, it is
possible to split the line between the warnings and then proceed as usual, say:
do_first_thing & ! { dg-warning "a" }
& do_second_thing ! { dg-warning "b" }
IIRC there are testcases that do just that.
HTH,
- Tobi
Re: A couple more subversion notes
(I'm sorry that I'm breaking threading, but I don't feel to bad about this given whom I'm replying to, it's not like I'm cutting a huge thread in two) Richard Kenner wrote: > I must say that I find the amount of "fiddling" and special options or > configurations needed here very disturbing. People make a comment and one > of the experts gives an answer of the form "oh, just turn on obscure option in some tool>". > > This is barely described in a wiki, let alone in any real documentation. And > lots of people don't even like to read documentation. Plus, a huge amount of > hackery will scare people off. All these options are meant to address specific concerns people are having, they are not required to use svn effectively. ssh multiplexing in particular applies equally well to cvs as well. > I'm very concerned that we're greating increasing the barrier to entry for > work on GCC. cvs is very intuitive and simple to use. I'm not seeing the > same thing for svn/svk, but instead a series of increasingly complex > suggestions on how to do things efficiently. If you don't want to do things more effectively than in cvs (svn merge comes to mind) there really is no great difference in using svn. Tags, branches and revisions are in my opinion _much_ easier to understand in svn. How many people really understand how cvs version numbers come about, when stuff ends up in the attic etc (I remember this question appearing on fortran@ just last week); how again do you figure out the set of files changed in a single cvs commit (you don't, you search through the gcc-cvs archives) etc. svn _is_ easier, and it's not difficult to install, as the downloadable source tarball is self-contained (or "reasonably self-contained", it required no additional downloads for building on the rather barebones setup my institute is using) > Saying "casual developers of GCC can use snapshots" is not something I think > we ought to be doing. I don't think so either. Since a lot of people have expressed concerns WRT to the switch, I'd like to say that I'm all in favor of switching, and I think that I'm speaking for a not-so-vocal majority. I've had to wait for a lock too often, and working on branches (esp backporting patches) has cost too much of time for me to be a fan of staying with cvs. The increased disk usage will be compensated for by the easy means of switching a checked-out tree between branches. The only issue I'm having is that there seems to be no way of excluding certain directories in a checkout, e.g. I have zero interest in Ada, yet it takes up a lot of diskspace (and no, 'svn co -N' is no alternative). Finally, the move to subversion was agreed to in February, the increased disk usage was discussed then, and a test repository was setup back then. I found a few issues (svn ann ChangeLog comes to mind) which I made sure Daniel Berlin knew about, and the next released version of subversion contained fixes for them. It completely escapes me why so many people didn't deem it necessary to give it a spin back then, especially given the fact that Daniel Berlin committed to fixing any issues that came up in the testing. Even now very few people have actually tried working with svn -- the repository revision has increased by less than ten revisions since I originally checked out the tree a few days ago. - Tobi (Disclaimer: I've been using svn a little before the test repository was set up, but only on very small projects, nevertheless I heavily used tags there simply because it was so easy compared to cvs)
Re: Vectorizing HIRLAM 4: complicated access patterns examined.
[ Bringing this back to fortran@, taking the optimizer guys out of CC: ] Quoting Toon Moene: > I still have to construct a bug report of something that confuses the parser > and that basically looks like this: > > IMPLICIT CHARACTER*8 (Y) > CHARACTER*11 Y1, Y2, Y3 > ... > YA = 'D' // Y1 // Y2(1:3) // Y3(1:3) // > 1 // YB(1:5) > 1 > Unclassifiable statement at (1) > > Unfortunately, if I reduce the code to this one (continued) line and the > necessary declarations, it doesn't fail ;-) Does this fail as long as you keep the type implicit? This reminds me of another PR, where the parser would decide too early that it had seen an array range instead of a substring, which would lead to these kinds of niceties further down the line. Unfortunately, I couldn't find this bug in bugzilla, looks like its PR's summary is not very descriptive. - Tobi
Re: Vectorizing HIRLAM 4: complicated access patterns examined.
Quoting Jakub Jelinek <[EMAIL PROTECTED]>: > On Tue, Nov 01, 2005 at 02:01:43PM +0100, > [EMAIL PROTECTED] wrote: > > [ Bringing this back to fortran@, taking the optimizer guys out of CC: ] > > > > Quoting Toon Moene: > > > I still have to construct a bug report of something that confuses the > parser > > > and that basically looks like this: > > > > > > IMPLICIT CHARACTER*8 (Y) > > > CHARACTER*11 Y1, Y2, Y3 > > > ... > > > YA = 'D' // Y1 // Y2(1:3) // Y3(1:3) // > > > 1 // YB(1:5) > > > 1 > > > Unclassifiable statement at (1) > > > > > > Unfortunately, if I reduce the code to this one (continued) line and the > > > necessary declarations, it doesn't fail ;-) > > > > Does this fail as long as you keep the type implicit? This reminds me of > > another PR, where the parser would decide too early that it had seen an > array > > range instead of a substring, which would lead to these kinds of niceties > > further down the line. Unfortunately, I couldn't find this bug in > bugzilla, > > looks like its PR's summary is not very descriptive. > > You mean PR18833? Yes, but I don't have time right now to investigate if this is indeed the same parser problem. The patch for 18833 only added a special case for EQUIVALENCEs, so it might well be. - Tobi
Re: Build using --with-gmp and shared libraries
Quoting Janne Blomqvist <[EMAIL PROTECTED]>: > Would it be possible to replace gmp with mpfr entirely? Or do we use > gmp functionality that isn't found in mpfr? We use mpz_* for our integer handling, so that's not an option, unfortunately. - Tobi
Re: What happened to bubblestrap?
Quoting Paolo Bonzini <[EMAIL PROTECTED]>: > Yes. "make bubblestrap" is now called simply "make". As Giovanni put > it a few minutes ago: > > "I would also note that using "make" in the cp/ directory at least used > to build cc1plus with the system compiler, without -Werror and with a > different set of warnings. There have been many cases where a patch > tested by C++ rules (which is *not* a full bootstrap, but just "build > compiler, build libjava, check c++") resulted in a bootstrap failure > because of a variable not initialized or something. The correct solution > used to be (guess what!) "make bubblestrap" to build the compiler. Now, > it's simply the default :)" Cool. Of course I didn't notice, because the first build after the switch was from scratch :-) - Tobi
Re: Compilation time has more than doubled on some Polyhedron tests
[ Added gcc@gcc.gnu.org to the CC list and included Dominique's mail in full, as the problem might well be in the common code. ] Quoting Dominique Dhumieres <[EMAIL PROTECTED]>: > I have the following timing for the compilation of the polyhedron tests > on a 1.8Ghz G5 with: > > gfortran -w -O3 -ftree-loop-linear -ffast-math -funroll-loops > > for the following snapshots patched with the Paul Thomas' optimization of > dot_product. > > snapshot 12/24 12/31 01/07 01/14 > > ac5.8s 6.0s 24.7s 23.0s+ > aermod 223.9s227.3s485.8s467.6s+ > air 21.0s 21.6s 8.2s 8.0s- > capacita 4.6s 4.7s 5.8s 5.6s > channel 2.5s 2.5s 17.6s 17.7s+ > doduc19.7s 20.0s 38.6s 37.0s+ > fatigue 15.0s 15.4s 7.2s 6.8s- > gas_dyn 8.6s 8.8s 19.6s 18.5s+ > induct 28.1s 28.7s 66.1s 61.6s+ > kepler0.6s 0.6s 1.1s 1.0s+ > linpk 1.4s 1.4s 1.4s 1.4s > mdbx 5.3s 5.4s 6.9s 6.5s > nf3.6s 3.6s 4.4s 4.3s > protein 15.5s 15.9s 15.9s 14.5s > rnflow 11.4s 11.6s 12.6s 12.7s > test_fpu 8.4s 8.5s 8.8s 8.5s > tfft 1.3s 1.3s 1.8s 1.7s > > I only noticed it today, but there has been a noticable change in the > compilation time between the 20051231 and 20060107 snapshots: > air.f90 and fatigue.f90 compile twice faster, but aermode.f90, > doduc.f90, gas_dyn.f90, induct.f90, and kepler.f90 compile twice slower, > while ac.f90 takes four more time and channel.f90 takes seven more time. > > Am I the only one to see that? If not, does any one has any idea of what > caused this slow down in compilation? > > Using the François-Xavier's builds I have narrowed the problem between the > 05/01 and the 06/01: > > [scala] gfortran/2006> time irun/bin/gfortran -v -O3 -ffast-math > -funroll-loops induct.f90 > ... > GNU F95 version 4.2.0 20060105 (experimental) (x86_64-unknown-linux-gnu) > ... > 19.375u 0.250s 0:20.39 96.2%0+0k 0+0io 0pf+0w > > [scala] gfortran/2006> time irun/bin/gfortran -v -O3 -ffast-math > -funroll-loops induct.f90 > ... > GNU F95 version 4.2.0 20060106 (experimental) (x86_64-unknown-linux-gnu) > ... > 33.865u 0.362s 0:35.09 97.5%0+0k 0+0io 0pf+0w > > TIA > > Dominique > > On the induct.f90 test I get with the latest snapshot: > > optionscompile exec > > -O3 -ftree-loop-linear -ffast-math -funroll-loops 62.766.7 > -O3 -ffast-math -funroll-loops61.066.6 > -O3 -ffast-math 59.572.0 > -O3 -funroll-loops60.181.1 > -O3 59.581.4 > -O2 -ffast-math -funroll-loops60.167.0 > -O2 -ffast-math 54.3 154.5 > -O2 -funroll-loops58.781.0 > -O2 55.2 112.3 > -O1 -ffast-math -funroll-loops14.680.5 > -O1 -ffast-math 12.6 160.3 > -O1 -funroll-loops14.4 105.7 > -O1 12.7 164.4 > -O0 -ffast-math -funroll-loops 3.3 638.0 > -O03.4 634.4 Are you building with --enable-checking (the default)? Can you try compiling some of the most-affected files with -ftime-report, so that we can see where the slowdown occured? - Tobi
Missing new file
Zdenek, you forgot to add tree-ssa-loop-prefetch.c in your latest commit, which breaks bootstrap. Regards, - Tobi
Re: How can I remove articles posted under my name?
[ cutting down the CC list ] Alexander Verhaeghe <[EMAIL PROTECTED]> wrote on Mon, 26 Jun 2006: As the title says, how can I remove articles posted under my name "Alexander Verhaeghe" or e-mailaddress "alexanderverhaeghe at yahoo dot com" When I do a search in http://gcc.gnu.org/lists.html I get 8 results which I would like to have removed, espcially when they popup in the searchengines. You've just added another 2 to that list. Had you not misspelled gnu.org once that would have been three. Needless to say that these 2 will be reproduced on several other list archives, including gmane.org which you found before. Please stop spamming the lists with requests to be removed from the list archives hosted on gcc.gnu.org and other, unrelated sites. As other people have pointed out to you, this is not going to happen (reg. my previous answers, I might add that I wasn't aware that there's a policy in place against this, but it makes a lot of sense), and the lists themselves are the wrong place to ask for this. If you don't want your address published, this originally happened a year ago, when you originally posted to the list and only turning back time can revert this fact. If you don't want unfavorably looking posts appearing in a google search of your name, you've not done yourself a favor with today's series of posts. Sorry, - Tobi This message was sent using IMP, the Internet Messaging Program.
