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 optimization regression in constant folder

> Set?  I thought we would have

I don't see what that would serve.

> Where does it do that?  I am not aware of any such relation in
> middle-end code.

Not middle-end code, but front end.  The point is that sizetype must
have the same signedness and precision as the C size_t.

> It's an "issue" because it makes optimizations performed on Ada
> sizetype expressions different than C sizetype expressions.  

But that's wrong and where this whole thread started: if the code tests
TYPE_IS_SIZETYPE then it doesn't matter if it's signed or unsigned.

> Right.  So ssizetype and sizetype have the same semantics?  

Not sure what "semantics" means in this context.  One might be signed
and one might be unsigned.  If you mean "same semantics in the way
we generate expressions for them", then yes.

> Why do we have both of them if nobody cares about signedness of
> sizetype?

Who said nobody cares?  We don't care about it for optimization purposes
but we certainly do in terms of the types themselves.

> The point is the current situation is 1) confusing 2) redundant 3) a mess
> (IMHO).  

It's not confusing to me and it's been this way for decades.  There's
a major burden that must be met on a proposal to change it.

> I want to reduce the mess, not add to it.  It is already hard
> enough to judge what flags you need to test on optimizations on integer
> types, now you want to add another one that should be considered?

No.  I want the optimizations to correctly take into account a flag that's
been around for decades.  I am *not* proposing linking these with the other
flags: indeed I'm specifically *against* doing that for just the reasons you

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