This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Fix PR middle-end/26306

Richard Kenner wrote:
My beef with AGGREGATE_TYPE_P is that I can't see any reason that an SImode "struct S { int i; }" should be treated differently from plain "int i". Even accepting the arguments about hardware registers, etc., I would still have a hard time explaining why the struct should behave differently from the scalar.

But that's not the only way to make an SImode struct!

That's just more evidence that AGGREGATE_TYPE_P isn't the right test, in my mind. :-)

Thus far, we've got:

1. The Ada front-end generates some code that it intends to be a no-op.

2. Defining middle-end semantics is complicated, in that determining what exactly ought to be a no-op is tricky (AGGREGATE_TYPE_P? BLKmode? Something else?)

3. Documenting those semantics may be hard in that it might end up relying on GCC internal concepts (like BLKmode)

4. On the one hand, we'd like to behave like previous versions of, but, on the other, we'd like to do something well-defined that we can document and live with for years to come.

It seems to me the easiest path forward is for the Ada front-end not to generate this particular kind of no-op. :-)

However, I'll not further stand in the way if someone else thinks we should really do something in the middle end, even if that something is to check AGGREGATE_TYPE_P as suggested. I think that might be suprising to C/C++ users, who (now?) have gotten used to references to volatile structures generating loads, but if we think it's worth changing, I agree that the semantics of such things are fuzzy at best.

Mark Mitchell
(650) 331-3385 x713

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