Re: [9fans] A compiler bug
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, 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 > >
Re: [9fans] A compiler bug
> 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
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 wrote: > Oh. I meant that I'd fix it. > > On Thu, 2 Aug 2018 at 01:29, Bakul Shah wrote: >> >> On Aug 1, 2018, at 4:35 PM, Charles Forsyth >> 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
Oh. I meant that I'd fix it. On Thu, 2 Aug 2018 at 01:29, Bakul Shah wrote: > On Aug 1, 2018, at 4:35 PM, Charles Forsyth > 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
On Aug 1, 2018, at 4:35 PM, Charles Forsyth 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
"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 wrote:
> Consider:
>
> % cat x.c
> #include
> 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.
>
>
