This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [trunk<-vta] Re: [vta,vta4.3,trunk?] introduce -fcompare-debug


On Jun  2, 2009, Ian Lance Taylor <iant@google.com> wrote:

> Alexandre Oliva <aoliva@redhat.com> writes:
>>> I don't fully understand what the proposed option does, so I don't know
>>> if this comment applies: if this is for a run-time option to improve
>>> checking, then it should not be a -f option, it should be a --param.  -f
>>> options are for users.  --param options are for developers.
>> 
>> Err...  -fdump-*, -fsched-verbose, etc are all -f options.  Besides, --*
>> is an alias for -f*, so --param is -fparam.  And then, most if not all
>> params I'm aware of are for users rather than for developers.

> Please consider what I am really saying, and if you want to pick nits
> then consider how gcc has developed historically.

Honestly, I don't know what you're getting at.  Even -fdump-* are recent
additions, earlier it was just -d<letter>.  I don't recall whether
--param is newer or older, but I don't see what âfor developersâ means.
For GCC developers?  Or for GCC users that are developers, rather than
say gentoo users?  I took your statement as meaning GCC developers,
which is what got me to question it with -fdump-*, but even if you meant
GCC users that are developers, I don't quite see the distinction you're
suggesting between -fwhatever=N and --param whatever=N, and the manual
doesn't mention it either.  The one bit that appears to point in that
direction is the paragraph about the options being related with
internals and subject to change without notice.  That's certainly not
the case of -fcompare-debug.  Besides, --param opt=N requires N to be a
number, whereas -fcompare-debug[="opt opt"] can take multiple
command-line options.

>> Anyhow, what the option does is to compile twice, once with the given
>> flags, once adding the flags given to -fcompare-debug, and comparing the
>> final RTL they generate to check that it is the same.

> Is this worth doing in gcc rather than in a wrapper script and/or in the
> testsuite?  It's a serious question.

It's something I considered, but decided it made more sense to do it
this way, for the following reasons:

1. it's a trivial drop-in for testsuite runs, for bootstrap stages, and
for target libraries.  A script in STAGE_CC_WRAPPER would work for most
stuff, but certainly not (without further work) for the compiler calls
from within gnatmake.

2. we didn't have an option to dump the internals of the compiler in a
suitable format for this comparison, so we'd have to introduce one
anyway.

3. controlling the compiler output (stdout/stderr) and other files
generated as side effects of compilation is not so easy when you're
wrapping around the compiler.  The compiler ends up requiring some means
to tell it âhey, I'm on the recompile, don't overwrite stuff now that
you just wrote beforeâ (e.g. gcov, C++ repo, Ada ali, some Fortran
user-visible data layout dumps).

4. there's really no way to implement say -gtoggle without duplicating
GCC's command line handling, including the way duplicates and overrides
work (inconsistently, mind you).  And then, there might be other
wrappers that tweak command-line options adding or removing -g-related
flags.

None of this says -fcompare-debug (however it's named) must be
implemented in the compiler driver rather than in a wrapper, but it
seems to me to make far more sense there than elsewhere.

Ideally, this flag or at least BUILD_CONFIG=bootstrap-debug should
become part of the standard requirements for testing patches, so that we
don't regress on -g/-g0 stability *and* we get faster and leaner (or,
optionally, slower and more thoroughly tested with -fcompare-debug)
bootstraps while at that.

-- 
Alexandre Oliva, freedom fighter    http://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/   FSF Latin America board member
Free Software Evangelist      Red Hat Brazil Compiler Engineer


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]