On 6/28/19 6:46 AM, Andrew Stubbs wrote:
This patch improves the diagnostics given for unmappable C++ types in
OpenMP programs.
Here is the output *without* the patch, for the new testcase:
----
unmappable-1.C: In function 'int main()':
unmappable-1.C:16:24: error: 'v' does not have a mappable type in 'map'
clause
16 | #pragma omp target map(v)
----
This is correct, but not very helpful for anything but the most trivial
C++ types. Anything involving inheritance, templates, typedefs, etc.
could be extremely difficult to track down.
With the patch applied we now get this (I removed the "dg-message"
comments for clarity):
----
unmappable-1.C: In function 'int main()':
unmappable-1.C:16:24: error: 'v' does not have a mappable type in 'map'
clause
16 | #pragma omp target map(v)
| ^
cc1plus: note: incomplete types are not mappable
unmappable-1.C:4:7: note: types with virtual members are not mappable
4 | class C
| ^
unmappable-1.C:7:14: note: static fields are not mappable
7 | static int static_member;
| ^~~~~~~~~~~~~
----
The compiler now reports all the problematic fields in the whole type,
recursively. If anybody knows how to report the location of incomplete
array declarations then that would be nice to add.
OK to commit?
+ inform ((decl ? DECL_SOURCE_LOCATION (decl) : UNKNOWN_LOCATION),
+ "incomplete types are not mappable");
It's better to use input_location as a fallback; essentially no
diagnostics should use UNKNOWN_LOCATION. And let's print the type with %qT.
+ if (notes)
+ result = false;
+ else
+ return false;
Returning early when !notes doesn't seem worth the extra lines of code.
Jason
