[patch, c++ openmp] Improve diagnostics for unmappable types

Jason Merrill jason@redhat.com
Fri Jun 28 16:21:00 GMT 2019


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



More information about the Gcc-patches mailing list