[Patch][v5] OpenMP: Move omp requires checks to libgomp

Tobias Burnus tobias@codesourcery.com
Fri Jul 1 21:08:16 GMT 2022

Updated version attached – I hope I got everything right, but I start to
get tired, I am not 100% sure.

On 01.07.22 18:55, Jakub Jelinek wrote:
> Perhaps you're just lucky and the stack contains '\0' there?
> Maybe it would be better to simply use different error message for the
> 0 vs. non-0 case,
Done so.
>> For mkoffload, the single results are merged - and TARGET_USE is stripped,
>> such that it is either 0 or a combination of USM/UA/RO
> I'd find it clearer if we never stripped that, so that even the library knows.
I have done so – and I concur that the check works then better in
libgomp as well.
>>> Pedantically reading current standard probably yes, but perhaps again
>>> something to be discussed.  The question is what the requires directive
>>> in that case would do, nothing at all as there are no device constructs
>>> etc.?
>> Isn't there a device construct – which happens to be empty?
> In d.c there is.  But in c.c there isn't.
> So, the question is if the directive in c.c is just completely ignored
> (ok, aside from semantic checking) or if it should mean that if it is
> specified there, it must be specified elsewhere where device constructs etc.
> are used too.

Good question. The current code follows the wording of the spec and
ignores it. I think that's fine but still feels a bit odd.
>> Question: If it is not the same, should there just be a message to
>> stderr (gomp_error) or should libgomp abort (gomp_fatal)?
> I'd say gomp_fatal.
Done so - it makes life easier.

Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955
-------------- next part --------------
A non-text attachment was scrubbed...
Name: omp-requires-v6.1.diff
Type: text/x-patch
Size: 67132 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/gcc-patches/attachments/20220701/58d1333d/attachment-0001.bin>

More information about the Gcc-patches mailing list