not computable at load time

not computable at load time

[Paul Koning]

One of my testsuite failures for the pdp11 back end is gcc.c-torture/compile/930326-1.c which is:

struct
{
  char a, b, f[3];
} s;

long i = s.f-&s.b;

It fails with "error: initializer element is not computable at load time".  
I don't understand why because it seems to be a perfectly reasonable 
compile time constant; "load time" doesn't enter into the picture that
I can see.

If I replace "long" by "short" it works correctly.  So presumably it has
something to do with the fact that Pmode == HImode.  But how that translates
into this failure I don't know.

	paul

Re: not computable at load time

[Richard Biener]

On Fri, May 25, 2018 at 8:05 PM Paul Koning <paulkoning@comcast.net> wrote:

> One of my testsuite failures for the pdp11 back end is
gcc.c-torture/compile/930326-1.c which is:

> struct
> {
>    char a, b, f[3];
> } s;

> long i = s.f-&s.b;

> It fails with "error: initializer element is not computable at load time".
> I don't understand why because it seems to be a perfectly reasonable
> compile time constant; "load time" doesn't enter into the picture that
> I can see.

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).

> If I replace "long" by "short" it works correctly.  So presumably it has
> something to do with the fact that Pmode == HImode.  But how that
translates
> into this failure I don't know.

>          paul

Re: not computable at load time

[Andreas Schwab]

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?

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: not computable at load time

[Richard Biener]

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. 

Richard. 

>Andreas.

Re: not computable at load time

[Paul Koning]

> 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. 

	paul

Re: not computable at load time

[Richard Biener]

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

Re: not computable at load time

[Paul Koning]

> On May 29, 2018, at 5:49 AM, Richard Biener <richard.guenther@gmail.com> wrote:
> ...
> 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.

Done, https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85974

	paul

Re: not computable at load time

[Jeff Law]

On 05/29/2018 03:49 AM, Richard Biener wrote:
> 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.
Given the name 93xxxx.c it goes back to the c-torture releases from
Torbjorn which were separate from GCC releases.  His c-torture suite
helped seed the integrated regression testsuite.;

Jeff

Re: not computable at load time

[Joseph Myers]

On Tue, 29 May 2018, Richard Biener wrote:

> 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.

My model of constant expressions for GNU C says this sort of subtraction 
(of two address constants based on the same object or function address) is 
a symbolic difference constant expression, which should be accepted as 
constant in initializers as an extension; it should be folded like other 
offsetof-like constructs.  That should not depend on whether the result 
gets converted to a type of different width.

However, the result of converting an address constant pointer to an 
integer type is only expected to be a constant expression if the resulting 
type *is* the same width as pointers.

-- 
Joseph S. Myers
joseph@codesourcery.com