[cfe-dev] Crash on conditional operation with address_space pointer

[Leonard Chan via cfe-dev]

Oh. Should an error be printed here instead, or it's fine to let it
crash I suppose since the code shouldn't be generate in the first
place?

It seems that at least 3 tests expect this conditional operator to
print a "pointer type mismatch" warning.
On Fri, Aug 3, 2018 at 4:50 PM John McCall <rjmccall at apple.com> wrote:
>
> > On Aug 3, 2018, at 7:42 PM, Leonard Chan <leonardchan at google.com> wrote:
> > Does this mean the check during the BitCast codegen shouldn't be there
> > in the first place?
>
> We should not be generating code for this program, correct.
>
> John.
>
> > On Fri, Aug 3, 2018 at 4:28 PM John McCall <rjmccall at apple.com> wrote:
> >>
> >>> On Aug 3, 2018, at 7:03 PM, Leonard Chan via cfe-dev <cfe-dev at lists.llvm.org> wrote:
> >>> Compiling the following causes clang to crash
> >>>
> >>> char *cmp(__attribute__((address_space(1))) char *x,
> >>> __attribute__((address_space(2))) char *y) {
> >>> return x < y ? x : y;
> >>> }
> >>>
> >>> with the message: "wrong cast for pointers in different address
> >>> spaces(must be an address space cast)!"
> >>>
> >>> The problem seems to be that BitCast is used when
> >>> AddressSpaceConversion should be used instead when casting the `y` to
> >>> a void *. The error is thrown during code gen where a BitCast expects
> >>> the source and dest address space to be the same.
> >>>
> >>> I submitted a patch (https://reviews.llvm.org/D50278) for a fix where
> >>> we check for differing address spaces in the operands and perform an
> >>> AddressSpaceConversion cast if anyone wants to review it. It seems
> >>> that AddressSpaceConversions though were only available when using
> >>> OpenCL. I'm not familiar with OpenCL and not sure if this was
> >>> intended, but it fixes the crash while still retaining the warning of
> >>> using mismatched pointers and all the clang tests pass.
> >>
> >> If address spaces 1 and 2 don't overlap — and absent target-specific
> >> information, the assumption is that they don't — then neither the comparison
> >> nor the conditional operator here should type-check.
> >>
> >> John.
>