[Bug c/96810] New: This is a case that gcc shoud not compile successfully, but gcc acts opposite.

[Bug c/96810] New: This is a case that gcc shoud not compile successfully, but gcc acts opposite.

[weiwt.fnst at cn dot fujitsu.com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96810

            Bug ID: 96810
           Summary: This is a case that gcc shoud not compile
                    successfully, but gcc acts opposite.
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: weiwt.fnst at cn dot fujitsu.com
  Target Milestone: ---

In the examples below, gcc has opposite behavior when complie:

These examples are from:
https://www.openmp.org/wp-content/uploads/openmp-examples-5-0-1.pdf

4.5 Array Sections in Device Constructs
Example array_sections.2.c

As the declaration before the example says "This example shows the invalid
usage of two separate sections of the same array inside of a target construct"
and the text annotation in the example says, gcc shoud not compile
successfully.

However, gcc acts opposite when compile, details are as below:

test case:
-------------------------------------------------
Example array_sections.2.c
void foo ()
{
    int A[30], *p;
    #pragma omp target data map( A[0:4] )
  {
    p = &A[0];
    /* invalid because p[3] and A[3] are the same
     * location on the host but the array section
     * specified via p[...] is not a subset of A[0:4] */
    #pragma omp target map( p[3:20] )
    {
    A[2] = 0;
    p[8] = 0;
    }
  }
}

test command:
-------------------------------------------------
#gcc -v
Target: x86_64-pc-linux-gnu
Configured with:./.../configure 
   --prefix=/.../ 
   --with-gmp=/.../gmp-6.1.0/ 
   --with-mpfr=/.../mpfr-3.1.4/ 
   --with-mpc=/.../mpc-1.0.3/ 
   --enable-multilib
Thread model: posix
gcc version 11.0.0 20200519 (experimental) (GCC)

#gcc -fopenmp -I/.../include Example array_sections.2.c

-------------------------------------------------

[Bug c/96810] This is a case that gcc shoud not compile successfully, but gcc acts opposite.

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96810

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org
         Resolution|---                         |INVALID
             Status|UNCONFIRMED                 |RESOLVED

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
The standard says this is unspecified behavior, but the unspecified behavior
happens at runtime, so if the compiler could detect it at compile time, it
would need to be at most a warning (if the code is never called, there is no
unspecified behavior).  Generally this isn't something that can be detected at
compile time, e.g. the target data can be in a different function from target,
or there could be target exit data that unmaps it in between and makes it
valid, or the fact that the pointer must alias the array could be not known to
the compiler, etc.
And the testcase is rejected at runtime:
libgomp: Trying to map into device [0x7ffc13463cbc..0x7ffc13463d0c) object when
[0x7ffc13463cb0..0x7ffc13463cc0) is already mapped

[Bug c/96810] This is a case that gcc shoud not compile successfully, but gcc acts opposite.

[weiwt.fnst at cn dot fujitsu.com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96810

--- Comment #2 from Wei Wentao <weiwt.fnst at cn dot fujitsu.com> ---
> --- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
> >The standard says this is unspecified behavior, but the unspecified behavior
> >happens at runtime, so if the compiler could detect it at compile time, it
> >would need to be at most a warning (if the code is never called, there is no
> >unspecified behavior).  Generally this isn't something that can be detected at
> >compile time, e.g. the target data can be in a different function from target,
> >or there could be target exit data that unmaps it in between and makes it
> >valid, or the fact that the pointer must alias the array could be not known to
> >the compiler, etc.
> >And the testcase is rejected at runtime:
> >libgomp: Trying to map into device [0x7ffc13463cbc..0x7ffc13463d0c) object when
> > [0x7ffc13463cb0..0x7ffc13463cc0) is already mapped 



When I use clang to compile the same case, the compilation fails which is in
line with expectations and is opposite to the result of gcc. The details show
as below:

clang version 11.0.0

clang /.../llvm/build/bin/clang -fopenmp-version=50 -fopenmp
-I/.../common.deb.ompt.optional/include/ Example array_sections.2.c
Example_array_sections.2.c:19:7: error: original storage of expression in data
environment is shared but data environment do not fully contain mapped
expression storage
      A[2] = 0;
      ^
Example_array_sections.2.c:11:30: note: used here
#pragma omp target data map( A[0:4] )
                             ^~~~~~
1 error generated.

[Bug c/96810] This is a case that gcc shoud not compile successfully, but gcc acts opposite.

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96810

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
   Last reconfirmed|                            |2020-08-28
         Resolution|INVALID                     |---
     Ever confirmed|0                           |1

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Actually sorry, the diagnostics clang emits is not about the bug mentioned in
the testcase, but about something different.
And while the bug described in the comment is really hard to diagnose at
compile time and in most cases impossible, what clang diagnoses is the fact
that
the target construct has implicit map(tofrom:A) clause and because the target
data maps only a small part of it, it mapping in target construct will fail.
Still, clang implements it incorrectly, it e.g. rejects:
int A[30];

void
foo (void)
{
  #pragma omp target data map (A[0:4])
  #pragma omp target
  A[2] = 0;
}

int
main ()
{
  #pragma omp target data map (A)
  foo ();
  return 0;
}

or

void bar (int *, int);

void
foo (void)
{
  int A[30];
  bar (A, 0);
  #pragma omp target data map (A[0:4])
  #pragma omp target
  A[2] = 0;
  bar (A, 1);
}

Both are completely valid and e.g. the latter could work just fine at runtime
if bar performs #pragma omp target enter data (arg1[:30]) for arg2 0 and exit
data for arg2 non-zero.
Perhaps a warning might be ok, but it still can have many false positives
(unless the compiler can prove that the array can't be mapped before the outer
target data).

[Bug c/96810] This is a case that gcc shoud not compile successfully, but gcc acts opposite.

[weiwt.fnst at cn dot fujitsu.com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96810

--- Comment #4 from Wei Wentao <weiwt.fnst at cn dot fujitsu.com> ---
>>--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
>>Actually sorry, the diagnostics clang emits is not about the bug mentioned in
>>the testcase, but about something different.
>>And while the bug described in the comment is really hard to diagnose at
>>compile time and in most cases impossible, what clang diagnoses is the fact
>>that
>>the target construct has implicit map(tofrom:A) clause and because the target
>>data maps only a small part of it, it mapping in target construct will fail.
>>Still, clang implements it incorrectly, it e.g. rejects:
>>int A[30];

>>void
>>foo (void)
>>{
>>  #pragma omp target data map (A[0:4])
>>  #pragma omp target
>>  A[2] = 0;
>>}

>>int
>>main ()
>>{
>>  #pragma omp target data map (A)
>>  foo ();
>>  return 0;
>>}

>>or

>>void bar (int *, int);

>>void
>>foo (void)
>>{
>>  int A[30];
>>  bar (A, 0);
>>  #pragma omp target data map (A[0:4])
>>  #pragma omp target
>>  A[2] = 0;
>>  bar (A, 1);
>>}

>>Both are completely valid and e.g. the latter could work just fine at runtime
>>if bar performs #pragma omp target enter data (arg1[:30]) for arg2 0 and exit
>>data for arg2 non-zero.
>>Perhaps a warning might be ok, but it still can have many false positives
>>(unless the compiler can prove that the array can't be mapped before the outer
>>target data).

[Bug c/96810] This is a case that gcc shoud not compile successfully, but gcc acts opposite.

[weiwt.fnst at cn dot fujitsu.com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96810

--- Comment #5 from Wei Wentao <weiwt.fnst at cn dot fujitsu.com> ---
Sorry for the last comment.I don't know how this happened.
Let's get to the point.

>>And while the bug described in the comment is really hard to diagnose at
>>compile time and in most cases impossible, what clang diagnoses is the fact
>>that
>>the target construct has implicit map(tofrom:A) clause and because the target
>>data maps only a small part of it, it mapping in target construct will fail.
>>Still, clang implements it incorrectly,

>>Both are completely valid and e.g. the latter could work just fine at runtime
>>if bar performs #pragma omp target enter data (arg1[:30]) for arg2 0 and exit
>>data for arg2 non-zero.

Thank you for your explanation. I agree with that. May I think that clang can
at least emit a diagnostic while gcc did nothing?
Since clang can find the problem in implicit the map, why can't it and gcc find
the problem in the explicit map?
Does it mean that there are some areas in gcc need to be improved? That is what
I am wondering about.