Re: [9fans] A compiler bug

Re: [9fans] A compiler bug

[cinap_lenrek]

> Fwiw, the bugs in 6c and 8c where the cast fails was fixed in 9front
> with https://code.9front.org/hg/plan9front/rev/7cf7079502a7

for 8c/6c only. but its not portable as charles pointed out. this needs a
proper fix.

--
cinap

Re: [9fans] A compiler bug

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 474 bytes --]

I've fixed the immediate problem I think in a local copy but I want to
eliminate another difference between targets before publishing the change.

On Thu, 2 Aug 2018 at 15:20, <cinap_lenrek@felloff.net> wrote:

> > Fwiw, the bugs in 6c and 8c where the cast fails was fixed in 9front
> > with https://code.9front.org/hg/plan9front/rev/7cf7079502a7
>
> for 8c/6c only. but its not portable as charles pointed out. this needs a
> proper fix.
>
> --
> cinap
>
>

[-- Attachment #2: Type: text/html, Size: 845 bytes --]

Re: [9fans] A compiler bug

[Benjamin Purcell]

Fwiw, the bugs in 6c and 8c where the cast fails was fixed in 9front
with https://code.9front.org/hg/plan9front/rev/7cf7079502a7

On Thu, Aug 2, 2018 at 5:38 AM, Charles Forsyth
<charles.forsyth@gmail.com> wrote:
> Oh. I meant that I'd fix it.
>
> On Thu, 2 Aug 2018 at 01:29, Bakul Shah <bakul@bitblocks.com> wrote:
>>
>> On Aug 1, 2018, at 4:35 PM, Charles Forsyth <charles.forsyth@gmail.com>
>> wrote:
>>
>> > even so, the format and intention of the example seems practical (with
>> > the correct cast to uintptr) and "An implementation may accept other forms
>> > of constant expressions".
>> > it should be fairly easy to add as an extension with consistent handling
>> > across ?c.
>>
>> Both gcc and clang handle this case. This example was derived from
>> ObjectIcon (it works on plan9/x86 & unix systems but not on plan9/arm).
>>
>> I am not familiar with the C compiler sources but will take a look.
>>
>> Thanks for your response.

Re: [9fans] A compiler bug

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 724 bytes --]

Oh. I meant that I'd fix it.

On Thu, 2 Aug 2018 at 01:29, Bakul Shah <bakul@bitblocks.com> wrote:

> On Aug 1, 2018, at 4:35 PM, Charles Forsyth <charles.forsyth@gmail.com>
> wrote:
>
> > even so, the format and intention of the example seems practical (with
> the correct cast to uintptr) and "An implementation may accept other forms
> of constant expressions".
> > it should be fairly easy to add as an extension with consistent handling
> across ?c.
>
> Both gcc and clang handle this case. This example was derived from
> ObjectIcon (it works on plan9/x86 & unix systems but not on plan9/arm).
>
> I am not familiar with the C compiler sources but will take a look.
>
> Thanks for your response.
>

[-- Attachment #2: Type: text/html, Size: 1065 bytes --]

Re: [9fans] A compiler bug

[Bakul Shah]

On Aug 1, 2018, at 4:35 PM, Charles Forsyth <charles.forsyth@gmail.com> wrote:

> even so, the format and intention of the example seems practical (with the correct cast to uintptr) and "An implementation may accept other forms of constant expressions".
> it should be fairly easy to add as an extension with consistent handling across ?c.

Both gcc and clang handle this case. This example was derived from
ObjectIcon (it works on plan9/x86 & unix systems but not on plan9/arm).

I am not familiar with the C compiler sources but will take a look.

Thanks for your response.

Re: [9fans] A compiler bug

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 1473 bytes --]

"6.6 Constant expressions" doesn't allow a cast from a non-arithmetic type
to an arithmetic one generally, and a cast
in an address constant can only cast from an integer constant to a pointer
type (eg, char *reg = (char*)0x123450);

the one example with 8c escaped with a warning ("initialize pointer to an
integer") because of some 8c x86-specific folding that makes the expression
acceptable.

even so, the format and intention of the example seems practical (with the
correct cast to uintptr) and "An implementation may accept other forms of
constant expressions".
it should be fairly easy to add as an extension with consistent handling
across ?c.



On Wed, 1 Aug 2018 at 08:22, Bakul Shah <bakul@bitblocks.com> wrote:

> Consider:
>
> % cat x.c
> #include <u.h>
> uintptr foo[3];
> uintptr bar=&foo[2];
>
> % 8c -c x.c     # this works.
> % 5c -c x.c     # this fails
> x.c:3 initializer is not a constant: bar
>
> If I change the last line to
>
> uintptr* bar=&foo[2];
>
> Both compilers compile it fine. But if I change the last line
> to
>
> uintptr bar=(uintptr)&foo[2];
>
> both compilers fail. Note that the last two examples are
> type correct.
>
> uintptr is the same size as int* so there should be no runtime
> cost and we already know from the second example that &foo[2]
> is a link time constant.
>
> Similar code to the last two examples compiles on gcc/clang.
>
> This seems like a compiler bug.
>
>

[-- Attachment #2: Type: text/html, Size: 2148 bytes --]

[9fans] A compiler bug

[Bakul Shah]

Consider:

% cat x.c
#include <u.h>
uintptr foo[3];
uintptr bar=&foo[2];

% 8c -c x.c	# this works.
% 5c -c x.c	# this fails
x.c:3 initializer is not a constant: bar

If I change the last line to

uintptr* bar=&foo[2];

Both compilers compile it fine. But if I change the last line
to

uintptr bar=(uintptr)&foo[2];

both compilers fail. Note that the last two examples are
type correct.

uintptr is the same size as int* so there should be no runtime
cost and we already know from the second example that &foo[2]
is a link time constant.

Similar code to the last two examples compiles on gcc/clang.

This seems like a compiler bug.