Re: ACATS

Re: ACATS

[Richard Kenner]

    The point of using the vendor branch is to have *both* the original form
    (on the vendor branch) and the GCC version (on the mainline) in CVS - and
    when a new version is imported onto the vendor branch, CVS should be able
    to help with a lot of the work of merging onto the mainline.  The CVS
    experts here can probably provide step-by-step instructions for doing this
    and indications of the pitfalls.

I think there's a disconnect here.

The issue is that the *format*, not the *content*, of the two branches
is fundamentally different.  The ACATS cvs contains one file per test
while the GCC ACATS cvs would contain one file per *compilation unit*
and there are often multiple such per test.

Re: ACATS

[Mark Mitchell]

> I believe Mark said all maintainers could approve patches for the 3.4
> branch using the "usual rules" - which are a bit fuzzy when it comes
> to non-regression bugfixes, I admit.  

If it's not a documentation change and it's not a regression
fix, it needs my OK, unless I've otherwise explicitly 
delegated/preapproved it.

> If you want his opinion it is best to cc: him personally.

Indeed.  I tend to get somewhat behind on GCC mail, reading it in batch 
mode every few days.

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com

Re: ACATS

[Zack Weinberg]

kenner@vlsi1.ultra.nyu.edu (Richard Kenner) writes:

>     Thank you. That fixed the problem.
>
> Even though it's not a regression, it's a serious bug, a very safe fix,
> and something that only affects Ada, so it could probably go into the
> 3.4 branch, but that's up to Mark.

I believe Mark said all maintainers could approve patches for the 3.4
branch using the "usual rules" - which are a bit fuzzy when it comes
to non-regression bugfixes, I admit.  

If you want his opinion it is best to cc: him personally.

zw

Re: ACATS

[Richard Kenner]

    Thank you. That fixed the problem.

Even though it's not a regression, it's a serious bug, a very safe fix,
and something that only affects Ada, so it could probably go into the
3.4 branch, but that's up to Mark.

Re: ACATS

[Richard Kenner]

    Yes, it's in my code:

         if (typecode =3D=3D ARRAY_TYPE)
                {
                  if (! compare_constant (TREE_PURPOSE (l1),
                                          TREE_PURPOSE (l2)))
                    return 0;
                }
    and I still have the problem.

This fix was to insert a case for VIEW_CONVERT_EXPR with the other
conversions in compare_constant.  Look at the head sources if unclear.

Re: ACATS

[John R. Shannon]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Yes, it's in my code:

         if (typecode == ARRAY_TYPE)
                {
                  if (! compare_constant (TREE_PURPOSE (l1),
                                          TREE_PURPOSE (l2)))
                    return 0;
                }
and I still have the problem.

On Thursday 29 April 2004 10:47 am, Richard Kenner wrote:
>     An answer to "What's actually at .L123 ?" :
>
> I fixed this a while ago.  Do you have this fix and still have the problem?
>
> 2004-04-19  Richard Kenner  <kenner@vlsi1.ultra.nyu.edu>
>
> 	* varasm.c (compare_constant, case VIEW_CONVERT_EXPR): Add case.

- -- 

John R. Shannon
john@johnrshannon.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (NetBSD)

iEYEARECAAYFAkCRN0sACgkQOKbCxya4HYsuXwCgrs1luBhcZFDq+CcGiX8k12JJ
6AsAn1IA1PMYxEbvYQXzYK/uv4qzxJV1
=9E2Z
-----END PGP SIGNATURE-----

Re: ACATS

[Richard Kenner]

    An answer to "What's actually at .L123 ?" :

I fixed this a while ago.  Do you have this fix and still have the problem?

2004-04-19  Richard Kenner  <kenner@vlsi1.ultra.nyu.edu>

	* varasm.c (compare_constant, case VIEW_CONVERT_EXPR): Add case.

Re: ACATS

[John R. Shannon]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

An answer to "What's actually at .L123 ?" :

.LC123:
        .long   1
        .long   1
        .long   1
        .long   1
        .long   1
        .long   1
        .long   1
        .long   1
        .long   1
        .long   1
        .long   1
        .long   1
        .long   1
        .long   1
        .long   1
        .data
        .align 16
.LC68:
        .quad   .LC124
        .quad   .LC59
        .section        .rodata
        .align 8

Replacing LC124 with LC123 in LC68 fixes the problem and allows the test case 
(this is one of the ACATS tests) to pass.

P.S.:

gcc -v
Reading specs from /usr/pkg/tasking/lib/gcc/x86_64--netbsdelf2.0/3.4.0/specs
Configured 
with: /home/drochner/netbsd/pkg/wip/gcc-3.4-ada/work.x86_64/gcc-3.4.0/configure 
- --enable-languages=c,ada --prefix=/usr/pkg/tasking 
- --host=x86_64--netbsdelf2.0
Thread model: posix
gcc version 3.4.0

Same test works in ix86 -- netbsdelf2.0


On Thursday 29 April 2004 10:18 am, Dave Korn wrote:
> > -----Original Message-----
> > From: gcc-owner On Behalf Of John R. Shannon
> > Sent: 29 April 2004 16:59
> >
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Thank you. I have a case of '.L124' being reference where it
> > should be '.L123'.
>
>   Ouch.  Grep the source for ASM_OUTPUT_INTERNAL_LABEL where the second
> parameter is "L", and you'll see that these are generated in
> final_scan_insn in final.c, using CODE_LABEL_NUMBER (insn).  However
> defaults.h also implements default definitions of ASM_OUTPUT_ADDR_VEC_ELT
> and
> ASM_OUTPUT_DEBUG_LABEL from ASM_OUTPUT_INTERNAL_LABEL.  So your problem may
> be specifically related either to switch....case constructs, or to debug
> info, or your problem may be more generic.  What's actually at .L123 ?
>
>   The problem seems likely to be that either the CODE_LABEL_NUMBER field of
> the insn is getting stomped on, or something is damaging the operand of the
> reference in the label_ref.  It might become clear which by following the
> rtl dumps through the various stages; or it might be something you can
> locate easily by setting a watchpoint or two with gdb.  I'd suspect
> something going wrong when insns get deleted, myself.
>
>
>
>     cheers,
>       DaveK

- -- 

John R. Shannon
john@johnrshannon.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (NetBSD)

iEYEARECAAYFAkCRL8cACgkQOKbCxya4HYv6nACeJyvvE8dhCNPyVpE/O3Z1DxPb
VhQAn0WR6m0cru8OW9WLaAtkmy8hGa/g
=eXNv
-----END PGP SIGNATURE-----

RE: ACATS

[Dave Korn]

> -----Original Message-----
> From: gcc-owner On Behalf Of John R. Shannon
> Sent: 29 April 2004 16:59

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Thank you. I have a case of '.L124' being reference where it 
> should be '.L123'.


  Ouch.  Grep the source for ASM_OUTPUT_INTERNAL_LABEL where the second
parameter is "L", and you'll see that these are generated in final_scan_insn
in final.c, using CODE_LABEL_NUMBER (insn).  However defaults.h also
implements default definitions of ASM_OUTPUT_ADDR_VEC_ELT and
ASM_OUTPUT_DEBUG_LABEL from ASM_OUTPUT_INTERNAL_LABEL.  So your problem may
be specifically related either to switch....case constructs, or to debug
info, or your problem may be more generic.  What's actually at .L123 ?

  The problem seems likely to be that either the CODE_LABEL_NUMBER field of
the insn is getting stomped on, or something is damaging the operand of the
reference in the label_ref.  It might become clear which by following the
rtl dumps through the various stages; or it might be something you can
locate easily by setting a watchpoint or two with gdb.  I'd suspect
something going wrong when insns get deleted, myself.



    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....

Re: ACATS

[John R. Shannon]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Thank you. I have a case of '.L124' being reference where it should be 
'.L123'.

On Thursday 29 April 2004 6:45 am, Dave Korn wrote:
> > -----Original Message-----
> > From: gcc-owner On Behalf Of John R. Shannon
> > Sent: 29 April 2004 13:20
> >
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > I'm sorry, but I don't understand your reply.
> >
> > On Thursday 29 April 2004 6:13 am, Dave Korn wrote:
> > > > -----Original Message-----
> > > > From: gcc-owner On Behalf Of John R. Shannon
> > > > Sent: 29 April 2004 13:09
> > > > To: gcc@gcc.gnu.org
> > > > Subject: ACATS
> > > >
> > > > -----BEGIN PGP SIGNED MESSAGE-----
> > > > Hash: SHA1
> > > >
> > > > Could someone please point me in the right direction in
> > > > chasing down undefined
> > > > references to `.LC124' and `.LC93' in gnatlink? Off-hand, I
> > > > don't see where
> > > > the references come from.
> > >
> > >  --save-temps
>
> Run your compiles with --save-temps on the command line.  That'll save the
> generated assembler files.  Any label beginning ".LC" is a local label
> (usually a string constant or switch..case jump table); that is, it should
> be both defined and referred to in the same file.  You should be able to
> see if gcc is generating the wrong label in the reference, or is forgetting
> to output the label definition in front of the object it refers to, or if
> they look valid but there's some accident perhaps to do with what section
> they end up in that's confusing the link.
>
>
>     cheers,
>       DaveK

- -- 

John R. Shannon
john@johnrshannon.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (NetBSD)

iEYEARECAAYFAkCRJjYACgkQOKbCxya4HYtpIACfUTUzhWscVfbX/YEop64T0C1I
wMwAn1H9NvsQkjinPBAIO98QeRulZrkE
=WUjM
-----END PGP SIGNATURE-----

RE: ACATS

[Dave Korn]

> -----Original Message-----
> From: gcc-owner On Behalf Of John R. Shannon
> Sent: 29 April 2004 13:20

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> I'm sorry, but I don't understand your reply.
> 
> On Thursday 29 April 2004 6:13 am, Dave Korn wrote:
> > > -----Original Message-----
> > > From: gcc-owner On Behalf Of John R. Shannon
> > > Sent: 29 April 2004 13:09
> > > To: gcc@gcc.gnu.org
> > > Subject: ACATS
> > >
> > > -----BEGIN PGP SIGNED MESSAGE-----
> > > Hash: SHA1
> > >
> > > Could someone please point me in the right direction in
> > > chasing down undefined
> > > references to `.LC124' and `.LC93' in gnatlink? Off-hand, I
> > > don't see where
> > > the references come from.
> >
> >  --save-temps


Run your compiles with --save-temps on the command line.  That'll save the
generated assembler files.  Any label beginning ".LC" is a local label
(usually a string constant or switch..case jump table); that is, it should
be both defined and referred to in the same file.  You should be able to see
if gcc is generating the wrong label in the reference, or is forgetting to
output the label definition in front of the object it refers to, or if they
look valid but there's some accident perhaps to do with what section they
end up in that's confusing the link.


    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....
 

Re: ACATS

[John R. Shannon]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I'm sorry, but I don't understand your reply.

On Thursday 29 April 2004 6:13 am, Dave Korn wrote:
> > -----Original Message-----
> > From: gcc-owner On Behalf Of John R. Shannon
> > Sent: 29 April 2004 13:09
> > To: gcc@gcc.gnu.org
> > Subject: ACATS
> >
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Could someone please point me in the right direction in
> > chasing down undefined
> > references to `.LC124' and `.LC93' in gnatlink? Off-hand, I
> > don't see where
> > the references come from.
>
>  --save-temps
>
>     cheers,
>       DaveK

- -- 

John R. Shannon
john@johnrshannon.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (NetBSD)

iEYEARECAAYFAkCQ8t8ACgkQOKbCxya4HYs1PwCfXHVUuvNXnWC4cqE4h2smyhFL
diQAnR/YySB97MPX8OfA4iUZFNoEmBsB
=xHem
-----END PGP SIGNATURE-----

RE: ACATS

[Dave Korn]

> -----Original Message-----
> From: gcc-owner On Behalf Of John R. Shannon
> Sent: 29 April 2004 13:09
> To: gcc@gcc.gnu.org
> Subject: ACATS
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Could someone please point me in the right direction in 
> chasing down undefined 
> references to `.LC124' and `.LC93' in gnatlink? Off-hand, I 
> don't see where 
> the references come from.


 --save-temps

    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....

ACATS

[John R. Shannon]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Could someone please point me in the right direction in chasing down undefined 
references to `.LC124' and `.LC93' in gnatlink? Off-hand, I don't see where 
the references come from.

Thank You.

- -- 

John R. Shannon
john@johnrshannon.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (NetBSD)

iEYEARECAAYFAkCQ8GAACgkQOKbCxya4HYuH2ACfREklxaO50Q/L3TktOIm/YGWF
M9kAn3n+fYRVj+BHBO6NCG0gN9y5cnUY
=9RlK
-----END PGP SIGNATURE-----

Re: ACATS

[Richard Kenner]

     255 ; 307  ; c9 Tasks and Synchronization
     268 ; 298  ; ce Predefined Language Environment (Ada 83)

My suggestion is that these not be run by default.  They are primarily
tests of the library itself, not the compiler, and are two of the longest
chapters to run.

Re: ACATS

[Florian Weimer]

"Joseph S. Myers" <jsm28@cam.ac.uk> writes:

> The point of using the vendor branch is to have *both* the original form
> (on the vendor branch) and the GCC version (on the mainline) in CVS - and
> when a new version is imported onto the vendor branch, CVS should be able
> to help with a lot of the work of merging onto the mainline.

The vendor version uses different filenames, so CVS cannot deal
properly with this situation.

Re: ACATS

[Joseph S. Myers]

On Thu, 6 Dec 2001 guerby@acm.org wrote:

> self: I'm no CVS specialist, keeping things in ACATS original form
> will require maintaining piles of dubious scripts at best, I don't
> want to do that myself, I by far prefer the hand crafted approach, and
> have things directly in GCC usable form in CVS.

The point of using the vendor branch is to have *both* the original form
(on the vendor branch) and the GCC version (on the mainline) in CVS - and
when a new version is imported onto the vendor branch, CVS should be able
to help with a lot of the work of merging onto the mainline.  The CVS
experts here can probably provide step-by-step instructions for doing this
and indications of the pitfalls.

> Geoff Keating: You do plan to use dejagnu to run the tests, correct?
> 
> self: My initial tarball will only contain readily compilable sources,
> a list of test main names and attributes as described above,
> documentation on the test to run and omitted, and a minimalistic
> Bourne shell script to run the thing.  From there, I assume DejaGNU
> experts will volunteer or guide volunteers on how to best integrate
> this in the existing Makefile + dg scripts. I must admit I'm not
> really impressed by the existing testing framework, and I believe and
> I can do much better with not that much effort, I'll propose something
> later on, but I don't want this to delay inclusion of ACATS in usable
> form in the GCC project, and I certainly don't want to stop people
> that would volunteer on integrating ACATS and existing DejaGNU.
> People will also have to decide what is officially part of the
> mandatory testing process.

I think DejaGNU must be a requirement for this to be part of the standard
"make check".  As well as providing support for testing cross-compilers in
many different environments, both simulators and target boards, many
people have scripts that use DejaGNU-format .sum files to check for
regressions and analyse results.  For example, that's what the automated
regression checker uses, and it must be desirable for the regression
checker to run these tests.

-- 
Joseph S. Myers
jsm28@cam.ac.uk

ACATS

[guerby]

[I have ISP problems at the moment, I hope this will get through.]

[0] General:

Jerry: Basically the question is if you want to see the test suite as
an scaled down ACATS (in which case all changes etc need to be
documented), or see ACATS as a starting point, and develop the suite
further, for example adding regression testing for discovered bugs,
etc. My first impulse is to stick to ACATS, to follow language
development, and add extra tests separately.

self: ACATS in GCC will be the part of ACATS where a volunteer has
done the packaging work. I proposed to do a piece of this packaging,
if people want to work on packaging more I'll try to help but won't do
it myself, I certainly agree that packaging all of ACATS is a great
goal, as I said I'll carefully document what I left out and why,
anyone is free to finish the work. IMHO non ACATS or ACATS-derived
tests should be packaged in another subdirectory so that it is easier
to track upstream ACATS.  The December ACATS update email has been
sent, I'm forwarding it to the list so people can make an
idea. Following upstream ACATS should be very easy, all changes are
very well documented and there isn't a large volume of changes.

Joseph S. Myers: We ought to have a link to this from the Ada section
of readings.html.

self: I'll work hard at documenting and linking to a maximum of Ada
ressources, Ada is pretty unique in that all (or nearly all) language
requirement, design, norms, maintainance and testsuite sources and
documents are freely available.

[1] pre-gnatchop

Jerry: I assume we want to run an ACATS subset as a basic sanity
check, right ?  But even in that case, it would be advisable to follow
the changes made to the test suite. Your proposal means this has to be
done manually by someone. Who is going to monitor this, and propagate
all changes in the tests ?

self: I proposed to do the upstream tracking work for the executable
section. As for the subset we want to run, this is open to
discussions, I have no opinion on the subject. Personally, I'll run
every single GCC test available for all of my changes up to 8 hours of
wall clock time (make a daily patch, check during night, commit in the
morning).

[2] directory structure

Mike Stump: Split them up some.  <200 per directory would be good (or
maybe <359 per directory).

Jerry: I like the current subdirectory structure, it makes it easier
if you want to check just one test, or a set or related tests.

Geert: From experience I find it really valuable to have separate
subdirectories per class/chapter. For example, if you work on some
changes to handling of floating point, you would initially just want
to run chapter CXG, which means the executable RM Annex G tests.

self: okay, I'll keep the existing ACATS directory structure.  Running
easily subsets of scripts is on the spec of any testing technology and
shouldn't be related to directory structure. I intend to have the test
list file provide test key annotated with a few attributes, like
wether the test use tasking, is ok for the no-run-time mode, has some
real code, is part of minimal testing requirement, etc... so that it
is easy select a test subset.

[3] filename length

Geert: It might be preferable to "krunch" the names to a more
managable length using the -gnatk option, since there are still many
filesystems that have issues with long names and it's also easier to
deal with shorter names as human beings (those who have seen the few
examples of few long names in ACATS tests, will agree they do not
help: only the first few are useful).

self: I believe the longest name is
ca13001_1-ca13001_2-ca13001_4-family_transportation.adb 

There is a test checking for the longest package name supported by the
implementation, this is part of my "drop because stupid and painful"
list. Such tests should be auto-generated and tailored to GCC in some
other part of the test suite, the ACATS stuff is of little value.

Mike Stump: I'd say ok.

self: let's say okay.

[4] top dir gcc/gcc/testsuite/ada/acats

Joseph S. Myers: That seems plausible - presumably "runtest --tool
ada" will be used in "make check" to run both those and other Ada
tests?

self: to be decided.

[5] source separate from harness

self: no comment, okay.

[6] drop compilation model tests

self: Geert and Robert agreed, okay.

[7] B tests

Mike Stump: They can be made to require less, by having them line
resolution only, this is what the C++ testsuite does.  This is for the
Ada maintainers to determine.  If they want the testing, and want the
burden, then they should stay the same, if they want to escape it,
then a line based approach can be used.

Jerry: I think it's important to test the whole GNAT system, not just
the backend.  The value of the B tests is that it alerts you to
unexpected changes. I think that at least for now they should stay. We
can add 'skip tests' for changes that are to much work for the added
value.

Zack Weinberg: I disagree in the strongest possible terms.  Put the B
tests in the public repository.  If you don't, you only make life
harder for people outside of ACT who wish to work on the Ada front
end.  The maintenance work has to be done anyway, and ought to be the
responsibility of the person who makes the change that causes the
tests to regress.  If the B tests are run as part of "make check" in
the FSF tree, this will be enforced automatically.

self: B tests are 1525 files, 11886 errors to be flagged (errors are
marked with a -- ERROR: xxx comment).  No one is against inclusion, I
just points out that there is painful initial work and maintainance,
and that I don't volunteer to do it, given passionate answers, I
assume that Zack and Jerry volunteered to do the work :). I will also
point out that actually including this might make it less likely that
people will propose patches to improve error messages, since any of
such patches will probably generate hundreds of changes to be
validated in the B tests, this is not really fun, so by this effect
including B test requirement might *lower* the future quality of the compiler
by preventing some useful patches.  Also note that GNAT currently
generates the best error messages I've ever seen for any compiler and
language, and by a fair margin.

[8] tasking delay patch

Geert and Richard Kenner: Test timings?

self: ACATS timing on a 1GHz P3 at -O0, in number of test and seconds
per section:

   N ; T(s) ; Desc.

   4 ; 	30  ; support + cz Check that the test reporting stuff works
  75 ; 	38  ; a  
  34 ; 	15  ; c2 Lexical Elements
 351 ; 267  ; c3 Declarations and Types
 339 ; 186  ; c4 Names and Expressions
  95 ; 	59  ; c5 Statements
  81 ; 	43  ; c6 Subprograms 
  51 ; 	48  ; c7 Packages
 140 ; 141  ; c8 Visibility Rules
 255 ; 307  ; c9 Tasks and Synchronization
  74 ; 	49  ; ca Program Structure and Compilation Issues
  43 ; 	26  ; cb Exceptions
 117 ; 	78  ; cc Generic Units
 173 ; 	87  ; cd Representation Issues
 268 ; 298  ; ce Predefined Language Environment (Ada 83)
  87 ; 133  ; cxa Predefined Language Environment (Ada 95)
  30 ; 	32  ; cxb Interface to Other Languages
  13 ; 	30  ; cxc Systems Programming
  38 ; 	75  ; cxd Real-Time Systems
   1 ; 	 1  ; cxe Distributed Systems 
  20 ; 	24  ; cxf Information Systems
  29 ; 	63  ; cxg Numerics
   4 ; 	19  ; cxh Safety and Security
   4 ; 	 2  ; d  
  11 ; 	 5  ; e  
  26 ; 	19  ; l  

Joseph S. Myers: It is arguable that perhaps the CVS vendor branch
mechanism should be used - import the unmodified sources on the vendor
branch with GCC's modified version on the mainline.  This should make
it easy to use CVS to see what the differences from unmodified ACATS
are.  I don't know whether whatever tests it is deliberately decided
to drop rather than include in the GCC testsuite should also go on the
vendor branch, or whether it should just be documented which are
dropped.

self: I'm no CVS specialist, keeping things in ACATS original form
will require maintaining piles of dubious scripts at best, I don't
want to do that myself, I by far prefer the hand crafted approach, and
have things directly in GCC usable form in CVS.

[9] prototype tarball ftp upload

self: I'll put stuff in <http://perso.wanadoo.fr/guerby/acats/>

[10] first harness prototype

Geert: You did not really address the reason why you had decided not
to use the existing testing harness. I can see a number of reasons why
seperate scripts would be better for ACATS, but these should be
documented.

Geoff Keating: You do plan to use dejagnu to run the tests, correct?

self: My initial tarball will only contain readily compilable sources,
a list of test main names and attributes as described above,
documentation on the test to run and omitted, and a minimalistic
Bourne shell script to run the thing.  From there, I assume DejaGNU
experts will volunteer or guide volunteers on how to best integrate
this in the existing Makefile + dg scripts. I must admit I'm not
really impressed by the existing testing framework, and I believe and
I can do much better with not that much effort, I'll propose something
later on, but I don't want this to delay inclusion of ACATS in usable
form in the GCC project, and I certainly don't want to stop people
that would volunteer on integrating ACATS and existing DejaGNU.
People will also have to decide what is officially part of the
mandatory testing process.

[12] DFAR legalese and GCC changes

Geert: I wouldn't think so. This seems to only add confusion about the
licensing.  Of course if we would make significant changes to the
tests, we should put the files under GPL. Also any new files and
scripts should be GPL-ed.

self: when I'll gnatchop the original sources, only one file will
retain the legalese, I assume I don't need to copy it to every file
after gnatchop.

Mike Stump: No.

Hmm, I don't intend to change anything without properly identifying
what I've done (like any other change made to any part of GCC), may be
I misunderstand what your answer means?

[13] maintainership

self: I'll add myself in MAINTAINERS for gcc/gcc/testsuite/ada/acats
once the discussion is complete and the commit is done.

-- 
Laurent Guerby <guerby@acm.org>