public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
* Automatically testing gcc
@ 2011-08-13  1:09 Dimitrios Apostolou
  2011-08-14 14:43 ` Paolo Bonzini
  0 siblings, 1 reply; 2+ messages in thread
From: Dimitrios Apostolou @ 2011-08-13  1:09 UTC (permalink / raw)
  To: gcc-help; +Cc: Steven Bosscher, Paolo Bonzini

Hello list,

I've two questions regarding testing:

First, how can I make sure that my change did not affect code generation 
at all? Ideally I would like to run the test-suite on trunk, then on the 
patched version, and diff all object files. Is there an automated way?

Also is it guaranteed that two runs on all testsuite will always produce 
the same code? Or are there maybe some passes that don't guarantee 
determinism?

Second, given that I made a tiny change in the logic, can I make sure that 
there is no case that would generate worse code? Is there automated way 
for that? Does it involve benchmarking or somehow measuring code quality?


Thanks in advance,
Dimitris

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: Automatically testing gcc
  2011-08-13  1:09 Automatically testing gcc Dimitrios Apostolou
@ 2011-08-14 14:43 ` Paolo Bonzini
  0 siblings, 0 replies; 2+ messages in thread
From: Paolo Bonzini @ 2011-08-14 14:43 UTC (permalink / raw)
  To: Dimitrios Apostolou; +Cc: Steven Bosscher, gcc-help

On Sat, Aug 13, 2011 at 03:09, Dimitrios Apostolou <jimis@gmx.net> wrote:
> Hello list,
>
> I've two questions regarding testing:
>
> First, how can I make sure that my change did not affect code generation at
> all? Ideally I would like to run the test-suite on trunk, then on the
> patched version, and diff all object files. Is there an automated way?

There are automated scripts for .s comparison across all the testsuite
but I don't have them.  Usually I just try a bunch of .i files (from
cc1 or elsewhere) and compare the output of those.

> Also is it guaranteed that two runs on all testsuite will always produce the
> same code? Or are there maybe some passes that don't guarantee determinism?

No, that would be a bug.

> Second, given that I made a tiny change in the logic, can I make sure that
> there is no case that would generate worse code? Is there automated way for
> that? Does it involve benchmarking or somehow measuring code quality?

There is SPEC, but it's proprietary and expensive.

Paolo

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2011-08-14 14:43 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-08-13  1:09 Automatically testing gcc Dimitrios Apostolou
2011-08-14 14:43 ` Paolo Bonzini

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).