Re: RFC: attribute "unpadded"

Re: RFC: attribute "unpadded"

[Robert Dewar]

> By "GNAT" I meant the Ada front-end combined with the GCC back-end
> (of which stor-layout.c is a part).

Then the statement that objects are layed out by GNAT is hardly informative
(since obviously *some* code in the compiler is laying out Ada objects :-)

Re: RFC: attribute "unpadded"

[Kai Henningsen]

mark@codesourcery.com (Mark Mitchell)  wrote on 29.08.02 in < 17800000.1030660041@warlock.codesourcery.com >:

> > Or perhaps you see the ABI creating intermediate types, such as
> >
> > 	struct __A { void *__vptr; char c; } attribute((unpadded));
> > 	struct A { struct __A body; };
> > 	struct B { struct __A base; char d; };
> >
> > In this modified form, A is correctly sized for an array,
> > though __A is not.
>
> Yes.  Most front ends (sample of 4) actually create both types, although
> they do:
>
>   struct A { void *__vptr; char c; };
>
> rather than:
>
>   struct A { struct __A body; }
>
> I'm not sure if there's ever a case where that matters.
>
> If there is a virtual base "V" then the full "A" looks like:
>
>   struct A { void *__vptr; char c; struct __V vbase; };
>
> Some front ends do this because their back ends expect all types to
> be basically C types.

So then it seems to me that a reasonably sane model of this for C would be  
to make an unpadded type be similar to an incomplete type, *except* that  
it can be used as a structure field (and possibly that we can dereference  
its fields from a pointer to it).

Can't use it to construct a variable or an array, same as you can't with  
an incomplete type. Can have pointers to it as long as you don't try  
pointer arithmetic, but again that should be the same as with an  
incomplete type.

Incomplete types can't sizeof(); no idea if it would be wiser to allow or  
forbid this for unpadded types.

Summary: an unpadded struct type is the same as an incomplete struct type,  
except there are a very few things more that can be done with it (and that  
can easily be enumerated in the docs) - *not* a complete struct type with  
a number of hard-to-predict things that you can't do with it.

MfG Kai

Re: RFC: attribute "unpadded"

[Mark Mitchell]

--On Thursday, August 29, 2002 04:32:58 PM -0700 Richard Henderson 
<rth@redhat.com> wrote:

On Thu, Aug 29, 2002 at 03:27:21PM -0700, Mark Mitchell wrote:

Re: RFC: attribute "unpadded"

[Richard Henderson]

On Thu, Aug 29, 2002 at 03:27:21PM -0700, Mark Mitchell wrote:
> Yes.  Most front ends (sample of 4) actually create both types, although
> they do:
> 
>  struct A { void *__vptr; char c; };
> 
> rather than:
> 
>  struct A { struct __A body; }
> 
> I'm not sure if there's ever a case where that matters.

For type-based aliasing, it does matter.

Indeed, using the later form in the C++ front end would fix
the aliasing issues currently in the front end, would it not?


r~

Re: RFC: attribute "unpadded"

[Richard Henderson]

On Thu, Aug 29, 2002 at 03:28:42PM -0700, Mark Mitchell wrote:
> This is one of the bugs I recently discovered in G++'s ABI implementation;
> it does in fact make sizeof(B) == 8, even though it shouldn't.

Right.  Found that in a later message to the list.  ;-)


r~

Re: RFC: attribute "unpadded"

[Gabriel Dos Reis]

Mark Mitchell <mark@codesourcery.com> writes:

| The point is that the RECORD_TYPE created by G++ is "unlowered"; it
| doesn't really look like a C representation of the equivalent type.  As
| a result, it's tricky for the back end to find all of the components of
| the class.

Thanks for the clarification.

-- Gaby

Re: RFC: attribute "unpadded"

[Mark Mitchell]

--On Friday, August 30, 2002 12:41:00 AM +0200 Gabriel Dos Reis 
<gdr@integrable-solutions.net> wrote:

Mark Mitchell <mark@codesourcery.com> writes:

| This is part of why type-based alias analysis and C++ run into trouble;

Just to have a clarification:  Do you mean something intrinsic to any C++
front-end or just g++?

Re: RFC: attribute "unpadded"

[Gabriel Dos Reis]

Mark Mitchell <mark@codesourcery.com> writes:

| This is part of why type-based alias analysis and C++ run into trouble;

Just to have a clarification:  Do you mean something intrinsic to any C++
front-end or just g++? 

-- Gaby

Re: RFC: attribute "unpadded"

[Mark Mitchell]

--On Thursday, August 29, 2002 03:24:48 PM -0700 Richard Henderson 
<rth@redhat.com> wrote:

On Thu, Aug 29, 2002 at 03:10:15PM -0700, Richard Henderson wrote:

Re: RFC: attribute "unpadded"

[Mark Mitchell]

Re: RFC: attribute "unpadded"

[Richard Henderson]

On Thu, Aug 29, 2002 at 03:10:15PM -0700, Richard Henderson wrote:
> Perhaps you could elaborate further on the distinction here?

I just thought of one other thing.  Please tell me what
is supposed to happen with

	struct A { virtual void foo(); int x : 31; };
	struct B : public A { unsigned int x : 1; };

If sizeof(B) == 8, then I don't see that "unpadded" does
you any good.  Having 

	struct B { struct A __base; unsigned int x : 1; };

somehow use the leftover bits of A would, IMO, do extreme
violence to gcc's structure layout routines.

If sizeof(B) == 8, then I think you're much better off modeling
this by including members directly, as I discussed earlier.


r~

Re: RFC: attribute "unpadded"

[Richard Henderson]

On Wed, Aug 28, 2002 at 01:00:14AM +1000, Fergus Henderson wrote:
> But for users of GCC who need to
> define or use structures that are layout-compatible with particular
> C++ structures, I think it would make more sense to just write C++ code
> that uses the original C++ definitions of these structures.

Or, instead, make certain that the data structures that 
are shared between C and C++ are POD types, since POD
types do not have this "unpadded" feature about them.


r~

Re: RFC: attribute "unpadded"

[Richard Henderson]

On Mon, Aug 26, 2002 at 09:38:50AM -0700, Mark Mitchell wrote:
> However, it is the one extension that will naturally express the thing
> that the C++ ABI does; that ABI creates types whose sizes are not multiples
> of their alignments by ignoring tail padding.

But it doesn't really do that, does it?

	struct A { virtual void foo(); char c; };
	struct B : public A { char d; };

sizeof(class A) is still 8, isn't it?  You can still make arrays
of type A.  What the ABI seems to actually do is include members
directly.  I.e. the C equivalent is *not*

	struct B { struct A __base; char d; };

but rather

	struct B { void *__vptr; char c; char d; };

which more or less naturally handles tail padding as you like.
And which is _somewhat_ remeniscent of the now-deprecated MSVC
extension

	struct B { struct A; char d; };

(I'm not actually sure what MSVC would say about sizeof(B) here,
and the relevant test case, gcc.dg/anon-struct-3.c, uses chars.
FWIW, gcc currently sets sizeof(struct B) == 12.)

Or perhaps you see the ABI creating intermediate types, such as

	struct __A { void *__vptr; char c; } attribute((unpadded));
	struct A { struct __A body; };
	struct B { struct __A base; char d; };

In this modified form, A is correctly sized for an array,
though __A is not.

Perhaps you could elaborate further on the distinction here?


r~

Re: RFC: attribute "unpadded"

[Richard Earnshaw]

> On 28-Aug-2002, Richard Earnshaw <rearnsha@arm.com> wrote:
> > > 
> > > > I wonder if we should not just give the type two sizes, an unpadded one 
> > > > and a padded one.  Then the unpadded one would be used for operations such 
> > > > as sizeof, and in creating larger records, but the padded one could be 
> > > > used for arrays and pointer arithmetic operations.  That is, an array 
> > > > would consist of a series of such structures laid out at their natural 
> > > > alignment.
> > > 
> > > That would violate C semantics: sizeof() must return the padded length.
> > > If it did not, the common C idiom
> > > 
> > > 	struct foo *p = malloc(array_length * sizeof(struct foo));
> > > 
> > > would break.
> > 
> > We've already gone outside the realm of the C standard as soon as we 
> > define __attribute__ ((unpadded)).
> 
> True.  However, silently breaking common C idioms is usually not a very
> good idea, even if they are only broken for specially annotated types,
> since it is error-prone -- programmers may accidentally make use of the
> common idiom even in cases when it doesn't work.
> 
> This is especially likely for programs which use have significant code
> reuse using templates or the C preprocessor.
> 
> It is important to forbid pointer arithmetic on pointers to unpadded types,
> IMHO, because this is necessary to catch such breakage.

Pointer arithmetic wouldn't be broken, only <num_elt> * 
sizeof(unpadded_type).

That is

	unpadded_type *f;

	f++;

would be defined to be equivalent to

	f = (unpadded_type *)(((char *)f) + sizeof (unpadded_type[1]));

I think sizeof (*f) should also return the padded size.

R.

Re: RFC: attribute "unpadded"

[Richard Earnshaw]

> Richard Earnshaw:
> > > > I wonder if we should not just give the type two sizes, an unpadded one 
> > > > and a padded one.  Then the unpadded one would be used for operations such 
> 
> Me:
> > > That would violate C semantics: sizeof() must return the padded length.
> > > If it did not, the common C idiom
> 
> Richard:
> > We've already gone outside the realm of the C standard as soon as we 
> > define __attribute__ ((unpadded)).
> 
> You're right, I was confused.  Objection withdrawn, pardon my stupidity.
> 
> On the other hand, there may be other problems with making arrays of unpadded
> objects.  It almost seems contractory: to find the address of foo[1] we
> consider padding, but we've declared the thing unpadded.
> 

The point of unpadded is that when the type is embedded in a larger one, 
other elements can be located around it without leaving holes if the 
alignment of such elements allow this.  If you want to say in effect that 
"unpadded" types may only be used as elements of larger aggregates, then 
fine, but that seems a little draconian.

My suggestion allows for

struct foo {int a; char b} __attribute__((unpadded));

struct bar {struct foo a1; struct foo a2};

to be written as

struct bar {struct foo a[2]};

and for the layout to be the same (in both cases the padding is placed in 
bar, not in the member types);  without this, the second form must be 
declared illegal.

R.

Re: RFC: attribute "unpadded"

[Fergus Henderson]

On 28-Aug-2002, Richard Earnshaw <rearnsha@arm.com> wrote:
> > 
> > > I wonder if we should not just give the type two sizes, an unpadded one 
> > > and a padded one.  Then the unpadded one would be used for operations such 
> > > as sizeof, and in creating larger records, but the padded one could be 
> > > used for arrays and pointer arithmetic operations.  That is, an array 
> > > would consist of a series of such structures laid out at their natural 
> > > alignment.
> > 
> > That would violate C semantics: sizeof() must return the padded length.
> > If it did not, the common C idiom
> > 
> > 	struct foo *p = malloc(array_length * sizeof(struct foo));
> > 
> > would break.
> 
> We've already gone outside the realm of the C standard as soon as we 
> define __attribute__ ((unpadded)).

True.  However, silently breaking common C idioms is usually not a very
good idea, even if they are only broken for specially annotated types,
since it is error-prone -- programmers may accidentally make use of the
common idiom even in cases when it doesn't work.

This is especially likely for programs which use have significant code
reuse using templates or the C preprocessor.

It is important to forbid pointer arithmetic on pointers to unpadded types,
IMHO, because this is necessary to catch such breakage.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: < http://www.cs.mu.oz.au/~fjh >  |     -- the last words of T. S. Garp.

Re: RFC: attribute "unpadded"

[Joe Buck]

Richard Earnshaw:
> > > I wonder if we should not just give the type two sizes, an unpadded one 
> > > and a padded one.  Then the unpadded one would be used for operations such 

Me:
> > That would violate C semantics: sizeof() must return the padded length.
> > If it did not, the common C idiom

Richard:
> We've already gone outside the realm of the C standard as soon as we 
> define __attribute__ ((unpadded)).

You're right, I was confused.  Objection withdrawn, pardon my stupidity.

On the other hand, there may be other problems with making arrays of unpadded
objects.  It almost seems contractory: to find the address of foo[1] we
consider padding, but we've declared the thing unpadded.

Re: RFC: attribute "unpadded"

[Richard Earnshaw]

> 
> > I wonder if we should not just give the type two sizes, an unpadded one 
> > and a padded one.  Then the unpadded one would be used for operations such 
> > as sizeof, and in creating larger records, but the padded one could be 
> > used for arrays and pointer arithmetic operations.  That is, an array 
> > would consist of a series of such structures laid out at their natural 
> > alignment.
> 
> That would violate C semantics: sizeof() must return the padded length.
> If it did not, the common C idiom
> 
> 	struct foo *p = malloc(array_length * sizeof(struct foo));
> 
> would break.

We've already gone outside the realm of the C standard as soon as we 
define __attribute__ ((unpadded)).  Anyway, defining

	struct foo *p = malloc(array_length * sizeof(struct foo[1]));

would work if you used my further suggestion, since struct foo[1] would 
always return the padded size.

> > It does mean that using code such as n * sizeof(struct A) would be 
> > undefined, but it would mean that some array operations would be well 
> > defined.
> 
> But C already specifies the meaning of n * sizeof(struct A) and assures
> that if you pass such an argument to malloc, the result will hold n A's,
> complete with padding.

It doesn't specify *anything* for unpadded types, it isn't part of the 
standard.

R.

Re: RFC: attribute "unpadded"

[Joe Buck]

> I wonder if we should not just give the type two sizes, an unpadded one 
> and a padded one.  Then the unpadded one would be used for operations such 
> as sizeof, and in creating larger records, but the padded one could be 
> used for arrays and pointer arithmetic operations.  That is, an array 
> would consist of a series of such structures laid out at their natural 
> alignment.

That would violate C semantics: sizeof() must return the padded length.
If it did not, the common C idiom

	struct foo *p = malloc(array_length * sizeof(struct foo));

would break.

> It does mean that using code such as n * sizeof(struct A) would be 
> undefined, but it would mean that some array operations would be well 
> defined.

But C already specifies the meaning of n * sizeof(struct A) and assures
that if you pass such an argument to malloc, the result will hold n A's,
complete with padding.

Re: RFC: attribute "unpadded"

[Richard Earnshaw]

> I want to create a new type attribute "unpadded" that would, on
> this code:
> 
>   struct S __attribute__((unpadded)) {
>     int i;
>     char c;
>   };
> 
> define S to have size 5 and alignment 4 on an ILP32 machine.
> 
> The idea is that the normal tail padding of S (the three bytes
> after "c" to round it out to a multiple of the alignment) would
> be suppressed.  It would be illegal to create arrays of these
> types, since the required alignment would not then be provided
> to all of the array elements.
> 
> The motivation for this comes from work on the C++ ABI, including
> the tests for interoperability that we are developing.  The C++
> ABI essentially has types like the above, but they are implicit.
> Making them explicit gives us a way to express the same thing in C.
> 
> This comes up in C++ like so:
> 
>   struct A { virtual void f();  char c; };
>   struct B : public A { char c2 };
> 
> Here, the size of B is 8, not 12, because "c2" is packed into
> the tail padding of A.  If A were "unpadded", you could express
> this in C as:
> 
>   struct A __attribute__((unpadded)) { void *vptr; char c; };
>   struct B { struct A __base; char c2; };
> 
> If I do not here objections, I will create a patch for this and
> check it in shortly.  Rats, we are in Stage 3 -- so I will check
> it in after we branch for GCC 3.3.
> 
I wonder if we should not just give the type two sizes, an unpadded one 
and a padded one.  Then the unpadded one would be used for operations such 
as sizeof, and in creating larger records, but the padded one could be 
used for arrays and pointer arithmetic operations.  That is, an array 
would consist of a series of such structures laid out at their natural 
alignment.

It does mean that using code such as n * sizeof(struct A) would be 
undefined, but it would mean that some array operations would be well 
defined.

(We could even define sizeof (struct A[1]) to return the padded size.)

R.

Re: RFC: attribute "unpadded"

[Fergus Henderson]

On 27-Aug-2002, Richard Kenner <kenner@vlsi1.ultra.nyu.edu> wrote:
>     Presumably Ada objects are layed out by GNAT,
> 
> No, Ada objects are also layed out by stor-layout.c, for the most part.

By "GNAT" I meant the Ada front-end combined with the GCC back-end
(of which stor-layout.c is a part).

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: < http://www.cs.mu.oz.au/~fjh >  |     -- the last words of T. S. Garp.

Re: RFC: attribute "unpadded"

[Richard Kenner]

    Presumably Ada objects are layed out by GNAT,

No, Ada objects are also layed out by stor-layout.c, for the most part.

Re: RFC: attribute "unpadded"

[Joe Buck]

Mark writes:
> > People who generate C from their
> > object-oriented language compilers and want C++ interoperability also
> > would like to make use of this feature.

Fergus writes:
> Wouldn't those people be better off just retargetting their compilers
> to generate C++ rather than C?

It would certainly seem so.  After all, we'd be talking about an extension
supported only by GNU C, and anyone who can get GNU C can get GNU C++ for
the same platform.  Not only that, but by targeting C++, *any* C++
compiler could be used, not just GNU.  Given this, I can't conceive of why
as a tool-maker I'd want to take advantage of such a feature (and writing
tools that generate C or C++ code is what I do for a living).

In the old days, my approach tended to be to generate C, but found that I
wasted a lot of my time duplicating features that C++ provides for free
(reliable constructors and destructors, for example), so it's better to
generate C++.

Re: RFC: attribute "unpadded"

[Gabriel Dos Reis]

Fergus Henderson <fjh@cs.mu.OZ.AU> writes:

| > People who generate C from their
| > object-oriented language compilers and want C++ interoperability also
| > would like to make use of this feature.
| 
| Wouldn't those people be better off just retargetting their compilers
| to generate C++ rather than C?

Certainly.  That is a much more viable and portable way to deal with
the issue.

-- Gaby

Re: RFC: attribute "unpadded"

[Mark Mitchell]

Re: RFC: attribute "unpadded"

[Fergus Henderson]

On 27-Aug-2002, Mark Mitchell <mark@codesourcery.com> wrote:
> 
> >What's the advantage *for users* in being able to emulate the C++ ABI in
> >C?
> 
> Good question.
> 
> There is probably little utility for users, but there is utility for tools,
> and for other languages.

That statement seems plausible, but your examples are not very convincing,
IMHO.

> For example, Ada people have talked about laying
> out objects in a C++-compatible way so that objects could be passed back
> and forth between the languages.

I don't see how extending the C front-end to support attribute "unpadded"
would achieve that goal.  Presumably Ada objects are layed out by GNAT,
not C... if the issue is Ada/C++ compatibility, I don't see where C
comes into it.

> People who generate C from their
> object-oriented language compilers and want C++ interoperability also
> would like to make use of this feature.

Wouldn't those people be better off just retargetting their compilers
to generate C++ rather than C?

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: < http://www.cs.mu.oz.au/~fjh >  |     -- the last words of T. S. Garp.

Re: RFC: attribute "unpadded"

[Mark Mitchell]

Re: RFC: attribute "unpadded"

[Tom Tromey]

>>>>> "Fergus" == Fergus Henderson <fjh@cs.mu.OZ.AU> writes:

>> Here is what I am going to do at this point: implement the extension,
>> and use it for myself.  I will check it in after GCC 3.3 branches --
>> unless a maintainer asks me not to do so.

Fergus> Implementing it as an extension might (currently) be the
Fergus> easiest way to implement a good test suite for the C++ ABI.
Fergus> So I would not object to it being added for that purpose.
Fergus> However, if there is no pressing *user* need for it, then I
Fergus> think it might be a mistake to document it as an offically
Fergus> supported extension at this point.


Is there another front end that can do layouts the way Mark requires
for testing?  For instance, could treelang be used instead of
extending C?  (I've never looked at treelang, so this may be
completely off the wall.)

Tom

Re: RFC: attribute "unpadded"

[Fergus Henderson]

On 26-Aug-2002, Mark Mitchell <mark@codesourcery.com> wrote:
> 
> There's no point arguing about the specific extension.  It is what it
> is, warts and all.  I will not argue it is pretty.
> 
> However, it is the one extension that will naturally express the thing
> that the C++ ABI does; that ABI creates types whose sizes are not multiples
> of their alignments by ignoring tail padding.  If you were to create a
> type-theoretic calculus for the ABI, you would need these types.
> 
> So, the debate we should be having is one about the user-level feature
> of being able to emulate the C++ ABI in other languages.  If we want
> to be able to do this, we need this extension.  If we don't think that's
> important, then I'll withdraw the proposal.

What's the advantage *for users* in being able to emulate the C++ ABI in C?

I can see why this would be useful for the GCC implementors, to implement
GCC's own internal test suite.  But for users of GCC who need to
define or use structures that are layout-compatible with particular
C++ structures, I think it would make more sense to just write C++ code
that uses the original C++ definitions of these structures.
If these structures need to be accessed from C, it's always possible to
write access routines (get_field_1, set_field_1, etc.) in C++, and
export them to C using `extern "C"'.  This approach has the advantage
that it is more portable: it doesn't matter which C++ ABI the compiler
uses, and it doesn't require the C compiler to support this attribute
"unpadded" extension.

> Here is what I am going to do at this point: implement the extension,
> and use it for myself.  I will check it in after GCC 3.3 branches --
> unless a maintainer asks me not to do so.

Implementing it as an extension might (currently) be the easiest way
to implement a good test suite for the C++ ABI.  So I would not object
to it being added for that purpose.  However, if there is no pressing
*user* need for it, then I think it might be a mistake to document it
as an offically supported extension at this point.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: < http://www.cs.mu.oz.au/~fjh >  |     -- the last words of T. S. Garp.

Re: RFC: attribute "unpadded"

[Mark Mitchell]

--On Tuesday, August 27, 2002 03:10:00 AM +0100 Jamie Lokier 
<egcs@tantalophile.demon.co.uk> wrote:

Mark Mitchell wrote:

Re: RFC: attribute "unpadded"

[Jamie Lokier]

Mark Mitchell wrote:
> This comes up in C++ like so:
> 
>   struct A { virtual void f();  char c; };
>   struct B : public A { char c2 };

Here in C++, `sizeof(struct A)' is 8, and `sizeof(struct B)' is also 8.

> Here, the size of B is 8, not 12, because "c2" is packed into
> the tail padding of A.  If A were "unpadded", you could express
> this in C as:
> 
>   struct A __attribute__((unpadded)) { void *vptr; char c; };
>   struct B { struct A __base; char c2; };

This does _not_ express the same thing in C, because this C version of
`sizeof(struct A)' is 5.

For this reason, Alexandre Oliva's suggestion to use the attribute in
the definition of `struct B' to control the layout of `struct B' make
more sense to me.  Not because it's type-theoretically right, but simply
because that gives the same results as C++.

-- Jamie

Re: RFC: attribute "unpadded"

[Gabriel Dos Reis]

Mark Mitchell <mark@codesourcery.com> writes:

| However, it is the one extension that will naturally express the thing
| that the C++ ABI does; that ABI creates types whose sizes are not multiples
| of their alignments by ignoring tail padding.

I'm pretty sure similar arguments can be constructed for extensions that
were deemed not "appropriate" and removed :-)

| Here is what I am going to do at this point: implement the extension,
| and use it for myself.  I will check it in after GCC 3.3 branches --
| unless a maintainer asks me not to do so.

Aha, I now see the benefits of having global write privs. 1/2 ;-)

-- Gaby

Re: RFC: attribute "unpadded"

[Mark Mitchell]

Re: RFC: attribute "unpadded"

[Gabriel Dos Reis]

Andreas Schwab <schwab@suse.de> writes:

| Paul Koning <pkoning@equallogic.com> writes:
| 
| |> What I meant is: as far as I know, C has never had types that have
| |> this sort of properties, so the new class is unlike normal C types.
| |> And the restrictions are of a kind that a lot of C programmers would
| |> probably find rather surprising.  (It's not that they don't make sense
| |> if you analyze what is going on.  But C, nor for that matter any of
| |> the half dozen or so languages I can think of, doesn't have any types
| |> that aren't permitted as array elements.)
| 
| C always had function types and incomplete types, both are not valid as
| array elements.

Yes, however an important distinction is that function types
aren't object types and you can't create objects of incomplete types.
Having a complete object type for which pointer arithmetic isn't
allowed isn't something I'll say natural for C.

|  But the new types are neither functions nor incomplete,
| so there is something new about them.

Exactly.

I think Paul has a point here that needs some consideration as far as 
the pertubations to the existing type system are concerned.

Well, I won't repeat the arguments Mark himself made in the past
regarding extensions 8-)

-- Gaby

Re: RFC: attribute "unpadded"

[Andreas Schwab]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 937 bytes --]

Paul Koning <pkoning@equallogic.com> writes:

|> What I meant is: as far as I know, C has never had types that have
|> this sort of properties, so the new class is unlike normal C types.
|> And the restrictions are of a kind that a lot of C programmers would
|> probably find rather surprising.  (It's not that they don't make sense
|> if you analyze what is going on.  But C, nor for that matter any of
|> the half dozen or so languages I can think of, doesn't have any types
|> that aren't permitted as array elements.)

C always had function types and incomplete types, both are not valid as
array elements.  But the new types are neither functions nor incomplete,
so there is something new about them.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: RFC: attribute "unpadded"

[Paul Koning]

>>>>> "Mark" == Mark Mitchell <mark@codesourcery.com> writes:
 Mark> My proposal doesn't "do violence" to the type system; it simply
 Mark> adds a class of types for which certain actions are not
 Mark> allowed, such as the creation of arrays of these types.

What I meant is: as far as I know, C has never had types that have
this sort of properties, so the new class is unlike normal C types.
And the restrictions are of a kind that a lot of C programmers would
probably find rather surprising.  (It's not that they don't make sense
if you analyze what is going on.  But C, nor for that matter any of
the half dozen or so languages I can think of, doesn't have any types
that aren't permitted as array elements.)

     paul

Re: RFC: attribute "unpadded"

[Zack Weinberg]

On Mon, Aug 26, 2002 at 12:03:38PM +1000, Fergus Henderson wrote:
> On 23-Aug-2002, Zack Weinberg <zack@codesourcery.com> wrote:
> > 
> > (Idle thought: Is our language-independent type system powerful enough
> > that we could implement ML type inference with it?  I suspect not.)
> 
> The Mercury front-end supports type inference in a manner very similar
> to ML, and maps this to GCC's C-like type system.  The mapping is pretty
> straight-forward, actually: polymorphically typed variables are given
> the GCC type represented by `ptr_type_node', i.e. `void *'.

I guessed as much, but I meant something different: could we implement
a type inference engine as a language-independent component, using
only the information stored in the existing language-independent type
system?  If not, what's missing?

zw

Re: RFC: attribute "unpadded"

[Fergus Henderson]

On 23-Aug-2002, Zack Weinberg <zack@codesourcery.com> wrote:
> 
> (Idle thought: Is our language-independent type system powerful enough
> that we could implement ML type inference with it?  I suspect not.)

The Mercury front-end supports type inference in a manner very similar
to ML, and maps this to GCC's C-like type system.  The mapping is pretty
straight-forward, actually: polymorphically typed variables are given
the GCC type represented by `ptr_type_node', i.e. `void *'.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: < http://www.cs.mu.oz.au/~fjh >  |     -- the last words of T. S. Garp.

Re: RFC: attribute "unpadded"

[Mark Mitchell]

--On Friday, August 23, 2002 7:42 PM -0400 Olivier Galibert 
<galibert@pobox.com> wrote:

On Fri, Aug 23, 2002 at 06:49:17PM +0100, Andrew Haley wrote:

Re: RFC: attribute "unpadded"

[Mark Mitchell]

I like that.  The "unpadded" proposal sounded like it would do
significant violence to the C type system, and this avoids that
issue.

Re: RFC: attribute "unpadded"

[Paul Koning]

>>>>> "Alexandre" == Alexandre Oliva <aoliva@redhat.com> writes:

 Alexandre> Instead of attaching this attribute to the type, perhaps
 Alexandre> it would bring us less complications to attach it to a
 Alexandre> struct member, i.e., instead of:

 >> struct A __attribute__((unpadded)) { void *vptr; char c; }; struct
 >> B { struct A __base; char c2; };

 Alexandre> you'd write:

 >> struct A { void *vptr; char c; }; struct B { struct A __base
 >> __attribute__((unpadded)); char c2; };

 Alexandre> this wouldn't require any change in the typing rules,
 Alexandre> since the type of struct A would be unchanged.

I like that.  The "unpadded" proposal sounded like it would do
significant violence to the C type system, and this avoids that
issue. 

       paul

Re: RFC: attribute "unpadded"

[Alexandre Oliva]

On Aug 23, 2002, Mark Mitchell <mark@codesourcery.com> wrote:

> I want to create a new type attribute "unpadded" that would, on
> this code:

>   struct S __attribute__((unpadded)) {
>     int i;
>     char c;
>   };

> define S to have size 5 and alignment 4 on an ILP32 machine.

Instead of attaching this attribute to the type, perhaps it would
bring us less complications to attach it to a struct member, i.e.,
instead of:

>   struct A __attribute__((unpadded)) { void *vptr; char c; };
>   struct B { struct A __base; char c2; };

you'd write:

>   struct A { void *vptr; char c; };
>   struct B { struct A __base __attribute__((unpadded)); char c2; };

this wouldn't require any change in the typing rules, since the type
of struct A would be unchanged.  The attribute would only be used to
affect the lay out of struct B.  I have no idea whether this would
make the implementation of this feature much harder, though, since it
would have to peek into struct A to see how much padding it had, and
cancel that for the layout of struct B.  But it sounds like a less
intrusive change in the type system.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: RFC: attribute "unpadded"

[Olivier Galibert]

On Fri, Aug 23, 2002 at 06:49:17PM +0100, Andrew Haley wrote:
> Documenting the semantics of (attribute "unpadded") and (attribute
> "aligned") and (attribute "packed") and the way that they interact in
> a way that is comprehensible to a programmer will present some poor
> soul with quite a challenge.

Maybe you want to define that in terms of internal alignment (within
the structure) and external alignment (when you put these structures
next to each other, i.e. sizeof() in practice).

Then:
- unpadded   = set external alignment to 1
- packed     = set internal alignment to 1
- aligned(n) = set internal and external alignment to n

Order matters, or unpadded/packed trump aligned.

Of course, all accessibility bets/arrays are off when
external alignment < internal alignment.

  OG.

Re: RFC: attribute "unpadded"

[Richard Kenner]

    I wonder if Ada can do something like this already, it seems to have
    everything *else* in its type system...

Yes and no.  Certainly you need to be able to have a record in Ada where
there is no padding, but the idea of its size not being a multiple of its
alignment is problematic.  So what's actually done is that *two* sizes are
stored, the "GCC size", which includes the padding and is a multiple of the
alignment, and the "Ada size", which does not include the alignment.  The
distinction is that it's the Ada size that represents the minimum size that
the record requires when placed into another packed record.

I was trying to decide if Mark's proposal would help Ada, but can't tell:
I'd need to see more details to know for sure.

Re: RFC: attribute "unpadded"

[Zack Weinberg]

On Fri, Aug 23, 2002 at 08:18:47PM -0000, Mark Mitchell wrote:
> >So, you're adding more
> >complexity to an edifice that is already rather baroque -- and the end
> >result of the combination of these attributes will be difficult to
> >explain and understand.
> 
> Yes; I make this argument all the time when we discuss various extensions.
> 
> When the extension just provides an easier way of doing something
> that can already be done, it's a particularly strong argument.  In this
> case, that's not true; the proposed extension does let us do something
> new.

However, the effect of the extension has to be duplicated internally
by the C++ front end.  It might be a good idea if the language-
independent type system could represent this concept directly.  If the
C extension falls naturally out of adding the language-independent
concept, it shouldn't be that bad to provide it.

I wonder if Ada can do something like this already, it seems to have
everything *else* in its type system...

(Idle thought: Is our language-independent type system powerful enough
that we could implement ML type inference with it?  I suspect not.)

zw

Re: RFC: attribute "unpadded"

[Mark Mitchell]

Types with this new attribute will have unusual semantics - you can't
have arrays of them nor take the addresses of objects with that type,

Re: RFC: attribute "unpadded"

[Neil Booth]

Andrew Haley wrote:-

> Types with this new attribute will have unusual semantics - you can't
> have arrays of them nor take the addresses of objects with that type,
> for example.

I think you can take the address, you just can't do arithmetic on the
address if the underlying type is one of these unpadded types.

Neil.

Re: RFC: attribute "unpadded"

[Andrew Haley]

Mark Mitchell writes:
 > 
 > 
 > --On Friday, August 23, 2002 6:49 PM +0100 Andrew Haley 
 > <aph@cambridge.redhat.com> wrote:
 > 
 > > Documenting the semantics of (attribute "unpadded") and (attribute
 > > "aligned") and (attribute "packed") and the way that they interact in
 > > a way that is comprehensible to a programmer will present some poor
 > > soul with quite a challenge.
 > 
 > That would be me, I expect.
 > 
 > Your underlying point (that this is all very complex) is correct.
 
It's not just that.

Types with this new attribute will have unusual semantics - you can't
have arrays of them nor take the addresses of objects with that type,
for example.  Also, "unpadded" will interact with other attributes in
interesting and possibly strange ways.  So, you're adding more
complexity to an edifice that is already rather baroque -- and the end
result of the combination of these attributes will be difficult to
explain and understand.

Andrew.

Re: RFC: attribute "unpadded"

[Benjamin Kosnik]

> I will make a more detailed announcement later, when we are nearer to
> completion.

Thanks. I look forward to hearing more about this.

-benjamin

Re: RFC: attribute "unpadded"

[Mark Mitchell]

Re: RFC: attribute "unpadded"

[Mark Mitchell]

Is this something that will be in addition to, or in replacement of, the
make-check abi work for libstdc++ and the thoughts to make the vlad
cosistency checks work again?

Re: RFC: attribute "unpadded"

[Janis Johnson]

On Fri, Aug 23, 2002 at 11:07:09AM -0700, Benjamin Kosnik wrote:
> 
> > > Can you specify for the record what you are talking about here?
> > 
> > We are under contract to deliver a C++ ABI testsuite that we believe will
> > be very comprehensive.  We anticipate completing the work by the end of
> > FY2002.  We anticipate that the results of the testsuite will be available
> > to GCC developers.
> 
> That's nice to know, thanks. I was previously unaware of this effort. 
> 
> Is this something that will be in addition to, or in replacement of, the
> make-check abi work for libstdc++ and the thoughts to make the vlad
> cosistency checks work again?
> 
> There seem to be other people working on this. If there is a specific
> plan, then perhaps it could be less work for everyone.

I agree.  I've been looking into ways to test compiler consistency.  I
started writing up the issues involved and possible testing approaches
(see http://gcc.gnu.org/ml/gcc/2002-08/msg01251.html ) and plan to turn
that into useful documentation, as well as a place to record what
testing is available.  If this is redundant with your efforts then I'd
like to know soon so I can work on something else instead.

Will your testsuite itself be available to GCC developers, or just the
results that you get by running it yourself on a limited number of
platforms?

Janis

Re: RFC: attribute "unpadded"

[Benjamin Kosnik]

> > Can you specify for the record what you are talking about here?
> 
> We are under contract to deliver a C++ ABI testsuite that we believe will
> be very comprehensive.  We anticipate completing the work by the end of
> FY2002.  We anticipate that the results of the testsuite will be available
> to GCC developers.

That's nice to know, thanks. I was previously unaware of this effort. 

Is this something that will be in addition to, or in replacement of, the
make-check abi work for libstdc++ and the thoughts to make the vlad
cosistency checks work again?

There seem to be other people working on this. If there is a specific
plan, then perhaps it could be less work for everyone.

-benjamin

Re: RFC: attribute "unpadded"

[Mark Mitchell]

--On Friday, August 23, 2002 10:57 AM -0700 Benjamin Kosnik 
<bkoz@redhat.com> wrote:

Re: RFC: attribute "unpadded"

[Benjamin Kosnik]

> The motivation for this comes from work on the C++ ABI, including
> the tests for interoperability that we are developing.  

Can you specify for the record what you are talking about here?

-benjamin

Re: RFC: attribute "unpadded"

[Mark Mitchell]

Re: RFC: attribute "unpadded"

[Fergus Henderson]

On 23-Aug-2002, Mark Mitchell <mark@codesourcery.com> wrote:
> I want to create a new type attribute "unpadded" that would, on
> this code:
> 
>  struct S __attribute__((unpadded)) {
>    int i;
>    char c;
>  };
> 
> define S to have size 5 and alignment 4 on an ILP32 machine.
> 
> The idea is that the normal tail padding of S (the three bytes
> after "c" to round it out to a multiple of the alignment) would
> be suppressed.  It would be illegal to create arrays of these
> types, since the required alignment would not then be provided
> to all of the array elements.

What about pointer arithmetic, for pointers of type `S *'?
Would that be disallowed too?

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: < http://www.cs.mu.oz.au/~fjh >  |     -- the last words of T. S. Garp.

Re: RFC: attribute "unpadded"

[Mark Mitchell]

--On Friday, August 23, 2002 6:49 PM +0100 Andrew Haley 
<aph@cambridge.redhat.com> wrote:

Documenting the semantics of (attribute "unpadded") and (attribute
"aligned") and (attribute "packed") and the way that they interact in
a way that is comprehensible to a programmer will present some poor
soul with quite a challenge.

RFC: attribute "unpadded"

[Andrew Haley]

Documenting the semantics of (attribute "unpadded") and (attribute
"aligned") and (attribute "packed") and the way that they interact in
a way that is comprehensible to a programmer will present some poor
soul with quite a challenge.

Andrew.

RFC: attribute "unpadded"

[Mark Mitchell]

I want to create a new type attribute "unpadded" that would, on
this code:

 struct S __attribute__((unpadded)) {
   int i;
   char c;
 };

define S to have size 5 and alignment 4 on an ILP32 machine.

The idea is that the normal tail padding of S (the three bytes
after "c" to round it out to a multiple of the alignment) would
be suppressed.  It would be illegal to create arrays of these
types, since the required alignment would not then be provided
to all of the array elements.

The motivation for this comes from work on the C++ ABI, including
the tests for interoperability that we are developing.  The C++
ABI essentially has types like the above, but they are implicit.
Making them explicit gives us a way to express the same thing in C.

This comes up in C++ like so:

 struct A { virtual void f();  char c; };
 struct B : public A { char c2 };

Here, the size of B is 8, not 12, because "c2" is packed into
the tail padding of A.  If A were "unpadded", you could express
this in C as:

 struct A __attribute__((unpadded)) { void *vptr; char c; };
 struct B { struct A __base; char c2; };

If I do not here objections, I will create a patch for this and
check it in shortly.  Rats, we are in Stage 3 -- so I will check
it in after we branch for GCC 3.3.

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