[committed] testsuite: Add testcase for already fixed PR [PR109362]
Hi!
This PR got fixed with r13-137.
Add a testcase to make sure it doesn't reappear.
Regtested on x86_64-linux and i686-linux, committed to trunk as obvious.
2023-04-01 Jakub Jelinek
PR tree-optimization/109362
* gcc.target/i386/pr109362.c: New test.
--- gcc/testsuite/gcc.target/i386/pr109362.c.jj 2023-03-31 17:36:08.396428411
+0200
+++ gcc/testsuite/gcc.target/i386/pr109362.c2023-03-31 17:35:49.768696966
+0200
@@ -0,0 +1,19 @@
+/* PR tree-optimization/109362 */
+/* { dg-do compile { target lp64 } } */
+/* { dg-options "-O2 -masm=att" } */
+/* Ensure we don't waste a register set to %rdi + 8. */
+/* { dg-final { scan-assembler "\tmovq\t\\\(%rdi\\\), %r" } } */
+/* { dg-final { scan-assembler "\tmovq\t8\\\(%rdi\\\), %r" } } */
+
+struct S { long a, b; };
+
+int
+foo (struct S *v)
+{
+ while (1)
+{
+ __atomic_load_n (&v->a, __ATOMIC_ACQUIRE);
+ if (__atomic_load_n (&v->b, __ATOMIC_ACQUIRE))
+ return 1;
+}
+}
Jakub
Re: [PATCH] range-op-float: Further comparison fixes
On Fri, Mar 31, 2023 at 01:28:35PM +0200, Aldy Hernandez wrote:
> > Ok for trunk if this passes bootstrap/regtest?
>
> LGTM
Unfortunately I ran into 4 tests where we run into the known bug
where if ranger finds out a range of some floating point operation
it folds it and throws away the trapping side-effects with it.
In particular, e.g. VARYING > __builtin_inf () is now folded to false
because no finite or infinite value is larger than +inf, and if
NAN is compared against it, the result is false as well.
Given that it is a known problem we need to find some solution for
in GCC 14, I've just changed those testcases to disable dom and vrp
passes which were optimizing it. Another workaround would be
to hide the infinity from the optimizers, but given that the test was
added exactly to verify match.pd doesn't optimize this for -ftrapping-math,
I think disabling dom/vrp is better.
So, here is what I've committed (the other patch committed unchanged):
2023-04-01 Jakub Jelinek
* range-op-float.cc (foperator_equal::fold_range): Perform the
non-singleton handling regardless of maybe_isnan (op1, op2).
(foperator_not_equal::fold_range): Likewise.
(foperator_lt::fold_range, foperator_le::fold_range,
foperator_gt::fold_range, foperator_ge::fold_range): Perform the
real_* comparison check which results in range_false (type)
even if maybe_isnan (op1, op2). Simplify.
(foperator_ltgt): New class.
(fop_ltgt): New variable.
(floating_op_table::floating_op_table): Handle LTGT_EXPR using
fop_ltgt.
* gcc.dg/torture/inf-compare-1.c: Add dg-additional-options
-fno-tree-dominator-opts -fno-tree-vrp.
* gcc.dg/torture/inf-compare-1-float.c: Likewise.
* gcc.dg/torture/inf-compare-2.c: Likewise.
* gcc.dg/torture/inf-compare-2-float.c: Likewise.
--- gcc/range-op-float.cc.jj2023-03-31 09:30:11.245296618 +0200
+++ gcc/range-op-float.cc 2023-03-31 11:23:04.817876083 +0200
@@ -616,7 +616,7 @@ foperator_equal::fold_range (irange &r,
else
r = range_false (type);
}
- else if (!maybe_isnan (op1, op2))
+ else
{
// If ranges do not intersect, we know the range is not equal,
// otherwise we don't know anything for sure.
@@ -638,8 +638,6 @@ foperator_equal::fold_range (irange &r,
else
r = range_true_and_false (type);
}
- else
-r = range_true_and_false (type);
return true;
}
@@ -734,7 +732,7 @@ foperator_not_equal::fold_range (irange
else
r = range_true (type);
}
- else if (!maybe_isnan (op1, op2))
+ else
{
// If ranges do not intersect, we know the range is not equal,
// otherwise we don't know anything for sure.
@@ -756,8 +754,6 @@ foperator_not_equal::fold_range (irange
else
r = range_true_and_false (type);
}
- else
-r = range_true_and_false (type);
return true;
}
@@ -839,17 +835,13 @@ foperator_lt::fold_range (irange &r, tre
if (frelop_early_resolve (r, type, op1, op2, rel, VREL_LT))
return true;
- if (op1.known_isnan () || op2.known_isnan ())
+ if (op1.known_isnan ()
+ || op2.known_isnan ()
+ || !real_less (&op1.lower_bound (), &op2.upper_bound ()))
r = range_false (type);
- else if (!maybe_isnan (op1, op2))
-{
- if (real_less (&op1.upper_bound (), &op2.lower_bound ()))
- r = range_true (type);
- else if (!real_less (&op1.lower_bound (), &op2.upper_bound ()))
- r = range_false (type);
- else
- r = range_true_and_false (type);
-}
+ else if (!maybe_isnan (op1, op2)
+ && real_less (&op1.upper_bound (), &op2.lower_bound ()))
+r = range_true (type);
else
r = range_true_and_false (type);
return true;
@@ -959,17 +951,13 @@ foperator_le::fold_range (irange &r, tre
if (frelop_early_resolve (r, type, op1, op2, rel, VREL_LE))
return true;
- if (op1.known_isnan () || op2.known_isnan ())
+ if (op1.known_isnan ()
+ || op2.known_isnan ()
+ || !real_compare (LE_EXPR, &op1.lower_bound (), &op2.upper_bound ()))
r = range_false (type);
- else if (!maybe_isnan (op1, op2))
-{
- if (real_compare (LE_EXPR, &op1.upper_bound (), &op2.lower_bound ()))
- r = range_true (type);
- else if (!real_compare (LE_EXPR, &op1.lower_bound (), &op2.upper_bound
()))
- r = range_false (type);
- else
- r = range_true_and_false (type);
-}
+ else if (!maybe_isnan (op1, op2)
+ && real_compare (LE_EXPR, &op1.upper_bound (), &op2.lower_bound ()))
+r = range_true (type);
else
r = range_true_and_false (type);
return true;
@@ -1073,17 +1061,13 @@ foperator_gt::fold_range (irange &r, tre
if (frelop_early_resolve (r, type, op1, op2, rel, VREL_GT))
return true;
- if (op1.known_isnan () || op2.known_isnan ())
+ if (op1.known_isnan ()
+ || op2.known_isnan ()
+ || !real_compare (GT_EXPR, &op1.upper_bou
Re: [PATCH] Fix fc-prototypes usage with C_INT64_T and non LP64 Targets.
Hi Steve,
Hi Andrew,
"long long". This was just an oversight and a missing check.
Committed as obvious after a bootstrap/test on x86_64-linux-gnu.
Thanks!
I think this one is obvious enough that it deserves a backport.
I've cherry-picked this for gcc12, will do gcc11 tomorrow.
The patch is incomplete.
module foo
use, intrinsic :: iso_c_binding
implicit none
public :: bar
type, bind(c) :: bar
real(10) a
end type
end module
This yields
typedef struct bar {
long_double a /* WARNING: Converting 'REAL(10)' to interoperable type */;
} bar;
That should be 'long double'.
Fixed as obvious in 69044e11ac5 .
I will backport soon.
Thanks for the heads-up!
Best regards
Thomas
Re: [PATCH 1/7] openmp: Add Fortran support for "omp unroll" directive
Hi Frederik!
Thanks for including a good number of test cases with your code changes!
This new test case:
On 2023-03-24T16:30:39+0100, Frederik Harwath wrote:
> --- /dev/null
> +++ b/libgomp/testsuite/libgomp.fortran/loop-transforms/unroll-1.f90
> @@ -0,0 +1,52 @@
> +! { dg-additional-options "-fdump-tree-original" }
> +! { dg-do run }
> +
> +module test_functions
> + contains
> + integer function compute_sum() result(sum)
> +implicit none
> +
> +integer :: i,j
> +
> +!$omp do
> +do i = 1,10,3
> + !$omp unroll full
> + do j = 1,10,3
> + sum = sum + 1
> + end do
> +end do
> + end function
> +
> + integer function compute_sum2() result(sum)
> +implicit none
> +
> +integer :: i,j
> +
> +!$omp parallel do reduction(+:sum)
> +!$omp unroll partial(2)
> +do i = 1,10,3
> + do j = 1,10,3
> + sum = sum + 1
> + end do
> +end do
> + end function
> +end module test_functions
> +
> +program test
> + use test_functions
> + implicit none
> +
> + integer :: result
> +
> + result = compute_sum ()
> + write (*,*) result
> + if (result .ne. 16) then
> + call abort
> + end if
> +
> + result = compute_sum2 ()
> + write (*,*) result
> + if (result .ne. 16) then
> + call abort
> + end if
> +end program
... I see FAIL for x86_64-pc-linux-gnu '-m32' (thus, host, not
offloading), '-O0' (only):
spawn [open ...]
1437822992
Program aborted. Backtrace:
#0 0x8048df0 in ???
#1 0x8048ea6 in ???
#2 0x559a3af2 in ???
#3 0x8048bc0 in ???
FAIL: libgomp.fortran/loop-transforms/unroll-1.f90 -O0 execution test
All other variants PASS with:
spawn [open ...]
16
16
And similarly, this new test case:
> --- /dev/null
> +++ b/libgomp/testsuite/libgomp.fortran/loop-transforms/unroll-simd-1.f90
> @@ -0,0 +1,33 @@
> +! { dg-options "-fno-openmp -fopenmp-simd" }
> +! { dg-additional-options "-fdump-tree-original" }
> +! { dg-do run }
> +
> +module test_functions
> + contains
> + integer function compute_sum() result(sum)
> +implicit none
> +
> +integer :: i,j
> +
> +!$omp simd
> +do i = 1,10,3
> + !$omp unroll full
> + do j = 1,10,3
> + sum = sum + 1
> + end do
> +end do
> + end function compute_sum
> +end module test_functions
> +
> +program test
> + use test_functions
> + implicit none
> +
> + integer :: result
> +
> + result = compute_sum ()
> + write (*,*) result
> + if (result .ne. 16) then
> + call abort
> + end if
> +end program
... I see FAIL for x86_64-pc-linux-gnu '-m32' (thus, host, not
offloading), '-O0' (only):
spawn [open ...]
41
Program aborted. Backtrace:
#0 0x8048c35 in ???
#1 0x8048c72 in ???
#2 0x55977af2 in ???
#3 0x8048a60 in ???
FAIL: libgomp.fortran/loop-transforms/unroll-simd-1.f90 -O0 execution
test
All other variants PASS with:
spawn [open ...]
16
Grüße
Thomas
-
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
Re: [PATCH] c++: NTTP constraint depending on outer args [PR109160]
On Wed, 29 Mar 2023, Jason Merrill wrote:
> On 3/17/23 11:26, Patrick Palka wrote:
> > Here we're crashing during satisfaction for the NTTP 'C auto' from
> > do_auto_deduction ultimately because convert_template_argument / unify
> > don't pass all outer template arguments to do_auto_deduction, and during
> > satisfaction we need to know all arguments. While these callers do
> > pass some outer arguments, they are only sufficient to properly
> > substitute the 'auto' and are not necessarily the complete set.
> >
> > Fortunately it seems it's possible to obtain the full set of outer
> > arguments from these callers via convert_template_argument's IN_DECL
> > parameter and unify's TPARMS parameter. So this patch adds a TMPL
> > parameter to do_auto_deduction, used only during adc_unify deduction,
> > which contains the (partially instantiated) template corresponding to
> > this auto and from which we can obtain all outer template arguments for
> > satisfaction.
> >
> > This patch also adjusts the IN_DECL argument passed to
> > coerce_template_parms from tsubst_decl so that we could in turn safely
> > assume convert_template_argument's IN_DECL is always a TEMPLATE_DECL,
> > and thus could pass it as-is to do_auto_deduction. (tsubst_decl seems
> > to be the only caller that passes a non-empty non-template IN_DECL to
> > coerce_template_parms.)
> >
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
> > trunk/12?
> >
> > PR c++/109160
> >
> > gcc/cp/ChangeLog:
> >
> > * cp-tree.h (do_auto_deduction): Add defaulted TMPL parameter.
> > * pt.cc (convert_template_argument): Pass IN_DECL as TMPL to
> > do_auto_deduction.
> > (tsubst_decl) : Pass TMPL instead of T as
> > IN_DECL to coerce_template_parms.
> > (unify) : Pass the corresponding
> > template as TMPL to do_auto_deduction.
> > (do_auto_deduction): Document default arguments. Use TMPL
> > to obtain a full set of template arguments for satisfaction
> > in the adc_unify case.
> >
> > gcc/testsuite/ChangeLog:
> >
> > * g++.dg/cpp2a/concepts-placeholder12.C: New test.
> > ---
> > gcc/cp/cp-tree.h | 3 +-
> > gcc/cp/pt.cc | 30 ++-
> > .../g++.dg/cpp2a/concepts-placeholder12.C | 29 ++
> > 3 files changed, 53 insertions(+), 9 deletions(-)
> > create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-placeholder12.C
> >
> > diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
> > index dfc1c845768..e7190c5cc62 100644
> > --- a/gcc/cp/cp-tree.h
> > +++ b/gcc/cp/cp-tree.h
> > @@ -7324,7 +7324,8 @@ extern tree do_auto_deduction (tree,
> > tree, tree,
> >auto_deduction_context
> > = adc_unspecified,
> > tree = NULL_TREE,
> > -int = LOOKUP_NORMAL);
> > +int = LOOKUP_NORMAL,
> > +tree = NULL_TREE);
> > extern tree type_uses_auto(tree);
> > extern tree type_uses_auto_or_concept (tree);
> > extern void append_type_to_template_for_access_check (tree, tree, tree,
> > diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc
> > index ddbd73371b9..6400b686a58 100644
> > --- a/gcc/cp/pt.cc
> > +++ b/gcc/cp/pt.cc
> > @@ -8638,7 +8638,7 @@ convert_template_argument (tree parm,
> > else if (tree a = type_uses_auto (t))
> > {
> > t = do_auto_deduction (t, arg, a, complain, adc_unify, args,
> > -LOOKUP_IMPLICIT);
> > +LOOKUP_IMPLICIT, in_decl);
> > if (t == error_mark_node)
> > return error_mark_node;
> > }
> > @@ -15243,7 +15243,7 @@ tsubst_decl (tree t, tree args, tsubst_flags_t
> > complain)
> > the template. */
> > argvec = (coerce_template_parms
> > (DECL_TEMPLATE_PARMS (gen_tmpl),
> > -argvec, t, complain));
> > +argvec, tmpl, complain));
> > if (argvec == error_mark_node)
> > RETURN (error_mark_node);
> > hash = spec_hasher::hash (gen_tmpl, argvec);
> > @@ -24655,7 +24655,9 @@ unify (tree tparms, tree targs, tree parm, tree arg,
> > int strict,
> > if (tree a = type_uses_auto (tparm))
> > {
> > tparm = do_auto_deduction (tparm, arg, a,
> > -complain, adc_unify, targs);
> > +complain, adc_unify, targs,
> > +LOOKUP_NORMAL,
> > +TPARMS_PRIMARY_TEMPLATE (tparms)); >
> > if (tparm == error_mark_node)
> > return 1;
> > }
> > @@ -30643,13 +30645,20 @@ unparenthesized_id_or_c
Re: 'g++.dg/modules/modules.exp': don't leak local 'unsupported' proc [PR108899]
On Mar 30, 2023, at 6:51 AM, Alexandre Oliva wrote: > > On Mar 30, 2023, Alexandre Oliva wrote: > >> If we're dropping the renaming, I suppose we could also revert Jakub's >> change. I suppose this patch will take care of it, pending testing... > > Regstrapped on x86_64-linux-gnu and also tested on arm-vx7r2 (with > gcc-12), where I used to get fails after an unsupported modules.exp > test, but there are no curly braces in the log files after the patch. > Ok to install? Ok.
Re: [PATCH] range-op-float: Further comparison fixes
On 4/1/23 09:39, Jakub Jelinek wrote: On Fri, Mar 31, 2023 at 01:28:35PM +0200, Aldy Hernandez wrote: Ok for trunk if this passes bootstrap/regtest? LGTM Unfortunately I ran into 4 tests where we run into the known bug where if ranger finds out a range of some floating point operation it folds it and throws away the trapping side-effects with it. Is VRP folding it, or is some other pass using ranger making a decision based on INF > INF being false? Cause we'd ultimately like to keep ranger honest...that is returning FALSE for the above, so the onus is on the ranger callers on making correct decisions. IMO. Aldy
