CLANG_ENABLE_OPAQUE_POINTERS=OFF does not prevent Attempting to get element type of opaque pointer assertion

[illwieckz]

The documentation says:

As of April 2022 both LLVM and Clang have complete support for opaque pointers, and opaque pointers are enabled by default in Clang. It is possible to temporarily restore the old default using the -DCLANG_ENABLE_OPAQUE_POINTERS=OFF cmake option.

But I verified in multiple ways this is not true, building clang with CLANG_ENABLE_OPAQUE_POINTERS=OFF does not provide previous behaviour.

• Building Mesa (before the Mesa commit passing -no-opaque-pointers) was facing Defaulting CLANG_ENABLE_OPAQUE_POINTERS_INTERNAL to ON broke OpenCL #54970 whatever CLANG_ENABLE_OPAQUE_POINTERS is ON or OFF,
  see: mesa/mesa#6342 clover: Assertion `NumContainedTys && "Attempting to get element type of opaque pointer"' failed (comment).
• Using llvm-spriv compiled against clang is facing the same problem whatever clang was built with CLANG_ENABLE_OPAQUE_POINTERS set to ON or OFF,
  see: How to deal with opaque pointers in the translator KhronosGroup/SPIRV-LLVM-Translator#1444 (comment)

[nikic]

Do mesa / llvm-spir make use of the driver or the cc1 interface? CLANG_ENABLE_OPAQUE_POINTERS affects whether the driver passes -no-opaque-pointers to cc1. If they're using cc1, then they need to pass -no-opaque-pointers to the cc1 invocation.

[nikic]

I've committed 3d888b0 to clarify the behavior wrt cc1.

[illwieckz]

Do mesa / llvm-spir make use of the driver or the cc1 interface? CLANG_ENABLE_OPAQUE_POINTERS affects whether the driver passes -no-opaque-pointers to cc1. If they're using cc1, then they need to pass -no-opaque-pointers to the cc1 invocation.

I don't know but for Mesa I worked it around by making Mesa pass -no-opaque-pointers on invocation (I don't know the rest of the Mesa code so I don't know how it is interfaced):

• https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16129/diffs

On mean term the Mesa code would have to be ported to opaque pointers, but this simple trick made Mesa building again without being too-much intrusive on Mesa code.

Note: I've noticed writing -Xclang -no-opaque-pointers instead of -no-opaque-pointers in Mesa code makes applications crash, maybe that can help to understand which kind of interface Mesa uses as -Xclang seems to not be expected.

[nikic]

Based on the linked merge request, mesa is indeed using the cc1 interface.

Note: I've noticed writing -Xclang -no-opaque-pointers instead of -no-opaque-pointers in Mesa code makes applications crash, maybe that can help to understand which kind of interface Mesa uses as -Xclang seems to not be expected.

Right, -Xclang is how you pass options through to cc1 when using the driver interface.

As far as I can tell, there is nothing actionable here on the LLVM side, apart from the documentation update that has already been committed (see https://llvm.org/docs/OpaquePointers.html#transition-state).

[illwieckz]

@nikic Thank you for the documentation clarification, I assume this line can also be removed from the page as “next step”:

• Enable opaque pointers by default in LLVM.

Opaque pointers are already enabled by default since 702d5de so this step is not a “next step” anymore.

[nikic]

@illwieckz Opaque pointers are currently enabled by default in Clang, but not in LLVM.

[illwieckz]

Ah you're right! That's good then.