This is the mail archive of the 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: [v3] update abi docs

> This could get quite big.  Have you thought about how to manage that,
> particularly when there are baseline files for many targets?

No. I'm open to good suggestions though! Phil seems to have some clever
ideas about coalescing baseline files. See the libstdc++ discussion.

> ! It should be possible to use sizeof, alignof, and offset to compute
> ! offsets for each structure and type in the standard library, saving to
> ! another datafile. Then, compute this for new binaries, and look for
> ! differences.
> This would catch changes to the compiler that change the layout of
> existing class definitions, plus inadvertent changes to the class
> definitions themselves within the library sources.  I suppose that it
> won't be difficult to determine the cause when a difference is detected.

Here's hoping. 

Again, this check is designed primarily for the C++ library. If we go
about catching uncaught compiler bugs as well, well then, lucky bonus.
The goal will remain the library though. As Mark's pointed out, this
seems to be the area of non-overlapping work so I'm concentrating on

> ! Another approach might be to use the -fdump-class-hierarchy flag to
> ! get information.
> ! (See g++/7470 on how this was used to find bugs.)
> Nice.  This, too, could result in many large baseline files.  I'm
> interested in how to solve that problem because I would like to see the
> consistency.vlad tests become usable.

Yeah, me too. Also, -fdump-class-hierarchy needs to give more info.

> How does this sound?  We could have a separate CVS tree for individual
> baseline files, with a similar set of files for both the libstdc++
> abi files and for the compiler testsuite's consistency.vlad files.  We
> would also have, available for download, compressed sets of all baseline
> files for a particular target, where "target" here actually means a set
> of targets that share the same baseline files.  Only the people who are
> generating the baseline sets need to deal with the CVS tree containing
> the individual files; everyone else just downloads the sets for the
> targets they are testing and unpacks them on top of their local tree.

Hmmm. This is a possibility, where we could have a 'gcc-abi' module in
the CVS repository or something. Nice idea.

Since many of these tests are still in their infancy, I'm suggesting
that the baselines just get checked into the normal 'gcc' module right
now, as is currently being done. As things get out more and more out of
control, the design can evolve. 

I'm actually inclined to keep the baseline files, regardless of size, in
the main gcc CVS tree.

I dunno. 

Do you have more info on the vlad test baselines? How big are they for


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