On Wed, May 24, 2023 at 4:41 PM Eric Botcazou wrote:
>
> > But nobody is going to understand why the INTEGER_CST case goes the
> > other way.
>
> I can add a fat comment to that effect of course. :-)
>
> > As you say we don't have a good way to say we're doing
> > this to avoid undefined behavior,
> But nobody is going to understand why the INTEGER_CST case goes the
> other way.
I can add a fat comment to that effect of course. :-)
> As you say we don't have a good way to say we're doing
> this to avoid undefined behavior, but then a view-convert back would
> be a good way to indicate that
On Wed, May 24, 2023 at 2:39 PM Eric Botcazou wrote:
>
> > I don't like littering the patterns with this and it's likely far from the
> > only cases we have?
>
> Maybe, but that's the only problematic case we have in Ada. It occurs only on
> mainline because we have streamlined address calculatio
> I don't like littering the patterns with this and it's likely far from the
> only cases we have?
Maybe, but that's the only problematic case we have in Ada. It occurs only on
mainline because we have streamlined address calculations there, from out-of-
line to inline expansion, i.e. from run t
On Wed, May 24, 2023 at 11:56 AM Eric Botcazou via Gcc-patches
wrote:
>
> Hi,
>
> on the attached testcase, the Ada compiler gives a bogus warning:
> storage_offset1.ads:16:52: warning: Constraint_Error will be raised at run
> time [enabled by default]
>
> This directly comes from the GENERIC fold
Hi,
on the attached testcase, the Ada compiler gives a bogus warning:
storage_offset1.ads:16:52: warning: Constraint_Error will be raised at run
time [enabled by default]
This directly comes from the GENERIC folding setting a bogus TREE_OVERFLOW on
an INTEGER_CST during the (T)P - (T)(P + A) ->
