@@ -323,37 +323,39 @@ no way to reference the variable in the unnamed namespace using fully qualified
323323lookup.
324324
325325Such programs are still legal, though. The integration footer can support
326- cases like this by defining a temporary variable that holds the address of the
326+ cases like this by defining a shim function that returns a reference to the
327327shadowed device global:
328328
329329```
330330namespace {
331- const void *__sycl_UNIQUE_STRING = &FuBar; // References 'FuBar' in the
332- // unnamed namespace
331+ namespace __sycl_detail {
332+
333+ static constexpr decltype(FuBar) &__shim_1() {
334+ return FuBar; // References 'FuBar' in the unnamed namespace
333335}
334336
337+ } // namespace __sycl_detail
338+ } // namespace (unnamed)
339+
335340namespace sycl::detail {
336- namespace {
337341
338342__sycl_device_global_registration::__sycl_device_global_registration() noexcept {
339343 device_global_map::add(&::FuBar,
340344 /* same string returned from __builtin_sycl_unique_stable_id(::FuBar) */);
341- device_global_map::add(::__sycl_UNIQUE_STRING ,
345+ device_global_map::add(&::__sycl_detail::__shim_1() ,
342346 /* same string returned from __builtin_sycl_unique_stable_id(::(unnamed)::FuBar) */);
343347}
344348
345- } // namespace (unnamed)
346349} // namespace sycl::detail
347350```
348351
349- The ` __sycl_UNIQUE_STRING ` variable is defined in the same namespace as the
350- second ` FuBar ` device global, so it can reference the variable through
351- unqualified name lookup. Furthermore, the name of the temporary variable
352- (` __sycl_UNIQUE_STRING ` ) is globally unique, so it is guaranteed not to be
353- shadowed by any other name in the translation unit. This problem with variable
354- shadowing is also a problem for the integration footer we use for
355- specialization constants. See the [ specialization constant design document] [ 5 ]
356- for more details on this topic.
352+ The ` __shim_1() ` function is defined in the same namespace as the second
353+ ` FuBar ` device global, so it can reference the variable through unqualified
354+ name lookup. Furthermore, the name of the shim function is globally unique, so
355+ it is guaranteed not to be shadowed by any other name in the translation unit.
356+ This problem with variable shadowing is also a problem for the integration
357+ footer we use for specialization constants. See the [ specialization constant
358+ design document] [ 5 ] for more details on this topic.
357359
358360[ 5 ] : < SpecializationConstants.md >
359361
0 commit comments