On Tue, Jun 28, 2022 at 04:06:14PM +0200, Jakub Jelinek via Gcc-patches wrote:
> On Thu, Jun 23, 2022 at 11:47:59PM +0800, Chung-Lin Tang wrote:
> > with the way that chunk_size < 1 is handled for gomp_iter_dynamic_next:
> >
> > (1) chunk_size <= -1: wraps into large unsigned value, seems to work though.
> > (2) chunk_size == 0: infinite loop
> >
> > The (2) behavior is obviously not desired. This patch fixes this by changing
>
> Why? It is a user error, undefined behavior, we shouldn't slow down valid
> code for users who don't bother reading the standard.
>
> E.g. OpenMP 5.1 [132:14] says clearly:
> "chunk_size must be a loop invariant integer expression with a positive
> value."
> and omp_set_schedule for chunk_size < 1 should use a default value (which it
> does).
>
> For OMP_SCHEDULE the standard says it is implementation-defined what happens
> if the format isn't the specified one, so I guess the env.c change
> could be acceptable (though without it it is fine too), but the
Though, seems we quietly transform the only problematic value (0) in there
to 1 for selected schedules which don't accept 0 as "unspecified" and for
the negative values, we'll have large ulong chunk sizes which is fine.
If we really want help people debugging their programs, we could introduce
something like -fsanitize=openmp that would add runtime instrumentation of a
lot of OpenMP restrictions and could diagnose it with nice diagnostics,
perhaps using some extra library and with runtime checks in generated code.
Jakub
