Intel® C++ Compiler
Support and discussions for creating C++ code that runs on platforms based on Intel® processors.
Announcements
The Intel sign-in experience is changing in February to support enhanced security controls. If you sign in, click here for more information.
7749 Discussions

C++17 Non-Conformance: CTAD Unsupported at Class Scope

jase439
Beginner
850 Views

Hello. I am writing with regards to what I believe to be a conformance deviation in the Intel 19.2 and Intel 2022 DPC++ compilers with regard to the C++17 standard as it relates to Class Template Argument Deduction (CTAD) guides:

[temp.deduct.guide] (eel.is)

 

Specifically, this in reference to this part of the standard:

 

deduction-guide shall inhabit the scope to which the corresponding class template belongs and, for a member class template, have the same access.

See also: [temp.deduct.guide] (timsong-cpp.github.io)

 

Presently, the Intel compiler toolchain only supports CTAD at namespace-level scope. Deduction guides that are given within a nested scope are unrecognizable by the compiler and yields an ambiguous error about the return type of the deduction guide requiring a reference to a class specialization (even though one is given):

error: the return type must directly designate a specialization of the associated class template

 
A demonstration of this problem can be seen here:
 
 
This issue was originally reported as a conformance issue (and ICE) in GCC 10.x and has since been fixed in GCC 12.x. Clang/LLVM have also addressed the non-conformance. MSVC 2017 and later are also conformant. Intel should endeavor to join this party
 
Here are the GCC and LLVM reports with sample code:
 
 
I can confirm that both Intel Classic and DPC++ compilers behave correctly if the deduction-guides and the classes for which they deduce are moved out to namespace scope.
 
It would be great if this could be addressed in a near-term update as this issue currently requires me to break out my private nested classes into top-level entities and introduce undesired friend relationships and type-aliases to keep the logical abstraction intact - that or adopt an non-intuitive verbose creation syntax that doesn't rely on CTAD deduction guides for type-inferences. CTAD is possibly my favorite addition to the C++17 standard and really allows the compiler to do intelligent things without having to resort to overly-clever template jujitsu. Having this this work as spec'd would be a huge boon to my project.
 
Thanks for your time!
 
PS. On a side note, I am unable to 'detect' the DPC++ compiler in the preprocessor. The __INTEL_COMPILER macro works for classic, but __INTEL_LLVM_COMPILER does not appear to be defined when I build in DPC++ 2022.x. Is there another macro I should be looking at?

 

 

0 Kudos
10 Replies
VarshaS_Intel
Moderator
816 Views

Hi,

 

Thanks for posting in Intel Communities.

 

Could you please try using the icx compiler as it works as expected? And also, we didn't face any errors while using the dpcpp compiler for the sample code provided by you. Please find the below commands and screenshot of it:

 

For ICX compiler: 
Compiling: icx -std=c++17 -O2 -Wall -Wextra -pedantic sample.cpp 
./a.out
For DPCPP compiler:
Compiling: dpcpp sample.cpp
./a.out

cppOutput.png

Could you please try and let us know if you are facing any issues?

 

Thanks & Regards,

Varsha

 

jase439
Beginner
785 Views

Hi Varsha,

 

This issue turns out to be a bit more of a bit more complicated than I first realized. As it were, the ICX 2022 compiler is actually bumping up against a different problem than ICC 19.2 (or ICX 2021.5) but oddly, the condition that triggers both defects is the same. I have hopefully produced a bit of sample code that will demonstrate both problems. I will endeavor not to confuse you.

 

The issue I posted initially (specifically the error, "the return type must directly designate a specialization of the associated class template") is a conformance defect in ICC 19.2 and ICX 2021.5. However, as you noted, this error is NOT present in ICX 2022. Yay, for that. It is worth noting (I just discovered this) that if the outer class is NOT templated, nested deduction guides appear to compile just fine in ICC 19.2 as well.

 

There is a separate CTAD issue present in ICX 2022 (and ICC 19.2) that is preventing the nested/inner type from deducing correctly from a single template argument when the outer class is also templated.

 

Here is a different (but similar) sample that demonstrates both problems:

 

https://godbolt.org/z/h7TWefa1h

 

You should observe that when OUTER_AS_VARIADIC_TEMPLATE=1, ICC 19.2 will fail with both errors and ICX 2022 will fail with the second one (but not the first). You can workaround the ICX failure by uncommenting the (unnecessary) single argument deduction guide.

 

When OUTER_AS_VARIADIC_TEMPLATE=0 both compilers should handle this code just fine. 

 

This code compiles correctly in MSVC 2017 and later as well as GCC 12.x (11.x does not) without issue regardless of whether or not the outer type is templated. Moreover, neither MSVC nor GCC require the single-argument deduction guide to deduce the inner type from a single argument as this deduction should be inherently non-ambiguous.

 

Thank you,

 

Jason

VarshaS_Intel
Moderator
718 Views

Hi,


We are working on your issue internally and will get back to you soon.


Thanks & Regards,

Varsha


Viet_H_Intel
Moderator
708 Views

_INTEL_LLVM_COMPILER does not appear to be defined when I build in DPC++ 2022.x. Is there another macro I should be looking at?

This is a known issue and will be fixed in the future update. To workaround you can add __INTEL_LLVM_COMPILER=202110 in your Visual Studio project property, Configuration Properties -> C/C++ -> Preprocessor -> Preprocessor Definitions


jase439
Beginner
674 Views
jase439
Beginner
595 Views

Any progress updates on this topic?

Viet_H_Intel
Moderator
589 Views

Sorry, this issue hasn't been fixed yet.


jase439
Beginner
322 Views

Just wondering if a fix is on the roadmap for the DPC++ compiler or if it is languishing in the "won't fix" bucket.

Viet_H_Intel
Moderator
302 Views

Yes, it's still on the road map. Developer has not yet closed the case.

This also is captured in LLVM community.  We'll wait for community to move on this issue 

Thanks,

 

Viet_H_Intel
Moderator
101 Views

Hi,

Since C++Compiler Classic (ICC) is deprecated and will be removed from product release in the second half of 2023, this issue won't be fixed in ICC.

For ICX, this issue is also captured in the LLVM community. Once, the issue is fixed there, then ICX will also be fixed.

Sorry for the inconvenience.

We are going to close this case.


Thanks,


Reply