RE: Using DejaGNU on GCC's Testsuite
Thanks, but how come nobody noticed that some of these tests
(gcc.dg/pr27528.c and some others) needed the line
{ dg-options "-O0" } instead of { dg-options "" } ?
-
From : Jonathan Wakely
On : 20/08/2012
On 20/08/2012, PARAT Didier wrote:
> Hi,
>
> I am using DejaGNU on GCC's Testsuite and a problem appeared to me, some
> tests fail when they shouldn't be.
>
> For example: The test gcc.dg/pr27528.c has the line " /* { dg-options "" }
> */ " which means that this test should be compiled without any options,
> right?
Wrong. It means an empty string should be appended to the list of
default optio.s (at least that's what it means for libstdc++ tests,
where the defaults come from scripts/testsuite_flags)
> But DejaGNU seems to pass some basic options anyway (for ex. -O1,
> -O2, etc...) and this causes the test to fail because it is meant to be
> tested without optimizations.
Then maybe it should use { dg-options "-O0" }
> I saw this problem with a lot more testcases causing them to have two
> optimization level in the same command line "gcc ... -O1 -O2 -o ...". This
> problem seems to happen when the testcase has some specific options in the
> line dg_options, for ex. " /* { dg-options "-O2" } */ ".
That's not a problem, the last -On option overrides any earlier ones.
> Did anyone ever try to run the GCC testsuite with DejaGNU and notice this
> kind of things?
>
> I'm using DejaGNU 1.5
>
> Thanks,
> Didier
>
-
Re: at exit alternative for AIX
On 21 August 2012 00:55, Perry Smith wrote: > > I have added __cxa_atexit and __cxa_finalize in the libstdc++ library > instead of the libgcc library because it is only used by g++ and not gcc. That doesn't sound right, not all C++ programs link to libstdc++ and not all C++ programs are compiled with g++. gcc and g++ are both simply drivers that invoke the actually compiler (cc1 for C and cc1plus for C++) so you can use either driver for C++ code, allowing the driver to invoke the right compiler by inferring the source language from the file extension or being told it with the -x option.
Re: Using DejaGNU on GCC's Testsuite
On 21 August 2012 09:20, PARAT Didier wrote:
>
> Thanks, but how come nobody noticed that some of these tests
> (gcc.dg/pr27528.c and some others) needed the line
> { dg-options "-O0" } instead of { dg-options "" } ?
Probably because they're not failing for most people, see e.g.
http://gcc.gnu.org/ml/gcc-testresults/2012-08/msg02023.html
Re: Using DejaGNU on GCC's Testsuite
PARAT Didier writes:
> For example: The test gcc.dg/pr27528.c has the line " /* { dg-options
> "" } */ " which means that this test should be compiled without any
> options, right? But DejaGNU seems to pass some basic options anyway
> (for ex. -O1, -O2, etc...)
Does it? Only c-torture tests normally do that. What does the testuite
log file says for that test?
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
RE: Using DejaGNU on GCC's Testsuite
If no options are passed to DejaGNU for the GCC testsuite,
it will take default ones in testsuite/lib/gcc-dg.exp and
testsuite/lib/c-torture.exp. So 'dg' tests, as well as c-torture,
use basic options.
By the way, I'm working on gcc-4.5.2 (gnat-6.4.2)
-
From : Andreas Schwab
On 21/08/2012
PARAT Didier writes:
> For example: The test gcc.dg/pr27528.c has the line " /* { dg-options
> "" } */ " which means that this test should be compiled without any
> options, right? But DejaGNU seems to pass some basic options anyway
> (for ex. -O1, -O2, etc...)
Does it? Only c-torture tests normally do that. What does the testuite
log file says for that test?
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
-
Re: Using DejaGNU on GCC's Testsuite
PARAT Didier writes: > If no options are passed to DejaGNU for the GCC testsuite, > it will take default ones in testsuite/lib/gcc-dg.exp and > testsuite/lib/c-torture.exp. So 'dg' tests, as well as c-torture, > use basic options. gcc.dg/dg.exp doesn't use gcc-dg-runtest (and never did). Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Optimising/cleaning-up GSOC summary. What was done, future directions.
This year's GSOC has come to an end. In a very brief summary, I achieved a few things this summer: Ported patches from last year - some made it to mainline, extended old patches and resubmitted them, wrote new but mostly small clean-ups/speed-ups. In a nutshell: [DF] Generate REFs in REGNO order http://gcc.gnu.org/ml/gcc-patches/2012-05/msg01348.html Show hash table stats when -fmem-report http://gcc.gnu.org/ml/gcc-patches/2012-05/msg01392.html http://gcc.gnu.org/ml/gcc-patches/2012-08/ [line-map] simple oneliner that speeds up track-macro-expansion http://gcc.gnu.org/ml/gcc-patches/2012-06/msg00163.html PR #53525 - track-macro-expansion performance regression http://gcc.gnu.org/ml/gcc-patches/2012-07/msg00284.html PR 51094 - fprint_w() in output_addr_const() reinstated http://gcc.gnu.org/ml/gcc-patches/2012-07/msg00345.html [libiberty] add obstack macros http://gcc.gnu.org/ml/gcc-patches/2012-08/msg00214.html Assembly output optimisations http://gcc.gnu.org/ml/gcc-patches/2012-08/msg00329.html A pool of small patches I had not sent until the end of GSOC. See full thread: http://gcc.gnu.org/ml/gcc-patches/2012-08/msg01245.html strnlen in libiberty http://gcc.gnu.org/ml/gcc-patches/2012-08/msg00333.html All in all I plan to resubmit the patches that haven't made it to mainline, after doing extra changes in some (like converting the hash table statistics patch to be generic with only code in hashtab.c, though I have doubts of its usefulness now that more and more code is moving to C++ hash tables). However I couldn't complete some deeper stuff I started working on. For example all the strlen() calls on identifier strings seem superfluous, so I tried converting str to a flexible-array member in struct ht_identifier, so that length is always at str[-4]. I hadn't noticed that it would translate to a change in tree_identifier, which lead to a whole number of changes in irrelevant points. I gave up after getting errors on gengtype generated files. See more thorough reports concerning my failed attempts at http://gcc.gnu.org/ml/gcc-patches/2012-08/msg01362.html http://gcc.gnu.org/ml/gcc-patches/2012-08/msg01356.html Other than that, I think a good portion of my time this summer went to coding a valgrind parser: from callgrind profile to SVG. It was first presented at [1] and the source is at [2]. I plan to document it a little and make a proper project out of it. You can see it live at [3], just make sure you click on the individual points. [1] http://gcc.gnu.org/ml/gcc/2012-06/msg00373.html [2] https://code.launchpad.net/~jimis/+junk/callgrind_parser [3] http://teras-ics.mooo.com:8003/ I believe I've incorporated most ideas we discussed in Cauldron, please let me know of any more ideas that come to mind. I am now in the process of moving all the backend to the compile farm (waiting for a support request to be processed since my requirements are pretty high) and last step will be emailing @overseers for hosting somewhere more appropriate. Overall, the experience was great and I am sure that even though summer ends here my involvement with the GCC community will keep going. I had a great time, I'm glad I met most of you people in Cauldron, I hope we keep in touch. Thanks Andrey for your kind mentoring, thanks to everybody else for comments, patch reviews, opinions, and finally thanks Google for funding open source development in such an awesome manner! Yours, Dimitris
Auto-stuff in GCC
Hi, I was planning to include this in my final report, but it turned out big enough as a rant to send it separately. About my patch at [1], since I was using strnlen() in one of my dwarf2out patches I had to also make sure configure tested for its availability, and also provide it in libiberty for targets missing it. This process proved way more tedious than it ought to be, and even after completing it there were some licensing issues because of GPL incompatibilities since I borrowed code from gnulib. I /think/ the discussion ended up proving there are no issues, so I'll try pushing the patch again. [1] http://gcc.gnu.org/ml/gcc-patches/2012-08/msg00333.html It is a pity however to have such issues in-between GPL programs. IMHO it would be awesome if all the necessary bits from gnulib were included to GCC, so we could use all the automatic auto* tools that help with multi-platform development. Moreover, while messing with the auto-stuff in GCC I also made an attempt to enable AM_SILENT_RULES in automake. But it seems each directory is configured in a different manner, and I think automake is not even used in most. I'm sure I haven't understood the architecture of GCC's autotools stack, so I'd appreciate pointers to any documentation describing it, or mentioning things that should be cleaned up. I wanted to make even more changes for cleaning up the build process, but I have to figure it out at first. Thanks, Dimitris
Re: Optimising/cleaning-up GSOC summary. What was done, future directions.
On Tue, Aug 21, 2012 at 10:26 AM, Dimitrios Apostolou wrote: > > In a very brief summary, I achieved a few things this summer: Ported patches > from last year - some made it to mainline, extended old patches and > resubmitted them, wrote new but mostly small clean-ups/speed-ups.k Thanks for all your work on this. Ian
