Re: Negative arguments in OpenMP 'num_threads' clause etc.

[Thomas Schwinge <thomas@codesourcery.com>]

[-- Attachment #1: Type: text/plain, Size: 1981 bytes --]

Hi Jakub!

On Wed, 29 May 2019 16:52:45 +0200, Jakub Jelinek <jakub@redhat.com> wrote:
> On Wed, May 29, 2019 at 04:42:14PM +0200, Thomas Schwinge wrote:
> > On Tue, 09 Apr 2019 17:51:46 +0200, I wrote:
> > > On Tue, 29 Nov 2016 17:47:08 -0800, Cesar Philippidis <cesar@codesourcery.com> wrote:
> > > > One notable difference between the trunk and gomp4 implementation of the
> > > > tile clause is that gomp4 errors on negative value tile arguments,
> > > > whereas trunk issues warnings.

> > > > Is there a reason why the fortran FE
> > > > generally emits a warning, on say num_threads(-5), instead of an error?
> > > 
> > > Same for the C/C++ front ends, which I'm looking into first.
> > > 
> > > Jakub, is the reason that even if the user is clearly doing something
> > > "strage" there, the compiler doesn't have a problem to continue
> > > compilation for 'num_threads(-5)', so it just emits a warning, but for
> > > example for 'collapse(-5)' is has to stop with an error, because it can't
> > > continue compilation in that case?  Or, is there a different reason for
> > > the many 'warning_at ([...], "[...] must be positive"' (C front end, for
> > > example), instead of using 'error_at' for these?
> 
> collapse has a constant expression argument and if the value is negative (or
> 0), then parsing doesn't make sense, so that case is clearly something where
> an error is in order.  num_threads is an example of where the standard is
> not completely clear if it is or is not ok to reject compilation as opposed
> to just UB at runtime if that happens and no problem if that construct is
> never encoutered at runtime.

Thanks, so that matches my understanding, and we shall thus retract the
OpenACC "update gfortran's tile clause error handling" patch, that got
posted several times in several variations.


Later, we shall audit all front end clauses handling to make sure that
this is done consistently.


Grüße
 Thomas

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 658 bytes --]