This is the mail archive of the gcc-patches@gcc.gnu.org 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/56474


> For the C family I found exactly one - the layout_type case, and fixed
> it in the FEs by making empty arrays use [1, 0] domains or signed domains
> (I don't remember exactly).  I believe the layout_type change was to make
> Ada happy.

I'm skeptical, I had to narrow down the initial kludge because it hurted Ada.

> It may be that enabling overflow detection for even unsigned sizetype was
> because of Ada as well.  After all only Ada changed its sizetype sign
> recently.

Not true, overflow detection has _always_ been enabled for sizetypes.
But sizetypes, including unsigned ones, were sign-extended so 0 -1 didn't 
overflow and we need that behavior back for Ada to work properly, 

> I don't like special casing 0 - 1 in a general compute function.  Maybe
> you want to use size_diffop for the computation?  That would result in
> a signed result and thus no overflow for 0 - 1.

But it's not a general compute function, it's size_binop which is meant to be 
used for sizetypes only and which forces overflow on unsigned types.  We need 
overflow detection for sizetypes but we can also tailor it to fit our needs.

> The other option is to for example disable overflow handling for _all_
> constants and MINUS_EXPR (and then please PLUS_EXPR as well)
> in size_binop.  Maybe it's only the MULT_EXPR overflow we want to
> know (byte-to-bit conversion / element size scaling IIRC).

Well, we just need 0 - 1 because of the way we compute size expressions for 
variable-sized arrays.

-- 
Eric Botcazou


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