Ada updates frozen

Ada updates frozen

[Arnaud Charlet]

People,

This is to inform you that due to major recent changes in the GCC back-end
which completely broke Ada builds (it started with ia64, and now include
at least ia32 and possibly other platforms), I am currently not in a position
to test any of our Ada changes, so I have to hold on any update on the
tree.

The changes have been (and are being) discussed at length under this and
gcc-patches lists (about XFMode and co.), so I'd expect some improvements in
this area, but according to our analysis, the recent changes break
many assumptions in a pretty fundamental way, so it won't be a matter
of simply changing a few lines of code (unless we revert the offending
XFMode changes), which is pretty bad given that we are in stage 3.

It would be particularly bad if GCC 3.4.0 had no Ada support at all, even
if not part of the release criterias, that would be a pretty major
regression IMO, in particular given all the recent efforts to bring a
much more reliable and powerful Ada compiler in the tree.

Arno

Re: Ada updates frozen

[Roger Sayle]

Hi Arno,
> This is to inform you that due to major recent changes in the GCC back-end
> which completely broke Ada builds (it started with ia64, and now include
> at least ia32 and possibly other platforms), I am currently not in a position
> to test any of our Ada changes, so I have to hold on any update on the
> tree.

I think you are well within your rights to invoke the "patch reversion"
rule and start the 48-hour clock ticking.  If x86/IA-64 bootstrap can't
be restored on mainline by Tuesday the patches should be pulled, or the
problematic aspects temporarily disabled.

As a compromise, removing simultaneous support for XFmode and TFmode
for non-Ada languages from mainline can also be viewed as a regression
from today's CVS, which will give Zack, Jan and the Ada folks the freedom
to work on resolving the issue during the rest of stage3.

I'm sure Zack and Jan much appreciate the Ada folks efforts to fix this
problem themselves.  After all its the patch submitters responsibility
to resolve major regressions caused by their patches.  At the very least,
this should prompt them to include Ada in the list of languages they
enable when testing changes, its even the default on many recent Linux
distributions.

Zack, Jan, Mark, does this sound reasonable?

Roger
--
Roger Sayle,                         E-mail: roger@eyesopen.com
OpenEye Scientific Software,         WWW: http://www.eyesopen.com/
Suite 1107, 3600 Cerrillos Road,     Tel: (+1) 505-473-7385
Santa Fe, New Mexico, 87507.         Fax: (+1) 505-473-0833

Re: Ada updates frozen

[Geert Bosch]

On Nov 2, 2003, at 9:11 AM, Roger Sayle wrote:
> I think you are well within your rights to invoke the "patch reversion"
> rule and start the 48-hour clock ticking.  If x86/IA-64 bootstrap can't
> be restored on mainline by Tuesday the patches should be pulled, or the
> problematic aspects temporarily disabled.

Given the significant problems this patch introduces, I would
appreciate it if Jan would revert this patch, until the regressions
are resolved.

Richard Kenner already implemented the required changes for gigi
(the Ada front end/back end interface), but these are on hold now.
It will be a few days before the remaining front end work is
finished.

   -Geert

Re: Ada updates frozen

[Zack Weinberg]

Geert Bosch <bosch@gnat.com> writes:

> On Nov 2, 2003, at 9:11 AM, Roger Sayle wrote:
>> I think you are well within your rights to invoke the "patch reversion"
>> rule and start the 48-hour clock ticking.  If x86/IA-64 bootstrap can't
>> be restored on mainline by Tuesday the patches should be pulled, or the
>> problematic aspects temporarily disabled.
>
> Given the significant problems this patch introduces, I would
> appreciate it if Jan would revert this patch, until the regressions
> are resolved.
>
> Richard Kenner already implemented the required changes for gigi
> (the Ada front end/back end interface), but these are on hold now.
> It will be a few days before the remaining front end work is
> finished.

I am presently testing a patch which reverts GET_MODE_BITSIZE to its
original meaning (i.e. GET_MODE_SIZE * BITS_PER_UNIT) and introduces
a new macro GET_MODE_PRECISION which is used in a very few places
(notably mode_for_size).  I think this should be an adequate bandage
to restore Ada bootstrap so that work can go forward on the complete
solution.  However, there are still some issues with the patch, so I
cannot provide it just yet, but I intend to have them worked out by
the end of the day.

zw

Re: Ada updates frozen

[Mark Mitchell]

On Sun, 2003-11-02 at 11:40, Zack Weinberg wrote:
> Geert Bosch <bosch@gnat.com> writes:
> 
> > On Nov 2, 2003, at 9:11 AM, Roger Sayle wrote:
> >> I think you are well within your rights to invoke the "patch reversion"
> >> rule and start the 48-hour clock ticking.  If x86/IA-64 bootstrap can't
> >> be restored on mainline by Tuesday the patches should be pulled, or the
> >> problematic aspects temporarily disabled.
> >
> > Given the significant problems this patch introduces, I would
> > appreciate it if Jan would revert this patch, until the regressions
> > are resolved.
> >
> > Richard Kenner already implemented the required changes for gigi
> > (the Ada front end/back end interface), but these are on hold now.
> > It will be a few days before the remaining front end work is
> > finished.
> 
> I am presently testing a patch which reverts GET_MODE_BITSIZE to its
> original meaning (i.e. GET_MODE_SIZE * BITS_PER_UNIT) and introduces
> a new macro GET_MODE_PRECISION which is used in a very few places
> (notably mode_for_size).  I think this should be an adequate bandage
> to restore Ada bootstrap so that work can go forward on the complete
> solution.  However, there are still some issues with the patch, so I
> cannot provide it just yet, but I intend to have them worked out by
> the end of the day.

I'm too far behind on email to understand what the reference to Jan's
patch is.  I do know about Zack's patch.  So, this email refers to
Zack's patch, but not Jan's patch.

I think that Zack's XFmode/TFmode patch is (a) the right thing, in
principle, and (b) has demonstrable benefit.

With respect to (a), the patch eliminates the weird design bug in GCC
that prevented the simultaneous use of 80-bit and 128-bit floating-point
modes.  With respect to (b), this change allowed us to support all of
the floating-point types on IA64 HP-UX, and also allowed us to improve
the code generated on IA64 HP-UX by, for example, inlining division. 
(That previously was allowed only on IA64 GNU/Linux, due to the problems
with floating-point modes.)

I do think that Zack (and, for that matter) CodeSourcery have an
obligation to solve the problems introduced by the patch.  I know that
Zack is working hard on that, and that is one of his present duties as a
CodeSourcery employee.

In general, as long as someone is continuing to work on fixing the
problems and as long as overall sentiment is that the patch is in
general a good thing, we've not reverted patches.  

I think that this problem will be solved relatively soon.

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

Re: Ada updates frozen

[Jan Hubicka]

> On Sun, 2003-11-02 at 11:40, Zack Weinberg wrote:
> > Geert Bosch <bosch@gnat.com> writes:
> > 
> > > On Nov 2, 2003, at 9:11 AM, Roger Sayle wrote:
> > >> I think you are well within your rights to invoke the "patch reversion"
> > >> rule and start the 48-hour clock ticking.  If x86/IA-64 bootstrap can't
> > >> be restored on mainline by Tuesday the patches should be pulled, or the
> > >> problematic aspects temporarily disabled.
> > >
> > > Given the significant problems this patch introduces, I would
> > > appreciate it if Jan would revert this patch, until the regressions
> > > are resolved.
> > >
> > > Richard Kenner already implemented the required changes for gigi
> > > (the Ada front end/back end interface), but these are on hold now.
> > > It will be a few days before the remaining front end work is
> > > finished.
> > 
> > I am presently testing a patch which reverts GET_MODE_BITSIZE to its
> > original meaning (i.e. GET_MODE_SIZE * BITS_PER_UNIT) and introduces
> > a new macro GET_MODE_PRECISION which is used in a very few places
> > (notably mode_for_size).  I think this should be an adequate bandage
> > to restore Ada bootstrap so that work can go forward on the complete
> > solution.  However, there are still some issues with the patch, so I
> > cannot provide it just yet, but I intend to have them worked out by
> > the end of the day.
> 
> I'm too far behind on email to understand what the reference to Jan's
> patch is.  I do know about Zack's patch.  So, this email refers to
> Zack's patch, but not Jan's patch.

My patch does exactly the same Zack did for IA-64.  x86-64 has exactly
symetric behaviour wrt long double and __float128 as IA-64 ABI has.  I
really hope that if Zack works out the issues with Ada, it will
automatically fix the x86-64 part too.  I can do any help with fixing
the bug if Zack figure out how to make me involved in his effort.

Honza

Re: Ada updates frozen

[Zack Weinberg]

Jan Hubicka <jh@suse.cz> writes:

>> 
>> I'm too far behind on email to understand what the reference to Jan's
>> patch is.  I do know about Zack's patch.  So, this email refers to
>> Zack's patch, but not Jan's patch.
>
> My patch does exactly the same Zack did for IA-64.  x86-64 has exactly
> symetric behaviour wrt long double and __float128 as IA-64 ABI has.  I
> really hope that if Zack works out the issues with Ada, it will
> automatically fix the x86-64 part too.  I can do any help with fixing
> the bug if Zack figure out how to make me involved in his effort.

I appreciate your patch because it has made it possible for me to
reproduce the Ada bootstrap problems on i386.  I do not have access to
any ia64 machine on which GNAT can be built.

The problem is indeed exactly symmetric.  I sent a partial patch to
the list earlier today.  [http://gcc.gnu.org/ml/gcc/2003-11/msg00064.html]

Jan, if you would like to help, could you
please try to debug the abort in make gnatlib_and_tools?

zw

Re: Ada updates frozen

[Jan Hubicka]

> Jan Hubicka <jh@suse.cz> writes:
> 
> >> 
> >> I'm too far behind on email to understand what the reference to Jan's
> >> patch is.  I do know about Zack's patch.  So, this email refers to
> >> Zack's patch, but not Jan's patch.
> >
> > My patch does exactly the same Zack did for IA-64.  x86-64 has exactly
> > symetric behaviour wrt long double and __float128 as IA-64 ABI has.  I
> > really hope that if Zack works out the issues with Ada, it will
> > automatically fix the x86-64 part too.  I can do any help with fixing
> > the bug if Zack figure out how to make me involved in his effort.
> 
> I appreciate your patch because it has made it possible for me to
> reproduce the Ada bootstrap problems on i386.  I do not have access to
> any ia64 machine on which GNAT can be built.
> 
> The problem is indeed exactly symmetric.  I sent a partial patch to
> the list earlier today.  [http://gcc.gnu.org/ml/gcc/2003-11/msg00064.html]
> 
> Jan, if you would like to help, could you
> please try to debug the abort in make gnatlib_and_tools?
I will try my best this evening.  (we do have conference now and I was
just scheduled to do some other work).
Does it happen on i386 or x86-64?  It should not happen for the former.
Urhm, yes.  Now I see it reproduces on i386 as I forgot to remove there
hack I used to bootstrap with -m128bit-long-double by default.
I am commiting obvious fix for this part at least and will continue with
testing on x86-64.

Honza

2003-11-03  Jan Hubicka  <jh@suse.cz>
	* i386.c (override_options):  Remove hack enabling 128bit long double
	commited by accident.
Index: i386.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/config/i386/i386.c,v
retrieving revision 1.616
diff -c -3 -p -r1.616 i386.c
*** i386.c	2 Nov 2003 19:47:57 -0000	1.616
--- i386.c	3 Nov 2003 11:50:46 -0000
*************** override_options (void)
*** 1374,1380 ****
    if (TARGET_SSE2)
      target_flags |= MASK_SSE;
  
-       target_flags |= (MASK_128BIT_LONG_DOUBLE);
    if (TARGET_64BIT)
      {
        if (TARGET_ALIGN_DOUBLE)
--- 1374,1379 ----

Re: Ada updates frozen

[Jan Hubicka]

> > Jan Hubicka <jh@suse.cz> writes:
> > 
> > >> 
> > >> I'm too far behind on email to understand what the reference to Jan's
> > >> patch is.  I do know about Zack's patch.  So, this email refers to
> > >> Zack's patch, but not Jan's patch.
> > >
> > > My patch does exactly the same Zack did for IA-64.  x86-64 has exactly
> > > symetric behaviour wrt long double and __float128 as IA-64 ABI has.  I
> > > really hope that if Zack works out the issues with Ada, it will
> > > automatically fix the x86-64 part too.  I can do any help with fixing
> > > the bug if Zack figure out how to make me involved in his effort.
> > 
> > I appreciate your patch because it has made it possible for me to
> > reproduce the Ada bootstrap problems on i386.  I do not have access to
> > any ia64 machine on which GNAT can be built.
> > 
> > The problem is indeed exactly symmetric.  I sent a partial patch to
> > the list earlier today.  [http://gcc.gnu.org/ml/gcc/2003-11/msg00064.html]
> > 
> > Jan, if you would like to help, could you
> > please try to debug the abort in make gnatlib_and_tools?
> I will try my best this evening.  (we do have conference now and I was
> just scheduled to do some other work).
> Does it happen on i386 or x86-64?  It should not happen for the former.
> Urhm, yes.  Now I see it reproduces on i386 as I forgot to remove there
> hack I used to bootstrap with -m128bit-long-double by default.
> I am commiting obvious fix for this part at least and will continue with
> testing on x86-64.
> 
> Honza
> 
> 2003-11-03  Jan Hubicka  <jh@suse.cz>
> 	* i386.c (override_options):  Remove hack enabling 128bit long double
> 	commited by accident.

One idea comes into mind.  I think ADA is duplicating all the knowledge
about target types somehow.  Perhaps it just gets confused by sudden
changes in long double type size and bootstrap will work just fine on
x86-64.  Just testing...

Honza

Re: Ada updates frozen

[Jan Hubicka]

> > > Jan Hubicka <jh@suse.cz> writes:
> > > 
> > > >> 
> > > >> I'm too far behind on email to understand what the reference to Jan's
> > > >> patch is.  I do know about Zack's patch.  So, this email refers to
> > > >> Zack's patch, but not Jan's patch.
> > > >
> > > > My patch does exactly the same Zack did for IA-64.  x86-64 has exactly
> > > > symetric behaviour wrt long double and __float128 as IA-64 ABI has.  I
> > > > really hope that if Zack works out the issues with Ada, it will
> > > > automatically fix the x86-64 part too.  I can do any help with fixing
> > > > the bug if Zack figure out how to make me involved in his effort.
> > > 
> > > I appreciate your patch because it has made it possible for me to
> > > reproduce the Ada bootstrap problems on i386.  I do not have access to
> > > any ia64 machine on which GNAT can be built.
> > > 
> > > The problem is indeed exactly symmetric.  I sent a partial patch to
> > > the list earlier today.  [http://gcc.gnu.org/ml/gcc/2003-11/msg00064.html]
> > > 
> > > Jan, if you would like to help, could you
> > > please try to debug the abort in make gnatlib_and_tools?
> > I will try my best this evening.  (we do have conference now and I was
> > just scheduled to do some other work).
> > Does it happen on i386 or x86-64?  It should not happen for the former.
> > Urhm, yes.  Now I see it reproduces on i386 as I forgot to remove there
> > hack I used to bootstrap with -m128bit-long-double by default.
> > I am commiting obvious fix for this part at least and will continue with
> > testing on x86-64.
> > 
> > Honza
> > 
> > 2003-11-03  Jan Hubicka  <jh@suse.cz>
> > 	* i386.c (override_options):  Remove hack enabling 128bit long double
> > 	commited by accident.
> 
> One idea comes into mind.  I think ADA is duplicating all the knowledge
> about target types somehow.  Perhaps it just gets confused by sudden
> changes in long double type size and bootstrap will work just fine on
> x86-64.  Just testing...

OK, x86-64 bootstrap passed.  I am going to test i386.

Honza
> 
> Honza

Re: Ada updates frozen

[Robert Dewar]

> I'm sure Zack and Jan much appreciate the Ada folks efforts to fix this
> problem themselves.  After all its the patch submitters responsibility
> to resolve major regressions caused by their patches.  At the very least,
> this should prompt them to include Ada in the list of languages they
> enable when testing changes, its even the default on many recent Linux
> distributions.


Just to let you know, we are certainly working on the (fairly major)
revision to GNAT to fix this, which is in fact a long term improvement,
but it's not clear how quickly we can get this revision completed.

Re: Ada updates frozen

[Richard Kenner]

    I am presently testing a patch which reverts GET_MODE_BITSIZE to its
    original meaning (i.e. GET_MODE_SIZE * BITS_PER_UNIT) and introduces
    a new macro GET_MODE_PRECISION which is used in a very few places
    (notably mode_for_size).  

So you're going to rename it as mode_for_precion?

And what about the _TYPE_SIZE macros?  Will they go back to being *sizes*
or remain precisions?

Re: Ada updates frozen

[Zack Weinberg]

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

>     I am presently testing a patch which reverts GET_MODE_BITSIZE to its
>     original meaning (i.e. GET_MODE_SIZE * BITS_PER_UNIT) and introduces
>     a new macro GET_MODE_PRECISION which is used in a very few places
>     (notably mode_for_size).  
>
> So you're going to rename it as mode_for_precion?

Yes, although not immediately; I intend to submit a minimal but
contentful change followed by a series of large mechanical name
changes.

> And what about the _TYPE_SIZE macros?  Will they go back to being *sizes*
> or remain precisions?

They need to remain precision (and I will rename them as such)
otherwise we cannot know which type to use for C long double on ia64
and i386.

The way the back end specifies the ABI's requirements for type sizes
(precisions) is unpleasantly C-centric and I would welcome ideas on
how to make it more generic.

zw

Re: Ada updates frozen

[Richard Kenner]

    > And what about the _TYPE_SIZE macros?  Will they go back to being *sizes*
    > or remain precisions?

    They need to remain precision (and I will rename them as such)
    otherwise we cannot know which type to use for C long double on ia64
    and i386.

OK, but just so you know, it's *that* which breaks Ada currently.

Re: Ada updates frozen

[Zack Weinberg]

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

>     > And what about the _TYPE_SIZE macros?  Will they go back to being *sizes*
>     > or remain precisions?
>
>     They need to remain precision (and I will rename them as such)
>     otherwise we cannot know which type to use for C long double on ia64
>     and i386.
>
> OK, but just so you know, it's *that* which breaks Ada currently.

I realize this.  Do you think it will work (at least as a stopgap
measure) for Ada to use 
GET_MODE_BITSIZE (mode_for_precision (LONG_DOUBLE_TYPE_SIZE))
instead of bare LONG_DOUBLE_TYPE_SIZE?  After I change
GET_MODE_BITSIZE to mean what it used to mean, that is.

zw

Re: Ada updates frozen

[Richard Kenner]

    I realize this.  Do you think it will work (at least as a stopgap
    measure) for Ada to use 
    GET_MODE_BITSIZE (mode_for_precision (LONG_DOUBLE_TYPE_SIZE))
    instead of bare LONG_DOUBLE_TYPE_SIZE?  After I change
    GET_MODE_BITSIZE to mean what it used to mean, that is.

In principle, yes, but it also needs to know the type sizes in a context where
it doesn't have the GCC backend available (for gnatpsta), so it's a little
harder than that.

Re: Ada updates frozen

[Zack Weinberg]

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

>     I realize this.  Do you think it will work (at least as a stopgap
>     measure) for Ada to use 
>     GET_MODE_BITSIZE (mode_for_precision (LONG_DOUBLE_TYPE_SIZE))
>     instead of bare LONG_DOUBLE_TYPE_SIZE?  After I change
>     GET_MODE_BITSIZE to mean what it used to mean, that is.
>
> In principle, yes, but it also needs to know the type sizes in a context where
> it doesn't have the GCC backend available (for gnatpsta), so it's a little
> harder than that.

I can't support doing anything with gnatpsta/gnatpsys except folding
them into gnat1, sorry, what you have now is flat broken and has been
since the invention of multilibs.

Here is the patch that I have been testing.  It gets me as far as

$ make gnatlib_and_tools
...
../../xgcc -B../../ -c -g -O2      -W -Wall -gnatpg  a-ncelfu.ads -o a-ncelfu.o
+===========================GNAT BUG DETECTED==============================+
| 3.4 20031102 (experimental) (i686-pc-linux-gnu) Gigi abort, Code=414     |
| Error detected at a-ngelfu.adb:237:14 [a-ngcefu.adb:38:4 [a-ncelfu.ads:19:1]]|
| Please submit a bug report; see http://gcc.gnu.org/bugs.html.            |
| Include the entire contents of this bug box in the report.               |
| Include the exact gcc or gnatmake command that you entered.              |
| Also include sources listed below in gnatchop format                     |
| (concatenated together with no headers between files).                   |
+==========================================================================+

Please include these source files with error report
Note that list may not be accurate in some cases, 
so please double check that the problem can still 
be reproduced with the set of files listed.


compilation abandoned
make[2]: *** [a-ncelfu.o] Error 1
make[2]: Leaving directory `/home/zack/src/gcc/vanilla/build/gcc/ada/rts'
make[1]: *** [gnatlib] Error 2
make[1]: Leaving directory `/home/zack/src/gcc/vanilla/build/gcc/ada'
make: *** [gnatlib] Error 2

(Where's the list of files?)

zw

===================================================================
Index: genmodes.c
--- genmodes.c	29 Oct 2003 17:01:27 -0000	1.8
+++ genmodes.c	3 Nov 2003 01:37:28 -0000
@@ -56,7 +56,7 @@ struct mode_data
 
   const char *name;		/* printable mode name -- SI, not SImode */
   enum mode_class class;	/* this mode class */
-  unsigned int bitsize;		/* size in bits, equiv to TYPE_PRECISION */
+  unsigned int precision;	/* size in bits, equiv to TYPE_PRECISION */
   unsigned int bytesize;	/* storage size in addressable units */
   unsigned int ncomponents;	/* number of subunits */
   unsigned int alignment;	/* mode alignment */
@@ -262,13 +262,13 @@ enum requirement { SET, UNSET, OPTIONAL 
 
 static void
 validate_mode (struct mode_data *m,
-	       enum requirement r_bitsize,
+	       enum requirement r_precision,
 	       enum requirement r_bytesize,
 	       enum requirement r_component,
 	       enum requirement r_ncomponents,
 	       enum requirement r_format)
 {
-  validate_field (m, bitsize);
+  validate_field (m, precision);
   validate_field (m, bytesize);
   validate_field (m, component);
   validate_field (m, ncomponents);
@@ -304,7 +304,7 @@ complete_mode (struct mode_data *m)
 
       validate_mode (m, UNSET, UNSET, UNSET, UNSET, UNSET);
 
-      m->bitsize = 0;
+      m->precision = 0;
       m->bytesize = 0;
       m->ncomponents = 0;
       m->component = 0;
@@ -349,8 +349,8 @@ complete_mode (struct mode_data *m)
       /* Complex modes should have a component indicated, but no more.  */
       validate_mode (m, UNSET, UNSET, SET, UNSET, UNSET);
       m->ncomponents = 2;
-      if (m->component->bitsize != (unsigned int)-1)
-	m->bitsize = 2 * m->component->bitsize;
+      if (m->component->precision != (unsigned int)-1)
+	m->precision = 2 * m->component->precision;
       m->bytesize = 2 * m->component->bytesize;
       break;
 
@@ -358,8 +358,8 @@ complete_mode (struct mode_data *m)
     case MODE_VECTOR_FLOAT:
       /* Vector modes should have a component and a number of components.  */
       validate_mode (m, UNSET, UNSET, SET, SET, UNSET);
-      if (m->component->bitsize != (unsigned int)-1)
-	m->bitsize = m->ncomponents * m->component->bitsize;
+      if (m->component->precision != (unsigned int)-1)
+	m->precision = m->ncomponents * m->component->precision;
       m->bytesize = m->ncomponents * m->component->bytesize;
       break;
 
@@ -413,7 +413,7 @@ make_complex_modes (enum mode_class clas
   for (m = modes[class]; m; m = m->next)
     {
       /* Skip BImode.  FIXME: BImode probably shouldn't be MODE_INT.  */
-      if (m->bitsize == 1)
+      if (m->precision == 1)
 	continue;
 
       if (strlen (m->name) >= sizeof buf)
@@ -479,7 +479,7 @@ make_vector_modes (enum mode_class class
 	 not be necessary.  */
       if (class == MODE_FLOAT && m->bytesize == 1)
 	continue;
-      if (class == MODE_INT && m->bitsize == 1)
+      if (class == MODE_INT && m->precision == 1)
 	continue;
 
       if ((size_t)snprintf (buf, sizeof buf, "V%u%s", ncomponents, m->name)
@@ -515,12 +515,12 @@ make_special_mode (enum mode_class class
 
 static void
 make_int_mode (const char *name,
-	       unsigned int bitsize, unsigned int bytesize,
+	       unsigned int precision, unsigned int bytesize,
 	       const char *file, unsigned int line)
 {
   struct mode_data *m = new_mode (MODE_INT, name, file, line);
   m->bytesize = bytesize;
-  m->bitsize = bitsize;
+  m->precision = precision;
 }
 
 #define FLOAT_MODE(N, Y, F)             FRACTIONAL_FLOAT_MODE (N, -1, Y, F)
@@ -529,13 +529,13 @@ make_int_mode (const char *name,
 
 static void
 make_float_mode (const char *name,
-		 unsigned int bitsize, unsigned int bytesize,
+		 unsigned int precision, unsigned int bytesize,
 		 const char *format,
 		 const char *file, unsigned int line)
 {
   struct mode_data *m = new_mode (MODE_FLOAT, name, file, line);
   m->bytesize = bytesize;
-  m->bitsize = bitsize;
+  m->precision = precision;
   m->format = format;
 }
 
@@ -565,7 +565,7 @@ reset_float_format (const char *name, co
   make_partial_integer_mode (#M, "P" #M, -1, __FILE__, __LINE__)
 static void ATTRIBUTE_UNUSED
 make_partial_integer_mode (const char *base, const char *name,
-			   unsigned int bitsize,
+			   unsigned int precision,
 			   const char *file, unsigned int line)
 {
   struct mode_data *m;
@@ -582,7 +582,7 @@ make_partial_integer_mode (const char *b
     }
   
   m = new_mode (MODE_PARTIAL_INT, name, file, line);
-  m->bitsize = bitsize;
+  m->precision = precision;
   m->component = component;
 }
 
@@ -645,18 +645,18 @@ create_modes (void)
 /* Processing.  */
 
 /* Sort a list of modes into the order needed for the WIDER field:
-   major sort by bitsize, minor sort by component bitsize.
+   major sort by precision, minor sort by component precision.
 
    For instance:
      QI < HI < SI < DI < TI
      V4QI < V2HI < V8QI < V4HI < V2SI.
 
-   If the bitsize is not set, sort by the bytesize.  A mode with
-   bitsize set gets sorted before a mode without bitsize set, if
+   If the precision is not set, sort by the bytesize.  A mode with
+   precision set gets sorted before a mode without precision set, if
    they have the same bytesize; this is the right thing because
-   the bitsize must always be smaller than the bytesize * BITS_PER_UNIT.
+   the precision must always be smaller than the bytesize * BITS_PER_UNIT.
    We don't have to do anything special to get this done -- an unset
-   bitsize shows up as (unsigned int)-1, i.e. UINT_MAX.  */
+   precision shows up as (unsigned int)-1, i.e. UINT_MAX.  */
 static int
 cmp_modes (const void *a, const void *b)
 {
@@ -668,9 +668,9 @@ cmp_modes (const void *a, const void *b)
   else if (m->bytesize < n->bytesize)
     return -1;
 
-  if (m->bitsize > n->bitsize)
+  if (m->precision > n->precision)
     return 1;
-  else if (m->bitsize < n->bitsize)
+  else if (m->precision < n->precision)
     return -1;
 
   if (!m->component && !n->component)
@@ -681,9 +681,9 @@ cmp_modes (const void *a, const void *b)
   else if (m->component->bytesize < n->component->bytesize)
     return -1;
 
-  if (m->component->bitsize > n->component->bitsize)
+  if (m->component->precision > n->component->precision)
     return 1;
-  else if (m->component->bitsize < n->component->bitsize)
+  else if (m->component->precision < n->component->precision)
     return -1;
 
   return 0;
@@ -802,7 +802,7 @@ enum machine_mode\n{");
 	 end will try to use it for bitfields in structures and the
 	 like, which we do not want.  Only the target md file should
 	 generate BImode widgets.  */
-      if (first && first->bitsize == 1)
+      if (first && first->precision == 1)
 	first = first->next;
 
       if (first && last)
@@ -892,16 +892,16 @@ emit_mode_class (void)
 }
 
 static void
-emit_mode_bitsize (void)
+emit_mode_precision (void)
 {
   enum mode_class c;
   struct mode_data *m;
 
-  print_decl ("unsigned short", "mode_bitsize", "NUM_MACHINE_MODES");
+  print_decl ("unsigned short", "mode_precision", "NUM_MACHINE_MODES");
 
   for_all_modes (c, m)
-    if (m->bitsize != (unsigned int)-1)
-      tagged_printf ("%u", m->bitsize, m->name);
+    if (m->precision != (unsigned int)-1)
+      tagged_printf ("%u", m->precision, m->name);
     else
       tagged_printf ("%u*BITS_PER_UNIT", m->bytesize, m->name);
 
@@ -968,8 +968,8 @@ emit_mode_mask (void)
    : ((unsigned HOST_WIDE_INT) 1 << (m)) - 1\n");
 
   for_all_modes (c, m)
-    if (m->bitsize != (unsigned int)-1)
-      tagged_printf ("MODE_MASK (%u)", m->bitsize, m->name);
+    if (m->precision != (unsigned int)-1)
+      tagged_printf ("MODE_MASK (%u)", m->precision, m->name);
     else
       tagged_printf ("MODE_MASK (%u*BITS_PER_UNIT)", m->bytesize, m->name);
 
@@ -1020,7 +1020,7 @@ emit_class_narrowest_mode (void)
     /* Bleah, all this to get the comment right for MIN_MODE_INT.  */
     tagged_printf ("MIN_%s", mode_class_names[c],
 		   modes[c]
-		   ? (modes[c]->bitsize != 1
+		   ? (modes[c]->precision != 1
 		      ? modes[c]->name
 		      : (modes[c]->next
 			 ? modes[c]->next->name
@@ -1156,7 +1156,7 @@ emit_insn_modes_c (void)
   emit_insn_modes_c_header ();
   emit_mode_name ();
   emit_mode_class ();
-  emit_mode_bitsize ();
+  emit_mode_precision ();
   emit_mode_size ();
   emit_mode_nunits ();
   emit_mode_wider ();
===================================================================
Index: machmode.def
--- machmode.def	15 Oct 2003 21:57:21 -0000	1.26
+++ machmode.def	3 Nov 2003 01:37:28 -0000
@@ -47,7 +47,7 @@ Software Foundation, 59 Temple Place - S
    A MODE argument must be the printable name of a machine mode,
    without quotation marks or trailing "mode".  For instance, SI.
 
-   A BITSIZE, BYTESIZE, or COUNT argument must be a positive integer
+   A PRECISION, BYTESIZE, or COUNT argument must be a positive integer
    constant.
 
    A FORMAT argument must be one of the real_mode_format structures
@@ -78,18 +78,18 @@ Software Foundation, 59 Temple Place - S
         declares MODE to be of class INT and BYTESIZE bytes wide.
 	All of the bits of its representation are significant.
 
-     FRACTIONAL_INT_MODE (MODE, BITSIZE, BYTESIZE);
+     FRACTIONAL_INT_MODE (MODE, PRECISION, BYTESIZE);
         declares MODE to be of class INT, BYTESIZE bytes wide in
-	storage, but with only BITSIZE significant bits.
+	storage, but with only PRECISION significant bits.
 
      FLOAT_MODE (MODE, BYTESIZE, FORMAT);
         declares MODE to be of class FLOAT and BYTESIZE bytes wide,
 	using floating point format FORMAT.
 	All of the bits of its representation are significant.
 
-     FRACTIONAL_FLOAT_MODE (MODE, BITSIZE, BYTESIZE, FORMAT);
+     FRACTIONAL_FLOAT_MODE (MODE, PRECISION, BYTESIZE, FORMAT);
         declares MODE to be of class FLOAT, BYTESIZE bytes wide in
-	storage, but with only BITSIZE significant bits, using
+	storage, but with only PRECISION significant bits, using
 	floating point format FORMAT.
 
      RESET_FLOAT_FORMAT (MODE, FORMAT);
@@ -101,7 +101,7 @@ Software Foundation, 59 Temple Place - S
         declares a mode of class PARTIAL_INT with the same size as
 	MODE (which must be an INT mode).  The name of the new mode
 	is made by prefixing a P to the name MODE.  This statement
-	may grow a BITSIZE argument in the future.
+	may grow a PRECISION argument in the future.
 
      VECTOR_MODE (CLASS, MODE, COUNT);
         Declare a vector mode whose component mode is MODE (of class
===================================================================
Index: machmode.h
--- machmode.h	25 Oct 2003 02:03:34 -0000	1.37
+++ machmode.h	3 Nov 2003 01:37:28 -0000
@@ -76,15 +76,15 @@ extern const unsigned char mode_class[NU
 #define SCALAR_FLOAT_MODE_P(MODE)		\
   (GET_MODE_CLASS (MODE) == MODE_FLOAT)
 
-/* Get the size in bytes of an object of mode MODE.  */
+/* Get the size in bytes and bits of an object of mode MODE.  */
 
 extern CONST_MODE_SIZE unsigned char mode_size[NUM_MACHINE_MODES];
-#define GET_MODE_SIZE(MODE)   mode_size[MODE]
+#define GET_MODE_SIZE(MODE)    ((unsigned short) mode_size[MODE])
+#define GET_MODE_BITSIZE(MODE) ((unsigned short) (GET_MODE_SIZE (MODE) * BITS_PER_UNIT))
 
-/* Get the size in bits of an object of mode MODE.  */
-
-extern const unsigned short mode_bitsize[NUM_MACHINE_MODES];
-#define GET_MODE_BITSIZE(MODE)  mode_bitsize[MODE]
+/* Get the number of value bits of an object of mode MODE.  */
+extern const unsigned short mode_precision[NUM_MACHINE_MODES];
+#define GET_MODE_PRECISION(MODE)  mode_precision[MODE]
 
 /* Get a bitmask containing 1 for all bits in a word
    that fit within mode MODE.  */
===================================================================
Index: stor-layout.c
--- stor-layout.c	22 Oct 2003 02:14:36 -0000	1.172
+++ stor-layout.c	3 Nov 2003 01:37:30 -0000
@@ -203,10 +203,10 @@ variable_size (tree size)
 #define MAX_FIXED_MODE_SIZE GET_MODE_BITSIZE (DImode)
 #endif
 
-/* Return the machine mode to use for a nonscalar of SIZE bits.
-   The mode must be in class CLASS, and have exactly that many bits.
-   If LIMIT is nonzero, modes of wider than MAX_FIXED_MODE_SIZE will not
-   be used.  */
+/* Return the machine mode to use for a nonscalar of SIZE bits.  The
+   mode must be in class CLASS, and have exactly that many value bits;
+   it may have padding as well.  If LIMIT is nonzero, modes of wider
+   than MAX_FIXED_MODE_SIZE will not be used.  */
 
 enum machine_mode
 mode_for_size (unsigned int size, enum mode_class class, int limit)
@@ -219,7 +219,7 @@ mode_for_size (unsigned int size, enum m
   /* Get the first mode which has this size, in the specified class.  */
   for (mode = GET_CLASS_NARROWEST_MODE (class); mode != VOIDmode;
        mode = GET_MODE_WIDER_MODE (mode))
-    if (GET_MODE_BITSIZE (mode) == size)
+    if (GET_MODE_PRECISION (mode) == size)
       return mode;
 
   return BLKmode;
@@ -242,7 +242,7 @@ mode_for_size_tree (tree size, enum mode
 }
 
 /* Similar, but never return BLKmode; return the narrowest mode that
-   contains at least the requested number of bits.  */
+   contains at least the requested number of value bits.  */
 
 enum machine_mode
 smallest_mode_for_size (unsigned int size, enum mode_class class)
@@ -253,7 +253,7 @@ smallest_mode_for_size (unsigned int siz
      specified class.  */
   for (mode = GET_CLASS_NARROWEST_MODE (class); mode != VOIDmode;
        mode = GET_MODE_WIDER_MODE (mode))
-    if (GET_MODE_BITSIZE (mode) >= size)
+    if (GET_MODE_PRECISION (mode) >= size)
       return mode;
 
   abort ();
===================================================================
Index: ada/targtyps.c
--- ada/targtyps.c	31 Oct 2003 01:08:43 -0000	1.7
+++ ada/targtyps.c	3 Nov 2003 01:37:30 -0000
@@ -68,6 +68,8 @@
 /* The following provide a functional interface for the front end Ada code
    to determine the sizes that are used for various C types. */
 
+#define SIZE_WITH_PADDING(X, Y) GET_MODE_BITSIZE (smallest_mode_for_size (X, Y))
+
 Pos
 get_target_bits_per_unit (void)
 {
@@ -83,62 +85,62 @@ get_target_bits_per_word (void)
 Pos
 get_target_char_size (void)
 {
-  return CHAR_TYPE_SIZE;
+  return SIZE_WITH_PADDING (CHAR_TYPE_SIZE, MODE_INT);
 }
 
 Pos
 get_target_wchar_t_size (void)
 {
   /* We never want wide chacters less than "short" in Ada.  */
-  return MAX (SHORT_TYPE_SIZE, WCHAR_TYPE_SIZE);
+  return SIZE_WITH_PADDING (MAX (SHORT_TYPE_SIZE, WCHAR_TYPE_SIZE), MODE_INT);
 }
 
 Pos
 get_target_short_size (void)
 {
-  return SHORT_TYPE_SIZE;
+  return SIZE_WITH_PADDING (SHORT_TYPE_SIZE, MODE_INT);
 }
 
 Pos
 get_target_int_size (void)
 {
-  return INT_TYPE_SIZE;
+  return SIZE_WITH_PADDING (INT_TYPE_SIZE, MODE_INT);
 }
 
 Pos
 get_target_long_size (void)
 {
-  return ADA_LONG_TYPE_SIZE;
+  return SIZE_WITH_PADDING (ADA_LONG_TYPE_SIZE, MODE_INT);
 }
 
 Pos
 get_target_long_long_size (void)
 {
-  return LONG_LONG_TYPE_SIZE;
+  return SIZE_WITH_PADDING (LONG_LONG_TYPE_SIZE, MODE_INT);
 }
 
 Pos
 get_target_float_size (void)
 {
-  return FLOAT_TYPE_SIZE;
+  return SIZE_WITH_PADDING (FLOAT_TYPE_SIZE, MODE_FLOAT);
 }
 
 Pos
 get_target_double_size (void)
 {
-  return DOUBLE_TYPE_SIZE;
+  return SIZE_WITH_PADDING (DOUBLE_TYPE_SIZE, MODE_FLOAT);
 }
 
 Pos
 get_target_long_double_size (void)
 {
-  return WIDEST_HARDWARE_FP_SIZE;
+  return SIZE_WITH_PADDING (WIDEST_HARDWARE_FP_SIZE, MODE_FLOAT);
 }
 
 Pos
 get_target_pointer_size (void)
 {
-  return POINTER_SIZE;
+  return SIZE_WITH_PADDING (POINTER_SIZE, MODE_INT);
 }
 
 Pos

Re: Ada updates frozen

[Arnaud Charlet]

> I can't support doing anything with gnatpsta/gnatpsys except folding

gnatpsys has been removed completely already.
gnatpsta ideally should indeed be integrated into gnat1, but that has not
been done yet. I have disabled it in the makefile for now, but that's
still something that requires more work.

> (Where's the list of files?)

Lost because the compiler is too confused to produce one.

Arno