Re: [committed] openmp: Add support for OpenMP 5.1 atomics for C++

2021-10-02 Thread H.J. Lu via Gcc-patches 
On Fri, Sep 17, 2021 at 2:34 AM Jakub Jelinek via Gcc-patches
 wrote:
>
> Hi!
>
> Besides the C++ FE changes, I've noticed that the C FE didn't reject
>   #pragma omp atomic capture compare
>   { v = x; x = y; }
> and other forms of atomic swap, this patch fixes that too.  And the
> c-family/ routine needed quite a few changes so that the new code
> in it works fine with both FEs.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk.
>
> 2021-09-17  Jakub Jelinek  
>
> gcc/c-family/
> * c-omp.c (c_finish_omp_atomic): Avoid creating
> TARGET_EXPR if test is true, use create_tmp_var_raw instead of
> create_tmp_var and add a zero initializer to TARGET_EXPRs that
> had NULL initializer.  When omitting operands after v = x,
> use type of v rather than type of x.  Fix type of vtmp
> TARGET_EXPR.
> gcc/c/
> * c-parser.c (c_parser_omp_atomic): Reject atomic swap if capture
> is true.
> gcc/cp/
> * cp-tree.h (finish_omp_atomic): Add r and weak arguments.
> * parser.c (cp_parser_omp_atomic): Update function comment for
> OpenMP 5.1 atomics, parse OpenMP 5.1 atomics and fail, compare and
> weak clauses.
> * semantics.c (finish_omp_atomic): Add r and weak arguments, handle
> them, handle COND_EXPRs.
> * pt.c (tsubst_expr): Adjust for COND_EXPR forms that
> finish_omp_atomic can now produce.
> gcc/testsuite/
> * c-c++-common/gomp/atomic-18.c: Expect same diagnostics in C++ as in
> C.
> * c-c++-common/gomp/atomic-25.c: Drop c effective target.
> * c-c++-common/gomp/atomic-26.c: Likewise.
> * c-c++-common/gomp/atomic-27.c: Likewise.
> * c-c++-common/gomp/atomic-28.c: Likewise.
> * c-c++-common/gomp/atomic-29.c: Likewise.
> * c-c++-common/gomp/atomic-30.c: Likewise.  Adjust expected 
> diagnostics
> for C++ when it differs from C.
> (foo): Change return type from double to void.
> * g++.dg/gomp/atomic-5.C: Adjust expected diagnostics wording.
> * g++.dg/gomp/atomic-20.C: New test.
> libgomp/
> * testsuite/libgomp.c-c++-common/atomic-19.c: Drop c effective target.
> Use /* */ comments instead of //.
> * testsuite/libgomp.c-c++-common/atomic-20.c: Likewise.
> * testsuite/libgomp.c-c++-common/atomic-21.c: Likewise.

This test fails on i686 and x86-64 with -m32 -mfpmath=sse:

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

> * testsuite/libgomp.c++/atomic-16.C: New test.
> * testsuite/libgomp.c++/atomic-17.C: New test.
>

H.J.

Re: [Patch] Fortran: Avoid var initialization in interfaces [PR54753]

2021-10-02 Thread Sandra Loosemore 

On 10/2/21 2:28 PM, Harald Anlauf wrote:

Hi Tobias,

the corrected attached patch fixes the regression for testcase
default_initialization_3.f90 for me now, and as a bonus matches
the description.


Me too!  I'm also seeing clean test results now.

-Sandra

Re: [PATCH] Handle EQ_EXPR relation for operator_lshift.

2021-10-02 Thread Jeff Law via Gcc-patches 




On 10/2/2021 1:50 PM, Aldy Hernandez via Gcc-patches wrote:

Bah.  The range was being clobbered half way through the calculation.

Tested on x86-64 Linux.

Pushed.

On Fri, Oct 1, 2021 at 4:52 PM Aldy Hernandez  wrote:

Well, after talking with Andrew it seems that X << Y being non-zero
also implies X is non-zero.  So we don't even need relationals here.

So, I leave gori relationals in his capable hands, while I test this
much simpler patch which fixes the PR with no additional
infrastructure ;-).

Will push pending tests.
Aldy

On Fri, Oct 1, 2021 at 2:43 PM Aldy Hernandez  wrote:

Knowing that X << X is non-zero means X is also non-zero.  This patch
teaches this this to range-ops.

As usual, the big twiddling experts could come up with all sorts of
fancy enhancements in this area, and we welcome all patches :).

I will push this pending tests.

gcc/ChangeLog:

 PR tree-optimization/102546
 * range-op.cc (operator_lshift::op1_range): Handle EQ_EXPR
 relation.
I'm going to assume this also fixes a similar ICE building the linux 
kernel.  One less thing to bisect today :-)


jeff

[committed] libstdc++: Fix typos in std::filesystem code

2021-10-02 Thread Jonathan Wakely via Gcc-patches 
There were a couple of typos in r12-4070 and r12-4071 which don't show
up when building for POSIX targets.

libstdc++-v3/ChangeLog:

* src/c++17/fs_ops.cc (create_directory): Fix typo in enum name.
* src/filesystem/ops-common.h (__last_system_error): Add
explicit cast to avoid narrowing conversion.
(do_space): Fix type in function name.

Tested x86_64-linux. Committed to trunk.

commit b7848a2068b2579092e0b1bbe02bdb743eb7db26
Author: Jonathan Wakely 
Date:   Sat Oct 2 21:18:19 2021

libstdc++: Fix typos in std::filesystem code

There were a couple of typos in r12-4070 and r12-4071 which don't show
up when building for POSIX targets.

libstdc++-v3/ChangeLog:

* src/c++17/fs_ops.cc (create_directory): Fix typo in enum name.
* src/filesystem/ops-common.h (__last_system_error): Add
explicit cast to avoid narrowing conversion.
(do_space): Fix type in function name.

diff --git a/libstdc++-v3/src/c++17/fs_ops.cc b/libstdc++-v3/src/c++17/fs_ops.cc
index cb2dc2c617e..5b7f7edd1c9 100644
--- a/libstdc++-v3/src/c++17/fs_ops.cc
+++ b/libstdc++-v3/src/c++17/fs_ops.cc
@@ -631,7 +631,7 @@ fs::create_directory(const path& p, const path& attributes,
 }
   return create_dir(p, static_cast(st.st_mode), ec);
 #else
-  ec = std::make_error_code(std::errc::function_function_not_supported);
+  ec = std::make_error_code(std::errc::function_not_supported);
   return false;
 #endif
 }
diff --git a/libstdc++-v3/src/filesystem/ops-common.h 
b/libstdc++-v3/src/filesystem/ops-common.h
index 90ebeba7f01..b3147639cd9 100644
--- a/libstdc++-v3/src/filesystem/ops-common.h
+++ b/libstdc++-v3/src/filesystem/ops-common.h
@@ -63,7 +63,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   __last_system_error() noexcept
   {
 #ifdef _GLIBCXX_FILESYSTEM_IS_WINDOWS
-return {::GetLastError(), std::system_category()};
+return {(int)::GetLastError(), std::system_category()};
 #else
 return {errno, std::generic_category()};
 #endif
@@ -597,7 +597,7 @@ _GLIBCXX_BEGIN_NAMESPACE_FILESYSTEM
ec.clear();
   }
 else
-  ec = std::last_system_error();
+  ec = std::__last_system_error();
 #else
 ec = std::make_error_code(std::errc::function_not_supported);
 #endif

Re: [Patch] Fortran: Avoid var initialization in interfaces [PR54753]

2021-10-02 Thread Harald Anlauf via Gcc-patches 

Hi Tobias,

the corrected attached patch fixes the regression for testcase
default_initialization_3.f90 for me now, and as a bonus matches
the description.

Am 02.10.21 um 21:56 schrieb Tobias Burnus:

Hi Harald,

unfortunately, your email did not arrive at fort...@gcc.gnu.org – nor at
my private address.

I copied it from
https://gcc.gnu.org/pipermail/gcc-patches/2021-October/580794.html

You wrote:

>/I do not see this error. Can you double check that you indeed use
the />/posted patch:
/>//>/https://gcc.gnu.org/pipermail/gcc-patches/2021-September/580483.html

– />/and nothing else, e.g., an earlier draft? /
Sandra is right.  Actually I do see that regression, too.
The default initialization is missing in F1, see dump-tree:

Look as if I had attached the first/interim version of the patch –
which lacked what I wrote in the patch submission at:
https://gcc.gnu.org/pipermail/gcc-patches/2021-September/580483.html

Namely, I wrote:

Regarding the patch, '!= IFSRC_IFBODY' has to be used; "== IFSRC_DECL"
won't work as the the generatedy ENTRY master function has IFSRC_UNKNOWN.

Thus, no surprise that it passes here – while you see the fail.

Tobias



Harald

[I had trouble posting via gmane lately, and I haven't found out
yet what is causing it.]

Re: [committed] libstdc++: Specialize std::pointer_traits<__normal_iterator>

2021-10-02 Thread Jonathan Wakely via Gcc-patches 
On Sat, 2 Oct 2021 at 14:08, François Dumont  wrote:
>
> On 02/10/21 12:29 am, Jonathan Wakely wrote:
> > On Thu, 30 Sept 2021 at 21:27, François Dumont via Libstdc++
> >  wrote:
> >> Here is the _Safe_iterator one.
> >>
> >> Doing so I noticed that pointer_traits rebind for __normal_iterator was
> >> wrong and added tests on it.
> > Oops, thanks!
> >
> >> For _Safe_iterator maybe I should specialize only when instantiated with
> >> __normal_iterator ? Or maybe limit to random_access_iterator_tag ?
> > Yes, I think that's a good idea, maybe only for __normal_iterator > C>. I think that should cover all the cases we actually need to
> > support.
> >
> > And could you change the existing pointer_traits<__normal_iterator > C>> partial specialization to only be valid for
> > __normal_iterator as well? i.e. only for __normal_iterator that
> > wraps a pointer (which is true for string::iterator, vector::iterator
> > etc.)
>
> Is the attached patch what you had in mind ?

Yes, although I don't think we need to us __make_not_void for
to_pointer, because I don't think we would ever have
__normal_iterator. I don't think it will even compile,
because void* is not an iterator type, and iterator_traits is
invalid (in C++20 it's constrained with is_object_v and before
C++20 it will just give an error, because void& is ill-formed).

Re: [committed] libstdc++: Specialize std::pointer_traits<__normal_iterator>

2021-10-02 Thread Jonathan Wakely via Gcc-patches 
On Sat, 2 Oct 2021 at 18:27, François Dumont wrote:
>
> I would like to propose this alternative approach.
>
> In this patch I make __normal_iterator and random iterator
> _Safe_iterator compatible for pointer_traits primary template.
>
> Regarding pointer_traits I wonder if it shouldn't check for the
> to_pointer method availability and use per default: return {
> std::addressof(__e) }; otherwise. This way we wouldn't have to provide a
> pointer_to method on __normal_iterator.

But I would rather not have these members present in vector::iterator
and string::iterator, in case users accidentally start to rely on them
being present.

Another option would be to overload std::__to_address so it knows how
to get the address from __normal_iterator and _Safe_iterator.

Re: [Patch] Fortran: Avoid var initialization in interfaces [PR54753]

2021-10-02 Thread Tobias Burnus 

Hi Harald,

unfortunately, your email did not arrive at fort...@gcc.gnu.org – nor at my 
private address.

I copied it from 
https://gcc.gnu.org/pipermail/gcc-patches/2021-October/580794.html

You wrote:
>/I do not see this error. Can you double check that you indeed use the />/posted patch: />//>/https://gcc.gnu.org/pipermail/gcc-patches/2021-September/580483.html 
 – />/and nothing else, e.g., an earlier draft? /

Sandra is right.  Actually I do see that regression, too.
The default initialization is missing in F1, see dump-tree:

Look as if I had attached the first/interim version of the patch –
which lacked what I wrote in the patch submission at:
https://gcc.gnu.org/pipermail/gcc-patches/2021-September/580483.html

Namely, I wrote:

Regarding the patch, '!= IFSRC_IFBODY' has to be used; "== IFSRC_DECL"
won't work as the the generatedy ENTRY master function has IFSRC_UNKNOWN.

Thus, no surprise that it passes here – while you see the fail.

Tobias

Fortran: Avoid var initialization in interfaces [PR54753]

Intent(out) implies deallocation/default initialization; however, it is
pointless to do this for dummy-arguments symbols of procedures which are
inside an INTERFACE block. – This also fixes a bogus error for the attached
included testcase, but fixing the non-interface version still has to be done.

	PR fortran/54753

gcc/fortran/ChangeLog:

	* resolve.c (can_generate_init, resolve_fl_variable_derived,
	resolve_symbol): Only do initialization with intent(out) if not
	inside of an interface block.

gcc/testsuite/ChangeLog:

	* gfortran.dg/assumed_rank_23.f90: New test.

 gcc/fortran/resolve.c | 11 ---
 gcc/testsuite/gfortran.dg/assumed_rank_23.f90 | 16 
 2 files changed, 24 insertions(+), 3 deletions(-)

diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
index 30b96b2f597..511fe3a5e55 100644
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -12676,7 +12676,8 @@ can_generate_init (gfc_symbol *sym)
 || a->cray_pointer
 || sym->assoc
 || (!a->referenced && !a->result)
-|| (a->dummy && a->intent != INTENT_OUT)
+|| (a->dummy && (a->intent != INTENT_OUT
+		 || sym->ns->proc_name->attr.if_source == IFSRC_IFBODY))
 || (a->function && sym != sym->result)
   );
 }
@@ -12913,7 +12914,9 @@ resolve_fl_variable_derived (gfc_symbol *sym, int no_init_flag)
 
   /* Assign default initializer.  */
   if (!(sym->value || sym->attr.pointer || sym->attr.allocatable)
-  && (!no_init_flag || sym->attr.intent == INTENT_OUT))
+  && (!no_init_flag
+	  || (sym->attr.intent == INTENT_OUT
+	  && sym->ns->proc_name->attr.if_source != IFSRC_IFBODY)))
 sym->value = gfc_generate_initializer (>ts, can_generate_init (sym));
 
   return true;
@@ -16154,7 +16157,8 @@ resolve_symbol (gfc_symbol *sym)
 		|| sym->ts.u.derived->attr.alloc_comp
 		|| sym->ts.u.derived->attr.pointer_comp))
 	   && !(a->function && sym != sym->result))
-	  || (a->dummy && a->intent == INTENT_OUT && !a->pointer))
+	  || (a->dummy && !a->pointer && a->intent == INTENT_OUT
+	  && sym->ns->proc_name->attr.if_source != IFSRC_IFBODY))
 	apply_default_init (sym);
   else if (a->function && sym->result && a->access != ACCESS_PRIVATE
 	   && (sym->ts.u.derived->attr.alloc_comp
@@ -16166,6 +16170,7 @@ resolve_symbol (gfc_symbol *sym)
 
   if (sym->ts.type == BT_CLASS && sym->ns == gfc_current_ns
   && sym->attr.dummy && sym->attr.intent == INTENT_OUT
+  && sym->ns->proc_name->attr.if_source != IFSRC_IFBODY
   && !CLASS_DATA (sym)->attr.class_pointer
   && !CLASS_DATA (sym)->attr.allocatable)
 apply_default_init (sym);
diff --git a/gcc/testsuite/gfortran.dg/assumed_rank_23.f90 b/gcc/testsuite/gfortran.dg/assumed_rank_23.f90
new file mode 100644
index 000..c83aa7de1a3
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/assumed_rank_23.f90
@@ -0,0 +1,16 @@
+! { dg-do compile }
+!
+! PR fortran/54753
+! TS29113:C535c
+! F2018:C839
+!
+module m
+
+  interface
+subroutine s1 (x, y)
+  class(*) :: x(..)
+  class(*), intent (out) :: y(..)
+end subroutine
+  end interface
+
+end module

Re: [PATCH] Handle EQ_EXPR relation for operator_lshift.

2021-10-02 Thread Aldy Hernandez via Gcc-patches 
Bah.  The range was being clobbered half way through the calculation.

Tested on x86-64 Linux.

Pushed.

On Fri, Oct 1, 2021 at 4:52 PM Aldy Hernandez  wrote:
>
> Well, after talking with Andrew it seems that X << Y being non-zero
> also implies X is non-zero.  So we don't even need relationals here.
>
> So, I leave gori relationals in his capable hands, while I test this
> much simpler patch which fixes the PR with no additional
> infrastructure ;-).
>
> Will push pending tests.
> Aldy
>
> On Fri, Oct 1, 2021 at 2:43 PM Aldy Hernandez  wrote:
> >
> > Knowing that X << X is non-zero means X is also non-zero.  This patch
> > teaches this this to range-ops.
> >
> > As usual, the big twiddling experts could come up with all sorts of
> > fancy enhancements in this area, and we welcome all patches :).
> >
> > I will push this pending tests.
> >
> > gcc/ChangeLog:
> >
> > PR tree-optimization/102546
> > * range-op.cc (operator_lshift::op1_range): Handle EQ_EXPR
> > relation.
> > ---
> >  gcc/range-op.cc  | 19 ---
> >  gcc/testsuite/gcc.dg/tree-ssa/pr102546.c | 23 +++
> >  2 files changed, 39 insertions(+), 3 deletions(-)
> >  create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/pr102546.c
> >
> > diff --git a/gcc/range-op.cc b/gcc/range-op.cc
> > index 5e37133026d..53f3be4266e 100644
> > --- a/gcc/range-op.cc
> > +++ b/gcc/range-op.cc
> > @@ -2075,9 +2075,14 @@ operator_lshift::op1_range (irange ,
> > tree type,
> > const irange ,
> > const irange ,
> > -   relation_kind rel ATTRIBUTE_UNUSED) const
> > +   relation_kind rel) const
> >  {
> >tree shift_amount;
> > +  int_range<2> adjust (type);
> > +
> > +  if (rel == EQ_EXPR && !lhs.contains_p (build_zero_cst (type)))
> > +adjust.set_nonzero (type);
> > +
> >if (op2.singleton_p (_amount))
> >  {
> >wide_int shift = wi::to_wide (shift_amount);
> > @@ -2086,10 +2091,11 @@ operator_lshift::op1_range (irange ,
> >if (wi::ge_p (shift, wi::uhwi (TYPE_PRECISION (type),
> >  TYPE_PRECISION (op2.type ())),
> > UNSIGNED))
> > -   return false;
> > +   goto done;
> >if (shift == 0)
> > {
> >   r = lhs;
> > + r.intersect (adjust);
> >   return true;
> > }
> >
> > @@ -2126,9 +2132,16 @@ operator_lshift::op1_range (irange ,
> >
> >if (utype != type)
> > range_cast (r, type);
> > +  r.intersect (adjust);
> >return true;
> >  }
> > -  return false;
> > +
> > + done:
> > +  if (adjust.varying_p ())
> > +return false;
> > +
> > +  r = adjust;
> > +  return true;
> >  }
> >
> >  bool
> > diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr102546.c 
> > b/gcc/testsuite/gcc.dg/tree-ssa/pr102546.c
> > new file mode 100644
> > index 000..4bd98747732
> > --- /dev/null
> > +++ b/gcc/testsuite/gcc.dg/tree-ssa/pr102546.c
> > @@ -0,0 +1,23 @@
> > +// { dg-do compile }
> > +// { dg-options "-O3 -fdump-tree-optimized" }
> > +
> > +static int a;
> > +static char b, c, d;
> > +void bar(void);
> > +void foo(void);
> > +
> > +int main() {
> > +int f = 0;
> > +for (; f <= 5; f++) {
> > +bar();
> > +b = b && f;
> > +d = f << f;
> > +if (!(a >= d || f))
> > +foo();
> > +c = 1;
> > +for (; c; c = 0)
> > +;
> > +}
> > +}
> > +
> > +// { dg-final { scan-tree-dump-not "foo" "optimized" } }
> > --
> > 2.31.1
> >
From 72739a6fde0020b98cdabad7218c6d4f5ce36bce Mon Sep 17 00:00:00 2001
From: Aldy Hernandez 
Date: Sat, 2 Oct 2021 16:59:26 +0200
Subject: [PATCH] [PR102563] Do not clobber range in
 operator_lshift::op1_range.

We're clobbering the final range before we're done calculating it.

Tested on x86-64 Linux.

gcc/ChangeLog:

	* range-op.cc (operator_lshift::op1_range): Do not clobber
	range.

gcc/testsuite/ChangeLog:

	* gcc.dg/tree-ssa/pr102563.c: New test.
---
 gcc/range-op.cc  | 12 ++--
 gcc/testsuite/gcc.dg/tree-ssa/pr102563.c | 16 
 2 files changed, 22 insertions(+), 6 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/pr102563.c

diff --git a/gcc/range-op.cc b/gcc/range-op.cc
index 2baca4a197f..bbf2924f815 100644
--- a/gcc/range-op.cc
+++ b/gcc/range-op.cc
@@ -2112,8 +2112,6 @@ operator_lshift::op1_range (irange ,
   else
 	op_rshift.fold_range (tmp_range, utype, lhs, op2);
 
-  r.intersect (tmp_range);
-
   // Start with ranges which can produce the LHS by right shifting the
   // result by the shift amount.
   // ie   [0x08, 0xF0] = op1 << 2 will start with
@@ -2128,13 +2126,15 @@ operator_lshift::op1_range (irange ,
   unsigned low_bits = TYPE_PRECISION (utype)
 			  - TREE_INT_CST_LOW (shift_amount);
   wide_int up_mask = wi::mask

Re: [Patch] Fortran: Avoid var initialization in interfaces [PR54753]

2021-10-02 Thread Harald Anlauf via Gcc-patches 

Hi Tobias,

Am 02.10.21 um 20:29 schrieb Tobias Burnus:

On 02.10.21 20:01, Sandra Loosemore wrote:

On 9/29/21 2:53 AM, Tobias Burnus wrote:

There are three issues, this patch solves the first:
* reject-valid issue due to adding the initializer also to a dummy
   argument which is in an INTERFACE block. Having initializers in
   INTERFACE blocks is pointless and causes for the attached testcase

   the bogus error:

   "Assumed-rank variable y at (1) may only be used as actual argument"
...
This has indeed allowed me to make progress on adding the diagnostic, 
but I'm seeing some test regressions on x86_64-linux-gnu that are due 
to this patch alone:


FAIL: gfortran.dg/default_initialization_3.f90   -O0  execution test


I do not see this error. Can you double check that you indeed use the 
posted patch:


https://gcc.gnu.org/pipermail/gcc-patches/2021-September/580483.html – 
and nothing else, e.g., an earlier draft?


Sandra is right.  Actually I do see that regression, too.
The default initialization is missing in F1, see dump-tree:

__attribute__((fn spec (". R w w ")))
integer(kind=4) master.0.f1 (integer(kind=8) __entry, struct t1 * d2, 
struct t1 * d1)

{
  integer(kind=4) res;
  integer(kind=4) __result_master.0.f1;
  integer(kind=4) res.0 [value-expr: __result_master.0.f1];

  if (d1 != 0B)
{
  {
struct t1 t1.1;

t1.1.i = 7;
*d1 = t1.1;
  }
}

The latter "if (d1 != 0B)" block gets removed by your change, and
this is not good.

(I still have to commit it; it was approved by Harald, but he also he 
preferred to have a second view, I decided to wait until tomorrow/Monday 
before committing it.)


Well, I did not regtest, only read the patch and trust that you did your
homework!


Tobias


Harald

Re: [PATCH v3] Fix ICE when mixing VLAs and statement expressions [PR91038]

2021-10-02 Thread Uecker, Martin 
Am Donnerstag, den 23.09.2021, 17:37 -0400 schrieb Jason Merrill:
> On 9/23/21 15:49, Uecker, Martin wrote:
> > Am Mittwoch, den 22.09.2021, 17:18 -0400 schrieb Jason Merrill:
> > > On 9/5/21 15:14, Uecker, Martin wrote:
> > > > Here is the third version of the patch. This also
> > > > fixes the index zero case.  Thus, this should be
> > > > a complete fix for 91038 and should fix all cases
> > > > also supported by clang.  Still not working is
> > > > returning a struct of variable size from a
> > > > statement expression (29970) when the size depends
> > > > on computations inside the statement expression.
> > > > 
> > > > Bootstrapped and regression tested
> > > > on x86-64 for all languages.
> > > > 
> > > > Martin
> > > > 
> > > > 
> > > > 
> > > > 
> > > > Fix ICE when mixing VLAs and statement expressions [PR91038]
> > > > 
> > > > When returning VM-types from statement expressions, this can
> > > > lead to an ICE when declarations from the statement expression
> > > > are referred to later. Most of these issues can be addressed by
> > > > gimplifying the base expression earlier in gimplify_compound_lval.
> > > > Another issue is fixed by not reording some size-related expressions
> > > > during folding. This fixes PR91038 and some of the test cases
> > > > from PR29970 (structs with VLA members need further work).
> > > > 
> > > >   
> > > >   2021-08-01  Martin Uecker  
> > > >   
> > > >   gcc/
> > > > PR c/91038
> > > > PR c/29970
> > > > * gimplify.c (gimplify_var_or_parm_decl): Update comment.
> > > > (gimplify_compound_lval): Gimplify base expression first.
> > > > (gimplify_target_expr): Do not gimplify size expression.
> > > > * fold-const.c (fold_binary_loc): Do not reorder SAVE_EXPR
> > > > in pointer arithmetic for variably modified types.
> > > >   
> > > >   gcc/testsuite/
> > > > PR c/91038
> > > > PR c/29970
> > > > * gcc.dg/vla-stexp-3.c: New test.
> > > > * gcc.dg/vla-stexp-4.c: New test.
> > > > * gcc.dg/vla-stexp-5.c: New test.
> > > > * gcc.dg/vla-stexp-6.c: New test.
> > > > * gcc.dg/vla-stexp-7.c: New test.
> > > > * gcc.dg/vla-stexp-8.c: New test.
> > > > * gcc.dg/vla-stexp-9.c: New test.
> > > > 
> > > > 
> > > > diff --git a/gcc/fold-const.c b/gcc/fold-const.c
> > > > index ff23f12f33c..1e6f50692b5 100644
> > > > --- a/gcc/fold-const.c
> > > > +++ b/gcc/fold-const.c
> > > > @@ -10854,7 +10854,15 @@ fold_binary_loc (location_t loc, enum 
> > > > tree_code code, tree type,
> > > >   return build2_loc (loc, COMPOUND_EXPR, type, TREE_OPERAND 
> > > > (arg0, 0),
> > > >  tem);
> > > > }
> > > > -  if (TREE_CODE (arg1) == COMPOUND_EXPR)
> > > > +  /* This interleaves execution of the two sub-expressions
> > > > +which is allowed in C.  For pointer arithmetic when the
> > > > +the pointer has a variably modified type, the right expression
> > > > +might have a SAVE_EXPR which depends on the left expr, so
> > > > +do not fold in this case.  */
> > > > +  if (TREE_CODE (arg1) == COMPOUND_EXPR
> > > > + && !(code == POINTER_PLUS_EXPR
> > > > +  && TREE_CODE (TREE_OPERAND (arg1, 0)) == SAVE_EXPR)
> > > > +  && variably_modified_type_p (type, NULL_TREE))
> > > 
> > > This seems pretty fragile.  If the problem is that the SAVE_EXPR depends
> > > on a statement-expr on the LHS, can't that happen with expressions other
> > > than POINTER_PLUS_EXPR?
> > 
> > I intentionally limited the change to this specific
> > case to avoid accidentally breaking or pessimizing
> > anything else. I did not notice any other cases that
> > need fixing. It is of course possible that
> > I have missed some...
> > 
> > > Maybe we should include the statement-expr in the SAVE_EXPR?
> > 
> > I am not really sure how to implement this.
> 
> Nor am I, I'm not at all familiar with the VLA handling code.  But if 
> the generated trees rely on evaluation happening with a stricter order 
> than is actually guaranteed, that seems like a bug in the generation of 
> the expression trees, not the folding code.

Is there a definition about what is guaranteed?

It seems to be based on the somewhat scary
C semantics where in

(a, b) op (c, d)

evaluation order could be

a, c, b, d.

If I remember correctly

({ int N; int x[N];  })[0]

becomes

TARGET_EXPR  + (SAVE_EXPR  * 0)

which (somehow involving the rule above) becomes

SAVE_EXPR ; TARGET_EXPR  Could someone that knows more about VLA weigh in?

> > Maybe we could apply this patch first (because
> > I have to work around this bug in a couple of
> > projects which is a bit annoying)? I am happy
> > to implement an alternative later if there is
> > a better way (which I can understand).
> 
> The gimplify_compound_lval change is OK now.
> 
> What's the rationale for the gimplify_target_expr change?

It

Re: [Patch] Fortran: Avoid var initialization in interfaces [PR54753]

2021-10-02 Thread Tobias Burnus 

On 02.10.21 20:01, Sandra Loosemore wrote:

On 9/29/21 2:53 AM, Tobias Burnus wrote:

There are three issues, this patch solves the first:
* reject-valid issue due to adding the initializer also to a dummy
   argument which is in an INTERFACE block. Having initializers in
   INTERFACE blocks is pointless and causes for the attached testcase
   the bogus error:
   "Assumed-rank variable y at (1) may only be used as actual argument"
...
This has indeed allowed me to make progress on adding the diagnostic, 
but I'm seeing some test regressions on x86_64-linux-gnu that are due 
to this patch alone:


FAIL: gfortran.dg/default_initialization_3.f90   -O0  execution test


I do not see this error. Can you double check that you indeed use the 
posted patch:


https://gcc.gnu.org/pipermail/gcc-patches/2021-September/580483.html – 
and nothing else, e.g., an earlier draft?


(I still have to commit it; it was approved by Harald, but he also he 
preferred to have a second view, I decided to wait until tomorrow/Monday 
before committing it.)


Tobias

Re: [Patch] Fortran: Avoid var initialization in interfaces [PR54753]

2021-10-02 Thread Sandra Loosemore 

On 9/29/21 2:53 AM, Tobias Burnus wrote:

Found when looking at F2018:C839 / PR54753.

For INTENT(OUT) the dummy variable (might) also be default initialized
or deallocated. However, with assumed rank, that causes issues, which
C839 prevents. In the current GCC implementation, missing C839 constraint
diagnostic, but also rejects-valid/ice-on-valid appears.

There are three issues, this patch solves the first:

* reject-valid issue due to adding the initializer also to a dummy
   argument which is in an INTERFACE block. Having initializers in
   INTERFACE blocks is pointless and causes for the attached testcase
   the bogus error:
   "Assumed-rank variable y at (1) may only be used as actual argument"

(Except for wasting resources and this error, they should be ignored
in trans*.c and usually do not cause any further harm.)


I think Sandra has a nearly ready patch to do the C839 constraint
diagnostic, which needs the attached patch to do the checks.

The third issue is that GCC currently gives either an ICE or the
above error message when declaring a procedure with a valid
assumed-rank intent(out) dummy. This has still to be solved as well.
But first I wanted to unblock Sandra's C839 work with this patch :-)


This has indeed allowed me to make progress on adding the diagnostic, 
but I'm seeing some test regressions on x86_64-linux-gnu that are due to 
this patch alone:


FAIL: gfortran.dg/default_initialization_3.f90   -O0  execution test
FAIL: gfortran.dg/default_initialization_3.f90   -O1  execution test
FAIL: gfortran.dg/default_initialization_3.f90   -O2  execution test
FAIL: gfortran.dg/default_initialization_3.f90   -O3 
-fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer 
-finline-functions  execution test

FAIL: gfortran.dg/default_initialization_3.f90   -O3 -g  execution test
FAIL: gfortran.dg/default_initialization_3.f90   -Os  execution test

It is failing with STOP 5, so I guess it is over-eagerly removing 
initialization in something that is not an interface.


BTW, I think it would be better to open a new issue for this and the 
"third issue" you describe for this than to tag them with PR54753, since 
these initialization bugs aren't really related to the missing 
diagnostic in that issue except so far as the bogus error/crashes make 
it impossible to test for the missing diagnostic.  Personally, I find it 
really confusing to track which bugs have really been fixed when 
multiple bugs that need different fixes are lumped together in the same 
issue...  there might be patches committed for such a mashed-up issue, 
but which parts have been fixed and which not, and when is it safe to 
close the issue?  :-S


-Sandra

Re: [committed] libstdc++: Specialize std::pointer_traits<__normal_iterator>

2021-10-02 Thread François Dumont via Gcc-patches 

I would like to propose this alternative approach.

In this patch I make __normal_iterator and random iterator 
_Safe_iterator compatible for pointer_traits primary template.


Regarding pointer_traits I wonder if it shouldn't check for the 
to_pointer method availability and use per default: return { 
std::addressof(__e) }; otherwise. This way we wouldn't have to provide a 
pointer_to method on __normal_iterator.


François

On 02/10/21 12:29 am, Jonathan Wakely wrote:

On Thu, 30 Sept 2021 at 21:27, François Dumont via Libstdc++
 wrote:

Here is the _Safe_iterator one.

Doing so I noticed that pointer_traits rebind for __normal_iterator was
wrong and added tests on it.

Oops, thanks!


For _Safe_iterator maybe I should specialize only when instantiated with
__normal_iterator ? Or maybe limit to random_access_iterator_tag ?

Yes, I think that's a good idea, maybe only for __normal_iterator. I think that should cover all the cases we actually need to
support.

And could you change the existing pointer_traits<__normal_iterator> partial specialization to only be valid for
__normal_iterator as well? i.e. only for __normal_iterator that
wraps a pointer (which is true for string::iterator, vector::iterator
etc.)


Whatever the pointer_to implementation is problematic, we can only
produce singular iterator as I did ifor now.

Hmm, yes. I think that's OK, because I don't think anybody is actually
going to use that function. What matters is that it works with
std::__to_address for C++17 mode, and that doesn't depend on
pointer_to, so it's OK if it doesn't work usefully.

Thanks!



diff --git a/libstdc++-v3/include/bits/stl_iterator.h 
b/libstdc++-v3/include/bits/stl_iterator.h
index 8afd6756613..594d4d5b65f 100644
--- a/libstdc++-v3/include/bits/stl_iterator.h
+++ b/libstdc++-v3/include/bits/stl_iterator.h
@@ -1017,6 +1017,13 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   template
 class __normal_iterator
 {
+#if __cplusplus >= 201103L
+  using __ite_ptr_traits = std::pointer_traits<_Iterator>;
+
+  template
+   using __ite_rebind = typename __ite_ptr_traits::template rebind<_Tp>;
+#endif
+
 protected:
   _Iterator _M_current;
 
@@ -1036,6 +1043,17 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   typedef typename __traits_type::referencereference;
   typedef typename __traits_type::pointer  pointer;
 
+#if __cplusplus >= 201103L
+  using element_type = typename __ite_ptr_traits::element_type;
+
+  template
+   using rebind = __normal_iterator<__ite_rebind<_Up>, _Container>;
+
+  static __normal_iterator
+  pointer_to(element_type& __e)
+  { return { __ite_ptr_traits::pointer_to(__e) }; }
+#endif
+
 #if __cplusplus > 201703L && __cpp_lib_concepts
   using iterator_concept = std::__detail::__iter_concept<_Iterator>;
 #endif
@@ -1311,34 +1329,6 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 { return __it.base(); }
 
 #if __cplusplus >= 201103L
-
-  // Need to specialize pointer_traits because the primary template will
-  // deduce element_type of __normal_iterator as T* rather than T.
-  template
-struct pointer_traits<__gnu_cxx::__normal_iterator<_Iterator, _Container>>
-{
-private:
-  using _Base = pointer_traits<_Iterator>;
-
-public:
-  using element_type = typename _Base::element_type;
-  using pointer = __gnu_cxx::__normal_iterator<_Iterator, _Container>;
-  using difference_type = typename _Base::difference_type;
-
-  template
-   using rebind = __gnu_cxx::__normal_iterator<_Tp, _Container>;
-
-  static pointer
-  pointer_to(element_type& __e) noexcept
-  { return pointer(_Base::pointer_to(__e)); }
-
-#if __cplusplus >= 202002L
-  static element_type*
-  to_address(pointer __p) noexcept
-  { return __p.base(); }
-#endif
-};
-
   /**
* @addtogroup iterators
* @{
diff --git a/libstdc++-v3/include/debug/safe_iterator.h 
b/libstdc++-v3/include/debug/safe_iterator.h
index 5584d06de5a..b175c9e4a31 100644
--- a/libstdc++-v3/include/debug/safe_iterator.h
+++ b/libstdc++-v3/include/debug/safe_iterator.h
@@ -653,6 +653,13 @@ namespace __gnu_debug
 : public _Safe_iterator<_Iterator, _Sequence,
std::bidirectional_iterator_tag>
 {
+#if __cplusplus >= 201103L
+  using __ite_ptr_traits = std::pointer_traits<_Iterator>;
+
+  template
+   using __ite_rebind = typename __ite_ptr_traits::template rebind<_Tp>;
+#endif
+
   typedef _Safe_iterator<_Iterator, _Sequence,
 std::bidirectional_iterator_tag> _Safe_base;
   typedef typename _Safe_base::_OtherIterator _OtherIterator;
@@ -672,6 +679,19 @@ namespace __gnu_debug
   typedef typename _Safe_base::difference_type difference_type;
   typedef typename _Safe_base::reference   reference;
 
+
+#if __cplusplus >= 201103L
+  using element_type = typename __ite_ptr_traits::element_type;
+
+  template
+   using rebind =

Re: [committed] libstdc++: Specialize std::pointer_traits<__normal_iterator>

2021-10-02 Thread François Dumont via Gcc-patches 

On 02/10/21 12:29 am, Jonathan Wakely wrote:

On Thu, 30 Sept 2021 at 21:27, François Dumont via Libstdc++
 wrote:

Here is the _Safe_iterator one.

Doing so I noticed that pointer_traits rebind for __normal_iterator was
wrong and added tests on it.

Oops, thanks!


For _Safe_iterator maybe I should specialize only when instantiated with
__normal_iterator ? Or maybe limit to random_access_iterator_tag ?

Yes, I think that's a good idea, maybe only for __normal_iterator. I think that should cover all the cases we actually need to
support.

And could you change the existing pointer_traits<__normal_iterator> partial specialization to only be valid for
__normal_iterator as well? i.e. only for __normal_iterator that
wraps a pointer (which is true for string::iterator, vector::iterator
etc.)


Is the attached patch what you had in mind ?

At least it is passing tests.





Whatever the pointer_to implementation is problematic, we can only
produce singular iterator as I did ifor now.

Hmm, yes. I think that's OK, because I don't think anybody is actually
going to use that function. What matters is that it works with
std::__to_address for C++17 mode, and that doesn't depend on
pointer_to, so it's OK if it doesn't work usefully.

This is why I think that my patch of the unordered containers to support 
custom pointers is not so bad because it avoids usage of 
pointer_traits::to_pointer :-)



diff --git a/libstdc++-v3/include/bits/stl_iterator.h 
b/libstdc++-v3/include/bits/stl_iterator.h
index 8afd6756613..f6dbe562505 100644
--- a/libstdc++-v3/include/bits/stl_iterator.h
+++ b/libstdc++-v3/include/bits/stl_iterator.h
@@ -1314,23 +1314,19 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 
   // Need to specialize pointer_traits because the primary template will
   // deduce element_type of __normal_iterator as T* rather than T.
-  template
-struct pointer_traits<__gnu_cxx::__normal_iterator<_Iterator, _Container>>
+  template
+struct pointer_traits<__gnu_cxx::__normal_iterator<_Tp*, _Container>>
 {
-private:
-  using _Base = pointer_traits<_Iterator>;
-
-public:
-  using element_type = typename _Base::element_type;
-  using pointer = __gnu_cxx::__normal_iterator<_Iterator, _Container>;
-  using difference_type = typename _Base::difference_type;
+  using element_type = _Tp;
+  using pointer = __gnu_cxx::__normal_iterator<_Tp*, _Container>;
+  using difference_type = ptrdiff_t;
 
-  template
-   using rebind = __gnu_cxx::__normal_iterator<_Tp, _Container>;
+  template
+   using rebind = __gnu_cxx::__normal_iterator<_Up*, _Container>;
 
-  static pointer
-  pointer_to(element_type& __e) noexcept
-  { return pointer(_Base::pointer_to(__e)); }
+  static _GLIBCXX20_CONSTEXPR pointer
+  pointer_to(__make_not_void& __r) noexcept
+  { return pointer(std::addressof(__r)); }
 
 #if __cplusplus >= 202002L
   static element_type*
diff --git a/libstdc++-v3/include/debug/safe_iterator.h 
b/libstdc++-v3/include/debug/safe_iterator.h
index 5584d06de5a..d2469574240 100644
--- a/libstdc++-v3/include/debug/safe_iterator.h
+++ b/libstdc++-v3/include/debug/safe_iterator.h
@@ -1013,6 +1013,45 @@ namespace __gnu_debug
 
 } // namespace __gnu_debug
 
+#if __cplusplus >= 201103L
+namespace std _GLIBCXX_VISIBILITY(default)
+{
+_GLIBCXX_BEGIN_NAMESPACE_VERSION
+  template
+struct pointer_traits<__gnu_debug::_Safe_iterator<
+  __gnu_cxx::__normal_iterator<_Tp*, _Container>, _Sequence,
+  std::random_access_iterator_tag>>
+{
+private:
+  using __base_ptr =
+   __gnu_cxx::__normal_iterator<_Tp*, _Container>;
+
+public:
+  using element_type = _Tp;
+  using pointer = __gnu_debug::_Safe_iterator<
+   __gnu_cxx::__normal_iterator<_Tp*, _Container>, _Sequence,
+   std::random_access_iterator_tag>;
+  using difference_type = ptrdiff_t;
+
+  template
+   using rebind = __gnu_debug::_Safe_iterator<
+ __gnu_cxx::__normal_iterator<_Up*, _Container>, _Sequence,
+ std::random_access_iterator_tag>;
+
+  static pointer
+  pointer_to(element_type& __e) noexcept
+  { return { __base_ptr(std::addressof(__e)), nullptr }; }
+
+#if __cplusplus >= 202002L
+  static element_type*
+  to_address(const pointer& __p) noexcept
+  { return __p.base().base(); }
+#endif
+};
+_GLIBCXX_END_NAMESPACE_VERSION
+} // namespace
+#endif
+
 #undef _GLIBCXX_DEBUG_VERIFY_DIST_OPERANDS
 #undef _GLIBCXX_DEBUG_VERIFY_REL_OPERANDS
 #undef _GLIBCXX_DEBUG_VERIFY_EQ_OPERANDS
diff --git a/libstdc++-v3/testsuite/20_util/pointer_traits/rebind.cc 
b/libstdc++-v3/testsuite/20_util/pointer_traits/rebind.cc
index 159ea8f5294..b78e974d777 100644
--- a/libstdc++-v3/testsuite/20_util/pointer_traits/rebind.cc
+++ b/libstdc++-v3/testsuite/20_util/pointer_traits/rebind.cc
@@ -18,6 +18,7 @@
 // { dg-do compile { target c++11 } }
 
 #include 
+#include 
 
 using std::is_same;
 
@@ -66,3 +67,13 @@ template
   };
 // PR

Re: [committed] libstdc++: Allow visiting inherited variants [PR 90943]

2021-10-02 Thread Daniel Krügler via Gcc-patches 
Am Fr., 1. Okt. 2021 um 21:57 Uhr schrieb Jonathan Wakely via
Libstdc++ :
>
> Implement the changes from P2162R2 (as a DR for C++17).
>
> Signed-off-by: Jonathan Wakely 
>
> libstdc++-v3/ChangeLog:
>
> PR libstdc++/90943
> * include/std/variant (__cpp_lib_variant): Update value.
> (__detail::__variant::__as): New helpers implementing the
> as-variant exposition-only function templates.
> (visit, visit): Use __as to upcast the variant parameters.
> * include/std/version (__cpp_lib_variant): Update value.
> * testsuite/20_util/variant/visit_inherited.cc: New test.
>
> Tested powerpc64le-linux. Committed to trunk.
>

I'm wondering why the first __as overload is not noexcept as well (or
asking it the other way around: Why different exception-specifications
are used for the different overloads):

+  // The __as function templates implement the exposition-only "as-variant"
+
+  template
+constexpr std::variant<_Types...>&
+__as(std::variant<_Types...>& __v)
+{ return __v; }

- Daniel

[PATCH][PUSHED] options: fix ASAN issue during saving of opt. options

2021-10-02 Thread Martin Liška 

Fix an obvious issue when processing save_decoded_options.

Patch can bootstrap on x86_64-linux-gnu and survives regression tests.

Thanks,
Martin

gcc/ChangeLog:

* toplev.c (toplev::main): save_decoded_options[0] is program
name and so it should be skipped.
---
 gcc/toplev.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/toplev.c b/gcc/toplev.c
index 78bb7e9749b..d952319ad95 100644
--- a/gcc/toplev.c
+++ b/gcc/toplev.c
@@ -2338,7 +2338,7 @@ toplev::main (int argc, char **argv)
_decoded_options_count);
 
   /* Save Optimization decoded options.  */

-  for (unsigned i = 0; i < save_decoded_options_count; ++i)
+  for (unsigned i = 1; i < save_decoded_options_count; ++i)
 if (cl_options[save_decoded_options[i].opt_index].flags & CL_OPTIMIZATION)
   save_opt_decoded_options.safe_push (save_decoded_options[i]);
 
--

2.33.0

[PATCH] c-family: Fix bootstrap for targets defining TARGET_FORMAT_TYPES.

2021-10-02 Thread Iain Sandoe via Gcc-patches 
A recent improvement in Waddress causes a bootstrap failure on
targets that define TARGET_FORMAT_TYPES since it cannot be NULL
if defined to an address.

There is no default for this target macro, and it would seem no
purpose to defining it to NULL, so the warning appears reasonable.

Fixed by removing the pointless test.

Tested on x86_64-darwin, pushed to master as a bootstrap fix
The targets that define TARGET_FORMAT_TYPES are Solaris, MinGW
and Darwin, so cc-ing the Solaris and MinGW maintainers.

thanks
Iain

Signed-off-by: Iain Sandoe 

gcc/c-family/ChangeLog:

* c-format.c: Remove a test of TARGET_FORMAT_TYPES with
NULL, this is not needed.
---
 gcc/c-family/c-format.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/c-family/c-format.c b/gcc/c-family/c-format.c
index b4cb765a9d3..ca66c81f716 100644
--- a/gcc/c-family/c-format.c
+++ b/gcc/c-family/c-format.c
@@ -5150,7 +5150,7 @@ handle_format_attribute (tree *node, tree atname, tree 
args,
 #ifdef TARGET_FORMAT_TYPES
   /* If the target provides additional format types, we need to
  add them to FORMAT_TYPES at first use.  */
-  if (TARGET_FORMAT_TYPES != NULL && !dynamic_format_types)
+  if (!dynamic_format_types)
 {
   dynamic_format_types = XNEWVEC (format_kind_info,
  n_format_types + TARGET_N_FORMAT_TYPES);
-- 
2.24.3 (Apple Git-128)

Re: [Patch] Add libgomp.fortran/order-reproducible-*.f90 [Re: [committed] openmp: Differentiate between order(concurrent) and order(reproducible:concurrent)]

2021-10-02 Thread Jakub Jelinek via Gcc-patches 
On Sat, Oct 02, 2021 at 09:52:29AM +0200, Tobias Burnus wrote:
> --- /dev/null
> +++ b/libgomp/testsuite/libgomp.fortran/order-reproducible-1.f90
> @@ -0,0 +1,72 @@
> +! { dg-additional-sources my-usleep.c }
> +! { dg-prune-output "command-line option '-fintrinsic-modules-path=.*' is 
> valid for Fortran but not for C" }
> +program main
> +  implicit none
> +  interface
> +subroutine usleep(t) bind(C, name="my_usleep")
> +  use iso_c_binding
> +  integer(c_int), value :: t
> +end subroutine
> +  end interface
> +
> +  integer :: a(128)
> +  integer :: i
> +
> +  !$omp teams num_teams(5)
> +!$omp loop bind(teams)
> +do i = 1, 128
> +  a(i) = i
> +  if (i == 0) then

i will never be 0, change it to some other number.

Otherwise LGTM, thanks.

Jakub

Re: [Patch] Add libgomp.fortran/order-reproducible-*.f90 [Re: [committed] openmp: Differentiate between order(concurrent) and order(reproducible:concurrent)]

2021-10-02 Thread Tobias Burnus 

On 01.10.21 11:45, Jakub Jelinek wrote:


Attached is the Fortran version of the two patches – the Fortran FE
modifications were already in Jakub's patch.

And no my-usleep.c in the patch.


Thou shall not send patches in a hurry when taking off on a day ...

New patch attached.

Tobias

-
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
Add libgomp.fortran/order-reproducible-*.f90

libgomp/ChangeLog:

	* testsuite/libgomp.fortran/order-reproducible-1.f90: New test
	based on libgomp.c-c++-common/order-reproducible-1.c.
	* testsuite/libgomp.fortran/order-reproducible-2.f90: Likewise.
	* testsuite/libgomp.fortran/my-usleep.c: New test.

 libgomp/testsuite/libgomp.fortran/my-usleep.c  |  9 +++
 .../libgomp.fortran/order-reproducible-1.f90   | 72 ++
 .../libgomp.fortran/order-reproducible-2.f90   | 37 +++
 3 files changed, 118 insertions(+)

diff --git a/libgomp/testsuite/libgomp.fortran/my-usleep.c b/libgomp/testsuite/libgomp.fortran/my-usleep.c
new file mode 100644
index 000..1764db9cd64
--- /dev/null
+++ b/libgomp/testsuite/libgomp.fortran/my-usleep.c
@@ -0,0 +1,9 @@
+/* Wrapper as usleep takes 'useconds_t', an unsigned integer type, as argument. */
+
+#include 
+
+void
+my_usleep (int t)
+{
+  usleep (t);
+}
diff --git a/libgomp/testsuite/libgomp.fortran/order-reproducible-1.f90 b/libgomp/testsuite/libgomp.fortran/order-reproducible-1.f90
new file mode 100644
index 000..0cf23e708bc
--- /dev/null
+++ b/libgomp/testsuite/libgomp.fortran/order-reproducible-1.f90
@@ -0,0 +1,72 @@
+! { dg-additional-sources my-usleep.c }
+! { dg-prune-output "command-line option '-fintrinsic-modules-path=.*' is valid for Fortran but not for C" }
+program main
+  implicit none
+  interface
+subroutine usleep(t) bind(C, name="my_usleep")
+  use iso_c_binding
+  integer(c_int), value :: t
+end subroutine
+  end interface
+
+  integer :: a(128)
+  integer :: i
+
+  !$omp teams num_teams(5)
+!$omp loop bind(teams)
+do i = 1, 128
+  a(i) = i
+  if (i == 0) then
+call usleep (20)
+  else if (i == 17) then
+call usleep (40)
+  end if
+end do
+!$omp loop bind(teams)
+do i = 1, 128
+  a(i) = a(i) + i
+end do
+  !$omp end teams
+  do i = 1, 128
+if (a(i) /= 2 * i) &
+  stop 1
+  end do
+  !$omp teams num_teams(5)
+!$omp loop bind(teams) order(concurrent)
+do i = 1, 128
+  a(i) = a(i) * 2
+  if (i == 1) then
+call usleep (20)
+  else if (i == 13) then
+call usleep (40)
+  end if
+end do
+!$omp loop bind(teams) order(concurrent)
+do i = 1, 128
+  a(i) = a(i) + i
+end do
+  !$omp end teams
+  do i = 1, 128
+if (a(i) /= 5 * i) &
+  stop 2
+  end do
+  !$omp teams num_teams(5)
+!$omp loop bind(teams) order(reproducible:concurrent)
+do i = 1, 128
+  a(i) = a(i) * 2
+  if (i == 3) then
+call usleep (20)
+  else if (i == 106) then
+call usleep (40)
+  end if
+end do
+!$omp loop bind(teams) order(reproducible:concurrent)
+do i = 1, 128
+  a(i) = a(i) + i
+end do
+  !$omp end teams
+  do i = 1, 128
+if (a(i) /= 11 * i) &
+  stop 3
+  end do
+end program main
diff --git a/libgomp/testsuite/libgomp.fortran/order-reproducible-2.f90 b/libgomp/testsuite/libgomp.fortran/order-reproducible-2.f90
new file mode 100644
index 000..9d720206144
--- /dev/null
+++ b/libgomp/testsuite/libgomp.fortran/order-reproducible-2.f90
@@ -0,0 +1,37 @@
+! { dg-additional-sources my-usleep.c }
+! { dg-prune-output "command-line option '-fintrinsic-modules-path=.*' is valid for Fortran but not for C" }
+program main
+  implicit none
+  interface
+subroutine usleep(t) bind(C, name="my_usleep")
+  use iso_c_binding
+  integer(c_int), value :: t
+end subroutine
+  end interface
+
+  integer :: a(128)
+  integer :: i
+
+  !$omp parallel num_threads(8)
+!$omp barrier
+!$omp do schedule (dynamic, 2) order(reproducible:concurrent)
+do i = 1, 128
+  a(i) = i
+  if (i == 1) then
+call usleep (20)
+  else if (i == 18) then
+call usleep (40)
+  end if
+end do
+!$omp end do nowait
+!$omp do schedule (dynamic, 2) order(reproducible:concurrent)
+do i = 1, 128
+  a(i) = a(i) + i
+end do
+!$omp end do nowait
+  !$omp end parallel
+  do i = 1, 128
+if (a(i) /= 2 * i) &
+  stop
+  end do
+end program main