Re: not computable at load time

[Richard Biener <richard.guenther@gmail.com>]

On Mon, May 28, 2018 at 8:34 PM Paul Koning <paulkoning@comcast.net> wrote:



> > On May 28, 2018, at 12:03 PM, Richard Biener
> <richard.guenther@gmail.com>
wrote:
> >
> > On May 28, 2018 12:45:04 PM GMT+02:00, Andreas Schwab <schwab@suse.de>
wrote:
> >> On Mai 28 2018, Richard Biener <richard.guenther@gmail.com> wrote:
> >>
> >>> It means there's no relocation that can express the result of 's.f -
> >> &s.b'
> >>> and the frontend doesn't consider this a constant expression (likely
> >> because
> >>> of the conversion).
> >>
> >> Shouldn't the frontend notice that s.f - &s.b by itself is a constant?
> >
> > Sure - the question is whether it is required to and why it doesn't.

> This is a test case in the C torture test suite.  The only  reason
> I can see for it being there is to verify that GCC resolves this as
> a compile time constant.

> The issue can be masked by changing the "long" in that test case to
> a ptrdiff_t, which eliminates the conversion.  Should I do that?
> It would make the test pass, at the expense of masking this glitch.

> By the way, I get the same error if I change the "long" to a "long long"
> and them compile for 32-bit Intel.

The testcase dates back to some repository creation rev. (egcs?) and
I'm not sure we may compute the difference of addresses of structure
members.  So that GCC accepts this is probably not required.  Joseph
may have a definitive answer here.

It might be a "regression" with the POINTER_MINUS_EXPR introduction.
You can debug this with gdb when you break on 'pointer_diff'.  For me
on x86_64 this builds a POINTER_DIFF_EXPR: (char *) &s.f - &s.b
of ptrdiff_t.  That a conversion breaks the simplification tells us that
somewhere we possibly fail to simplify it (maybe even during assembling).

You might want to file a bug for the 'long long' issue.

Richard.


>          paul