Re: Patch: stab info for const fields

Re: Patch: stab info for const fields

[Richard Kenner]

    If you look again at the bit you snipped, the implementation I
    suggested should be totally language-independent (in the
    language-independent parts of the compiler).

Yes, the *implementation* is, but the *definition* is not, so that when
people are looking at a tree, they can't know whether it's valid or not
without knowlege of the language in question and I think that's a bad idea.

Re: Patch: stab info for const fields

[Gabriel Dos Reis]

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

|     If you look again at the bit you snipped, the implementation I
|     suggested should be totally language-independent (in the
|     language-independent parts of the compiler).
| 
| Yes, the *implementation* is, but the *definition* is not, so that when
| people are looking at a tree, they can't know whether it's valid or not
| without knowlege of the language in question and I think that's a bad idea.

I strongly agree with Kenner on this point.  There ought to be a
precise definition.  I support option (1) and won't oppose to (2).
But (3) or (3a) aren't workable, IMO.

-- Gaby

Re: Patch: stab info for const fields

[Zack Weinberg]

On Fri, Nov 01, 2002 at 01:21:17AM +0100, Gabriel Dos Reis wrote:
> kenner@vlsi1.ultra.nyu.edu (Richard Kenner) writes:
> 
> |     If you look again at the bit you snipped, the implementation I
> |     suggested should be totally language-independent (in the
> |     language-independent parts of the compiler).
> | 
> | Yes, the *implementation* is, but the *definition* is not, so that when
> | people are looking at a tree, they can't know whether it's valid or not
> | without knowlege of the language in question and I think that's a bad idea.
> 
> I strongly agree with Kenner on this point.  There ought to be a
> precise definition.  I support option (1) and won't oppose to (2).
> But (3) or (3a) aren't workable, IMO.

I really don't understand the objections here.  The definition I had
in mind had no language dependencies either in the definition or the
implementation.  Let me go over it again hopefully described better:

 - We get rid of the ambiguously defined NOP_EXPR and CONVERT_EXPR.

 - In the language-independent tree representation, whenever a tree
   with type A has an operand with type B, A not identical to B, the
   operand is implicitly converted to type A before the operation
   occurs.  Most of the time there is just one, well-defined,
   conversion operation that makes sense in any such context.  If
   there is none, or if there could be multiple intended semantics,
   the tree is ill-formed; the middle-end will abort if handed such a
   tree.  (Examples: coercion between float and integer has several
   possible semantics, and it's ambiguous which one is meant; coercion
   between aggregate types is ill-defined.)

 - For situations where there is a choice of multiple intended
   conversion semantics, we define special unary conversion operators
   to make the choice explicit.  For instance, for floating point
   conversion, the existing FIX_*_EXPR and FLOAT_EXPR will do nicely.
   We will also want a REINTERPRET_EXPR that means "reinterpret the
   bits of this expression according to a different type".  It is the
   language's responsibility to insert these operators into trees
   wherever necessary.

 - Each language front end is responsible for checking all constraints
   imposed by its type algebra.  The language-independent trees have
   no such constraints; whatever is possible is permitted.

Does it make more sense now?  If you still disagree with me that this
semantic is well-defined and language-independent, please give an
example of a tree that you think would be ambiguous.

zw

Re: Patch: stab info for const fields

[Gabriel Dos Reis]

Zack Weinberg <zack@codesourcery.com> writes:

| On Fri, Nov 01, 2002 at 01:21:17AM +0100, Gabriel Dos Reis wrote:
| > kenner@vlsi1.ultra.nyu.edu (Richard Kenner) writes:
| > 
| > |     If you look again at the bit you snipped, the implementation I
| > |     suggested should be totally language-independent (in the
| > |     language-independent parts of the compiler).
| > | 
| > | Yes, the *implementation* is, but the *definition* is not, so that when
| > | people are looking at a tree, they can't know whether it's valid or not
| > | without knowlege of the language in question and I think that's a bad idea.
| > 
| > I strongly agree with Kenner on this point.  There ought to be a
| > precise definition.  I support option (1) and won't oppose to (2).
| > But (3) or (3a) aren't workable, IMO.
| 
| I really don't understand the objections here.  The definition I had
| in mind had no language dependencies either in the definition or the
| implementation.

Maybe what you had in mind has no language dependency, but that is not
transparent from the description you gave and at two persons don't see
the non-dependency.  If your definition is language independent and
precise then there ought to be possible to express it so that we can
check that the implementation matches what you intended and also our
understanding. 

|  Let me go over it again hopefully described better:
| 
|  - We get rid of the ambiguously defined NOP_EXPR and CONVERT_EXPR.

This part I do understand.

|  - In the language-independent tree representation, whenever a tree
|    with type A has an operand with type B, A not identical to B, the
|    operand is implicitly converted to type A before the operation
|    occurs.  Most of the time there is just one, well-defined,
|    conversion operation that makes sense in any such context.  If
|    there is none, or if there could be multiple intended semantics,
|    the tree is ill-formed; the middle-end will abort if handed such a
|    tree.  (Examples: coercion between float and integer has several
|    possible semantics, and it's ambiguous which one is meant; coercion
|    between aggregate types is ill-defined.)

I see that your examples try to make more precise the preceeding
assertion. IMO, we ought to define precisely the exceptional cases so
that every can check that the description is really language
indepeendent.

[...]

| Does it make more sense now? 

For me, that sheds more light on what you said earlier.  Still, I'm
uncomfortable with the non-exceptional cases not being precisely
defined.  If that part is resolved, I would see no reason not to go
with what you're proposing.

-- Gaby

Re: Patch: stab info for const fields

[Richard Kenner]

    So the question becomes: "in what circumstances is there just one,
    well-defined, conversion that makes sense?"  If we properly define
    those circumstances the problem is solved.

Sure, but, as I said, that's precisely equivalent to the original question.

Re: Patch: stab info for const fields

[Richard Kenner]

    I believe that Zack implicitly meant (3), using a superset of (2).

OK, what *is* that superset?  How is it defined precisely? 

Re: Patch: stab info for const fields

[Andrew Haley]

Richard Kenner writes:
 >     You seem to have smipped
 > 
 >        Most of the time there is just one, well-defined, conversion
 >        operation that makes sense in any such context.  If there is none,
 >        or if there could be multiple intended semantics, the tree is
 >        ill-formed; the middle-end will abort if handed such a tree.
 > 
 >     So the question becomes: "in what circumstances is there just one,
 >     well-defined, conversion that makes sense?"  If we properly define
 >     those circumstances the problem is solved.
 > 
 > Well, that's exactly what we're trying to do: to "properly define" what
 > "implicit conversions" are valid.  What is your proposal?
 > 
 > To restate the four that we've talked about into that terminology, they are:
 > 
 > (1) None.
 > (2) Only between types whose TYPE_MAIN_VARIANT are the same.
 > (3) Some other, language-independent formulation.
 > (3a) A language-dependent formulation.
 > 
 > So we're back to the original question.

I believe that Zack implicitly meant (3), using a superset of (2).
This has the advantage of economy because we won't be generating tree
nodes for many implicit conversions.

For example, we might decide that widening signed and unsigned
integers is well-defined, whereas narrowing is not.

Andrew.

Re: Patch: stab info for const fields

[Richard Kenner]

    You seem to have smipped

       Most of the time there is just one, well-defined, conversion
       operation that makes sense in any such context.  If there is none,
       or if there could be multiple intended semantics, the tree is
       ill-formed; the middle-end will abort if handed such a tree.

    So the question becomes: "in what circumstances is there just one,
    well-defined, conversion that makes sense?"  If we properly define
    those circumstances the problem is solved.

Well, that's exactly what we're trying to do: to "properly define" what
"implicit conversions" are valid.  What is your proposal?

To restate the four that we've talked about into that terminology, they are:

(1) None.
(2) Only between types whose TYPE_MAIN_VARIANT are the same.
(3) Some other, language-independent formulation.
(3a) A language-dependent formulation.

So we're back to the original question.

Re: Patch: stab info for const fields

[Andrew Haley]

Richard Kenner writes:
 >      - In the language-independent tree representation, whenever a tree
 >        with type A has an operand with type B, A not identical to B, the
 >        operand is implicitly converted to type A before the operation
 >        occurs.
 > 
 > But what does that mean?  That's the essence of the problem.
 > 
 > Please go back to the originally-stated question: if a see a PLUS_EXPR and
 > look at its type and the types of its operands, how do I know if that's
 > a valid tree node in our IL?  If the answer is "you look at the definition
 > of the language it's written in", that's a serious problem in my view.

You seem to have smipped

   Most of the time there is just one, well-defined, conversion
   operation that makes sense in any such context.  If there is none,
   or if there could be multiple intended semantics, the tree is
   ill-formed; the middle-end will abort if handed such a tree.

So the question becomes: "in what circumstances is there just one,
well-defined, conversion that makes sense?"  If we properly define
those circumstances the problem is solved.

Andrew.

Re: Patch: stab info for const fields

[Richard Kenner]

     - In the language-independent tree representation, whenever a tree
       with type A has an operand with type B, A not identical to B, the
       operand is implicitly converted to type A before the operation
       occurs.

But what does that mean?  That's the essence of the problem.

Please go back to the originally-stated question: if a see a PLUS_EXPR and
look at its type and the types of its operands, how do I know if that's
a valid tree node in our IL?  If the answer is "you look at the definition
of the language it's written in", that's a serious problem in my view.

Re: Patch: stab info for const fields

[Zack Weinberg]

On Thu, Oct 31, 2002 at 06:25:48PM -0500, Richard Kenner wrote:
>      (3a) The types are "compatible", which is a term with a precise
>           but language-specific definition; consult the relevant standard.
> 
> I don't like that idea at all.  It means that how you interpret a tree
> in the middle-end is a function of the front-end that generated it.
> But I'd strongly argue that the trees are meant to be a
> language-independent IL.

If you look again at the bit you snipped, the implementation I
suggested should be totally language-independent (in the
language-independent parts of the compiler).

zw

Re: Patch: stab info for const fields

[Richard Kenner]

     (3a) The types are "compatible", which is a term with a precise
          but language-specific definition; consult the relevant standard.

I don't like that idea at all.  It means that how you interpret a tree
in the middle-end is a function of the front-end that generated it.
But I'd strongly argue that the trees are meant to be a
language-independent IL.

Re: Patch: stab info for const fields

[Zack Weinberg]

On Thu, Oct 31, 2002 at 05:34:37PM -0500, Richard Kenner wrote:
> So the idea is that we allow "compatible" types on the two operands and
> the result of a PLUS_EXPR, but they are not required to all be the same?
> We've never really been clear on that and there are three possibilities:
> 
> (1) The types are exactly the same.
> (2) TYPE_MAIN_VARIANT of the types are the same.
> (3) The types are "compatible" (to be defined later).
> 
> I've argued for (1) in the past and continue to do so.  Is the above
> arguing for (2) or (3)?

Slight variant of (3), as I understand it:

 (3a) The types are "compatible", which is a term with a precise
      but language-specific definition; consult the relevant standard.

The actual implementation I would suggest for this is:  Language
specific code is responsible for enforcing all relevant constraints on
type compatibility.  The language independent optimizers and lowerers
assume that if the front end provided

  <plus_expr type <integer_type A>
     arg 0 <expression type <integer_type B>>
     arg 1 <expression type <integer_type C>>
  >

that it is to convert integer_types B and C to A before performing the
addition.  If this cannot be accomplished with a notional NOP_EXPR the
tree is invalid (ICE on detection).

zw

Re: Patch: stab info for const fields

[Richard Kenner]

    Again, this goes to Zack's point; we can allow two types to be compatible,
    even if they are not the same.  (That idea already exists in C/C++)

So the idea is that we allow "compatible" types on the two operands and
the result of a PLUS_EXPR, but they are not required to all be the same?
We've never really been clear on that and there are three possibilities:

(1) The types are exactly the same.
(2) TYPE_MAIN_VARIANT of the types are the same.
(3) The types are "compatible" (to be defined later).

I've argued for (1) in the past and continue to do so.  Is the above
arguing for (2) or (3)?

Re: Patch: stab info for const fields

[Mark Mitchell]

--On Thursday, October 31, 2002 05:06:41 PM +0000 Richard Kenner 
<kenner@vlsi1.ultra.nyu.edu> wrote:

>     GCC is pretty clear on the idea that the type system is, roughly
>     speaking, the C type system.  The front end's job is to translate its
>     own type system into that type system.
>
> Right, but we haven't been as clear as we should be on what "the C type
> system" is.  That's basically what started this: what about readonly?
> Consider (going back to C):
>
> 	int a;
> 	const int b;
>
> 	... a + b ...
>
> What does that PLUS_EXPR look like?

The C standard indicates that qualifiers do not matter in rvalue
contexts.

>     If you have declarations whose size is not that of their type, you
>     have to say more about what tree operations are legal in the middle
>     end.  Can you use a MODIFY_EXPR to assign these out-sized objects to
>     ordinary-sized objects?  Normally, the constraint on a MODIFY_EXPR is
>     that the two operands have the same type.  This is but the tip of the
>     iceberg.
>
> Yes, but I think they can all be solved the way the PLUS_EXPR above is:
> the *operation* is, semantically, that of its type.  However, the
> optimizers are allowed to use the fact that B is constant.

Sure -- and they can use that fact even if B is not of type "const int".

If I write:

  int b = 3;

and never modify or take the address of "b", the front end can set
TREE_READONLY on b.

> Similarly
> with a MODIFY_EXPR in the aggregate case: only the size corresponding to
> the type is modified, but if one operand is actually more aligned that
> the type, the optimizer and code generator is allowed to take advantage
> of that.

Again, this goes to Zack's point; we can allow two types to be compatible,
even if they are not the same.  (That idea already exists in C/C++)

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com

Re: Patch: stab info for const fields

[Joseph S. Myers]

On Thu, 31 Oct 2002, Zack Weinberg wrote:

> In general I think we encode way too much information in DECLs which
> is redundant with their TYPEs.  Off the top of my head: I don't see
> any legitimate reason why the size, size_unit, arguments, attributes,
> and possibly pointer_alias_set fields, and a bunch of the flags should
> ever differ from the corresponding field in TREE_TYPE (decl).

Some attributes apply to DECLs, others to TYPEs (and some meaningfully to
both).  A lot that apply to DECLs (only) should actually apply to TYPEs
(only), though.  See the FIXME comment about noreturn in attribs.c (which
I put there when trying to fix noreturn and const attributes to apply to
types properly (so c/3481 could be closed), and finding too many places
checking the DECL instead, much the same problem as the one discussed in
this thread).

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

Re: Patch: stab info for const fields

[Richard Kenner]

    GCC is pretty clear on the idea that the type system is, roughly
    speaking, the C type system.  The front end's job is to translate its
    own type system into that type system.

Right, but we haven't been as clear as we should be on what "the C type
system" is.  That's basically what started this: what about readonly?
Consider (going back to C):

	int a;
	const int b;

	... a + b ...

What does that PLUS_EXPR look like?  If A and B are different types (with
a different TREE_READONLY), then we have to have a conversion in that
PLUS_EXPR.  Sure the optimizer can "do the right thing" and ignore it,
but those conversions aren't making things any easier.

    If you have declarations whose size is not that of their type, you
    have to say more about what tree operations are legal in the middle
    end.  Can you use a MODIFY_EXPR to assign these out-sized objects to
    ordinary-sized objects?  Normally, the constraint on a MODIFY_EXPR is
    that the two operands have the same type.  This is but the tip of the
    iceberg.

Yes, but I think they can all be solved the way the PLUS_EXPR above is:
the *operation* is, semantically, that of its type.  However, the optimizers
are allowed to use the fact that B is constant.  Similarly with a MODIFY_EXPR
in the aggregate case: only the size corresponding to the type is modified,
but if one operand is actually more aligned that the type, the optimizer and
code generator is allowed to take advantage of that.

Re: Patch: stab info for const fields

[Mark Mitchell]

--On Thursday, October 31, 2002 04:38:15 PM +0000 Richard Kenner 
<kenner@vlsi1.ultra.nyu.edu> wrote:

>     It would be great to get all this junk out of DECLs, but it will
>     take some doing...
>
> I'm still not sure it's moving in the right direction.  Consider the
> following in Ada:
>
> 	type Myint is range 0..1000;
> 	for Myint'size use 32;
> 	type T is record f1, f2: Myint; end record;
> 	X: T;
> 	for X'size use 128;
>
> This has X of type T, which is 64 bits, but X is 128 bits.
>
> Currently, GNAT makes a special type for X which is a record of one
> field.  That field is of type T and the type for X has a size of 128 bits.
> Then X is of that type.
>
> But doing this means that all references to X need an implicit
> COMPONENT_REF to extract the actual data.  This is a mess.

Yes, but it's Ada's mess. :-)

GCC is pretty clear on the idea that the type system is, roughly
speaking, the C type system.  The front end's job is to translate
its own type system into that type system.

The current Ada approach is exactly the right one, in that respect.

There's no inherent reason that it should cause any problems; our
optimizers should be able to figure out what's going on.  If they
can't, they will be improved.

If you have declarations whose size is not that of their type, you
have to say more about what tree operations are legal in the middle
end.  Can you use a MODIFY_EXPR to assign these out-sized objects to
ordinary-sized objects?  Normally, the constraint on a MODIFY_EXPR
is that the two operands have the same type.  This is but the tip of
the iceberg.

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com

Re: Patch: stab info for const fields

[Richard Kenner]

    It would be great to get all this junk out of DECLs, but it will
    take some doing...

I'm still not sure it's moving in the right direction.  Consider the
following in Ada:

	type Myint is range 0..1000;
	for Myint'size use 32;
	type T is record f1, f2: Myint; end record;
	X: T;
	for X'size use 128;

This has X of type T, which is 64 bits, but X is 128 bits.

Currently, GNAT makes a special type for X which is a record of one
field.  That field is of type T and the type for X has a size of 128 bits.
Then X is of that type.

But doing this means that all references to X need an implicit
COMPONENT_REF to extract the actual data.  This is a mess.

If we allow the size of a decl to be larger than that of its type, we
can avoid this mess.

Re: Patch: stab info for const fields

[Mark Mitchell]

> It is valuable to be able to say "_this_ _particular_ integer needs a
> specific alignment independent of what alignment the ABI gives the
> type" but I don't see any real reason why we couldn't create a special
> type structure for that.  We already have to have a notion of "these
> two types are not the same but are still compatible" in the language-
> independent type algebra.

Exactly correct; I agree that this is the right way of thinking about
these attributes.

It would be great to get all this junk out of DECLs, but it will
take some doing...

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com

Re: Patch: stab info for const fields

[Zack Weinberg]

On Thu, Oct 31, 2002 at 12:51:38PM -0800, Mark Mitchell wrote:
> >In general I think we encode way too much information in DECLs which
> >is redundant with their TYPEs.  Off the top of my head: I don't see
> >any legitimate reason why the size, size_unit, arguments, attributes,
> >and possibly pointer_alias_set fields, and a bunch of the flags should
> >ever differ from the corresponding field in TREE_TYPE (decl).
> 
> I very much agree with this, in spirit.  There may be things in some
> languages that somehow make these things different, but I'm not sure what.
> You carefully left out alignment; the GNU attribute extensions do allow
> you to align variables differently from their types -- though I have
> argued in the past that this is an abuse of the notion of type.

I didn't intentionally leave it out; I missed it because it's buiried
in a union.

It is valuable to be able to say "_this_ _particular_ integer needs a
specific alignment independent of what alignment the ABI gives the
type" but I don't see any real reason why we couldn't create a special
type structure for that.  We already have to have a notion of "these
two types are not the same but are still compatible" in the language-
independent type algebra.

> There are other attributes (like "unused") that do make sense for a
> variable independently of its type, though.

Yah.

zw

Re: Patch: stab info for const fields

[Mark Mitchell]

> In general I think we encode way too much information in DECLs which
> is redundant with their TYPEs.  Off the top of my head: I don't see
> any legitimate reason why the size, size_unit, arguments, attributes,
> and possibly pointer_alias_set fields, and a bunch of the flags should
> ever differ from the corresponding field in TREE_TYPE (decl).

I very much agree with this, in spirit.  There may be things in some
languages that somehow make these things different, but I'm not sure what.
You carefully left out alignment; the GNU attribute extensions do allow
you to align variables differently from their types -- though I have
argued in the past that this is an abuse of the notion of type.  There
are other attributes (like "unused") that do make sense for a variable
independently of its type, though.

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com

Re: Patch: stab info for const fields

[Zack Weinberg]

On Thu, Oct 31, 2002 at 11:04:30AM -0800, Mark Mitchell wrote:
> 
> Yes.  The C front end is lying about the types of things.  The type of
> "const int a" is "const int"; the C front end is claiming that its type
> is "int" and that the variable is "readonly", which is not a notion in
> the C programming language.
> 
> Your patch changes the language-independent debugging output to do the
> wrong thing.  A front end, like C++, may set TREE_READONLY on a VAR_DECL
> when it knows the variable cannot change -- independently of the
> variable's type.
> 
> We certainly don't want to introduce regressions on the release branch,
> but there are some parts of GCC that are a mess, and we need to bite the
> bullet on cleaning them up.  That will introduce some regressions, in
> the short term, but it's the only path towards a more stable compiler
> in the future.

In general I think we encode way too much information in DECLs which
is redundant with their TYPEs.  Off the top of my head: I don't see
any legitimate reason why the size, size_unit, arguments, attributes,
and possibly pointer_alias_set fields, and a bunch of the flags should
ever differ from the corresponding field in TREE_TYPE (decl).

zw

Re: Patch: stab info for const fields

[Joseph S. Myers]

On Wed, 30 Oct 2002, Mark Mitchell wrote:

> > the C FE sets the READONLY bit on the FIELD_DECL node, not
> > on its type.
> 
> Yes, and that's what's wrong.  :-)
> 
> The right fix is to change that behavior in the C front end the same
> way that I changed the C++ front end a couple of years ago.

I suspect there are also some bugs in handling of "restrict" caused by the
current broken system, where when these qualifiers on the DECL are
converted back to a type only READONLY and VOLATILE are checked for.  It
would be good to try to spot these while fixing this, and add testcases
for them.

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

Re: Patch: stab info for const fields

[Mark Mitchell]

--On Thursday, October 31, 2002 10:25:27 AM -0800 Dale Johannesen 
<dalej@apple.com> wrote:

>
> On Thursday, October 31, 2002, at 09:45  AM, Mark Mitchell wrote:
>>>> The right fix is to change that behavior in the C front end the same
>>>> way that I changed the C++ front end a couple of years ago.
>>>
>>> How much of a can of worms is doing it this way?
>>
>> It took me a day or two to make the changes, and there were a few bugs
>> that trickled in over the next couple of weeks.
>
> OK, thanks.  Given that, it's very likely that trying to do as you
> suggest is going to introduce regressions.  Do you say this is "right"
> for some reason besides aesthetics?

Yes.  The C front end is lying about the types of things.  The type of
"const int a" is "const int"; the C front end is claiming that its type
is "int" and that the variable is "readonly", which is not a notion in
the C programming language.

Your patch changes the language-independent debugging output to do the
wrong thing.  A front end, like C++, may set TREE_READONLY on a VAR_DECL
when it knows the variable cannot change -- independently of the
variable's type.

We certainly don't want to introduce regressions on the release branch,
but there are some parts of GCC that are a mess, and we need to bite the
bullet on cleaning them up.  That will introduce some regressions, in
the short term, but it's the only path towards a more stable compiler
in the future.

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com

Re: Patch: stab info for const fields

[Dale Johannesen]

On Thursday, October 31, 2002, at 09:45  AM, Mark Mitchell wrote:
>>> The right fix is to change that behavior in the C front end the same
>>> way that I changed the C++ front end a couple of years ago.
>>
>> How much of a can of worms is doing it this way?
>
> It took me a day or two to make the changes, and there were a few bugs
> that trickled in over the next couple of weeks.

OK, thanks.  Given that, it's very likely that trying to do as you 
suggest is
going to introduce regressions.  Do you say this is "right" for some 
reason
besides aesthetics?  If not, I suggest my patch be accepted; it does 
after all
fix the problem, and is not at all likely to introduce regressions (a 
factor
that comes into my definition of "right").

Re: Patch: stab info for const fields

[Mark Mitchell]

>> The right fix is to change that behavior in the C front end the same
>> way that I changed the C++ front end a couple of years ago.
>
> How much of a can of worms is doing it this way?

It took me a day or two to make the changes, and there were a few bugs
that trickled in over the next couple of weeks.

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com

Re: Patch: stab info for const fields

[Dale Johannesen]

On Wednesday, October 30, 2002, at 09:58  PM, Mark Mitchell wrote:
> --On Wednesday, October 30, 2002 03:16:10 PM -0800 Dale Johannesen 
> <dalej@apple.com> wrote:
>
>> For fields of the form
>>    struct s {
>>       char *const p;
>>    }
>> the C FE sets the READONLY bit on the FIELD_DECL node, not
>> on its type.
>
> Yes, and that's what's wrong.  :-)
>
> The right fix is to change that behavior in the C front end the same
> way that I changed the C++ front end a couple of years ago.

How much of a can of worms is doing it this way?

Re: Patch: stab info for const fields

[Mark Mitchell]

--On Wednesday, October 30, 2002 03:16:10 PM -0800 Dale Johannesen 
<dalej@apple.com> wrote:

> For fields of the form
>    struct s {
>       char *const p;
>    }
> the C FE sets the READONLY bit on the FIELD_DECL node, not
> on its type.

Yes, and that's what's wrong.  :-)

The right fix is to change that behavior in the C front end the same
way that I changed the C++ front end a couple of years ago.

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com

Patch: stab info for const fields

[Dale Johannesen]

For fields of the form
   struct s {
      char *const p;
   }
the C FE sets the READONLY bit on the FIELD_DECL node, not
on its type.  This results in the 'const' attribute not getting
passed to the debugger.  Likewise for volatile.  Note that C++
does this differently, and is already generating correct debug
info (READONLY bit is on both the FIELD_DECL and the type) so
this code avoids emitting the 'const' code twice in that case.

Testing:  built the following -g, in C and C++, and verified that
gdb displayed all the types correctly.  How do you put a test like
this in the suite?  Also bootstrap and test.

struct ssc  { char *const p1; const char* p2; };
struct ss { char *ptr; };
struct ssv { char* volatile p1; volatile char* p2; };
struct big { const volatile char* p1; const char* volatile p2;
              volatile char* const p3; char* const volatile p4; };
struct sbits { char const p1:3; const char p2: 3; };
int main() {}

2002-10-30  Dale Johannesen  <dalej@apple.com>

         * dbxout.c (dbxout_type_fields):  Emit correct debug info
         for const and volatile fields.

Index: dbxout.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/dbxout.c,v
retrieving revision 1.128
diff -u -d -b -w -c -3 -p -r1.128 dbxout.c
cvs server: conflicting specifications of output style
*** dbxout.c    27 Sep 2002 03:08:37 -0000      1.128
--- dbxout.c    30 Oct 2002 23:12:29 -0000
*************** dbxout_type_fields (type)
*** 782,787 ****
--- 782,812 ----
               CHARS (2);
             }

+         if (use_gnu_debug_info_extensions
+             && TREE_CODE (tem) == FIELD_DECL
+             && (TREE_READONLY (tem) || TREE_THIS_VOLATILE (tem)))
+           {
+             tree type =
+               DECL_BIT_FIELD_TYPE (tem)
+               ? DECL_BIT_FIELD_TYPE (tem)
+               : TREE_TYPE (tem);
+             if ((TYPE_VOLATILE (type) != TREE_THIS_VOLATILE (tem))
+                || (TYPE_READONLY (type) != TREE_READONLY (tem)))
+               {
+                 have_used_extensions = 1;
+                 if ( TREE_READONLY (tem))
+                   {
+                     putc ('k', asmfile);
+                     CHARS (1);
+                   }
+                 if ( TREE_THIS_VOLATILE (tem))
+                   {
+                     putc ('B', asmfile);
+                     CHARS (1);
+                   }
+               }
+           }
+
           dbxout_type ((TREE_CODE (tem) == FIELD_DECL
                         && DECL_BIT_FIELD_TYPE (tem))
                        ? DECL_BIT_FIELD_TYPE (tem) : TREE_TYPE (tem), 
0);