Skip to content

[C++] ICE on the nested pointer indirection with address space conversion #39022

@AnastasiaStulova

Description

@AnastasiaStulova
Bugzilla Link 39674
Resolution FIXED
Resolved on Feb 12, 2020 04:56
Version trunk
OS Linux
Blocks #43900
CC @AnastasiaStulova,@bevin-hansson,@zmodem,@dobbelaj-snps

Extended Description

Multiple pointer indirection casting isn't working correctly. I.e. the following program:

kernel void foo(){
__private int** loc;
int** loc_p = loc;
**loc_p = 1;
}
will fail with ICE in C++ mode, but for C it will generate:

bitcast i32* addrspace(4)* %0 to i32 addrspace(4)* addrspace(4)*

and then perform store over pointer in AS 4 (generic). We have now lost the information that the original pointer was in private AS and that the adjustment of AS segment has to be performed before accessing memory pointed by the pointer. Based on the current specification of addrspacecast in https://llvm.org/docs/LangRef.html#addrspacecast-to-instruction I am not very clear whether it can be used for this case without any modifications or clarifications and also what would happen if there are multiple AS mismatches.

C++'s rules assume that qualifiers don't introduce real representation differences and that operations on qualified types are compatible with operations on unqualified types. That's not true of qualifiers in general: address space qualifiers can change representations, ARC qualifiers can have incompatible semantics, etc. There is no way to soundly implement a conversion from __private int ** to __generic int **, just there's no way to soundly implement a conversion from Derived ** to Base **.

Following this logic it seems reasonable to just disallow such conversions in order to prevent surprising behavior in the program.

See original discussion in https://reviews.llvm.org/D53764

Metadata

Metadata

Assignees

No one assigned

    Labels

    OpenCLbugzillaIssues migrated from bugzilla

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions