[Patch] contrib/gcc-changelog/git_update_version.py: Improve diagnostic (was: [Patch] contrib/gcc-changelog/git_update_version.py: Add ignore commit, improve diagnostic)
Hmm, there were now two daily bumps:
Date: Mon May 20 00:16:30 2024 +
Date: Sun May 19 18:15:28 2024 +
I really wonder why.
I guess, the 'ignore commit' is hence not needed – but I think the
improved diagnostic part still makes sense.
See updated patch.
On May 19, 24 Tobias Burnus wrote:
I noticed that the last bump happened on Thursday.
* * *
The error is according to
https://gcc.gnu.org/pipermail/gccadmin/2024q2/021298.html
2024-05-19 00:17:28,643:INFO:root:cannot find a ChangeLog location in
message
That's the commit
---
Revert "Revert: "Enable prange support.""
This reverts commit d7bb8eaade3cd3aa70715c8567b4d7b08098e699 and
enables prange
support again.
---
* * * The attached patch adds this commit to the ignore list and helps
with the diagnosis by showing the failing hash in the error message.
OK for mainline?
Post commit: Can someone install the new version + fix the ChangeLog
for the ignored commit?
* * *
What I do not understand: Why does this commit get applied? I do see
for both
contrib/gcc-changelog/git_check_commit.py -v -p
da73261ce7731be7f2b164f1db796878cdc23365
and
contrib/gcc-changelog/git_email.py
0001-Revert-Revert-Enable-prange-support.patch the error above. - And
I do not understand why it made it past the commit check but now fails?
Likewise for8057f9aa1f7e70490064de796d7a8d42d446caf8
Does the commit hook use an older version of the check scripts? Does
it ignore the errors? Or what goes wrong here? Any idea?
TobiasFrom f56b1764f2b5c2c83c6852607405e5be0a763a2c Mon Sep 17 00:00:00 2001
From: Tobias Burnus
Date: Sun, 19 May 2024 08:17:42 +0200
Subject: [PATCH] contrib/gcc-changelog/git_update_version.py: Improve diagnostic
contrib/ChangeLog:
* gcc-changelog/git_update_version.py (prepend_to_changelog_files): Output
git hash in case errors occurred.
diff --git a/contrib/gcc-changelog/git_update_version.py b/contrib/gcc-changelog/git_update_version.py
index 24f6c43d0b2..ec0151b83fe 100755
--- a/contrib/gcc-changelog/git_update_version.py
+++ b/contrib/gcc-changelog/git_update_version.py
@@ -58,6 +58,7 @@ def read_timestamp(path):
def prepend_to_changelog_files(repo, folder, git_commit, add_to_git):
if not git_commit.success:
+logging.info(f"While processing {git_commit.info.hexsha}:")
for error in git_commit.errors:
logging.info(error)
raise AssertionError()
--
2.45.0
Re: [PATCH] Optab: add isfinite_optab for __builtin_isfinite
Hi Andrew, 在 2024/5/19 3:42, Andrew Pinski 写道: > This is missing adding documentation for the new optab. > It should be documented in md.texi under `Standard Pattern Names For > Generation` section. Thanks for your reminder. I will add ones for all patches. Thanks Gui Haochen
[PATCH V3] report message for operator %a on unaddressible operand
Hi,
For PR96866, when printing asm code for modifier "%a", an addressable
operand is required. While the constraint "X" allow any kind of
operand even which is hard to get the address directly. e.g. extern
symbol whose address is in TOC.
An error message would be reported to indicate the invalid asm operand.
Compare with previous version, code comments and message are updated.
Bootstrap®test pass on ppc64{,le}.
Is this ok for trunk?
BR,
Jeff(Jiufu Guo)
PR target/96866
gcc/ChangeLog:
* config/rs6000/rs6000.cc (print_operand_address):
gcc/testsuite/ChangeLog:
* gcc.target/powerpc/pr96866-1.c: New test.
* gcc.target/powerpc/pr96866-2.c: New test.
---
gcc/config/rs6000/rs6000.cc | 7 ++-
gcc/testsuite/gcc.target/powerpc/pr96866-1.c | 18 ++
gcc/testsuite/gcc.target/powerpc/pr96866-2.c | 13 +
3 files changed, 37 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/gcc.target/powerpc/pr96866-1.c
create mode 100644 gcc/testsuite/gcc.target/powerpc/pr96866-2.c
diff --git a/gcc/config/rs6000/rs6000.cc b/gcc/config/rs6000/rs6000.cc
index 117999613d8..7e7c36a1bad 100644
--- a/gcc/config/rs6000/rs6000.cc
+++ b/gcc/config/rs6000/rs6000.cc
@@ -14664,7 +14664,12 @@ print_operand_address (FILE *file, rtx x)
fprintf (file, "@%s(%s)", SMALL_DATA_RELOC,
reg_names[SMALL_DATA_REG]);
else
- gcc_assert (!TARGET_TOC);
+ {
+ /* Do not support getting address directly from TOC, emit error.
+No more work is needed for !TARGET_TOC. */
+ if (TARGET_TOC)
+ output_operand_lossage ("%%a requires an address of memory");
+ }
}
else if (GET_CODE (x) == PLUS && REG_P (XEXP (x, 0))
&& REG_P (XEXP (x, 1)))
diff --git a/gcc/testsuite/gcc.target/powerpc/pr96866-1.c
b/gcc/testsuite/gcc.target/powerpc/pr96866-1.c
new file mode 100644
index 000..bcebbd6e310
--- /dev/null
+++ b/gcc/testsuite/gcc.target/powerpc/pr96866-1.c
@@ -0,0 +1,18 @@
+/* The "%a" modifier can't get the address of extern symbol directly from TOC
+ with -fPIC, even the symbol is propgated for "X" constraint under -O2. */
+/* { dg-options "-fPIC -O2" } */
+
+/* It's to verify no ICE here, ignore error messages about invalid 'asm'. */
+/* { dg-excess-errors "pr96866-1.c" } */
+
+int x[2];
+
+int __attribute__ ((noipa))
+f1 (void)
+{
+ int n;
+ int *p = x;
+ *p++;
+ __asm__ volatile("ld %0, %a1" : "=r"(n) : "X"(p));
+ return n;
+}
diff --git a/gcc/testsuite/gcc.target/powerpc/pr96866-2.c
b/gcc/testsuite/gcc.target/powerpc/pr96866-2.c
new file mode 100644
index 000..0577fd6d588
--- /dev/null
+++ b/gcc/testsuite/gcc.target/powerpc/pr96866-2.c
@@ -0,0 +1,13 @@
+/* The "%a" modifier can't get the address of extern symbol directly from TOC
+ with -fPIC. */
+/* { dg-options "-fPIC -O2" } */
+
+/* It's to verify no ICE here, ignore error messages about invalid 'asm'. */
+/* { dg-excess-errors "pr96866-2.c" } */
+
+void
+f (void)
+{
+ extern int x;
+ __asm__ volatile("#%a0" ::"X"(&x));
+}
--
2.25.1
Re: [PATCH v5 1/5] Improve must tail in RTL backend
On Tue, May 14, 2024 at 04:15:08PM +0200, Richard Biener wrote:
> On Sun, May 5, 2024 at 8:16 PM Andi Kleen wrote:
> >
> > - Give error messages for all causes of non sibling call generation
> > - Don't override choices of other non sibling call checks with
> > must tail. This causes ICEs. The must tail attribute now only
> > overrides flag_optimize_sibling_calls locally.
> > - Error out when tree-tailcall failed to mark a must-tail call
> > sibcall. In this case it doesn't know the true reason and only gives
> > a vague message (this could be improved, but it's already useful without
> > that) tree-tailcall usually fails without optimization, so must
> > adjust the existing must-tail plugin test to specify -O2.
> >
> > PR83324
> >
> > gcc/ChangeLog:
> >
> > * calls.cc (expand_call): Fix mustcall implementation.
> >
> > gcc/testsuite/ChangeLog:
> >
> > * gcc.dg/plugin/must-tail-call-1.c: Adjust.
> > ---
> > gcc/calls.cc | 30 ---
> > .../gcc.dg/plugin/must-tail-call-1.c | 1 +
> > 2 files changed, 21 insertions(+), 10 deletions(-)
> >
> > diff --git a/gcc/calls.cc b/gcc/calls.cc
> > index 21d78f9779fe..a6b8ee44cc29 100644
> > --- a/gcc/calls.cc
> > +++ b/gcc/calls.cc
> > @@ -2650,7 +2650,9 @@ expand_call (tree exp, rtx target, int ignore)
> >/* The type of the function being called. */
> >tree fntype;
> >bool try_tail_call = CALL_EXPR_TAILCALL (exp);
> > - bool must_tail_call = CALL_EXPR_MUST_TAIL_CALL (exp);
> > + /* tree-tailcall decided not to do tail calls. Error for the musttail
> > case. */
> > + if (!try_tail_call)
> > + maybe_complain_about_tail_call (exp, "other reasons");
> >int pass;
> >
> >/* Register in which non-BLKmode value will be returned,
> > @@ -3022,10 +3024,22 @@ expand_call (tree exp, rtx target, int ignore)
> > pushed these optimizations into -O2. Don't try if we're already
> > expanding a call, as that means we're an argument. Don't try if
> > there's cleanups, as we know there's code to follow the call. */
> > - if (currently_expanding_call++ != 0
> > - || (!flag_optimize_sibling_calls && !CALL_FROM_THUNK_P (exp))
> > - || args_size.var
> > - || dbg_cnt (tail_call) == false)
> > + if (currently_expanding_call++ != 0)
> > +{
> > + maybe_complain_about_tail_call (exp, "inside another call");
> > + try_tail_call = 0;
> > +}
> > + if (!flag_optimize_sibling_calls
> > + && !CALL_FROM_THUNK_P (exp)
> > + && !CALL_EXPR_MUST_TAIL_CALL (exp))
> > +try_tail_call = 0;
> > + if (args_size.var)
>
> If we are both inside another call and run into this we give two errors,
> but I guess that's OK ...
>
> > +{
> > + /* ??? correct message? */
> > + maybe_complain_about_tail_call (exp, "stack space needed");
>
> args_size.var != NULL_TREE means the argument size is not constant.
> I'm quite sure this is an overly conservative check.
>
> > + try_tail_call = 0;
> > +}
> > + if (dbg_cnt (tail_call) == false)
> > try_tail_call = 0;
> >
> >/* Workaround buggy C/C++ wrappers around Fortran routines with
> > @@ -3046,15 +3060,11 @@ expand_call (tree exp, rtx target, int ignore)
> > if (MEM_P (*iter))
> > {
> > try_tail_call = 0;
> > + maybe_complain_about_tail_call (exp, "hidden string length
> > argument");
>
> "hidden string length argument passed on stack"
>
> from what I read the code.
>
> > break;
> > }
> > }
> >
> > - /* If the user has marked the function as requiring tail-call
> > - optimization, attempt it. */
> > - if (must_tail_call)
> > -try_tail_call = 1;
> > -
> >/* Rest of purposes for tail call optimizations to fail. */
> >if (try_tail_call)
> > try_tail_call = can_implement_as_sibling_call_p (exp,
> > diff --git a/gcc/testsuite/gcc.dg/plugin/must-tail-call-1.c
> > b/gcc/testsuite/gcc.dg/plugin/must-tail-call-1.c
> > index 3a6d4cceaba7..44af361e2925 100644
> > --- a/gcc/testsuite/gcc.dg/plugin/must-tail-call-1.c
> > +++ b/gcc/testsuite/gcc.dg/plugin/must-tail-call-1.c
> > @@ -1,4 +1,5 @@
> > /* { dg-do compile { target tail_call } } */
> > +/* { dg-options "-O2" } */
>
> So I think this is unfortunate - I think when there's a must-tail attribute
> we should either run the tailcall pass to check the call even at -O0 or
> trust the user with correctness (hoping no optimization interfered with
> the ability to tail-call).
>
> What were the ICEs you ran into?
>
> I would guess it's for example problematic to duplicate must-tail calls?
I experimented more with this, the problem I have currently is that in
-O0 when returning a struct I get something like
D.2846 = caller3 (D.2836); [must tail call]
:
D.2836 ={v} {CLOBBER(eos)};
return D.2846;
And this always fails this check in tree-tailcall:
/* If the statement references m
[PATCH-3v2, rs6000] Implement optab_isnormal for SFDF and IEEE128
Hi,
This patch implemented optab_isnormal for SFDF and IEEE128 by
test data class instructions.
Compared with previous version, the main change is not to test
if pseudo can be created in expand and modify dg-options and
dg-finals of test cases according to reviewer's advice.
https://gcc.gnu.org/pipermail/gcc-patches/2024-April/649368.html
Bootstrapped and tested on powerpc64-linux BE and LE with no
regressions. Is it OK for trunk?
Thanks
Gui Haochen
ChangeLog
rs6000: Implement optab_isnormal for SFDF and IEEE128
gcc/
PR target/97786
* config/rs6000/vsx.md (isnormal2 for SFDF): New expand.
(isnormal2 for IEEE128): New expand.
gcc/testsuite/
PR target/97786
* gcc.target/powerpc/pr97786-7.c: New test.
* gcc.target/powerpc/pr97786-8.c: New test.
patch.diff
diff --git a/gcc/config/rs6000/vsx.md b/gcc/config/rs6000/vsx.md
index ab17178e0a8..cae30dc431e 100644
--- a/gcc/config/rs6000/vsx.md
+++ b/gcc/config/rs6000/vsx.md
@@ -5353,6 +5353,28 @@ (define_expand "isfinite2"
DONE;
})
+(define_expand "isnormal2"
+ [(use (match_operand:SI 0 "gpc_reg_operand"))
+ (use (match_operand:SFDF 1 "gpc_reg_operand"))]
+ "TARGET_HARD_FLOAT && TARGET_P9_VECTOR"
+{
+ rtx tmp = gen_reg_rtx (SImode);
+ emit_insn (gen_xststdcp (tmp, operands[1], GEN_INT (0x7f)));
+ emit_insn (gen_xorsi3 (operands[0], tmp, const1_rtx));
+ DONE;
+})
+
+(define_expand "isnormal2"
+ [(use (match_operand:SI 0 "gpc_reg_operand"))
+ (use (match_operand:IEEE128 1 "gpc_reg_operand"))]
+ "TARGET_HARD_FLOAT && TARGET_P9_VECTOR"
+{
+ rtx tmp = gen_reg_rtx (SImode);
+ emit_insn (gen_xststdcqp_ (tmp, operands[1], GEN_INT (0x7f)));
+ emit_insn (gen_xorsi3 (operands[0], tmp, const1_rtx));
+ DONE;
+})
+
;; The VSX Scalar Test Negative Quad-Precision
(define_expand "xststdcnegqp_"
[(set (match_dup 2)
diff --git a/gcc/testsuite/gcc.target/powerpc/pr97786-7.c
b/gcc/testsuite/gcc.target/powerpc/pr97786-7.c
new file mode 100644
index 000..2df472e35d4
--- /dev/null
+++ b/gcc/testsuite/gcc.target/powerpc/pr97786-7.c
@@ -0,0 +1,17 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target powerpc_vsx } */
+/* { dg-options "-O2 -mdejagnu-cpu=power9" } */
+
+int test1 (double x)
+{
+ return __builtin_isnormal (x);
+}
+
+int test2 (float x)
+{
+ return __builtin_isnormal (x);
+}
+
+/* { dg-final { scan-assembler-not {\mfcmp} } } */
+/* { dg-final { scan-assembler-times {\mxststdcsp\M} 1 } } */
+/* { dg-final { scan-assembler-times {\mxststdcdp\M} 1 } } */
diff --git a/gcc/testsuite/gcc.target/powerpc/pr97786-8.c
b/gcc/testsuite/gcc.target/powerpc/pr97786-8.c
new file mode 100644
index 000..0416970b89b
--- /dev/null
+++ b/gcc/testsuite/gcc.target/powerpc/pr97786-8.c
@@ -0,0 +1,12 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target ppc_float128_hw } */
+/* { dg-require-effective-target powerpc_vsx } */
+/* { dg-options "-O2 -mdejagnu-cpu=power9 -mabi=ieeelongdouble -Wno-psabi" } */
+
+int test1 (long double x)
+{
+ return __builtin_isnormal (x);
+}
+
+/* { dg-final { scan-assembler-not {\mxscmpuqp\M} } } */
+/* { dg-final { scan-assembler {\mxststdcqp\M} } } */
[PATCH-2v2, rs6000] Implement optab_isfinite for SFDF and IEEE128
Hi,
This patch implemented optab_isfinite for SFDF and IEEE128 by
test data class instructions.
Compared with previous version, the main change is not to test
if pseudo can be created in expand and modify dg-options and
dg-finals of test cases according to reviewer's advice.
https://gcc.gnu.org/pipermail/gcc-patches/2024-April/649346.html
Bootstrapped and tested on powerpc64-linux BE and LE with no
regressions. Is it OK for trunk?
Thanks
Gui Haochen
ChangeLog
rs6000: Implement optab_isfinite for SFDF and IEEE128
gcc/
PR target/97786
* config/rs6000/vsx.md (isfinite2 for SFDF): New expand.
(isfinite2 for IEEE128): New expand.
gcc/testsuite/
PR target/97786
* gcc.target/powerpc/pr97786-4.c: New test.
* gcc.target/powerpc/pr97786-5.c: New test.
patch.diff
diff --git a/gcc/config/rs6000/vsx.md b/gcc/config/rs6000/vsx.md
index f0cc02f7e7b..cbb538d6d86 100644
--- a/gcc/config/rs6000/vsx.md
+++ b/gcc/config/rs6000/vsx.md
@@ -5333,6 +5333,28 @@ (define_expand "isinf2"
DONE;
})
+(define_expand "isfinite2"
+ [(use (match_operand:SI 0 "gpc_reg_operand"))
+ (use (match_operand:SFDF 1 "gpc_reg_operand"))]
+ "TARGET_HARD_FLOAT && TARGET_P9_VECTOR"
+{
+ rtx tmp = gen_reg_rtx (SImode);
+ emit_insn (gen_xststdcp (tmp, operands[1], GEN_INT (0x70)));
+ emit_insn (gen_xorsi3 (operands[0], tmp, const1_rtx));
+ DONE;
+})
+
+(define_expand "isfinite2"
+ [(use (match_operand:SI 0 "gpc_reg_operand"))
+ (use (match_operand:IEEE128 1 "gpc_reg_operand"))]
+ "TARGET_HARD_FLOAT && TARGET_P9_VECTOR"
+{
+ rtx tmp = gen_reg_rtx (SImode);
+ emit_insn (gen_xststdcqp_ (tmp, operands[1], GEN_INT (0x70)));
+ emit_insn (gen_xorsi3 (operands[0], tmp, const1_rtx));
+ DONE;
+})
+
;; The VSX Scalar Test Negative Quad-Precision
(define_expand "xststdcnegqp_"
[(set (match_dup 2)
diff --git a/gcc/testsuite/gcc.target/powerpc/pr97786-4.c
b/gcc/testsuite/gcc.target/powerpc/pr97786-4.c
new file mode 100644
index 000..01faa962bd5
--- /dev/null
+++ b/gcc/testsuite/gcc.target/powerpc/pr97786-4.c
@@ -0,0 +1,17 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target powerpc_vsx } */
+/* { dg-options "-O2 -mdejagnu-cpu=power9" } */
+
+int test1 (double x)
+{
+ return __builtin_isfinite (x);
+}
+
+int test2 (float x)
+{
+ return __builtin_isfinite (x);
+}
+
+/* { dg-final { scan-assembler-not {\mfcmp} } } */
+/* { dg-final { scan-assembler-times {\mxststdcsp\M} 1 } } */
+/* { dg-final { scan-assembler-times {\mxststdcdp\M} 1 } } */
diff --git a/gcc/testsuite/gcc.target/powerpc/pr97786-5.c
b/gcc/testsuite/gcc.target/powerpc/pr97786-5.c
new file mode 100644
index 000..5fc98084274
--- /dev/null
+++ b/gcc/testsuite/gcc.target/powerpc/pr97786-5.c
@@ -0,0 +1,12 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target ppc_float128_hw } */
+/* { dg-require-effective-target powerpc_vsx } */
+/* { dg-options "-O2 -mdejagnu-cpu=power9 -mabi=ieeelongdouble -Wno-psabi" } */
+
+int test1 (long double x)
+{
+ return __builtin_isfinite (x);
+}
+
+/* { dg-final { scan-assembler-not {\mxscmpuqp\M} } } */
+/* { dg-final { scan-assembler {\mxststdcqp\M} } } */
[PATCH-1v2, rs6000] Implement optab_isinf for SFDF and IEEE128
Hi,
This patch implemented optab_isinf for SFDF and IEEE128 by test
data class instructions.
Compared with previous version, the main change is to modify
the dg-options and dg-finals of test cases according to reviewer's
advice.
https://gcc.gnu.org/pipermail/gcc-patches/2024-March/648304.html
Bootstrapped and tested on powerpc64-linux BE and LE with no
regressions. Is it OK for trunk?
Thanks
Gui Haochen
ChangeLog
rs6000: Implement optab_isinf for SFDF and IEEE128
gcc/
PR target/97786
* config/rs6000/vsx.md (isinf2 for SFDF): New expand.
(isinf2 for IEEE128): New expand.
gcc/testsuite/
PR target/97786
* gcc.target/powerpc/pr97786-1.c: New test.
* gcc.target/powerpc/pr97786-2.c: New test.
patch.diff
diff --git a/gcc/config/rs6000/vsx.md b/gcc/config/rs6000/vsx.md
index f135fa079bd..fa20fb4df91 100644
--- a/gcc/config/rs6000/vsx.md
+++ b/gcc/config/rs6000/vsx.md
@@ -5313,6 +5313,24 @@ (define_expand "xststdcp"
operands[4] = CONST0_RTX (SImode);
})
+(define_expand "isinf2"
+ [(use (match_operand:SI 0 "gpc_reg_operand"))
+ (use (match_operand:SFDF 1 "gpc_reg_operand"))]
+ "TARGET_HARD_FLOAT && TARGET_P9_VECTOR"
+{
+ emit_insn (gen_xststdcp (operands[0], operands[1], GEN_INT (0x30)));
+ DONE;
+})
+
+(define_expand "isinf2"
+ [(use (match_operand:SI 0 "gpc_reg_operand"))
+ (use (match_operand:IEEE128 1 "gpc_reg_operand"))]
+ "TARGET_HARD_FLOAT && TARGET_P9_VECTOR"
+{
+ emit_insn (gen_xststdcqp_ (operands[0], operands[1], GEN_INT (0x30)));
+ DONE;
+})
+
;; The VSX Scalar Test Negative Quad-Precision
(define_expand "xststdcnegqp_"
[(set (match_dup 2)
diff --git a/gcc/testsuite/gcc.target/powerpc/pr97786-1.c
b/gcc/testsuite/gcc.target/powerpc/pr97786-1.c
new file mode 100644
index 000..c1c4f64ee8b
--- /dev/null
+++ b/gcc/testsuite/gcc.target/powerpc/pr97786-1.c
@@ -0,0 +1,22 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target powerpc_vsx } */
+/* { dg-options "-O2 -mdejagnu-cpu=power9" } */
+
+int test1 (double x)
+{
+ return __builtin_isinf (x);
+}
+
+int test2 (float x)
+{
+ return __builtin_isinf (x);
+}
+
+int test3 (float x)
+{
+ return __builtin_isinff (x);
+}
+
+/* { dg-final { scan-assembler-not {\mfcmp} } } */
+/* { dg-final { scan-assembler-times {\mxststdcsp\M} 2 } } */
+/* { dg-final { scan-assembler-times {\mxststdcdp\M} 1 } } */
diff --git a/gcc/testsuite/gcc.target/powerpc/pr97786-2.c
b/gcc/testsuite/gcc.target/powerpc/pr97786-2.c
new file mode 100644
index 000..21d90868268
--- /dev/null
+++ b/gcc/testsuite/gcc.target/powerpc/pr97786-2.c
@@ -0,0 +1,17 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target ppc_float128_hw } */
+/* { dg-require-effective-target powerpc_vsx } */
+/* { dg-options "-O2 -mdejagnu-cpu=power9 -mabi=ieeelongdouble -Wno-psabi" } */
+
+int test1 (long double x)
+{
+ return __builtin_isinf (x);
+}
+
+int test2 (long double x)
+{
+ return __builtin_isinfl (x);
+}
+
+/* { dg-final { scan-assembler-not {\mxscmpuqp\M} } } */
+/* { dg-final { scan-assembler-times {\mxststdcqp\M} 2 } } */
Re: [PATCH 0/2] Align tight loops to solve cross cacheline issue
On Wed, May 15, 2024 at 11:30 AM Jiang, Haochen wrote:
>
> Also cc Honza and Richard since we touched generic tune.
>
> Thx,
> Haochen
>
> > -Original Message-
> > From: Haochen Jiang
> > Sent: Wednesday, May 15, 2024 11:04 AM
> > To: gcc-patches@gcc.gnu.org
> > Cc: Liu, Hongtao ; ubiz...@gmail.com
> > Subject: [PATCH 0/2] Align tight loops to solve cross cacheline issue
> >
> > Hi all,
> >
> > Recently, we have encountered several random performance regressions in
> > benchmarks commit to commit. It is caused by cross cacheline issue for tight
> > loops.
> >
> > We are trying to solve the issue by two patches. One is adjusting the loop
> > alignment for generic tune, the other is aligning tight and hot loops more
> > aggressively.
> >
> > For SPECINT, we get a 0.85% improvement overall in rates, under option
> > -O2 -march=x86-64-v3 -mtune=generic on Emerald Rapids.
> >
> > BenchMarks EMR Rates
> > 500.perlbench_r -1.21%
> > 502.gcc_r 0.78%
> > 505.mcf_r 0.00%
> > 520.omnetpp_r 0.41%
> > 523.xalancbmk_r 1.33%
> > 525.x264_r 2.83%
> > 531.deepsjeng_r 1.11%
> > 541.leela_r 0.00%
> > 548.exchange2_r 2.36%
> > 557.xz_r0.98%
> > Geomean-int 0.85%
> >
> > Side effect is that we get a 1.40% increase in codesize.
> >
> > BenchMarks EMR Codesize
> > 500.perlbench_r 0.70%
> > 502.gcc_r 0.67%
> > 505.mcf_r 3.26%
> > 520.omnetpp_r 0.31%
> > 523.xalancbmk_r 1.15%
> > 525.x264_r 1.11%
> > 531.deepsjeng_r 1.40%
> > 541.leela_r 1.31%
> > 548.exchange2_r 3.06%
> > 557.xz_r1.04%
> > Geomean-int 1.40%
> >
> > Bootstrapped and regtested on x86_64-pc-linux-gnu.
> >
> > After we committed into trunk for a month, if there isn't any unexpected
> > happen. We planned to backport it to GCC14.2.
> >
> > Thx,
> > Haochen
> >
> > Haochen Jiang (1):
> > Adjust generic loop alignment from 16:11:8 to 16 for Intel processors
For this one, current znver{1,2,3,4,5}_cost already set loop align as
16, so I think it should be fine set it to generic_cost.
> >
> > liuhongt (1):
> > Align tight&hot loop without considering max skipping bytes.
For this one, although we have seen similar growth on AMD's
processors, it's still nice to have someone from AMD to look at this
to see if it's what they need.
> >
> > gcc/config/i386/i386.cc | 148 ++-
> > gcc/config/i386/i386.md | 10 ++-
> > gcc/config/i386/x86-tune-costs.h | 2 +-
> > 3 files changed, 154 insertions(+), 6 deletions(-)
> >
> > --
> > 2.31.1
>
--
BR,
Hongtao
[r15-579 Regression] FAIL: libgomp.oacc-c++/../libgomp.oacc-c-c++-common/acc_prof-kernels-1.c -DACC_DEVICE_TYPE_host=1 -DACC_MEM_SHARED=1 -foffload=disable -O2 (test for excess errors) on Linux/x86_64
On Linux/x86_64,
a9251ab3c91c8c559d0306838575a666ae62dff4 is the first bad commit
commit a9251ab3c91c8c559d0306838575a666ae62dff4
Author: Richard Biener
Date: Thu May 16 12:35:28 2024 +0200
wrong code with points-to and volatile
caused
with GCC configured with
../../gcc/configure
--prefix=/export/users/haochenj/src/gcc-bisect/master/master/r15-579/usr
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld
--with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl
--enable-libmpx x86_64-linux --disable-bootstrap
To reproduce:
$ cd {build_dir}/x86_64-linux/libgomp/testsuite && make check
RUNTESTFLAGS="c++.exp=libgomp.oacc-c-c++-common/acc_prof-kernels-1.c
--target_board='unix{-m32}'"
$ cd {build_dir}/x86_64-linux/libgomp/testsuite && make check
RUNTESTFLAGS="c++.exp=libgomp.oacc-c-c++-common/acc_prof-kernels-1.c
--target_board='unix{-m32\ -march=cascadelake}'"
$ cd {build_dir}/x86_64-linux/libgomp/testsuite && make check
RUNTESTFLAGS="c++.exp=libgomp.oacc-c-c++-common/acc_prof-kernels-1.c
--target_board='unix{-m64}'"
$ cd {build_dir}/x86_64-linux/libgomp/testsuite && make check
RUNTESTFLAGS="c++.exp=libgomp.oacc-c-c++-common/acc_prof-kernels-1.c
--target_board='unix{-m64\ -march=cascadelake}'"
(Please do not reply to this email, for question about this report, contact me
at haochen dot jiang at intel.com.)
(If you met problems with cascadelake related, disabling AVX512F in command
line might save that.)
(However, please make sure that there is no potential problems with AVX512.)
Re: [PATCH] i386: Rename sat_plusminus expanders to standard names [PR11260]
On Fri, May 17, 2024 at 3:55 PM Uros Bizjak wrote:
>
> Rename _3 expander to a standard ssadd,
> usadd, sssub and ussub name to enable corresponding optab expansion.
>
> Also add named expander for MMX modes.
LGTM.
>
> PR middle-end/112600
>
> gcc/ChangeLog:
>
> * config/i386/mmx.md (3): New expander.
> * config/i386/sse.md
> (_3):
> Rename expander to 3.
> (3): Update for rename.
> * config/i386/i386-builtin.def (BDESC): Update for rename.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/i386/pr112600-1a.c: New test.
> * gcc.target/i386/pr112600-1b.c: New test.
>
> Bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.
>
> Uros.
--
BR,
Hongtao
Re: [PATCH 4/13] rs6000, extend the current vec_{un,}signed{e,o} built-ins
Hi Carl,
on 2024/5/18 04:20, Carl Love wrote:
> Kewen:
>
> I am working thru the patches. I made the changes as requested for this
> patch but have a question about
> one of your comments.
>
> On 5/14/24 00:53, Kewen.Lin wrote:
>> Hi,
>>
>> on 2024/4/20 05:17, Carl Love wrote:
>>> rs6000, extend the current vec_{un,}signed{e,o} built-ins
>>>
>>> The built-ins __builtin_vsx_xvcvspsxds and __builtin_vsx_xvcvspuxds
>>> convert a vector of floats to signed/unsigned long long ints. Extend the
>>> existing vec_{un,}signed{e,o} built-ins to handle the argument
>>> vector of floats to return the even/odd signed/unsigned integers.
>>>
>>> Add testcases and update documentation.
>>>
>>> gcc/ChangeLog:
>>> * config/rs6000/rs6000-builtins.def (__builtin_vsx_xvcvspsxds_low,
>>> __builtin_vsx_xvcvspuxds_low): New built-in definitions.
>>> * config/rs6000/rs6000-overload.def (vec_signede, vec_signedo):
>>> Add new overloaded specifications.
>>> * config/rs6000/vsx.md (vsx_xvcvspxds_low): New define_expand.
>>> * doc/extend.texi (vec_signedo, vec_signede): Add documentation.
>>>
>>> gcc/testsuite/ChangeLog:
>>> * gcc.target/powerpc/builtins-3-runnable: New tests for the added
>
>
>
>>
>> As the existing instances for vec_signed and vec_unsigned are with
>> names like VEC_V{UN,}SIGNED{O,E}_V2DF, I prefer these are updated
>> with similar style, maybe something like:
>>
>> VEC_V{UN,}SIGNED{E,O}_V4SF v{un,}signed{e,o}_v4sf
>
> Yes, sounds reasonable. Changed XVCVSPUXDS -> VEC_VUNSIGNEDE_V4SF
> XVCVSPUXDSO -> VEC_VUNSIGNEDO_V4SF
>XVCVSPSXDS -> VEC_VSIGNEDE_V4SF
>XVCVSPSXDSO -> VEC_VSIGNEDO_V4SF
>
> QUESTION:
> I am not sure what you want changed to v{un,}signed{e,o}_v4sf?? The
> overloaded instance entry names
It's about the expander name, just like the existing *vunsignede_v2df* and
*vunsignedo_v2df*:
const vsi __builtin_vsx_vunsignede_v2df (vd);
VEC_VUNSIGNEDE_V2DF vunsignede_v2df {}
const vsi __builtin_vsx_vunsignedo_v2df (vd);
VEC_VUNSIGNEDO_V2DF vunsignedo_v2df {}
, not for the actual builtin names, sorry for the confusion.
BR,
Kewen
> for vd, vf have to match the first line of the definition. The name can't be
> type specific, i.e. v4sf.
> So not sure where you want the v{un,}signed{e,o}_v4sf name used?
>
> For example, file rs6000-overloaded.def now looks like:
>
> [VEC_SIGNEDE, vec_signede, __builtin_vec_vsignede]
>vsi __builtin_vec_vsignede (vd);
> VEC_VSIGNEDE_V2DF
> + vsll __builtin_vec_vsignede (vf);
> +VEC_VSIGNEDE_V4SF
>
> [VEC_SIGNEDO, vec_signedo, __builtin_vec_vsignedo]
>vsi __builtin_vec_vsignedo (vd);
> VEC_VSIGNEDO_V2DF
> + vsll __builtin_vec_vsignedo (vf);
> +VEC_VSIGNEDO_V4SF
>
>
>
>
>
> Carl
RE: [PATCH v4] DSE: Fix ICE after allow vector type in get_stored_val
Committed, thanks Jeff. Let's wait for a while before backporting. Pan -Original Message- From: Jeff Law Sent: Monday, May 20, 2024 12:23 AM To: Li, Pan2 ; gcc-patches@gcc.gnu.org Cc: juzhe.zh...@rivai.ai; kito.ch...@gmail.com; Liu, Hongtao ; richard.guent...@gmail.com Subject: Re: [PATCH v4] DSE: Fix ICE after allow vector type in get_stored_val On 5/2/24 7:51 PM, pan2...@intel.com wrote: > From: Pan Li > > We allowed vector type for get_stored_val when read is less than or > equal to store in previous. Unfortunately, the valididate_subreg > treats the vector type's size is less than vector register as > invalid. Then we will have ICE here. > > This patch would like to fix it by filter-out the invalid type size, > and make sure the subreg is valid for both the read_mode and store_mode > before perform the real gen_lowpart. > > The below test suites are passed for this patch: > > * The x86 bootstrap test. > * The x86 regression test. > * The riscv rv64gcv regression test. > * The riscv rv64gc regression test. > * The aarch64 regression test. > > gcc/ChangeLog: > > * dse.cc (get_stored_val): Make sure read_mode/write_mode > is valid subreg before gen_lowpart. > > gcc/testsuite/ChangeLog: > > * gcc.target/riscv/rvv/base/bug-6.c: New test. OK for the trunk. Let's let it simmer on the trunk for a while before we consider backporting. jeff
Re: [Patch] Fortran: invoke.texi - link to OpenCoarrays.org + mention libcaf_single
On 5/19/24 02:01, Tobias Burnus wrote:
I noticed that gfortran's coarray support did not link to the
http://www.opencoarrays.org/ >
[snip]
diff --git a/gcc/fortran/invoke.texi b/gcc/fortran/invoke.texi
index 40e8e4a7cdd..78a2910b8d8 100644
--- a/gcc/fortran/invoke.texi
+++ b/gcc/fortran/invoke.texi
@@ -1753,7 +1753,10 @@ Single-image mode, i.e. @code{num_images()} is always
one.
@item @samp{lib}
Library-based coarray parallelization; a suitable GNU Fortran coarray
-library needs to be linked.
+library needs to be linked such as @url{http://opencoarrays.org}.
This would read better as
library such as @url{http://opencoarrays.org} needs to be linked.
+Alternatively, GCC's @code{libcaf_single} library can be linked,
+albeit it only supports a single image.
+
@end table
OK with that tweak.
-Sandra
Re: [to-be-committed][RISC-V] Eliminate redundant bitmanip operation
On 5/19/24 1:59 PM, Andrew Pinski wrote: On Sun, May 19, 2024 at 10:58 AM Jeff Law wrote: perl has some internal bitmap code. One of its implementation properties is that if you ask it to set a bit, the bit is first cleared. Unfortunately this is fairly hard to see in gimple/match due to type changes in the IL. But it is easy to see in the code we get from combine. So we just match the relevant cases. So looking into this from a gimple point of view, we can see the issue on x86_64 if you used explicitly `unsigned char`. We have: ``` c_8 = (unsigned char) _1; _2 = *a_10(D); c.0_3 = (signed char) _1; _4 = ~c.0_3; _12 = (unsigned char) _4; `` So for this, we could push the no_op cast from `signed char` to `unsigned char` past the `bit_not` and I think it will fix the issue on the gimple level. So something like: ``` /* Push no_op conversion past the bit_not expression if it was single use. */ (simplify (convert (bit_not:s @0)) (if (tree_nop_conversion_p (type, TREE_TYPE (@0))) (bit_not (convert @0 I'm not sure where the best place to put the conversion would be in gimple. I bet there's times when we want the conversion at the outer level and others times at the inner level. Just not sure it's going to be clear cut with either solution likely causing regressions somewhere. What we can (and probably should) do is put this simplification into simplify-rtx. It's target independent and shouldn't be hard to capture there. Jeff
Re: [pshed] testsuite, C++, Darwin: Skip cxa_atexit-6, which is not applicable.
On Sun, May 19, 2024 at 6:38 AM Iain Sandoe wrote:
>
> As per the analysis in the PR, tested on x86_64, i686 and aarch64 Darwin
> (and on x86_64 linux), pushed to trunk, thanks,
> Iain
Thanks for doing this.
Thanks,
Andrew
>
> --- 8< ---
>
> For Darwin, non-weak functions defined in a TU always bind locally
> and so cxa_atexit-6.C is not applicable here.
>
> PR testsuite/114982
>
> gcc/testsuite/ChangeLog:
>
> * g++.dg/tree-ssa/cxa_atexit-6.C: Skip for Darwin.
>
> Signed-off-by: Iain Sandoe
> ---
> gcc/testsuite/g++.dg/tree-ssa/cxa_atexit-6.C | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/gcc/testsuite/g++.dg/tree-ssa/cxa_atexit-6.C
> b/gcc/testsuite/g++.dg/tree-ssa/cxa_atexit-6.C
> index f6599a3c9f4..e22036067dd 100644
> --- a/gcc/testsuite/g++.dg/tree-ssa/cxa_atexit-6.C
> +++ b/gcc/testsuite/g++.dg/tree-ssa/cxa_atexit-6.C
> @@ -2,10 +2,14 @@
> /* { dg-require-effective-target fpic } */
> /* { dg-options "-O2 -fdump-tree-cddce1-details -fdump-tree-optimized -fPIC"
> } */
> // { dg-require-effective-target cxa_atexit }
> +/* This test is not appropriate for targets where non-weak functions defined
> + in the TU always bind locally; see PR114982. */
> +/* { dg-skip-if "PR114982" { *-*-darwin* } } */
> /* PR tree-optimization/19661 */
>
> /* The call to axexit should not be removed as A::~A() cannot be figured if
> it
> - is a pure/const function call as the function call g does not bind
> locally. */
> + is a pure/const function call for platforms where the function call g does
> + not bind locally. */
>
> __attribute__((noinline))
> void g() {}
> --
> 2.39.2 (Apple Git-143)
>
Re: [to-be-committed][RISC-V] Eliminate redundant bitmanip operation
On Sun, May 19, 2024 at 10:58 AM Jeff Law wrote: > > perl has some internal bitmap code. One of its implementation > properties is that if you ask it to set a bit, the bit is first cleared. > > > Unfortunately this is fairly hard to see in gimple/match due to type > changes in the IL. But it is easy to see in the code we get from > combine. So we just match the relevant cases. So looking into this from a gimple point of view, we can see the issue on x86_64 if you used explicitly `unsigned char`. We have: ``` c_8 = (unsigned char) _1; _2 = *a_10(D); c.0_3 = (signed char) _1; _4 = ~c.0_3; _12 = (unsigned char) _4; `` So for this, we could push the no_op cast from `signed char` to `unsigned char` past the `bit_not` and I think it will fix the issue on the gimple level. So something like: ``` /* Push no_op conversion past the bit_not expression if it was single use. */ (simplify (convert (bit_not:s @0)) (if (tree_nop_conversion_p (type, TREE_TYPE (@0))) (bit_not (convert @0 ``` Thanks, Andrew Pinski > > > > Regression tested in Ventana's CI system as well as my own. Waiting on > the Rivos CI system before moving forward. > > > > Jeff
Re: [PATCH] PHIOPT: Don't transform minmax if middle bb contains a phi [PR115143]
> Am 19.05.2024 um 01:12 schrieb Andrew Pinski :
>
> The problem here is even if last_and_only_stmt returns a statement,
> the bb might still contain a phi node which defines a ssa name
> which is used in that statement so we need to add a check to make sure
> that the phi nodes are empty for the middle bbs in both the
> `CMP?MINMAX:MINMAX` case and the `CMP?MINMAX:B` cases.
Is that single arg PHIs or do we have an extra edge into the middle BB? I
think that might be unexpected, at least costing wise. Maybe
Also to some of the replacement code we have ?
> OK for trunk and backport to all open branches since r14-3827-g30e6ee074588ba
> was backported?
> Bootstrapped and tested on x86_64_linux-gnu with no regressions.
>
Ok
Richard
>PR tree-optimization/115143
>
> gcc/ChangeLog:
>
>* tree-ssa-phiopt.cc (minmax_replacement): Check for empty
>phi nodes for middle bbs for the case where middle bb is not empty.
>
> gcc/testsuite/ChangeLog:
>
>* gcc.c-torture/compile/pr115143-1.c: New test.
>* gcc.c-torture/compile/pr115143-2.c: New test.
>* gcc.c-torture/compile/pr115143-3.c: New test.
>
> Signed-off-by: Andrew Pinski
> ---
> .../gcc.c-torture/compile/pr115143-1.c| 21 +
> .../gcc.c-torture/compile/pr115143-2.c| 30 +++
> .../gcc.c-torture/compile/pr115143-3.c| 29 ++
> gcc/tree-ssa-phiopt.cc| 12
> 4 files changed, 92 insertions(+)
> create mode 100644 gcc/testsuite/gcc.c-torture/compile/pr115143-1.c
> create mode 100644 gcc/testsuite/gcc.c-torture/compile/pr115143-2.c
> create mode 100644 gcc/testsuite/gcc.c-torture/compile/pr115143-3.c
>
> diff --git a/gcc/testsuite/gcc.c-torture/compile/pr115143-1.c
> b/gcc/testsuite/gcc.c-torture/compile/pr115143-1.c
> new file mode 100644
> index 000..5cb119ea432
> --- /dev/null
> +++ b/gcc/testsuite/gcc.c-torture/compile/pr115143-1.c
> @@ -0,0 +1,21 @@
> +/* PR tree-optimization/115143 */
> +/* This used to ICE.
> + minmax part of phiopt would transform,
> + would transform `a!=0?min(a, b) : 0` into `min(a,b)`
> + which was correct except b was defined by a phi in the inner
> + bb which was not handled. */
> +short a, d;
> +char b;
> +long c;
> +unsigned long e, f;
> +void g(unsigned long h) {
> + if (c ? e : b)
> +if (e)
> + if (d) {
> +a = f ? ({
> + unsigned long i = d ? f : 0, j = e ? h : 0;
> + i < j ? i : j;
> +}) : 0;
> + }
> +}
> +
> diff --git a/gcc/testsuite/gcc.c-torture/compile/pr115143-2.c
> b/gcc/testsuite/gcc.c-torture/compile/pr115143-2.c
> new file mode 100644
> index 000..05c3bbe9738
> --- /dev/null
> +++ b/gcc/testsuite/gcc.c-torture/compile/pr115143-2.c
> @@ -0,0 +1,30 @@
> +/* { dg-options "-fgimple" } */
> +/* PR tree-optimization/115143 */
> +/* This used to ICE.
> + minmax part of phiopt would transform,
> + would transform `a!=0?min(a, b) : 0` into `min(a,b)`
> + which was correct except b was defined by a phi in the inner
> + bb which was not handled. */
> +unsigned __GIMPLE (ssa,startwith("phiopt"))
> +foo (unsigned a, unsigned b)
> +{
> + unsigned j;
> + unsigned _23;
> + unsigned _12;
> +
> + __BB(2):
> + if (a_6(D) != 0u)
> +goto __BB3;
> + else
> +goto __BB4;
> +
> + __BB(3):
> + j_10 = __PHI (__BB2: b_11(D));
> + _23 = __MIN (a_6(D), j_10);
> + goto __BB4;
> +
> + __BB(4):
> + _12 = __PHI (__BB3: _23, __BB2: 0u);
> + return _12;
> +
> +}
> diff --git a/gcc/testsuite/gcc.c-torture/compile/pr115143-3.c
> b/gcc/testsuite/gcc.c-torture/compile/pr115143-3.c
> new file mode 100644
> index 000..53c5fb5588e
> --- /dev/null
> +++ b/gcc/testsuite/gcc.c-torture/compile/pr115143-3.c
> @@ -0,0 +1,29 @@
> +/* { dg-options "-fgimple" } */
> +/* PR tree-optimization/115143 */
> +/* This used to ICE.
> + minmax part of phiopt would transform,
> + would transform `a!=0?min(a, b) : 0` into `min(a,b)`
> + which was correct except b was defined by a phi in the inner
> + bb which was not handled. */
> +unsigned __GIMPLE (ssa,startwith("phiopt"))
> +foo (unsigned a, unsigned b)
> +{
> + unsigned j;
> + unsigned _23;
> + unsigned _12;
> +
> + __BB(2):
> + if (a_6(D) > 0u)
> +goto __BB3;
> + else
> +goto __BB4;
> +
> + __BB(3):
> + j_10 = __PHI (__BB2: b_7(D));
> + _23 = __MIN (a_6(D), j_10);
> + goto __BB4;
> +
> + __BB(4):
> + _12 = __PHI (__BB3: _23, __BB2: 0u);
> + return _12;
> +}
> diff --git a/gcc/tree-ssa-phiopt.cc b/gcc/tree-ssa-phiopt.cc
> index f166c3132cb..918cf50b589 100644
> --- a/gcc/tree-ssa-phiopt.cc
> +++ b/gcc/tree-ssa-phiopt.cc
> @@ -1925,6 +1925,10 @@ minmax_replacement (basic_block cond_bb, basic_block
> middle_bb, basic_block alt_
> || gimple_code (assign) != GIMPLE_ASSIGN)
>return false;
>
> + /* There cannot be any phi nodes in the middle bb. */
> + if (!gimple_seq_empty_p (phi_nodes (middle_bb)))
> +return false;
> +
> lhs = gimpl
[to-be-committed][RISC-V] Eliminate redundant bitmanip operation
perl has some internal bitmap code. One of its implementation
properties is that if you ask it to set a bit, the bit is first cleared.
Unfortunately this is fairly hard to see in gimple/match due to type
changes in the IL. But it is easy to see in the code we get from
combine. So we just match the relevant cases.
Regression tested in Ventana's CI system as well as my own. Waiting on
the Rivos CI system before moving forward.
Jeffgcc/
* config/riscv/bitmanip.md: Add patterns for setting a just
cleared bit or clearing a just set bit.
* config/riscv/riscv.cc (riscv_rtx_costs): Cost that RTL
properly
gcc/testsuite
* gcc.target/riscv/redundant-bitmap-1.c: New test.
* gcc.target/riscv/redundant-bitmap-2.c: New test.
* gcc.target/riscv/redundant-bitmap-3.c: New test.
diff --git a/gcc/config/riscv/bitmanip.md b/gcc/config/riscv/bitmanip.md
index 8769a6b818b..9d4247ec8b9 100644
--- a/gcc/config/riscv/bitmanip.md
+++ b/gcc/config/riscv/bitmanip.md
@@ -877,6 +877,29 @@ (define_insn_and_split ""
}"
[(set_attr "type" "bitmanip")])
+;; In theory these might be better handled with match.pd patterns, but
+;; the type changes tend to make it ugly, at least for the perl testcases
+(define_insn ""
+ [(set (match_operand:X 0 "register_operand" "=r")
+ (ior:X (and:X (rotate:X (const_int -2)
+ (match_operand:QI 1 "register_operand" "r"))
+ (match_operand:X 2 "register_operand" "r"))
+ (ashift:X (const_int 1) (match_operand:QI 3 "register_operand"
"r"]
+ "TARGET_ZBS && rtx_equal_p (operands[1], operands[3])"
+ "bset\t%0,%2,%1"
+ [(set_attr "type" "bitmanip")])
+
+(define_insn ""
+ [(set (match_operand:X 0 "register_operand" "=r")
+ (and:X (any_or:X (ashift:X (const_int 1)
+ (match_operand:QI 1 "register_operand" "r"))
+(match_operand:X 2 "register_operand" "r"))
+ (rotate:X (const_int -2)
+(match_operand:QI 3 "register_operand" "r"]
+ "TARGET_ZBS && rtx_equal_p (operands[1], operands[3])"
+ "bclr\t%0,%2,%1"
+ [(set_attr "type" "bitmanip")])
+
;; IF_THEN_ELSE: test for 2 bits of opposite polarity
(define_insn_and_split "*branch_mask_twobits_equals_singlebit"
[(set (pc)
diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
index b0a14a2a82d..78a4a1cd554 100644
--- a/gcc/config/riscv/riscv.cc
+++ b/gcc/config/riscv/riscv.cc
@@ -3712,6 +3712,22 @@ riscv_rtx_costs (rtx x, machine_mode mode, int
outer_code, int opno ATTRIBUTE_UN
return true;
}
+ /* Special case for bset followed by bclr. */
+ if (GET_CODE (x) == AND
+ && (GET_CODE (XEXP (x, 0)) == IOR
+ || GET_CODE (XEXP (x, 0)) == XOR)
+ && GET_CODE (XEXP (XEXP (x, 0), 0)) == ASHIFT
+ && XEXP (XEXP (XEXP (x, 0), 0), 0) == CONST1_RTX (word_mode)
+ && GET_CODE (XEXP (x, 1)) == ROTATE
+ && CONST_INT_P (XEXP (XEXP (x, 1), 0))
+ && INTVAL (XEXP (XEXP (x, 1), 0)) == -2
+ && rtx_equal_p (XEXP (XEXP (XEXP (x, 0), 0), 1),
+(XEXP (XEXP (x, 1), 1
+ {
+ *total = COSTS_N_INSNS (1);
+ return true;
+ }
+
gcc_fallthrough ();
case IOR:
case XOR:
@@ -3734,6 +3750,21 @@ riscv_rtx_costs (rtx x, machine_mode mode, int
outer_code, int opno ATTRIBUTE_UN
return true;
}
+ /* Special case for bclr followed by bset. */
+ if (GET_CODE (x) == IOR
+ && GET_CODE (XEXP (x, 0)) == AND
+ && GET_CODE (XEXP (XEXP (x, 0), 0)) == ROTATE
+ && CONST_INT_P (XEXP (XEXP (XEXP (x, 0), 0), 0))
+ && INTVAL (XEXP (XEXP (XEXP (x, 0), 0), 0)) == -2
+ && GET_CODE (XEXP (x, 1)) == ASHIFT
+ && XEXP (XEXP (x, 1), 0) == CONST1_RTX (word_mode)
+ && rtx_equal_p (XEXP (XEXP (XEXP (x, 0), 0), 1),
+ (XEXP (XEXP (x, 1), 1
+ {
+ *total = COSTS_N_INSNS (1);
+ return true;
+ }
+
/* Double-word operations use two single-word operations. */
*total = riscv_binary_cost (x, 1, 2);
return false;
diff --git a/gcc/testsuite/g++.target/riscv/redundant-bitmap-1.C
b/gcc/testsuite/g++.target/riscv/redundant-bitmap-1.C
new file mode 100644
index 000..85be608bdc8
--- /dev/null
+++ b/gcc/testsuite/g++.target/riscv/redundant-bitmap-1.C
@@ -0,0 +1,12 @@
+/* { dg-do compile } */
+/* { dg-options "-march=rv64gc_zbs -mabi=lp64" } */
+/* { dg-skip-if "" { *-*-* } { "-O0" "-Og" } } */
+
+void setBit(char &a, int b) {
+char c = 0x1UL << b;
+a &= ~c;
+a |= c;
+}
+
+/* { dg-final { scan-assembler-not "bclr\t" } } */
+
diff --git a/gcc/testsuite/g++.target/riscv/redundant-bitmap-2.C
b/gcc/testsuite/g++.target/riscv/redundant-bitmap-2.C
new file mode 100644
index 000..9060eb1d769
--- /dev/null
+++ b/gcc/testsuite/g++.target
Re: [PATCH v4] DSE: Fix ICE after allow vector type in get_stored_val
On 5/2/24 7:51 PM, pan2...@intel.com wrote: From: Pan Li We allowed vector type for get_stored_val when read is less than or equal to store in previous. Unfortunately, the valididate_subreg treats the vector type's size is less than vector register as invalid. Then we will have ICE here. This patch would like to fix it by filter-out the invalid type size, and make sure the subreg is valid for both the read_mode and store_mode before perform the real gen_lowpart. The below test suites are passed for this patch: * The x86 bootstrap test. * The x86 regression test. * The riscv rv64gcv regression test. * The riscv rv64gc regression test. * The aarch64 regression test. gcc/ChangeLog: * dse.cc (get_stored_val): Make sure read_mode/write_mode is valid subreg before gen_lowpart. gcc/testsuite/ChangeLog: * gcc.target/riscv/rvv/base/bug-6.c: New test. OK for the trunk. Let's let it simmer on the trunk for a while before we consider backporting. jeff
[pushed] wwwdocs: gcc-14: Fix seven typos
Pushed.
Gerald
---
htdocs/gcc-14/changes.html | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html
index dd3fea8d..6447898e 100644
--- a/htdocs/gcc-14/changes.html
+++ b/htdocs/gcc-14/changes.html
@@ -31,7 +31,7 @@ You may also want to check out our
another structure, is deprecated. Refer to
https://gcc.gnu.org/onlinedocs/gcc-14.1.0/gcc/Zero-Length.html";>
Zero Length Arrays.
- Any code relying on this extension should be modifed to ensure that
+ Any code relying on this extension should be modified to ensure that
C99 flexible array members only end up at the ends of structures.
Please use the warning option
https://gcc.gnu.org/onlinedocs/gcc-14.1.0/gcc/Warning-Options.html#index-Wflex-array-member-not-at-end";>-Wflex-array-member-not-at-end
to
@@ -111,7 +111,7 @@ You may also want to check out our
properties of functions and variables. The stack frame used by
functions marked with the attribute gets zeroed-out upon returning
or exception escaping. Scalar variables marked with the attribute
-cause functions contaning or accessing them to get stack scrubbing
+cause functions containing or accessing them to get stack scrubbing
enabled implicitly.
@@ -155,7 +155,7 @@ You may also want to check out our
can now be vectorized on a number of targets. In this first version any
input data sources must either have a statically known size at compile
time
- or the vectorizer must be able to determine based on auxillary
information
+ or the vectorizer must be able to determine based on auxiliary
information
that the accesses are aligned.
@@ -191,7 +191,7 @@ You may also want to check out our
used for allocatables and pointers using the allocate
directive and its OpenMP 5.2 replacement, the allocators
directive; files using this allocator and all files that might directly
- or indirectly (intrinisic assignment, intent(out), ...)
+ or indirectly (intrinsic assignment, intent(out), ...)
de- or reallocate such-allocated variables must be compiled with the
https://gcc.gnu.org/onlinedocs/gcc-14.1.0/gfortran/Fortran-Dialect-Options.html#index-fopenmp-allocators";
>-fopenmp-allocators option.
@@ -282,7 +282,7 @@ You may also want to check out our
with SPARK 2014.
Support for the LoongArch architecture.
Support for vxWorks 7 Cert RTP has been removed.
- Additional hardening improvements. For more information reltated to
+ Additional hardening improvements. For more information related to
hardening options, refer to
the https://gcc.gnu.org/onlinedocs/gcc-14.1.0/gcc/Instrumentation-Options.html#index-fharden-compares";>GCC
Instrumentation Options and
@@ -428,7 +428,7 @@ You may also want to check out our
-When a diagnostic occurrs involving a C++ template,
+When a diagnostic occurs involving a C++ template,
GCC will now quote the source code of the context at which
the template is instantiated ("required from here"),
rather than just print filename and line/column numbers.
@@ -1570,7 +1570,7 @@ it emits:
GCC diagnostics have been able to have execution paths associated
with them since GCC 10, but previously these were required to be
single-threaded.
-As of GCC 14, these execution paths can have multipled named threads
+As of GCC 14, these execution paths can have multiple named threads
associated with them, with each event being associated with one of the
threads.
No existing GCC diagnostics take advantage of this, but GCC plugins
--
2.45.0
Re: [PATCH] Add widening expansion of MULT_HIGHPART_EXPR for integral modes
On 5/19/24 3:40 AM, Eric Botcazou wrote: Hi, Just notice that this patch may result in some ICE when build libc++ for the riscv port, details as below. Please note not all configuration can reproduce this issue, feel free to ping me if you cannot reproduce this issue. CC more riscv port people for awareness. Sorry for the breakage, fixed thus, applied as obvious. * optabs-query.cc (can_mult_highpart_p): Test for the existence of a wider mode instead of requiring it. I had basically the same patch here, but hadn't run it through the bootstrap & regression test yesterday. Thanks for taking care of it! jeff
[pshed] testsuite, C++, Darwin: Skip cxa_atexit-6, which is not applicable.
As per the analysis in the PR, tested on x86_64, i686 and aarch64 Darwin
(and on x86_64 linux), pushed to trunk, thanks,
Iain
--- 8< ---
For Darwin, non-weak functions defined in a TU always bind locally
and so cxa_atexit-6.C is not applicable here.
PR testsuite/114982
gcc/testsuite/ChangeLog:
* g++.dg/tree-ssa/cxa_atexit-6.C: Skip for Darwin.
Signed-off-by: Iain Sandoe
---
gcc/testsuite/g++.dg/tree-ssa/cxa_atexit-6.C | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/gcc/testsuite/g++.dg/tree-ssa/cxa_atexit-6.C
b/gcc/testsuite/g++.dg/tree-ssa/cxa_atexit-6.C
index f6599a3c9f4..e22036067dd 100644
--- a/gcc/testsuite/g++.dg/tree-ssa/cxa_atexit-6.C
+++ b/gcc/testsuite/g++.dg/tree-ssa/cxa_atexit-6.C
@@ -2,10 +2,14 @@
/* { dg-require-effective-target fpic } */
/* { dg-options "-O2 -fdump-tree-cddce1-details -fdump-tree-optimized -fPIC" }
*/
// { dg-require-effective-target cxa_atexit }
+/* This test is not appropriate for targets where non-weak functions defined
+ in the TU always bind locally; see PR114982. */
+/* { dg-skip-if "PR114982" { *-*-darwin* } } */
/* PR tree-optimization/19661 */
/* The call to axexit should not be removed as A::~A() cannot be figured if it
- is a pure/const function call as the function call g does not bind locally.
*/
+ is a pure/const function call for platforms where the function call g does
+ not bind locally. */
__attribute__((noinline))
void g() {}
--
2.39.2 (Apple Git-143)
[pushed] testsuite, darwin: Compile a test without unwind frames.
Tested on i686, x86_64 Darwin, pushed to trunk, thanks
Iain
--- 8< ---
In the current Darwin implementation, we do not use .cfi_ insns
and emitted EH frames contain 'coalesced' section designations
which interfere with the scan asm.
gcc/testsuite/ChangeLog:
* gcc.dg/darwin-weakimport-3.c: Suppress unwind frames.
Signed-off-by: Iain Sandoe
---
gcc/testsuite/gcc.dg/darwin-weakimport-3.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/gcc/testsuite/gcc.dg/darwin-weakimport-3.c
b/gcc/testsuite/gcc.dg/darwin-weakimport-3.c
index a15b5b0e7cb..7e83987bad5 100644
--- a/gcc/testsuite/gcc.dg/darwin-weakimport-3.c
+++ b/gcc/testsuite/gcc.dg/darwin-weakimport-3.c
@@ -10,11 +10,12 @@
With modern linkers this is moot, since even weak symbols
are emitted into the regular sections.
- To avoid the unwind tables -fno-asynchronous-unwind-tables.
+ To avoid the unwind tables -fno-asynchronous-unwind-tables
+ and fno-unwind-tables (since EH contains coalesced data).
To ensure that we emit code for an older linker -mtarget-linker
To avoid the get_pc thunk optimise at least O1. */
-/* { dg-options "-fno-asynchronous-unwind-tables -O1 -mtarget-linker 85.2" } */
+/* { dg-options "-fno-asynchronous-unwind-tables -fno-unwind-tables -O1
-mtarget-linker 85.2" } */
/* { dg-require-weak "" } */
/* { dg-final { scan-assembler-not "coalesced" } } */
--
2.39.2 (Apple Git-143)
RE: [PATCH] Add widening expansion of MULT_HIGHPART_EXPR for integral modes
Thanks for quick response, 😉! Pan -Original Message- From: Eric Botcazou Sent: Sunday, May 19, 2024 5:40 PM To: Li, Pan2 Cc: gcc-patches@gcc.gnu.org; juzhe.zh...@rivai.ai; kito.ch...@gmail.com; Robin Dapp ; Jeff Law Subject: Re: [PATCH] Add widening expansion of MULT_HIGHPART_EXPR for integral modes Hi, > Just notice that this patch may result in some ICE when build libc++ for the > riscv port, details as below. Please note not all configuration can > reproduce this issue, feel free to ping me if you cannot reproduce this > issue. CC more riscv port people for awareness. Sorry for the breakage, fixed thus, applied as obvious. * optabs-query.cc (can_mult_highpart_p): Test for the existence of a wider mode instead of requiring it. -- Eric Botcazou
Re: [Patch] Fortran: invoke.texi - link to OpenCoarrays.org + mention libcaf_single
Hi Tobias, > OK for mainline? Seems reasonable, OK to push in 48 hours unless someone has suggestions related to wording. FX
[C PATCH, v2] Fix for redeclared enumerator initialized with different type [PR115109]
First version was flawed, as it used the wrong type.
Here is another iteration.
Bootstrapped and regression tested on x86_64.
c23: Fix for redeclared enumerator initialized with different type
[PR115109]
c23 specifies that the type of a redeclared enumerator is the one of the
previous declaration. Convert initializers with different type accordingly
and add -Woverflow warning.
2024-05-18 Martin Uecker
PR c/115109
gcc/c/
* c-decl.cc (build_enumerator): When redeclaring an
enumerator convert value to previous type. For redeclared
enumerators use underlying type for computing the next value.
gcc/testsuite/
* gcc.dg/pr115109.c: New test.
* gcc.dg/c23-tag-enum-6.c: New test.
* gcc.dg/c23-tag-enum-7.c: New test.
diff --git a/gcc/c/c-decl.cc b/gcc/c/c-decl.cc
index b691b91b3db..540927a8df6 100644
--- a/gcc/c/c-decl.cc
+++ b/gcc/c/c-decl.cc
@@ -10209,6 +10209,7 @@ build_enumerator (location_t decl_loc, location_t loc,
struct c_enum_contents *the_enum, tree name, tree value)
{
tree decl;
+ tree old_decl;
/* Validate and default VALUE. */
@@ -10268,6 +10269,24 @@ build_enumerator (location_t decl_loc, location_t loc,
definition. */
value = convert (the_enum->enum_type, value);
}
+ else if (flag_isoc23
+ && (old_decl = lookup_name_in_scope (name, current_scope))
+ && old_decl != error_mark_node
+ && TREE_TYPE (old_decl)
+ && TREE_TYPE (TREE_TYPE (old_decl))
+ && TREE_CODE (old_decl) == CONST_DECL)
+{
+ /* Enumeration constants in a redeclaration have the previous type. */
+ tree previous_type = TREE_TYPE (DECL_INITIAL (old_decl));
+ if (!int_fits_type_p (value, previous_type))
+ {
+ warning_at (loc, OPT_Woverflow,
+ "value of redeclared enumerator outside the range of "
+ "the previous type %qT", previous_type);
+ locate_old_decl (old_decl);
+ }
+ value = convert (previous_type, value);
+}
else
{
/* Even though the underlying type of an enum is unspecified, the
@@ -10334,9 +10353,14 @@ build_enumerator (location_t decl_loc, location_t loc,
false);
}
else
-the_enum->enum_next_value
- = build_binary_op (EXPR_LOC_OR_LOC (value, input_location),
-PLUS_EXPR, value, integer_one_node, false);
+{
+ /* In a redeclaration the type can already be the enumeral type. */
+ if (TREE_CODE (TREE_TYPE (value)) == ENUMERAL_TYPE)
+ value = convert (ENUM_UNDERLYING_TYPE (TREE_TYPE (value)), value);
+ the_enum->enum_next_value
+ = build_binary_op (EXPR_LOC_OR_LOC (value, input_location),
+ PLUS_EXPR, value, integer_one_node, false);
+}
the_enum->enum_overflow = tree_int_cst_lt (the_enum->enum_next_value, value);
if (the_enum->enum_overflow
&& !ENUM_FIXED_UNDERLYING_TYPE_P (the_enum->enum_type))
diff --git a/gcc/testsuite/gcc.dg/c23-tag-enum-6.c
b/gcc/testsuite/gcc.dg/c23-tag-enum-6.c
new file mode 100644
index 000..ff9ec89775e
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/c23-tag-enum-6.c
@@ -0,0 +1,14 @@
+/* { dg-do compile } */
+/* { dg-options "-std=c23" } */
+
+#include
+
+enum E : int { a = 1, b = 2 };
+enum E : int { b = _Generic(a, enum E: 2), a = 1 };
+
+enum H { x = 1 };
+enum H { x = 2UL + UINT_MAX }; /* { dg-warning "outside the range" } */
+
+enum K : int { z = 1 };
+enum K : int { z = 2UL + UINT_MAX }; /* { dg-error "outside the range" } */
+
diff --git a/gcc/testsuite/gcc.dg/c23-tag-enum-7.c
b/gcc/testsuite/gcc.dg/c23-tag-enum-7.c
new file mode 100644
index 000..4a5b4bc63f6
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/c23-tag-enum-7.c
@@ -0,0 +1,41 @@
+/* { dg-do compile }
+ * { dg-options "-std=c23" } */
+
+#include
+
+// enumerators are all representable in int
+enum E { a = 1UL, b = _Generic(a, int: 2) };
+static_assert(_Generic(a, int: 1));
+static_assert(_Generic(b, int: 1));
+enum E { a = 1UL, b = _Generic(a, int: 2) };
+static_assert(_Generic(a, int: 1));
+static_assert(_Generic(b, int: 1));
+
+// enumerators are not representable in int
+enum H { c = 1UL << (UINT_WIDTH + 1), d = 2 };
+static_assert(_Generic(c, enum H: 1));
+static_assert(_Generic(d, enum H: 1));
+enum H { c = 1UL << (UINT_WIDTH + 1), d = _Generic(c, enum H: 2) };
+static_assert(_Generic(c, enum H: 1));
+static_assert(_Generic(d, enum H: 1));
+
+// there is an overflow in the first redeclaration
+enum K { e = UINT_MAX, f, g = _Generic(e, unsigned int: 0) + _Generic(f,
unsigned long: 1) };
+static_assert(_Generic(e, enum K: 1));
+static_assert(_Generic(f, enum K: 1));
+static_assert(_Generic(g, enum K: 1));
+enum K { e = UINT_MAX, f, g = _Generic(e, enum K: 0) + _Generic(f, enum K: 1)
};
+static_assert(_Generic(e, enum K: 1));
+static_assert(_
Re: [Patch] Fortran: Fix SHAPE for zero-size arrays
Hi Tobias, > That is for https://gcc.gnu.org/PR115150 – a GCC 12/13/14/15 regression, > caused when switching from a libgomp call to inline code and missing the > corner case of zero-size arrays … OK to push, thanks. FX
Re: [PATCH] Add widening expansion of MULT_HIGHPART_EXPR for integral modes
Hi,
> Just notice that this patch may result in some ICE when build libc++ for the
> riscv port, details as below. Please note not all configuration can
> reproduce this issue, feel free to ping me if you cannot reproduce this
> issue. CC more riscv port people for awareness.
Sorry for the breakage, fixed thus, applied as obvious.
* optabs-query.cc (can_mult_highpart_p): Test for the existence of
a wider mode instead of requiring it.
--
Eric Botcazoudiff --git a/gcc/optabs-query.cc b/gcc/optabs-query.cc
index de145be7075..5149de57468 100644
--- a/gcc/optabs-query.cc
+++ b/gcc/optabs-query.cc
@@ -510,17 +510,16 @@ int
can_mult_highpart_p (machine_mode mode, bool uns_p)
{
optab op;
- scalar_int_mode int_mode;
+ scalar_int_mode int_mode, wider_mode;
op = uns_p ? umul_highpart_optab : smul_highpart_optab;
if (optab_handler (op, mode) != CODE_FOR_nothing)
return 1;
/* If the mode is integral, synth from widening or larger operations. */
- if (is_a (mode, &int_mode))
+ if (is_a (mode, &int_mode)
+ && GET_MODE_WIDER_MODE (int_mode).exists (&wider_mode))
{
- scalar_int_mode wider_mode = GET_MODE_WIDER_MODE (int_mode).require ();
-
op = uns_p ? umul_widen_optab : smul_widen_optab;
if (convert_optab_handler (op, wider_mode, mode) != CODE_FOR_nothing)
return 2;
Re: [PATCH 0/3] c++: expr-cast - C-style cast conformance [PR77465]
I noticed this patchset did not see any comment, did not get committed, and the PR is still open, so let me loop in Jason and Nathan as C++ maintainers. Ed, looking at the ChangeLog something seems missing: gcc/cp/ChangeLog: * call.c (tourney): (joust): (build_user_type_conversion_1): (reference_binding): (implicit_conversion_1): (build_user_type_conversion): : There should be a description of what changed after the colons. Can you send an updated patch? Gerald On Thu, 30 Dec 2021, Ed Catmur wrote: > This patch series improves conformance to the C++ standard for C-style casts > (explicit cast notation, [expr.cast]) in two scenarios. > > First, as discussed in CWG 909 [1], a C-style cast may invoke a user-defined > conversion (as a static_cast) followed by a const_cast; currently this is > erroneously rejected, tracked in PR77465 [2]. > > Second, a C-style cast to non-const reference to arithmetic type can and thus > should be interpreted as a static_cast reference binding to temporary > followed by a const_cast; currently it is interpreted as a reinterpret_cast > (possibly followed by const_cast). To the best of my knowledge this has not > been reported as a defect; credit to Turtlefight on Stack Overflow [3] for > analyzing the situation, drawing my attention to the above issues, and > convincing me that my interpretation was correct. Note that C-style cast to > /const/ arithmetic reference will already introduce a temporary; this patch > only changes the behavior where the reference is to non-const. > > Clearly there is the potential for miscompilation of existing code that > assumes an incorrect interpretation (reinterpret_cast); a number of existing > test cases are amended in this patch series. In consideration of this, I have > checked bootstrap (on x86_64) with no new errors, and add a warning (to > Wconversion) where a C-style cast to arithmetic reference introduces a > temporary in a situation where the user may expect a reinterpret_cast > (type-punning); this affects both the const (existing) and non-const case. > Note that this change will not affect C code compiled as C++, since that code > cannot contain user-defined conversions or references. > > In this patch series, > * 1/3 - allow C-style cast to invoke user-defined conversion followed by > const_cast, resolving PR77465; adds a test case and fixes existing test cases > which expect this to be rejected > * 2/3 - allow C-style cast to non-const reference to arithmetic type to > invoke static_cast reference binding to temporary followed by const_cast; > adds a test case and fixes existing test cases which expect reinterpret_cast > semantics > * 3/3 - add comprehensive test suite covering expr.cast scenarios, positive > and negative. > > 1. http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_closed.html#909 > 2. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77465 > 3. https://stackoverflow.com/a/70400230/567292 >
Re: [PATCH] added myself to maintainers
I don't see it in the tree/ChangeLog/... ? Gerald On Fri, 19 Aug 2022, Ondrej Kubanek via Gcc-patches wrote: > +2022-08-18 Ondrej Kubanek > + > + * MAINTAINERS: add myself. > + > 2022-07-04 Martin Liska > > * MAINTAINERS: fix sorting of names > diff --git a/MAINTAINERS b/MAINTAINERS > index 7d9aab76dd9..1a67bc6ea5c 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -486,6 +486,7 @@ Matt Kraai > > Jan Kratochvil > > Matthias Kretz > Louis Krupp > +Ondrej Kubanek > Prathamesh Kulkarni > Venkataramanan Kumar > Doug Kwan > @@ -717,6 +718,7 @@ Certificate of Origin Version 1.1. See > https://gcc.gnu.org/dco.html for more > information. > > > +Ondrej Kubanek > Matthias Kretz > Tim Lange > Jeff Law
[Patch] Fortran: Fix SHAPE for zero-size arrays
That is for https://gcc.gnu.org/PR115150 – a GCC 12/13/14/15 regression,
caused when switching from a libgomp call to inline code and missing the
corner case of zero-size arrays ...
OK for mainline + all affected branches?
Tobias
Fortran: Fix SHAPE for zero-size arrays
PR fortran/115150
gcc/fortran/ChangeLog:
* trans-intrinsic.cc (gfc_conv_intrinsic_bound): Fix SHAPE
for zero-size arrays
gcc/testsuite/ChangeLog:
* gfortran.dg/shape_12.f90: New test.
gcc/fortran/trans-intrinsic.cc | 4 ++-
gcc/testsuite/gfortran.dg/shape_12.f90 | 51 ++
2 files changed, 54 insertions(+), 1 deletion(-)
diff --git a/gcc/fortran/trans-intrinsic.cc b/gcc/fortran/trans-intrinsic.cc
index 80dc3426ab0..912c1000e18 100644
--- a/gcc/fortran/trans-intrinsic.cc
+++ b/gcc/fortran/trans-intrinsic.cc
@@ -3090,7 +3090,9 @@ gfc_conv_intrinsic_bound (gfc_se * se, gfc_expr * expr, enum gfc_isym_id op)
lbound, gfc_index_one_node);
}
else if (op == GFC_ISYM_SHAPE)
- se->expr = size;
+ se->expr = fold_build2_loc (input_location, MAX_EXPR,
+gfc_array_index_type, size,
+gfc_index_zero_node);
else
gcc_unreachable ();
diff --git a/gcc/testsuite/gfortran.dg/shape_12.f90 b/gcc/testsuite/gfortran.dg/shape_12.f90
new file mode 100644
index 000..e672e1ff9f9
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/shape_12.f90
@@ -0,0 +1,51 @@
+! { dg-do run }
+!
+! PR fortran/115150
+!
+! Check that SHAPE handles zero-sized arrays correctly
+!
+implicit none
+call one
+call two
+
+contains
+
+subroutine one
+ real,allocatable :: A(:),B(:,:)
+ allocate(a(3:0), b(5:1, 2:5))
+
+ if (any (shape(a) /= [0])) stop 1
+ if (any (shape(b) /= [0, 4])) stop 2
+ if (size(a) /= 0) stop 3
+ if (size(b) /= 0) stop 4
+ if (any (lbound(a) /= [1])) stop 5
+ if (any (lbound(b) /= [1, 2])) stop 6
+ if (any (ubound(a) /= [0])) stop 5
+ if (any (ubound(b) /= [0,5])) stop 6
+end
+
+subroutine two
+integer :: x1(10), x2(10,10)
+call f(x1, x2, -3)
+end
+
+subroutine f(y1, y2, n)
+ integer, value :: n
+ integer :: y1(1:n)
+ integer :: y2(1:n,4,2:*)
+ call g(y1, y2)
+end
+
+subroutine g(z1, z2)
+ integer :: z1(..), z2(..)
+
+ if (any (shape(z1) /= [0])) stop 1
+ if (any (shape(z2) /= [0, 4, -1])) stop 2
+ if (size(z1) /= 0) stop 3
+ if (size(z2) /= 0) stop 4
+ if (any (lbound(z1) /= [1])) stop 5
+ if (any (lbound(z2) /= [1, 1, 1])) stop 6
+ if (any (ubound(z1) /= [0])) stop 5
+ if (any (ubound(z2) /= [0, 4, -1])) stop 6
+end
+end
[Patch] Fortran: invoke.texi - link to OpenCoarrays.org + mention libcaf_single
I noticed that gfortran's coarray support did not link to the
http://www.opencoarrays.org/
As that library is needed to support parallelization, it makes sense to
have the link.
Motivated by someone claiming at ISC-HPC that GCC only supports a single
image.
And also motivated by Damian's presentation, which showed that
gfortran's coarrays could successfully run the ICAR atmospheric model
with 25,600 processes (OpenCoarrays with OpenSHMEM backend), which
definitely is more than one image :-)
I think mentioning the existing libcaf_single is still useful, even
though it is only of limited use (except that it does ship with GCC and
permits to do some testings. Especially, it is used by GCC's testsuite).
OK for mainline?
Tobias
Fortran: invoke.texi - link to OpenCoarrays.org + mention libcaf_single
gcc/fortran/ChangeLog:
* invoke.texi (fcoarray): Link to OpenCoarrays.org;
mention libcaf_single.
gcc/fortran/invoke.texi | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/gcc/fortran/invoke.texi b/gcc/fortran/invoke.texi
index 40e8e4a7cdd..78a2910b8d8 100644
--- a/gcc/fortran/invoke.texi
+++ b/gcc/fortran/invoke.texi
@@ -1753,7 +1753,10 @@ Single-image mode, i.e. @code{num_images()} is always one.
@item @samp{lib}
Library-based coarray parallelization; a suitable GNU Fortran coarray
-library needs to be linked.
+library needs to be linked such as @url{http://opencoarrays.org}.
+Alternatively, GCC's @code{libcaf_single} library can be linked,
+albeit it only supports a single image.
+
@end table
[Patch] contrib/gcc-changelog/git_update_version.py: Add ignore commit, improve diagnostic
I noticed that the last bump happened on Thursday.
* * *
The error is according to
https://gcc.gnu.org/pipermail/gccadmin/2024q2/021298.html
2024-05-19 00:17:28,643:INFO:root:cannot find a ChangeLog location in message
That's the commit
---
Revert "Revert: "Enable prange support.""
This reverts commit d7bb8eaade3cd3aa70715c8567b4d7b08098e699 and enables
prange
support again.
---
* * * The attached patch adds this commit to the ignore list and helps
with the diagnosis by showing the failing hash in the error message. OK
for mainline? Post commit: Can someone install the new version + fix the
ChangeLog for the ignored commit? * * * What I do not understand: Why does this commit get applied? I do see for both
contrib/gcc-changelog/git_check_commit.py -v -p
da73261ce7731be7f2b164f1db796878cdc23365 and
contrib/gcc-changelog/git_email.py
0001-Revert-Revert-Enable-prange-support.patch the error above. - And I
do not understand why it made it past the commit check but now fails?
Likewise for8057f9aa1f7e70490064de796d7a8d42d446caf8
Does the commit hook use an older version of the check scripts? Does it
ignore the errors? Or what goes wrong here? Any idea? Tobias
From f56b1764f2b5c2c83c6852607405e5be0a763a2c Mon Sep 17 00:00:00 2001
From: Tobias Burnus
Date: Sun, 19 May 2024 08:17:42 +0200
Subject: [PATCH] contrib/gcc-changelog/git_update_version.py: Add ignore
commit, improve diagnostic
contrib/ChangeLog:
* gcc-changelog/git_update_version.py (IGNORED_COMMITS): Add
cfceb070e2aea3cef9bd1f50d8d030c51449f45b.
(prepend_to_changelog_files): Output git hash in case of error.
diff --git a/contrib/gcc-changelog/git_update_version.py b/contrib/gcc-changelog/git_update_version.py
index 24f6c43d0b2..ec0151b83fe 100755
--- a/contrib/gcc-changelog/git_update_version.py
+++ b/contrib/gcc-changelog/git_update_version.py
@@ -41,7 +41,8 @@ IGNORED_COMMITS = (
'040e5b0edbca861196d9e2ea2af5e805769c8d5d',
'8057f9aa1f7e70490064de796d7a8d42d446caf8',
'109f1b28fc94c93096506e3df0c25e331cef19d0',
-'39f81924d88e3cc197fc3df74204c9b5e01e12f7')
+'39f81924d88e3cc197fc3df74204c9b5e01e12f7',
+'da73261ce7731be7f2b164f1db796878cdc23365')
FORMAT = '%(asctime)s:%(levelname)s:%(name)s:%(message)s'
logging.basicConfig(level=logging.INFO, format=FORMAT,
@@ -58,6 +59,7 @@ def read_timestamp(path):
def prepend_to_changelog_files(repo, folder, git_commit, add_to_git):
if not git_commit.success:
+logging.info(f"While processing {git_commit.info.hexsha}:")
for error in git_commit.errors:
logging.info(error)
raise AssertionError()
--
2.45.0
