date:20231002

[Bug middle-end/111669] New: bogus -Wnonnull in conditionally executed code

2023-10-02 Thread zfigura at codeweavers dot com via Gcc-bugs

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

Bug ID: 111669
   Summary: bogus -Wnonnull in conditionally executed code
   Product: gcc
   Version: 13.2.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zfigura at codeweavers dot com
  Target Milestone: ---

Created attachment 56032
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56032=edit
reduced testcase, compile with -O2 -Werror=nonnull

Sorry about the rather useless title, but I can't really figure out what
actually triggers this error. It seems to depend on some arcane combination of
optimizations.

I was able to reduce this down to a pretty minimal test case, attached here. It
may be possible to reduce it further but I couldn't easily find a way.

The actual code that triggers this is here [1]. lstrcpyA() and lstrcatA() are
trivial wrappers around strcpy/strcat. The NULL comes from get_search_path() at
line 192. The offending strcpy/strcat will never be reached if
GetWindowsDirectoryA() returns nonzero, which it always should. However, gcc
triggers a -Wnonnull warning anyway.

Interestingly, the original Wine code only triggers the warning with
-march=bdver2 (or other values of -march), but the reduced testcase triggers it
with no -march flags.

[1]
https://source.winehq.org/git/wine.git/blob/HEAD:/dlls/krnl386.exe16/file.c#l639

[PATCH] LoongArch: Replace UNSPEC_FCOPYSIGN with copysign RTL

2023-10-02 Thread Xi Ruoyao

When I added copysign support for LoongArch (r13-3702), we did not have
a copysign RTL insn, so I had to use UNSPEC to represent the copysign
instruction. Now the copysign RTX code has been added in r14-1586, so
this patch removes those UNSPECs, and it uses the native RTL copysign
insn.

Inspired by rs6000 patch "Cleanup: Replace UNSPEC_COPYSIGN with copysign
RTL" [1] from Michael Meissner.

[1]: https://gcc.gnu.org/pipermail/gcc-patches/2023-September/631701.html

gcc/ChangeLog:

* config/loongarch/loongarch.md (UNSPEC_FCOPYSIGN): Delete.
(copysign3): Use copysign RTL instead of UNSPEC.
---

Bootstrapped and regtested on loongarch64-linux-gnu.  Ok for trunk?

 gcc/config/loongarch/loongarch.md | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/gcc/config/loongarch/loongarch.md 
b/gcc/config/loongarch/loongarch.md
index 2b09209945b..9916c741641 100644
--- a/gcc/config/loongarch/loongarch.md
+++ b/gcc/config/loongarch/loongarch.md
@@ -37,7 +37,6 @@ (define_c_enum "unspec" [
   UNSPEC_FCLASS
   UNSPEC_FMAX
   UNSPEC_FMIN
-  UNSPEC_FCOPYSIGN
   UNSPEC_FTINT
   UNSPEC_FTINTRM
   UNSPEC_FTINTRP
@@ -1130,9 +1129,8 @@ (define_insn "abs2"
 
 (define_insn "copysign3"
   [(set (match_operand:ANYF 0 "register_operand" "=f")
-   (unspec:ANYF [(match_operand:ANYF 1 "register_operand" "f")
- (match_operand:ANYF 2 "register_operand" "f")]
-UNSPEC_FCOPYSIGN))]
+   (copysign:ANYF (match_operand:ANYF 1 "register_operand" "f")
+  (match_operand:ANYF 2 "register_operand" "f")))]
   "TARGET_HARD_FLOAT"
   "fcopysign.\t%0,%1,%2"
   [(set_attr "type" "fcopysign")
-- 
2.42.0

[Bug tree-optimization/111282] `a & (b ^ ~a)` (or `a & ~(a ^ b)`) not optimized to `a & b` in gimple

2023-10-02 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #1)
> Note we will need to detect both `a & (b ^ ~a)` and `a & ~(a ^ b)` since a
> might be comparison too.

Well and that will handle:
```
int f0(int a, int b)
{
return (~a) & (b ^ a); // ~a & b
}
```
Which we don't currently.

on the RTL level, we currently simplify that to:
(a | b) ^ a


The interesting thing is we do simplify the above in tree via the following
pattern:
/* (X | Y) ^ X -> Y & ~ X */

Re: [PATCH v3] RISC-V:Optimize the MASK opt generation

2023-10-02 Thread Kito Cheng

Proposed fix, and verified with "mawk" and "gawk -P" (gawk with posix
mode) on my linux also some other report it work on freebsd, just wait
review :)

https://gcc.gnu.org/pipermail/gcc-patches/2023-October/631785.html

On Tue, Oct 3, 2023 at 2:07 AM Jeff Law  wrote:
>
>
>
> On 10/2/23 12:03, David Edelsohn wrote:
> > On Mon, Oct 2, 2023 at 1:59 PM Jeff Law  > > wrote:
> >
> >
> >
> > On 10/2/23 11:20, David Edelsohn wrote:
> >  > Wang,
> >  >
> >  > The AWK portions of this patch broke bootstrap on AIX.
> >  >
> >  > Also, the AWK portions are common code, not RISC-V specific.  I
> > don't
> >  > see anywhere that the common portions of the patch were reviewed or
> >  > approved by anyone with authority to approve the changes to the
> > AWK files.
> >  >
> >  > This patch should not have been committed without approval by a
> > reviewer
> >  > with authority for that portion of the compiler and should have been
> >  > tested on targets other than RISC-V if common parts of the
> > compiler were
> >  > changed.
> > I acked the generic bits.  So the lack of testing on another target is
> > on me.
> >
> >
> > Hi, Jeff
> >
> > Sorry. I didn't see a comment from a global reviewer in the V3 thread.
> NP.
>
> >
> > I am using Gawk on AIX.  After the change, I see a parse error from
> > gawk.  I'm rebuilding with a checkout just before the change to confirm
> > that it was the source of the error, and it seems to be past that
> > failure location.  I didn't keep the exact error.  Once I get past this
> > build cycle, I'll reproduce it.
> I think there's already a patch circulating which fixes this.  It broke
> at least one other platform.  Hopefully it'll all be sorted out today.
>
>
> jeff

[Bug bootstrap/111664] [14 regression] Fails to build with mawk (error in gcc/opt-read.awk) after r14-4354-ge4a4b8e983bac8

2023-10-02 Thread kito at gcc dot gnu.org via Gcc-bugs

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

Kito Cheng  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2023-10-03

--- Comment #3 from Kito Cheng  ---
Proposed fix, and verified with mawk on my machine :)

https://gcc.gnu.org/pipermail/gcc-patches/2023-October/631785.html

[PATCH] RISC-V: Fix the riscv_legitimize_poly_move issue on targets where the minimal VLEN exceeds 512.

2023-10-02 Thread Kito Cheng

riscv_legitimize_poly_move was expected to ensure the poly value is at most 32
times smaller than the minimal VLEN (32 being derived from '4096 / 128').
This assumption held when our mode modeling was not so precisely defined.
However, now that we have modeled the mode size according to the correct minimal
VLEN info, the size difference between different RVV modes can be up to 64
times. For instance, comparing RVVMF64BI and RVVMF1BI, the sizes are [1, 1]
versus [64, 64] respectively.

gcc/ChangeLog:

* config/riscv/riscv.cc (riscv_legitimize_poly_move): Bump
max_power to 64.

gcc/testsuite/ChangeLog:

* g++.target/riscv/rvv/autovec/bug-01.C: New.
* g++.target/riscv/rvv/rvv.exp: Add autovec folder.
---
 gcc/config/riscv/riscv.cc |  7 ++--
 .../g++.target/riscv/rvv/autovec/bug-01.C | 33 +++
 gcc/testsuite/g++.target/riscv/rvv/rvv.exp|  3 ++
 3 files changed, 40 insertions(+), 3 deletions(-)
 create mode 100644 gcc/testsuite/g++.target/riscv/rvv/autovec/bug-01.C

diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
index d5446b63dbf..6468702e3a3 100644
--- a/gcc/config/riscv/riscv.cc
+++ b/gcc/config/riscv/riscv.cc
@@ -2386,9 +2386,10 @@ riscv_legitimize_poly_move (machine_mode mode, rtx dest, 
rtx tmp, rtx src)
 }
   else
 {
-  /* FIXME: We currently DON'T support TARGET_MIN_VLEN > 4096.  */
-  int max_power = exact_log2 (4096 / 128);
-  for (int i = 0; i < max_power; i++)
+  /* The size difference between different RVV modes can be up to 64 times.
+e.g. RVVMF64BI vs RVVMF1BI on zvl512b, which is [1, 1] vs [64, 64].  */
+  int max_power = exact_log2 (64);
+  for (int i = 0; i <= max_power; i++)
{
  int possible_div_factor = 1 << i;
  if (factor % (vlenb / possible_div_factor) == 0)
diff --git a/gcc/testsuite/g++.target/riscv/rvv/autovec/bug-01.C 
b/gcc/testsuite/g++.target/riscv/rvv/autovec/bug-01.C
new file mode 100644
index 000..fd10009ddbe
--- /dev/null
+++ b/gcc/testsuite/g++.target/riscv/rvv/autovec/bug-01.C
@@ -0,0 +1,33 @@
+/* { dg-options "-march=rv64gcv_zvl512b -mabi=lp64d -O3" } */
+
+class c {
+public:
+  int e();
+  void j();
+};
+float *d;
+class k {
+  int f;
+
+public:
+  k(int m) : f(m) {}
+  float g;
+  float h;
+  void n(int m) {
+for (int i; i < m; i++) {
+  d[0] = d[1] = d[2] = g;
+  d[3] = h;
+  d += f;
+}
+  }
+};
+c l;
+void o() {
+  int b = l.e();
+  k a(b);
+  for (;;)
+if (b == 4) {
+  l.j();
+  a.n(2);
+}
+}
diff --git a/gcc/testsuite/g++.target/riscv/rvv/rvv.exp 
b/gcc/testsuite/g++.target/riscv/rvv/rvv.exp
index 249530580d7..c30d6e93144 100644
--- a/gcc/testsuite/g++.target/riscv/rvv/rvv.exp
+++ b/gcc/testsuite/g++.target/riscv/rvv/rvv.exp
@@ -40,5 +40,8 @@ set CFLAGS "-march=$gcc_march -O3"
 dg-runtest [lsort [glob -nocomplain $srcdir/$subdir/base/*.C]] \
"" $CFLAGS
 
+dg-runtest [lsort [glob -nocomplain $srcdir/$subdir/autovec/*.\[C\]]] \
+"" $CFLAGS
+
 # All done.
 dg-finish
-- 
2.40.1

RISC-V V C Intrinsic API v1.0 release meeting reminder (October 3rd, 2023)

2023-10-02 Thread Eop Chen via Gcc

Hi all,

A reminder that the next open meeting to discuss on the RISC-V V C Intrinsic 
API v1.0 is going to
be held on 2023/10/03 7AM (GMT -7) / 10PM (GMT +8).

The agenda can be found in the second page of the meeting slides (link 
).
Please join the calendar to be constantly notified - Google calender link 
,
 ICal 

We also have a mailing list now hosted by RISC-V International (link 
).

Regards,

eop Chen

RFC: attributes documentation

2023-10-02 Thread Sandra Loosemore

When I was working on something else recently, I realized that the GCC manual 
had nothing in its attributes section saying that you could use the various 
documented GCC extension attributes with C/C++ standard attribute syntax too, 
or how (you have to use the "gnu::" prefix); I ended up finding this 
information in the release notes for GCC 10 instead.  :-(  So, minimally, I am 
going to address that.


Going beyond that, though, I think we should also document that the standard 
syntax is now the preferred way to do it, and change the examples (except for 
the parts documenting the old syntax) to use the new standard syntax.  It's 
been accepted by the default -std= setting for both C and C++ since GCC 10, and 
my understanding is that C2x will be official by the time GCC 14 is released 
(so supporting the new syntax won't be just another GNU extension any more). 
Does this sound OK to everybody?


-Sandra

Re: [RFC] expr: don't clear SUBREG_PROMOTED_VAR_P flag for a promoted subreg [target/111466]

2023-10-02 Thread Vineet Gupta





On 9/29/23 05:14, Jeff Law wrote:



On 9/28/23 21:49, Vineet Gupta wrote:


On 9/28/23 20:17, Jeff Law wrote:
I can bootstrap & regression test alpha using QEMU user mode 
emulation. So we might be able to trigger something that way. It'll 
take some time, but might prove fruitful. 


That would be awesome. It's not like this this is burning or anything 
and one of the things in the long tail of things we need to do in 
this area.
Absolutely true.  In fact, I doubt this particular quirk is all that 
important in the extension removal space.  But we've got enough data 
to do a bit of an experiment.  While it takes a long time to run, it 
doesn't require any kind of regular human intervention.  Better to 
fire it off now while it's still fresh in our minds.  If we wait a 
week or two I'll have forgotten everything.


Just as a data-point, the SPEC QEMU icount on RISC-V with this patch 
seems promising (+ve is better, lesser icount)


Baseline    subreg promoted
    note preserved   %
benchmark   workload #
500.perlbench_r 0   1222524143251   1222717055541 -0.02%
    1   741422677286    740573609468 0.11%
    2   694157786227    693787219643 0.05%
502.gcc_r   0   189519277112    188986824061 0.28%  <--
    1   224763075520    224225499491 0.24%
    2   216802546093    216426186662 0.17%
    3   179634122120    179165923074 0.26%  <--
    4   222757886491    222343753217 0.19%
503.bwaves_r    0   309660270217    309640234863 0.01%
    1   488871452301    488838894844 0.01%
    2   381243468081    381218065515 0.01%
    3   463786236849    463756755469 0.01%
505.mcf_r   0   675010417323    675014630665 0.00%
507.cactuBSSN_r 0   2856874668987   2856874679135 0.00%
508.namd_r  0   1877527849689   1877508676900 0.00%
510.parest_r    0   3479719575579   3479104891751 0.02%
511.povray_r    0   3028749801452   3030037805612 -0.04%
519.lbm_r   0   1172421269180   1172421185445 0.00%
520.omnetpp_r   0   1014838628822   1007680353306 0.71%  <--
521.wrf_r   0   3897783090826   3897162379983 0.02%
523.xalancbmk_r 0   1062577057227   1062508198843 0.01%
525.x264_r  0   451836043634    449289002218 0.56%  <--
    1   1761617424590   1758009904369 0.20%  <--
    2   1686037465791   1682815274048 0.19%  <--
526.blender_r   0   1660559350538   1660534452552 0.00%
527.cam4_r  0   2141572063843   2141254936488 0.01%
531.deepsjeng_r 0   1605692153702   1603021256993 0.17%
538.imagick_r   0   3401602661013   3401602660827 0.00%
541.leela_r 0   1989286081019   1987365526160 0.10%
544.nab_r   0   1537038165879   1528865609530 0.53%  <--
548.exchange2_r 0   2050220774922   2048840906692 0.07%
549.fotonik3d_r 0   2231807908394   2231807600916 0.00%
554.roms_r  0   2612969430882   2611529873683 0.06%
557.xz_r    0   367967125022    367760820700 0.06%
    1   961163448926    961025548415 0.01%
    2   522156857947    521939109911 0.04%
997.specrand_fr 0   413618578   413604068 0.00%
999.specrand_ir 0   413618578   413604068 0.00%

mvconst_internal splitter gated with !@ira_in_progess (was Re: Yet Another IRA question)

2023-10-02 Thread Vineet Gupta





On 9/28/23 12:52, Vineet Gupta wrote:


On 9/28/23 05:53, Jeff Law wrote:
Vineet -- assuming Vlad's patch goes in, the other obvious candidate 
for this would be the mvconst_internal define_insn_and_split where 
we'd probably want to reject the insn as a whole once IRA has started. 


Good point, although currently we've kind of papered over it with 
-fsched-pressure, but I'm sure there are way more cases that this will 
improve still.
I will spin up a full multilib test with that, hopefully with no 
fallout :-)


I have the results finally. This is testsuite neutral. Same results 
before/after


   = Summary of gcc testsuite =
    | # of unexpected case / # of unique 
unexpected case

    |  gcc |  g++ | gfortran |
   rv32imac/  ilp32/ medlow |  168 /    70 |   13 / 6 |   67 /    12 |
 rv32imafdc/ ilp32d/ medlow |  168 /    70 |   13 / 6 |   24 / 4 |
   rv64imac/   lp64/ medlow |  161 /    70 |    9 / 3 |   67 /    12 |
 rv64imafdc/  lp64d/ medlow |  160 /    69 |    5 / 2 |    6 / 1 |

But the SPEC runs are not affected at all, if anything it seems to be 
way under noise for 5 workloads.

Not sure if we still want to add the gate, your call

511.povray_r
< 3028749801452
---
> 3028749851039

521.wrf_r
< 3897783090826
---
> 3897783089025

523.xalancbmk_r
< 1062577057227
---
> 1062577053403

527.cam4_r
< 2141572063843
---
> 2141572063800

Thx,
-Vineet

[Bug c/111654] Introduce clang's invalid-noreturn warning

2023-10-02 Thread egallager at gcc dot gnu.org via Gcc-bugs

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #5 from Eric Gallager  ---
(In reply to Manuel López-Ibáñez from comment #4)
> Unfortunately, gcc does not have any patch tracking system

I thought someone was getting a patchwork installation set up? 
...ok yeah, here it is; it's being hosted on sourceware currently:
https://patchwork.sourceware.org/project/gcc/list/
(could be made a little more discoverable from gcc.gnu.org IMO)

Re: [PATCH] libiberty: Use posix_spawn in pex-unix when available.

2023-10-02 Thread Ian Lance Taylor

On Fri, Sep 29, 2023 at 12:18 PM Brendan Shanks  wrote:
>
> +  #define ERR_ON_FAILURE(ret, func) \
> +do { if (ret) { *err = ret; *errmsg = func; goto exit; } else {} } while 
> (0)

Thanks, but please don't use a macro that changes control flow.

Ian

Re: [committed] Require target lra in gcc.dg/pr108095.c

2023-10-02 Thread Jeff Law





On 10/2/23 14:42, John David Anglin wrote:

Committed to trunk.

Dave
---

Require target lra in gcc.dg/pr108095.c

2023-10-02  John David Anglin  

gcc/testsuite/ChangeLog:

* gcc.dg/pr108095.c: Require target lra.

Thanks.  I already had this in my local tree.

jeff

[Bug tree-optimization/111668] [12/13/14 Regression] vrp2 (match and simplify) introduces invalid wide signed Boolean values

2023-10-02 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |14.0
Summary|vrp2 (match and simplify)   |[12/13/14 Regression]  vrp2
   |introduces invalid wide |(match and simplify)
   |signed Boolean values   |introduces invalid wide
   ||signed Boolean values

--- Comment #3 from Andrew Pinski  ---
Since PR 110487  is a regression, this is a regression.

[Bug target/111506] RISC-V: Failed to vectorize conversion from INT64 -> _Float16

2023-10-02 Thread joseph at codesourcery dot com via Gcc-bugs

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

--- Comment #6 from joseph at codesourcery dot com  ---
On Mon, 2 Oct 2023, rdapp at gcc dot gnu.org via Gcc-bugs wrote:

> In our case the int64_t -> int32_t conversion is implementation defined when
> the source doesn't fit the target.

GCC documents the implementation-defined semantics it uses for 
out-of-range conversions from an integer type to a signed integer type.  
That does not depend on whether the conversion is vectorized or not.  And 
for conversions between floating and integer types in either direction, 
there is no conversion between two integer types involved in the abstract 
machine.

[Bug tree-optimization/111668] vrp2 (match and simplify) introduces invalid wide signed Boolean values

2023-10-02 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=110487

--- Comment #2 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #1)
> This was broken by r14-4125-g5c5851bd93b8 .

Basically that reintroduced PR 110487 .

[Bug tree-optimization/111668] vrp2 (match and simplify) introduces invalid wide signed Boolean values

2023-10-02 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|vrp2 introduces invalid |vrp2 (match and simplify)
   |wide Boolean values |introduces invalid wide
   ||signed Boolean values
   Last reconfirmed||2023-10-02
 Status|UNCONFIRMED |NEW
 CC||jakub at gcc dot gnu.org
 Ever confirmed|0   |1
   Keywords||wrong-code

--- Comment #1 from Andrew Pinski  ---
This was broken by r14-4125-g5c5851bd93b8 .


Before VRP:
```
  # RANGE [irange]  [-1, 0]
  _66 = _16 ? -1 : 0;
  vect_cst__67 = {_66, _66, _66, _66};
```

VRP2 dump:
```
Folding statement: _66 = _16 ? -1 : 0;
Applying pattern match.pd:5115, gimple-match-2.cc:16882
gimple_simplified to _38 = () _16;
_66 = -_38;
```

This is was the reasoning for the build_nonstandard_integer_type there. 


With r14-4125-g5c5851bd93b8 reverted:
```
Folding statement: _66 = _16 ? -1 : 0;
Applying pattern match.pd:5118, gimple-match-1.cc:16933
gimple_simplified to _38 = (signed int) _16;
_43 = -_38;
_66 = () _43;
Global Exported: _66 = [irange]  [-1, 0]
Folded into: _66 = () _43;
```


Note the testcase needs to compiled at -O3 on x86_64.

[Bug preprocessor/82335] Incorrect _Pragma expansion if macro passed to another macro

2023-10-02 Thread lhyatt at gcc dot gnu.org via Gcc-bugs

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

Lewis Hyatt  changed:

   What|Removed |Added

   Last reconfirmed||2023-10-02
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
 CC||lhyatt at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=90400,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=102409

--- Comment #2 from Lewis Hyatt  ---
Depending which variant of the test you look at, this ended up getting resolved
by r12-4797 and/or by r12-5454. It is the same issue as bug 102409 and bug
90400. The testcase from this PR seems worth adding in addition, so I will do
that prior to closing this one. Patch adding the testcase submitted for review
here: https://gcc.gnu.org/pipermail/gcc-patches/2023-October/631814.html

[PATCH] libcpp: testsuite: Add test for fixed _Pragma bug [PR82335]

2023-10-02 Thread Lewis Hyatt

Hello-

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82335 is another
_Pragma-related bug that got fixed in GCC 12 but is still open. Before
closing it out, I thought it would be good to add the testcase from that
PR, which we don't have exactly in the testsuite already. Is it OK please?
Thanks!

-Lewis

-- >8 --

This PR was fixed by r12-4797 and r12-5454. Add test coverage from the PR
that is not represented elsewhere.

gcc/testsuite/ChangeLog:

PR preprocessor/82335
* c-c++-common/cpp/diagnostic-pragma-3.c: New test.
---
 .../c-c++-common/cpp/diagnostic-pragma-3.c| 37 +++
 1 file changed, 37 insertions(+)
 create mode 100644 gcc/testsuite/c-c++-common/cpp/diagnostic-pragma-3.c

diff --git a/gcc/testsuite/c-c++-common/cpp/diagnostic-pragma-3.c 
b/gcc/testsuite/c-c++-common/cpp/diagnostic-pragma-3.c
new file mode 100644
index 000..459dcec73b3
--- /dev/null
+++ b/gcc/testsuite/c-c++-common/cpp/diagnostic-pragma-3.c
@@ -0,0 +1,37 @@
+/* This is like diagnostic-pragma-2.c, but handles the case where everything
+   is wrapped inside a macro, which previously caused additional issues tracked
+   in PR preprocessor/82335.  */
+
+/* { dg-do compile } */
+/* { dg-additional-options "-save-temps -Wattributes -Wtype-limits" } */
+
+#define B _Pragma("GCC diagnostic push") \
+  _Pragma("GCC diagnostic ignored \"-Wattributes\"")
+#define E _Pragma("GCC diagnostic pop")
+
+#define X() B int __attribute((unknown_attr)) x; E
+#define Y   B int __attribute((unknown_attr)) y; E
+#define WRAP(x) x
+
+void test1(void)
+{
+  WRAP(X())
+  WRAP(Y)
+}
+
+/* Additional test provided on the PR.  */
+#define PRAGMA(...) _Pragma(#__VA_ARGS__)
+#define PUSH_IGN(X) PRAGMA(GCC diagnostic push) PRAGMA(GCC diagnostic ignored 
X)
+#define POP() PRAGMA(GCC diagnostic pop)
+#define TEST(X, Y) \
+  PUSH_IGN("-Wtype-limits") \
+  int Y = (__typeof(X))-1 < 0; \
+  POP()
+
+int test2()
+{
+  unsigned x;
+  TEST(x, i1);
+  WRAP(TEST(x, i2))
+  return i1 + i2;
+}

[Bug tree-optimization/111668] New: vrp2 introduces invalid wide Boolean values

2023-10-02 Thread kristerw at gcc dot gnu.org via Gcc-bugs

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

Bug ID: 111668
   Summary: vrp2 introduces invalid wide Boolean values
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kristerw at gcc dot gnu.org
  Target Milestone: ---

The vrp2 pass introduces an invalid wide Boolean when compiling the function

  int *a, b, c, d;
  void
  foo (void)
  {
for (; d <= 0; d++)
  b &= ((a || d) ^ c) == 1;
  }

What is happening is that vrp2 changes the IR

  _Bool _16;
   _66;

  gimple_assign 

to the incorrect

  _Bool _16;
   _38;
   _66;

  gimple_assign 
  gimple_assign

Re: [PATCH] [11/12/13/14 Regression] ABI break in _Hash_node_value_base since GCC 11 [PR 111050]

2023-10-02 Thread François Dumont


Now backport to gcc-11/12/13 branches.

On 29/09/2023 11:53, Jonathan Wakely wrote:

On Thu, 28 Sept 2023 at 18:25, François Dumont  wrote:


On 28/09/2023 18:18, Jonathan Wakely wrote:

On Wed, 27 Sept 2023 at 05:44, François Dumont  wrote:

Still no chance to get feedback from TC ? Maybe I can commit the below
then ?

I've heard back from Tim now. Please use "Tim Song
" as the author.

You can change the commit again using git commit --amend --author "Tim
Song "

Sure :-)


OK for trunk with that change - thanks for waiting.

Committed to trunk, let me know for backports.

Please wait a few days in case of problems on the trunk (although I
don't expect any) and then OK for 11/12/13 too - thanks!



AFAICS on gcc mailing list several gcc releases were done recently, too
late.

There have been no releases this month, so the delay hasn't caused any problems.

I was confused by emails like this one:

https://gcc.gnu.org/pipermail/gcc/2023-September/242429.html

I just subscribed to gcc mailing list, I had no idea there were regular
snapshots like this.

[Bug libstdc++/111050] [11/12/13/14 Regression] ABI break in _Hash_node_value_base since GCC 11

2023-10-02 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

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

--- Comment #15 from CVS Commits  ---
The releases/gcc-13 branch has been updated by Francois Dumont
:

https://gcc.gnu.org/g:e6d26b141bf03a0348b51e4778c79d44dc760eed

commit r13-7931-ge6d26b141bf03a0348b51e4778c79d44dc760eed
Author: Tim Song 
Date:   Wed Sep 6 19:31:55 2023 +0200

libstdc++: Force _Hash_node_value_base methods inline to fix abi (PR111050)

   
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=1b6f0476837205932613ddb2b3429a55c26c409d
changed _Hash_node_value_base to no longer derive from _Hash_node_base,
which means
that its member functions expect _M_storage to be at a different offset. So
explosions
result if an out-of-line definition is emitted for any of the member
functions (say,
in a non-optimized build) and the resulting object file is then linked with
code built
using older version of GCC/libstdc++.

libstdc++-v3/ChangeLog:

PR libstdc++/111050
* include/bits/hashtable_policy.h
(_Hash_node_value_base<>::_M_valptr(),
_Hash_node_value_base<>::_M_v())
Add [[__gnu__::__always_inline__]].

(cherry picked from commit 2c1e3544a94c5d7354fad031e1f9731c3ce3af25)

[Bug libstdc++/111050] [11/12/13/14 Regression] ABI break in _Hash_node_value_base since GCC 11

2023-10-02 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

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

--- Comment #14 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Francois Dumont
:

https://gcc.gnu.org/g:1be57348229666c54954f1e5937cae00e113f7f1

commit r12-9903-g1be57348229666c54954f1e5937cae00e113f7f1
Author: Tim Song 
Date:   Wed Sep 6 19:31:55 2023 +0200

libstdc++: Force _Hash_node_value_base methods inline to fix abi (PR111050)

   
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=1b6f0476837205932613ddb2b3429a55c26c409d
changed _Hash_node_value_base to no longer derive from _Hash_node_base,
which means
that its member functions expect _M_storage to be at a different offset. So
explosions
result if an out-of-line definition is emitted for any of the member
functions (say,
in a non-optimized build) and the resulting object file is then linked with
code built
using older version of GCC/libstdc++.

libstdc++-v3/ChangeLog:

PR libstdc++/111050
* include/bits/hashtable_policy.h
(_Hash_node_value_base<>::_M_valptr(),
_Hash_node_value_base<>::_M_v())
Add [[__gnu__::__always_inline__]].

(cherry picked from commit 2c1e3544a94c5d7354fad031e1f9731c3ce3af25)

[committed] Add hppa--* to dg-error targets at line 5 in gfortran.dg/pr95690.f90

2023-10-02 Thread John David Anglin

Committed to trunk.

Dave
---

Add hppa*-*-* to dg-error targets at line 5

2023-10-02  John David Anglin  

gcc/testsuite/ChangeLog:

* gfortran.dg/pr95690.f90: Add hppa*-*-* to dg-error targets at line 5.

diff --git a/gcc/testsuite/gfortran.dg/pr95690.f90 
b/gcc/testsuite/gfortran.dg/pr95690.f90
index 47a5df9e894..1432937438a 100644
--- a/gcc/testsuite/gfortran.dg/pr95690.f90
+++ b/gcc/testsuite/gfortran.dg/pr95690.f90
@@ -2,8 +2,8 @@
 module m
 contains
subroutine s
-  print *, (erfc) ! { dg-error "not a floating constant" "" { target 
i?86-*-* x86_64-*-* sparc*-*-* cris-*-* } }
-   end ! { dg-error "not a floating constant" "" { target { ! "i?86-*-* 
x86_64-*-* sparc*-*-* cris-*-*" } } }
+  print *, (erfc) ! { dg-error "not a floating constant" "" { target 
i?86-*-* x86_64-*-* sparc*-*-* cris-*-* hppa*-*-* } }
+   end ! { dg-error "not a floating constant" "" { target { ! "i?86-*-* 
x86_64-*-* sparc*-*-* cris-*-* hppa*-*-*" } } }
function erfc()
end
 end


signature.asc
Description: PGP signature

[Bug libstdc++/111050] [11/12/13/14 Regression] ABI break in _Hash_node_value_base since GCC 11

2023-10-02 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

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

--- Comment #13 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Francois Dumont
:

https://gcc.gnu.org/g:50ace1f8a784d08a72edb8cb4044101fdabcc072

commit r11-11028-g50ace1f8a784d08a72edb8cb4044101fdabcc072
Author: Tim Song 
Date:   Wed Sep 6 19:31:55 2023 +0200

libstdc++: Force _Hash_node_value_base methods inline to fix abi (PR111050)

   
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=1b6f0476837205932613ddb2b3429a55c26c409d
changed _Hash_node_value_base to no longer derive from _Hash_node_base,
which means
that its member functions expect _M_storage to be at a different offset. So
explosions
result if an out-of-line definition is emitted for any of the member
functions (say,
in a non-optimized build) and the resulting object file is then linked with
code built
using older version of GCC/libstdc++.

libstdc++-v3/ChangeLog:

PR libstdc++/111050
* include/bits/hashtable_policy.h
(_Hash_node_value_base<>::_M_valptr(),
_Hash_node_value_base<>::_M_v())
Add [[__gnu__::__always_inline__]].

(cherry picked from commit 2c1e3544a94c5d7354fad031e1f9731c3ce3af25)

[committed] Require target lra in gcc.dg/pr108095.c

2023-10-02 Thread John David Anglin

Committed to trunk.

Dave
---

Require target lra in gcc.dg/pr108095.c

2023-10-02  John David Anglin  

gcc/testsuite/ChangeLog:

* gcc.dg/pr108095.c: Require target lra.

diff --git a/gcc/testsuite/gcc.dg/pr108095.c b/gcc/testsuite/gcc.dg/pr108095.c
index fb76caae72e..0a487cf614a 100644
--- a/gcc/testsuite/gcc.dg/pr108095.c
+++ b/gcc/testsuite/gcc.dg/pr108095.c
@@ -1,5 +1,5 @@
 /* PR tree-optimization/108095 */
-/* { dg-do compile } */
+/* { dg-do compile { target lra } } */
 /* { dg-options "-Os -g" } */
 
 int v;


signature.asc
Description: PGP signature

[committed] Increase timeout factor for hppa--* in gcc.dg/long_branch.c

2023-10-02 Thread John David Anglin

Committed to trunk.

Dave
---

Increase timeout factor for hppa*-*-* in gcc.dg/long_branch.c

2023-10-02  John David Anglin  

gcc/testsuite/ChangeLog:

* gcc.dg/long_branch.c: Increase timeout factor for hppa*-*-*.

diff --git a/gcc/testsuite/gcc.dg/long_branch.c 
b/gcc/testsuite/gcc.dg/long_branch.c
index c1ac24f5116..ba80ab3d15b 100644
--- a/gcc/testsuite/gcc.dg/long_branch.c
+++ b/gcc/testsuite/gcc.dg/long_branch.c
@@ -1,7 +1,7 @@
 /* { dg-do run } */
 /* { dg-options "-O2 -fno-reorder-blocks" } */
 /* { dg-skip-if "limited code space" { pdp11-*-* } } */
-/* { dg-timeout-factor 2.0 { target hppa*-*-* } } */
+/* { dg-timeout-factor 4.0 { target hppa*-*-* } } */
 
 void abort ();
 


signature.asc
Description: PGP signature

[Bug tree-optimization/111652] [14 Regression] wrong code at -O3 on x86_64-linux-gnu

2023-10-02 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Patrick Palka from comment #3)
> On x86_64 this seems to have started with r14-2852-gf5fb9ff2396fd4

I was expecting it was one of the loop splitting patches due to the ir changes
I saw

[Bug c++/111647] g++ accepts different c++ on -fchecking= anf checking=2

2023-10-02 Thread ppalka at gcc dot gnu.org via Gcc-bugs

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

Patrick Palka  changed:

   What|Removed |Added

   Keywords||accepts-invalid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-10-02
 Ever confirmed|0   |1

--- Comment #2 from Patrick Palka  ---
We probably want to diagnose this regardless of -fchecking.

Here's a similar IFNDR example that we don't diagnose even with -fchecking=2.

struct A { };

void g(A);

template
void f() {
  g(A(42));
}

[Bug preprocessor/36887] Please report #pragma GCC poison" location

2023-10-02 Thread lhyatt at gcc dot gnu.org via Gcc-bugs

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

Lewis Hyatt  changed:

   What|Removed |Added

 CC||lhyatt at gcc dot gnu.org

--- Comment #4 from Lewis Hyatt  ---
Patch submitted for review at
https://gcc.gnu.org/pipermail/gcc-patches/2023-September/630967.html

[Bug tree-optimization/111652] [14 Regression] wrong code at -O3 on x86_64-linux-gnu

2023-10-02 Thread ppalka at gcc dot gnu.org via Gcc-bugs

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

Patrick Palka  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org,
   ||ppalka at gcc dot gnu.org
   Keywords|needs-bisection |

--- Comment #3 from Patrick Palka  ---
On x86_64 this seems to have started with r14-2852-gf5fb9ff2396fd4

[PATCH] c++: merge tsubst_copy into tsubst_copy_and_build

2023-10-02 Thread Patrick Palka

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk?

-- >8 --

The relationship between tsubst_copy_and_build and tsubst_copy (two of
the main template argument substitution routines for expression trees)
is rather hazy.  The former is mostly a superset of the latter, with
some differences.

The main difference is that they handle many tree codes differently, but
much of the tree code handling in tsubst_copy appears to be dead code[1].
This is because tsubst_copy only gets directly called in a few places
and mostly on id-expressions.  The interesting exceptions are PARM_DECL,
VAR_DECL, BIT_NOT_EXPR, SCOPE_REF, TEMPLATE_ID_EXPR and IDENTIFIER_NODE:

 * for PARM_DECL and VAR_DECL, tsubst_copy_and_build calls tsubst_copy
   followed by doing some extra handling of its own
 * for BIT_NOT_EXPR tsubst_copy implicitly handles unresolved destructor
   calls (i.e. the first operand is an identifier or a type)
 * for SCOPE_REF, TEMPLATE_ID_EXPR and IDENTIFIER_NODE tsubst_copy
   refrains from doing name lookup of the terminal name

Other more minor differences are that tsubst_copy exits early when
'args' is null, and it calls maybe_dependent_member_ref, and finally
it dispatches to tsubst for type trees.

Thus tsubst_copy is (at this point) similar enough to tsubst_copy_and_build
that it makes sense to merge the two functions, with the main difference
being the name lookup behavior[2].  So this patch merges tsubst_copy into
tsubst_copy_and_build via a new tsubst tf_no_name_lookup which controls
name lookup and resolution of a (top-level) id-expression.

[1]: http://thrifty.mooo.com:8008/gcc-lcov/gcc/cp/pt.cc.gcov.html#17231
[2]: I don't know the history of tsubst_copy but I would guess it was
added before we settled on using processing_template_decl to control
whether our AST building routines perform semantic checking and return
non-templated trees, and so we needed a separate tsubst routine that
avoids semantic checking and always returns a templated tree for e.g.
partial substitution.

gcc/cp/ChangeLog:

* cp-tree.h (enum tsubst_flags): Add tf_no_name_lookup.
* pt.cc (tsubst_copy):
(tsubst_pack_expansion): Use tsubst for substituting BASES_TYPE.
(tsubst_decl) : Use tsubst_copy_and_build with
tf_no_name_lookup instead of tsubst_copy.
(tsubst) : Use tsubst_copy_and_build
instead of tsubst_copy for substituting
CLASS_PLACEHOLDER_TEMPLATE.
: Use tsubst_copy_and_build with
tf_no_name_lookup instead of tsubst_copy for substituting
TYPENAME_TYPE_FULLNAME.
(tsubst_qualified_id): Likewise for substituting the component
name of a SCOPE_REF.
(tsubst_copy): Remove.
(tsubst_copy_and_build): Clear tf_no_name_lookup at the start,
and remember if it was set.  Call maybe_dependent_member_ref.
: Don't do name lookup if tf_no_name_lookup
was set.
: Don't finish a template-id if
tf_no_name_lookup was set.
: Handle identifier and type operand (if
tf_no_name_lookup was set).
: Avoid trying to resolve a SCOPE_REF if
tf_no_name_lookup by calling build_qualified_name directly
instead of tsubst_qualified_id.
: Handling of sizeof...  copied from tsubst_copy.
: Use tsubst_copy_and_build with
tf_no_name_lookup instead of tsubst_copy to substitute
a TEMPLATE_ID_EXPR callee naming an unresolved template.
: Likewise to substitute the member.
: Copied from tsubst_copy and merged with ...
: ... these.  Initial handling copied
from tsubst_copy.  Optimize local variable substitution by
trying retrieve_local_specialization before checking
uses_template_parms.
: Copied from tsubst_copy.
: Likewise.
: Likewise.
: Likewise.
: Likewise.
: Likewise.
: Likewise.
: Likewise.
: Likewise.
: Likewise.
: Likewise.
: Likewise.
: Likewise.
: Likewise.
: Likewise.
: Use tsubst and tsubst_copy_and_build instead
of tsubst_copy.
: Copied from tsubst_copy.
(tsubst_initializer_list): Use tsubst and tsubst_copy_and_build
instead of tsubst_copy.
---
 gcc/cp/cp-tree.h |3 +
 gcc/cp/pt.cc | 1742 +++---
 2 files changed, 719 insertions(+), 1026 deletions(-)

diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index 8b9a7d58462..919eab34803 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -5619,6 +5619,9 @@ enum tsubst_flags {
   tf_qualifying_scope = 1 << 14, /* Substituting the LHS of the :: operator.
Affects TYPENAME_TYPE resolution from
make_typename_type.  */
+  tf_no_name_lookup = 1 << 15, /* Don't look up the terminal name of an
+ outermost id-expression,

[Bug bootstrap/111664] [14 regression] Fails to build with mawk (error in gcc/opt-read.awk) after r14-4354-ge4a4b8e983bac8

2023-10-02 Thread seurer at gcc dot gnu.org via Gcc-bugs

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

--- Comment #2 from seurer at gcc dot gnu.org ---
I installed gawk on the machine where it failed and the build works now.  So
definitely mawk.

[Bug middle-end/111659] document that -Wstrict-flex-arrays depends on -ftree-vrp

2023-10-02 Thread crrodriguez at opensuse dot org via Gcc-bugs

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

--- Comment #3 from Cristian Rodríguez  ---
Example code that emits no warning (in case if there is of any interest)

curl -LO https://www.netlib.org/fp/dtoa.c

gcc-14 -Og -c -Warray-bounds -fstrict-flex-arrays -Werror=strict-flex-arrays
-DIEEE_8087 dtoa.c

[Bug target/111506] RISC-V: Failed to vectorize conversion from INT64 -> _Float16

2023-10-02 Thread rdapp at gcc dot gnu.org via Gcc-bugs

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

--- Comment #5 from Robin Dapp  ---
Ah, thanks Joseph, so this at least means that we do not need
!flag_trapping_math here.

However, the vectorizer emulates the 64-bit integer to _Float16 conversion via
an intermediate int32_t and now the riscv expander does the same just without
the same restrictions.

I'm assuming the restrictions currently imposed on two-step vectorizing
conversions are correct.  For e.g. int64_t -> _Float16 we require the value
range of the source fit in int32_t (first step int64_t -> int32_t).  For
_Float16 -> int64_t we require -fno-trapping-math (first step _Float16 ->
int32_t).  The latter follows from Annex F of the C standard.

Therefore, my general question would rather be:
- Is it OK to circumvent either restriction by pretending to have an
instruction that performs the conversion in two steps but doesn't actually do
the checks?  I.e. does "implementation-defined behavior" cover the vectorizer
checking one thing and one target not doing it?

In our case the int64_t -> int32_t conversion is implementation defined when
the source doesn't fit the target.

[Bug libstdc++/111667] [C++23] Implement P1132R8, out_ptr - a scalable output pointer abstraction

2023-10-02 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2023-10-02
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
.

[pushed] contrib: Update Darwin entries in config-list.mk

2023-10-02 Thread Iain Sandoe

Although the script itself is very unlikely to be useful (it would assume
availability of both 'binutils' and a sysroot for each target) the list
is used by at least one vendor for some testing.  So I'd encourage other
port maintainers to make sure their entries are up to date!

I tested this on x86_64-linux with a script kindly shared by Martin and
it behaved as expected with an assortment of Darwin targets.  Pushed to
trunk, thanks.
Iain

--- 8< ---

This list was out of date, and included cases that are not well-supported
for cross-compilers.

This updates the list to bracket the range of OS versions we support and
to drop one earlier case where GCC will no longer build with native tools.

contrib/ChangeLog:

* config-list.mk: Add newer Darwin versions, trim one older.
Remove cases with no OS version, which is not supported for cross-
compilers.

Signed-off-by: Iain Sandoe 
---
 contrib/config-list.mk | 16 +---
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/contrib/config-list.mk b/contrib/config-list.mk
index e570b13c71b..c090be13147 100644
--- a/contrib/config-list.mk
+++ b/contrib/config-list.mk
@@ -29,7 +29,8 @@ GCC_SRC_DIR=../../gcc
 # > make.out 2>&1 &
 #
 
-LIST = aarch64-elf aarch64-freebsd13 aarch64-linux-gnu aarch64-rtems \
+LIST = \
+  aarch64-elf aarch64-freebsd13 aarch64-linux-gnu aarch64-rtems \
   alpha-linux-gnu alpha-netbsd alpha-openbsd \
   alpha64-dec-vms alpha-dec-vms \
   amdgcn-amdhsa \
@@ -47,11 +48,11 @@ LIST = aarch64-elf aarch64-freebsd13 aarch64-linux-gnu 
aarch64-rtems \
   hppa-linux-gnuOPT-enable-sjlj-exceptions=yes hppa64-linux-gnu \
   hppa64-hpux11.3 \
   hppa64-hpux11.0OPT-enable-sjlj-exceptions=yes \
-  i686-pc-linux-gnu i686-apple-darwin i686-apple-darwin9 i686-apple-darwin10 \
+  i686-apple-darwin9 i686-apple-darwin13 i686-apple-darwin17 \
   i686-freebsd13 i686-kfreebsd-gnu \
   i686-netbsdelf9 \
   i686-openbsd i686-elf i686-kopensolaris-gnu i686-gnu \
-  i686-pc-msdosdjgpp i686-lynxos i686-nto-qnx \
+  i686-pc-linux-gnu i686-pc-msdosdjgpp i686-lynxos i686-nto-qnx \
   i686-rtems i686-solaris2.11 i686-wrs-vxworks \
   i686-wrs-vxworksae \
   i686-cygwinOPT-enable-threads=yes i686-mingw32crt ia64-elf \
@@ -75,8 +76,8 @@ LIST = aarch64-elf aarch64-freebsd13 aarch64-linux-gnu 
aarch64-rtems \
   nvptx-none \
   or1k-elf or1k-linux-uclibc or1k-linux-musl or1k-rtems \
   pdp11-aout \
-  powerpc-darwin8 \
-  powerpc-darwin7 powerpc64-darwin powerpc-freebsd13 powerpc-netbsd \
+  powerpc-apple-darwin9 powerpc64-apple-darwin9 powerpc-apple-darwin8 \
+  powerpc-freebsd13 powerpc-netbsd \
   powerpc-eabisimaltivec powerpc-eabisim ppc-elf \
   powerpc-eabialtivec powerpc-xilinx-eabi powerpc-eabi \
   powerpc-rtems \
@@ -96,8 +97,9 @@ LIST = aarch64-elf aarch64-freebsd13 aarch64-linux-gnu 
aarch64-rtems \
   sparc-wrs-vxworks sparc64-elf sparc64-rtems sparc64-linux \
   sparc64-netbsd sparc64-openbsd \
   v850e1-elf v850e-elf v850-elf v850-rtems vax-linux-gnu \
-  vax-netbsdelf visium-elf x86_64-apple-darwin x86_64-gnu \
-  x86_64-pc-linux-gnuOPT-with-fpmath=avx \
+  vax-netbsdelf visium-elf \
+  x86_64-apple-darwin10 x86_64-apple-darwin15 x86_64-apple-darwin21 \
+  x86_64-gnu x86_64-pc-linux-gnuOPT-with-fpmath=avx \
   x86_64-elfOPT-with-fpmath=sse x86_64-freebsd13 x86_64-netbsd \
   x86_64-w64-mingw32 \
   x86_64-mingw32OPT-enable-sjlj-exceptions=yes x86_64-rtems \
-- 
2.39.2 (Apple Git-143)

[Bug libstdc++/111667] [C++23] Implement P1132R8, out_ptr - a scalable output pointer abstraction

2023-10-02 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug libstdc++/111667] New: [C++23] Implement P1132R8, out_ptr - a scalable output pointer abstraction

2023-10-02 Thread redi at gcc dot gnu.org via Gcc-bugs

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

Bug ID: 111667
   Summary: [C++23] Implement P1132R8, out_ptr - a scalable output
pointer abstraction
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
Blocks: 106749
  Target Milestone: ---

https://wg21.link/P1132R8


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106749
[Bug 106749] Implement C++23 library features

[Bug c/111665] internal compiler error: in c_objc_common_truthvalue_conversion

2023-10-02 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Keywords||ice-on-valid-code
   Last reconfirmed||2023-10-02
 Status|UNCONFIRMED |NEW

--- Comment #1 from Andrew Pinski  ---
Confirmed.
Also:
extern int func(void *);
int main(void)
{
[[gnu::assume(func)]];
}

[Bug fortran/111666] New: [OpenMP] Fortran FE creates too many temporaries for clauses / 'omp target'+'omp team' #teams/#threads optimize_target_teams optimization fails

2023-10-02 Thread burnus at gcc dot gnu.org via Gcc-bugs

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

Bug ID: 111666
   Summary: [OpenMP] Fortran FE creates too many temporaries for
clauses / 'omp target'+'omp team' #teams/#threads
optimize_target_teams optimization fails
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: missed-optimization, openmp
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
CC: andrewjenner at gcc dot gnu.org, jakub at gcc dot gnu.org
  Target Milestone: ---

I wonder whether trans-openmp.cc in general converts too much into temporaries.

Namely the following function. the 'gfc_evaluate_now' returns a constant as a
constant but otherwise creates a temporary:

static inline tree
gfc_convert_expr_to_tree (stmtblock_t *block, gfc_expr *expr)
{
  gfc_se se;
  tree result;

  gfc_init_se (, NULL );
  gfc_conv_expr (, expr);
  gfc_add_block_to_block (block, );
  result = gfc_evaluate_now (se.expr, block);
  gfc_add_block_to_block (block, );

  return result;
}

* * *

This bites us for something similar to libgomp.fortran/examples-4/teams-2.f90
but modified:

function dotprod (..., num_teams, block_threads)

  integer, VALUE :: num_teams, block_threads

  !$omp target map(to: B, C, block_size) ...
!$omp teams num_teams(num_teams) thread_limit(block_threads) ...


The problem is that the gfc_evaluate_now produces code like:

  D.4323 = num_teams;
  D.4324 = block_threads;
  #pragma omp teams ... num_teams(D.4323) thread_limit(D.4324)

And this is then too complex for gcc/gimplify.cc's optimize_target_teams
which no longer recognizes that num_teams and block_threads are (implicitly)
firstprivatize.

* * *

A similar issue shows up above without the VALUE attribute; this matches the
OpenMP Example document teams-2.f90 example - except that the values are passed
by reference.

(That's != libgomp.fortran/examples-4/teams-2.f90; the latter has 'map(tofrom:'
which prevents the optimize_target_teams optimization.)


In order to make that work, we would need to preserve 'num_teams(*num_teams)'
in the evaluation – and handle indirect-ref+DECL_P in optimize_target_teams.

Re: [PATCH v3] RISC-V:Optimize the MASK opt generation

2023-10-02 Thread Jeff Law

On 10/2/23 12:03, David Edelsohn wrote:
On Mon, Oct 2, 2023 at 1:59 PM Jeff Law > wrote:

On 10/2/23 11:20, David Edelsohn wrote:
 > Wang,
 >
 > The AWK portions of this patch broke bootstrap on AIX.
 >
 > Also, the AWK portions are common code, not RISC-V specific.  I
don't
 > see anywhere that the common portions of the patch were reviewed or
 > approved by anyone with authority to approve the changes to the
AWK files.
 >
 > This patch should not have been committed without approval by a
reviewer
 > with authority for that portion of the compiler and should have been
 > tested on targets other than RISC-V if common parts of the
compiler were
 > changed.
I acked the generic bits.  So the lack of testing on another target is
on me.

Hi, Jeff

Sorry. I didn't see a comment from a global reviewer in the V3 thread.

NP.

I am using Gawk on AIX.  After the change, I see a parse error from 
gawk.  I'm rebuilding with a checkout just before the change to confirm 
that it was the source of the error, and it seems to be past that 
failure location.  I didn't keep the exact error.  Once I get past this 
build cycle, I'll reproduce it.
I think there's already a patch circulating which fixes this.  It broke 
at least one other platform.  Hopefully it'll all be sorted out today.

jeff

[Bug c/111665] New: internal compiler error: in c_objc_common_truthvalue_conversion

2023-10-02 Thread nrk at disroot dot org via Gcc-bugs

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

Bug ID: 111665
   Summary: internal compiler error: in
c_objc_common_truthvalue_conversion
   Product: gcc
   Version: 13.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nrk at disroot dot org
  Target Milestone: ---

Minimal reproducer:

extern int func(void *);
int main(void)
{
__attribute__((__assume__(func)));
}

`-freport-bug` output:

// Target: x86_64-pc-linux-gnu
// Configured with:
/var/tmp/portage/sys-devel/gcc-13.2.1_p20230826/work/gcc-13-20230826/configure
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/13
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/13/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/13
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/13/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/13/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/13/include/g++-v13
--disable-silent-rules --disable-dependency-tracking
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/13/python
--enable-languages=c,c++ --enable-obsolete --enable-secureplt --disable-werror
--with-system-zlib --disable-nls --disable-libunwind-exceptions
--enable-checking=release --with-bugurl=https://bugs.gentoo.org/
--with-pkgversion='Gentoo 13.2.1_p20230826 p7' --with-gcc-major-version-only
--enable-libstdcxx-time --enable-lto --disable-libstdcxx-pch --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
--disable-multilib --with-multilib-list=m64 --disable-fixed-point
--enable-targets=all --enable-libgomp --disable-libssp --disable-libada
--disable-cet --disable-systemtap --disable-valgrind-annotations
--disable-vtable-verify --disable-libvtv --with-zstd --with-isl
--disable-isl-version-check --disable-default-pie --disable-default-ssp
--with-build-config='bootstrap-O3 bootstrap-lto'
// Thread model: posix
// Supported LTO compression algorithms: zlib zstd
// gcc version 13.2.1 20230826 (Gentoo 13.2.1_p20230826 p7) 
// 
// test.c: In function 'main':
// test.c:4:5: internal compiler error: in
c_objc_common_truthvalue_conversion, at c/c-typeck.cc:13368
// 4 | __attribute__((__assume__(func)));
//   | ^
// 0x1252094 internal_error(char const*, ...)
//  ???:0
// 0x1252166 fancy_abort(char const*, int, char const*)
//  ???:0
// 0x1acae13 c_parse_file()
//  ???:0
// 0x1ac201e c_common_parse_file()
//  ???:0
// Please submit a full bug report, with preprocessed source.
// Please include the complete backtrace with any bug report.
// See  for instructions.

// /usr/libexec/gcc/x86_64-pc-linux-gnu/13/cc1 -quiet test.c -quiet
-dumpbase test.c -dumpbase-ext .c -mtune=generic -march=x86-64 -freport-bug -o
- -frandom-seed=0 -fdump-noaddr

# 0 "test.c"
# 0 ""
# 0 ""
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 0 "" 2
# 1 "test.c"
extern int func(void *);
int main(void)
{
__attribute__((__assume__(func)));
}

Re: [PATCH v3] RISC-V:Optimize the MASK opt generation

2023-10-02 Thread David Edelsohn

On Mon, Oct 2, 2023 at 1:59 PM Jeff Law  wrote:

>
>
> On 10/2/23 11:20, David Edelsohn wrote:
> > Wang,
> >
> > The AWK portions of this patch broke bootstrap on AIX.
> >
> > Also, the AWK portions are common code, not RISC-V specific.  I don't
> > see anywhere that the common portions of the patch were reviewed or
> > approved by anyone with authority to approve the changes to the AWK
> files.
> >
> > This patch should not have been committed without approval by a reviewer
> > with authority for that portion of the compiler and should have been
> > tested on targets other than RISC-V if common parts of the compiler were
> > changed.
> I acked the generic bits.  So the lack of testing on another target is
> on me.
>

Hi, Jeff

Sorry. I didn't see a comment from a global reviewer in the V3 thread.

I am using Gawk on AIX.  After the change, I see a parse error from gawk.
I'm rebuilding with a checkout just before the change to confirm that it
was the source of the error, and it seems to be past that failure
location.  I didn't keep the exact error.  Once I get past this build
cycle, I'll reproduce it.

Thanks, David

Re: [PATCH v3] RISC-V:Optimize the MASK opt generation

2023-10-02 Thread Jeff Law





On 10/2/23 11:20, David Edelsohn wrote:

Wang,

The AWK portions of this patch broke bootstrap on AIX.

Also, the AWK portions are common code, not RISC-V specific.  I don't 
see anywhere that the common portions of the patch were reviewed or 
approved by anyone with authority to approve the changes to the AWK files.


This patch should not have been committed without approval by a reviewer 
with authority for that portion of the compiler and should have been 
tested on targets other than RISC-V if common parts of the compiler were 
changed.
I acked the generic bits.  So the lack of testing on another target is 
on me.


jeff

[Bug tree-optimization/111652] [14 Regression] wrong code at -O3 on x86_64-linux-gnu

2023-10-02 Thread tkoenig at gcc dot gnu.org via Gcc-bugs

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

Thomas Koenig  changed:

   What|Removed |Added

 CC||carll at gcc dot gnu.org

--- Comment #2 from Thomas Koenig  ---
I ran git bisect on POWER (gcc120) and strangely got this as the
first bad commit:

b51795c832cf6e724d61919eb18a383223b76694 is the first bad commit
commit b51795c832cf6e724d61919eb18a383223b76694
Author: Carl Love 
Date:   Wed Jul 26 11:31:53 2023 -0400

rs6000, fix vec_replace_unaligned built-in arguments

The first argument of the vec_replace_unaligned built-in should always be
of type vector unsigned char, as specified in gcc/doc/extend.texi.

This patch fixes the builtin definitions and updates the test cases to use
the correct arguments.  The original test file is renamed and a second test
file is added for a new test case.

This is weird because the problem also occurs on x86_64.

[Bug c++/60608] Template argument problem

2023-10-02 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||janschultke at googlemail dot 
com

--- Comment #10 from Andrew Pinski  ---
*** Bug 111662 has been marked as a duplicate of this bug. ***

[Bug c++/111662] Rejects valid: cv-qualifiers are not removed from function parameters of variadic templated function types

2023-10-02 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|UNCONFIRMED |RESOLVED

--- Comment #3 from Andrew Pinski  ---
Dup of bug 60608.

*** This bug has been marked as a duplicate of bug 60608 ***

[Bug target/111506] RISC-V: Failed to vectorize conversion from INT64 -> _Float16

2023-10-02 Thread joseph at codesourcery dot com via Gcc-bugs

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

--- Comment #4 from joseph at codesourcery dot com  ---
Conversion from 64-bit integers for _Float16 is fully defined, it produces 
the correctly rounded result according to the current rounding direction 
(round-to-nearest may be assumed in the absence of -frounding-math), which 
may be an infinity (depending on the rounding mode) in case of overflow 
(and in particular, anything not representable in a 32-bit integer 
certainly overflows on conversion to _Float16).  That's just the same as 
for any integer-to-floating conversions.

[Bug middle-end/51446] -fno-trapping-math generates NaN constant with different sign

2023-10-02 Thread joseph at codesourcery dot com via Gcc-bugs

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

--- Comment #22 from joseph at codesourcery dot com  ---
On Mon, 2 Oct 2023, eggert at cs dot ucla.edu via Gcc-bugs wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51446
> 
> --- Comment #20 from Paul Eggert  ---
> (In reply to jos...@codesourcery.com from comment #14)
> > This is just the same as other unspecified things like converting an 
> > out-of-range value from floating-point to integer.
> No, because when GCC's constant folding disagrees with machine arithmetic, GCC
> can generate code that violates the relevant standards.

The issue you describe is orthogonal to my comment in this bug.  The 
unspecified cases - both the one I mentioned in my comment and the one in 
the description of this bug - do not require any particular result (choice 
of quiet NaN, choice of value for out-of-range conversion to integer, 
etc.), and in particular do not require a result that could be generated 
by the hardware being used, but they do require that, for each evaluation 
of such an operation in the abstract machine, the implementation behaves 
as if some particular valid choice of result was made for that evaluation; 
wobbly values (some uses of the result behaving as if one choice of value 
were made and other uses behaving as if some other choice were made) are 
not permitted.  (This is similar to the question of whether use of 
uninitialized variables (if not undefined behavior) can produce a wobbly 
value, as such a value naturally results from optimizing a PHI node with 
one uninitialized operand to the value of the other operand.)

Re: [PATCH v3] RISC-V:Optimize the MASK opt generation

2023-10-02 Thread David Edelsohn

Wang,

The AWK portions of this patch broke bootstrap on AIX.

Also, the AWK portions are common code, not RISC-V specific.  I don't see
anywhere that the common portions of the patch were reviewed or approved by
anyone with authority to approve the changes to the AWK files.

This patch should not have been committed without approval by a reviewer
with authority for that portion of the compiler and should have been tested
on targets other than RISC-V if common parts of the compiler were changed.

Thanks, David

Re: Question about function splitting

2023-10-02 Thread Hanke Zhang via Gcc

Martin Jambor  于2023年10月3日周二 00:34写道：
>
> Hello,
>
> On Mon, Oct 02 2023, Hanke Zhang via Gcc wrote:
> > Hi, I have some questions about the strategy and behavior of function
> > splitting in gcc, like the following code:
> >
> > int glob;
> > void f() {
> >   if (glob) {
> > printf("short path\n");
> > return;
> >   }
> >   // do lots of expensive things
> >   // ...
> > }
> >
> > I hope it can be broken down like below, so that the whole function
> > can perhaps be inlined, which is more efficient.
> >
> > int glob;
> > void f() {
> >   if (glob) {
> > printf("short path\n");
> > return;
> >   }
> >   f_part();
> > }
> >
> > void f_part() {
> >   // do lots of expensive things
> >   // ...
> > }
> >
> >
> > But on the contrary, gcc splits it like these, which not only does not
> > bring any benefits, but may increase the time consumption, because the
> > function call itself is a more resource-intensive thing.
> >
> > int glob;
> > void f() {
> >   if (glob) {
> > f_part();
> > return;
> >   }
> >   // do lots of expensive things
> >   // ...
> > }
> >
> > void f_part() {
> >   printf("short path\n"); // just do this
> > }
> >
> > Are there any options I can offer to gcc to change this behavior? Or
> > do I need to make some changes in ipa-split.cc?
>
> I'd suggest you file a bug to Bugzilla with a specific example that is
> mis-handled, then we can have a look and discuss what and why happens
> and what can be done about it.
>
> Thanks,
>
> Martin

Hi, thanks for your reply.

I'm trying to create an account right now. And I put a copy of the
example code here in case someone is interested.

And I'm using gcc 12.3.0. When you complie the code below via 'gcc
test.c -O3 -flto -fdump-tree-fnsplit', you will find a phenomenon that
is consistent with what I described above in the gimple which is
dumped from fnsplit.

#include 
#include 

int opstatus;
unsigned char *objcode = 0;
unsigned long position = 0;
char *globalfile;

int test_split_write(char *file) {
  FILE *fhd;

  if (!opstatus) {
// short path here
printf("Object code generation not active! Forgot to call "
   "quantum_objcode_start?\n");
return 1;
  }

  if (!file)
file = globalfile;

  fhd = fopen(file, "w");

  if (fhd == 0)
return -1;

  fwrite(objcode, position, 1, fhd);

  fclose(fhd);

  int *arr = malloc(1000);
  for (int i = 0; i < 1000; i++) {
arr[i] = rand();
  }

  return 0;
}

// to avoid `test_split_write` inlining into main
void __attribute__((noinline)) call() { test_split_write("./txt"); }

int main() {
  opstatus = rand();
  objcode = malloc(100);
  position = 0;
  call();
  return 0;
}

Re: [PATCH v2] ARM: Block predication on atomics [PR111235]

2023-10-02 Thread Wilco Dijkstra

Hi Ramana,

>> I used --target=arm-none-linux-gnueabihf --host=arm-none-linux-gnueabihf
>> --build=arm-none-linux-gnueabihf --with-float=hard. However it seems that the
>> default armhf settings are incorrect. I shouldn't need the --with-float=hard 
>> since
>> that is obviously implied by armhf, and they should also imply armv7-a with 
>> vfpv3
>> according to documentation. It seems to get confused and skip some tests. I 
>> tried
>> using --with-fpu=auto, but that doesn't work at all, so in the end I forced 
>> it like:
>> --with-arch=armv8-a --with-fpu=neon-fp-armv8. With this it runs a few more 
>> tests.
> 
> Yeah that's a wart that I don't like.
> 
> armhf just implies the hard float ABI and came into being to help
> distinguish from the Base PCS for some of the distros at the time
> (2010s). However we didn't want to set a baseline arch at that time
> given the imminent arrival of v8-a and thus the specification of
> --with-arch , --with-fpu and --with-float became second nature to many
> of us working on it at that time.

Looking at it, the default is indeed incorrect, you get:
'-mcpu=arm10e' '-mfloat-abi=hard' '-marm' '-march=armv5te+fp'

That's like 25 years out of date!

However all the armhf distros have Armv7-a as the baseline and use Thumb-2:
'-mfloat-abi=hard' '-mthumb' '-march=armv7-a+fp'

So the issue is that dg-require-effective-target arm_arch_v7a_ok doesn't work on
armhf. It seems that if you specify an architecture even with hard-float 
configured,
it turns off FP and then complains because hard-float implies you must have 
FP...

So in most configurations Iincluding the one used by distro compilers) we 
basically
skip lots of tests for no apparent reason...

> Ok, thanks for promising to do so - I trust you to get it done. Please
> try out various combinations of -march v7ve, v7-a , v8-a with the tool
> as each of them have slightly different rules. For instance v7ve
> allows LDREXD and STREXD to be single copy atomic for 64 bit loads
> whereas v7-a did not .

You mean LDRD may be generated on CPUs with LPAE. We use LDREXD by
default since that is always atomic on v7-a.

> Ok if no regressions but as you might get nagged by the post commit CI ...

Thanks, I've committed it. Those links don't show anything concrete, however I 
do note
the CI didn't pick up v2.

Btw you're happy with backports if there are no issues reported for a few days?

Cheers,
Wilco

Re: [PATCH] Fix coroutine tests for libstdc++ gnu-version-namespace mode

2023-10-02 Thread François Dumont via Gcc


Hi

Gentle reminder for this minor patch.

Thanks

On 23/09/2023 22:10, François Dumont wrote:
I'm eventually fixing those tests the same way we manage this problem 
in libstdc++ testsuite.


   testsuite: Add optional libstdc++ version namespace in expected 
diagnostic


    When libstdc++ is build with 
--enable-symvers=gnu-versioned-namespace diagnostics are

    showing this namespace, currently __8.

    gcc/testsuite/ChangeLog:

    * 
testsuite/g++.dg/coroutines/coro-bad-alloc-00-bad-op-new.C: Add optional

    '__8' version namespace in expected diagnostic.
    * 
testsuite/g++.dg/coroutines/coro-bad-alloc-01-bad-op-del.C: Likewise.
    * 
testsuite/g++.dg/coroutines/coro-bad-alloc-02-no-op-new-nt.C: Likewise.
    * 
testsuite/g++.dg/coroutines/coro-bad-grooaf-01-grooaf-expected.C: 
Likewise.

    * testsuite/g++.dg/coroutines/pr97438.C: Likewise.
    * testsuite/g++.dg/coroutines/ramp-return-b.C: Likewise.

Tested under Linux x86_64.

I'm contributing to libstdc++ so I already have write access.

Ok to commit ?

François

Re: [PATCH] Fix coroutine tests for libstdc++ gnu-version-namespace mode

2023-10-02 Thread François Dumont


Hi

Gentle reminder for this minor patch.

Thanks

On 23/09/2023 22:10, François Dumont wrote:
I'm eventually fixing those tests the same way we manage this problem 
in libstdc++ testsuite.


   testsuite: Add optional libstdc++ version namespace in expected 
diagnostic


    When libstdc++ is build with 
--enable-symvers=gnu-versioned-namespace diagnostics are

    showing this namespace, currently __8.

    gcc/testsuite/ChangeLog:

    * 
testsuite/g++.dg/coroutines/coro-bad-alloc-00-bad-op-new.C: Add optional

    '__8' version namespace in expected diagnostic.
    * 
testsuite/g++.dg/coroutines/coro-bad-alloc-01-bad-op-del.C: Likewise.
    * 
testsuite/g++.dg/coroutines/coro-bad-alloc-02-no-op-new-nt.C: Likewise.
    * 
testsuite/g++.dg/coroutines/coro-bad-grooaf-01-grooaf-expected.C: 
Likewise.

    * testsuite/g++.dg/coroutines/pr97438.C: Likewise.
    * testsuite/g++.dg/coroutines/ramp-return-b.C: Likewise.

Tested under Linux x86_64.

I'm contributing to libstdc++ so I already have write access.

Ok to commit ?

François

[Bug preprocessor/90400] _Pragma not always expanded in the right location within macros

2023-10-02 Thread lhyatt at gcc dot gnu.org via Gcc-bugs

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

Lewis Hyatt  changed:

   What|Removed |Added

 CC||paboyle at ph dot ed.ac.uk

--- Comment #11 from Lewis Hyatt  ---
*** Bug 91517 has been marked as a duplicate of this bug. ***

[Bug preprocessor/91517] Pragma expansion in variadic macro reorders pragmas and breaks code

2023-10-02 Thread lhyatt at gcc dot gnu.org via Gcc-bugs

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

Lewis Hyatt  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE
 CC||lhyatt at gcc dot gnu.org

--- Comment #6 from Lewis Hyatt  ---
Same issue as bug 90400... was resolved as well by r12-5454.

*** This bug has been marked as a duplicate of bug 90400 ***

[Bug c++/109227] coroutines: ICE in tree check: expected record_type or union_type or qual_union_type, have array_type in build_special_member_call, at cp/call.cc:11067

2023-10-02 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

--- Comment #5 from Andrew Pinski  ---
Created attachment 56031
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56031=edit
More reduced testcase from the dup

[Bug c++/109227] coroutines: ICE in tree check: expected record_type or union_type or qual_union_type, have array_type in build_special_member_call, at cp/call.cc:11067

2023-10-02 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||redboltz at gmail dot com

--- Comment #4 from Andrew Pinski  ---
*** Bug 110913 has been marked as a duplicate of this bug. ***

[Bug c++/110913] internal compiler error when I pass temporary vector of string to co_await target function

2023-10-02 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #6 from Andrew Pinski  ---
Dup of bug 109227.

*** This bug has been marked as a duplicate of bug 109227 ***

RE: [ARC PATCH] Use rlc r0, 0 to implement scc_ltu (i.e. carry_flag ? 1 : 0)

2023-10-02 Thread Claudiu Zissulescu

Hi Roger,

Everything is good. Ok for mainline.

Thank you for your contribution,
Claudiu

-Original Message-
From: Claudiu Zissulescu 
Sent: Sunday, October 1, 2023 5:33 PM
To: Jeff Law ; Roger Sayle 
Cc: gcc-patches@gcc.gnu.org
Subject: RE: [ARC PATCH] Use rlc r0, 0 to implement scc_ltu (i.e. carry_flag ? 
1 : 0)

I'll add it to our nightly. Just to be sure  I’ll let you know asap it's 
status.

Roger, you can always use Synopsys free nsim simulator which you can find it on 
Synopsys website.

Thanks,
Claudiu


-Original Message-
From: Jeff Law  
Sent: Saturday, September 30, 2023 1:02 AM
To: Roger Sayle ; Claudiu Zissulescu 

Cc: gcc-patches@gcc.gnu.org
Subject: Re: [ARC PATCH] Use rlc r0, 0 to implement scc_ltu (i.e. carry_flag ? 
1 : 0)



On 9/29/23 15:11, Roger Sayle wrote:
> 
> Hi Claudiu,
>> The patch looks sane. Have you run dejagnu test suite?
> 
> I've not yet managed to set up an emulator or compile the entire 
> toolchain, so my dejagnu results are only useful for catching 
> (serious) problems in the compile only tests:
> 
>  === gcc Summary ===
> 
> # of expected passes91875
> # of unexpected failures23768
> # of unexpected successes   23
> # of expected failures  1038
> # of unresolved testcases   19490
> # of unsupported tests  3819
> /home/roger/GCC/arc-linux/gcc/xgcc  version 14.0.0 20230828 
> (experimental)
> (GCC)
> 
> If someone could double check there are no issues on real hardware 
> that would be great.  I'm not sure if ARC is one of the targets 
> covered by Jeff Law's compile farm?
It is :-)  Runs daily, about 4:30 am UTC.  So if the bits go in we'd have data 
within 24hrs.


Jeff

Re: Question about function splitting

2023-10-02 Thread Martin Jambor

Hello,

On Mon, Oct 02 2023, Hanke Zhang via Gcc wrote:
> Hi, I have some questions about the strategy and behavior of function
> splitting in gcc, like the following code:
>
> int glob;
> void f() {
>   if (glob) {
> printf("short path\n");
> return;
>   }
>   // do lots of expensive things
>   // ...
> }
>
> I hope it can be broken down like below, so that the whole function
> can perhaps be inlined, which is more efficient.
>
> int glob;
> void f() {
>   if (glob) {
> printf("short path\n");
> return;
>   }
>   f_part();
> }
>
> void f_part() {
>   // do lots of expensive things
>   // ...
> }
>
>
> But on the contrary, gcc splits it like these, which not only does not
> bring any benefits, but may increase the time consumption, because the
> function call itself is a more resource-intensive thing.
>
> int glob;
> void f() {
>   if (glob) {
> f_part();
> return;
>   }
>   // do lots of expensive things
>   // ...
> }
>
> void f_part() {
>   printf("short path\n"); // just do this
> }
>
> Are there any options I can offer to gcc to change this behavior? Or
> do I need to make some changes in ipa-split.cc?

I'd suggest you file a bug to Bugzilla with a specific example that is
mis-handled, then we can have a look and discuss what and why happens
and what can be done about it.

Thanks,

Martin

[pushed] diagnostics: group together source printing fields of diagnostic_context

2023-10-02 Thread David Malcolm

struct diagnostic_context has > 60 fields.

Try to tame some of the complexity by grouping together the 8
source-printing fields into a struct, the "m_source_printing" field.

No functional change intended.

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r14-4367-gc5c565eff6277a.

gcc/ada/ChangeLog:
* gcc-interface/misc.cc (gnat_post_options): Update for renaming
of diagnostic_context's show_caret to m_source_printing.enabled.

gcc/analyzer/ChangeLog:
* program-point.cc: Update for grouping of source printing fields
within diagnostic_context.

gcc/c-family/ChangeLog:
* c-common.cc (maybe_add_include_fixit): Update for renaming of
diagnostic_context's show_caret to m_source_printing.enabled.
* c-opts.cc (c_common_init_options): Update for renaming of
diagnostic_context's colorize_source_p to
m_source_printing.colorize_source_p.

gcc/ChangeLog:
* diagnostic-show-locus.cc: Update for reorganization of
source-printing fields of diagnostic_context.
* diagnostic.cc (diagnostic_set_caret_max_width): Likewise.
(diagnostic_initialize): Likewise.
* diagnostic.h (diagnostic_context::show_caret): Move to...
(diagnostic_context::m_source_printing::enabled): ...here.
(diagnostic_context::caret_max_width): Move to...
(diagnostic_context::m_source_printing::max_width): ...here.
(diagnostic_context::caret_chars): Move to...
(diagnostic_context::m_source_printing::caret_chars): ...here.
(diagnostic_context::colorize_source_p): Move to...
(diagnostic_context::m_source_printing::colorize_source_p): ...here.
(diagnostic_context::show_labels_p): Move to...
(diagnostic_context::m_source_printing::show_labels_p): ...here.
(diagnostic_context::show_line_numbers_p): Move to...
(diagnostic_context::m_source_printing::show_line_numbers_p): ...here.
(diagnostic_context::min_margin_width): Move to...
(diagnostic_context::m_source_printing::min_margin_width): ...here.
(diagnostic_context::show_ruler_p): Move to...
(diagnostic_context::m_source_printing::show_ruler_p): ...here.
(diagnostic_same_line): Update for above changes.
* opts.cc (common_handle_option): Update for reorganization of
source-printing fields of diagnostic_context.
* selftest-diagnostic.cc
(test_diagnostic_context::test_diagnostic_context): Likewise.
* toplev.cc (general_init): Likewise.
* tree-diagnostic-path.cc (struct event_range): Likewise.

gcc/fortran/ChangeLog:
* error.cc (gfc_diagnostic_starter): Update for reorganization of
source-printing fields of diagnostic_context.
(gfc_diagnostics_init): Likewise.
(gfc_diagnostics_finish): Likewise.

gcc/testsuite/ChangeLog:
* gcc.dg/plugin/diagnostic_plugin_show_trees.c: Update for
reorganization of source-printing fields of diagnostic_context.
* gcc.dg/plugin/diagnostic_plugin_test_inlining.c: Likewise.
* gcc.dg/plugin/diagnostic_plugin_test_paths.c: Likewise.
* gcc.dg/plugin/diagnostic_plugin_test_show_locus.c: Likewise.
* gcc.dg/plugin/diagnostic_plugin_test_string_literals.c: Likewise.
* gcc.dg/plugin/diagnostic_plugin_test_tree_expression_range.c:
Likewise.
---
 gcc/ada/gcc-interface/misc.cc |  2 +-
 gcc/analyzer/program-point.cc |  4 +-
 gcc/c-family/c-common.cc  |  2 +-
 gcc/c-family/c-opts.cc|  2 +-
 gcc/diagnostic-show-locus.cc  | 93 ++-
 gcc/diagnostic.cc | 16 ++--
 gcc/diagnostic.h  | 73 ---
 gcc/fortran/error.cc  | 10 +-
 gcc/opts.cc   |  8 +-
 gcc/selftest-diagnostic.cc|  8 +-
 .../plugin/diagnostic_plugin_show_trees.c |  2 +-
 .../plugin/diagnostic_plugin_test_inlining.c  |  2 +-
 .../plugin/diagnostic_plugin_test_paths.c |  2 +-
 .../diagnostic_plugin_test_show_locus.c   | 26 +++---
 .../diagnostic_plugin_test_string_literals.c  |  2 +-
 ...nostic_plugin_test_tree_expression_range.c |  2 +-
 gcc/toplev.cc |  8 +-
 gcc/tree-diagnostic-path.cc   |  2 +-
 18 files changed, 140 insertions(+), 124 deletions(-)

diff --git a/gcc/ada/gcc-interface/misc.cc b/gcc/ada/gcc-interface/misc.cc
index 3b21bf5b43a..269c15e4b0d 100644
--- a/gcc/ada/gcc-interface/misc.cc
+++ b/gcc/ada/gcc-interface/misc.cc
@@ -269,7 +269,7 @@ gnat_post_options (const char **pfilename ATTRIBUTE_UNUSED)
 
   /* No caret by default for Ada.  */
   if (!OPTION_SET_P (flag_diagnostics_show_caret))
-global_dc->show_caret = false;
+global_dc->m_source_printing.enabled = false;
 
   /* Copy global settings to local

[pushed] diagnostics: add diagnostic_output_format class

2023-10-02 Thread David Malcolm

Eliminate various global variables in the json/sarif output code by
bundling together callbacks and state into a new diagnostic_output_format
class, with per-output-format subclasses.

No functional change intended.

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r14-4368-g140820265d96b0.

gcc/ChangeLog:
* diagnostic-format-json.cc (toplevel_array): Remove global in
favor of json_output_format::m_top_level_array.
(cur_group): Likewise, for json_output_format::m_cur_group.
(cur_children_array): Likewise, for
json_output_format::m_cur_children_array.
(class json_output_format): New.
(json_begin_diagnostic): Remove, in favor of
json_output_format::on_begin_diagnostic.
(json_end_diagnostic): Convert to...
(json_output_format::on_end_diagnostic): ...this.
(json_begin_group): Remove, in favor of
json_output_format::on_begin_group.
(json_end_group): Remove, in favor of
json_output_format::on_end_group.
(json_flush_to_file): Remove, in favor of
json_output_format::flush_to_file.
(json_stderr_final_cb): Remove, in favor of json_output_format
dtor.
(json_output_base_file_name): Remove global.
(class json_stderr_output_format): New.
(json_file_final_cb): Remove.
(class json_file_output_format): New.
(json_emit_diagram): Remove.
(diagnostic_output_format_init_json): Update.
(diagnostic_output_format_init_json_file): Update.
* diagnostic-format-sarif.cc (the_builder): Remove this global,
moving to a field of the sarif_output_format.
(sarif_builder::maybe_make_artifact_content_object): Use the
context's m_file_cache.
(get_source_lines): Convert to...
(sarif_builder::get_source_lines): ...this, using context's
m_file_cache.
(sarif_begin_diagnostic): Remove, in favor of
sarif_output_format::on_begin_diagnostic.
(sarif_end_diagnostic): Remove, in favor of
sarif_output_format::on_end_diagnostic.
(sarif_begin_group): Remove, in favor of
sarif_output_format::on_begin_group.
(sarif_end_group): Remove, in favor of
sarif_output_format::on_end_group.
(sarif_flush_to_file): Delete.
(sarif_stderr_final_cb): Delete.
(sarif_output_base_file_name): Delete.
(sarif_file_final_cb): Delete.
(class sarif_output_format): New.
(sarif_emit_diagram): Delete.
(class sarif_stream_output_format): New.
(class sarif_file_output_format): New.
(diagnostic_output_format_init_sarif): Update.
(diagnostic_output_format_init_sarif_stderr): Update.
(diagnostic_output_format_init_sarif_file): Update.
(diagnostic_output_format_init_sarif_stream): Update.
* diagnostic-show-locus.cc (diagnostic_show_locus): Update.
* diagnostic.cc (default_diagnostic_final_cb): Delete, moving to
diagnostic_text_output_format's dtor.
(diagnostic_initialize): Update, making a new instance of
diagnostic_text_output_format.
(diagnostic_finish): Delete m_output_format, rather than calling
final_cb.
(diagnostic_report_diagnostic): Assert that m_output_format is
non-NULL.  Replace call to begin_group_cb with call to
m_output_format->on_begin_group.  Replace call to
diagnostic_starter with call to
m_output_format->on_begin_diagnostic.  Replace call to
diagnostic_finalizer with call to
m_output_format->on_end_diagnostic.
(diagnostic_emit_diagram): Replace both optional call to
m_diagrams.m_emission_cb and default implementation with call to
m_output_format->on_diagram.  Move default implementation to
diagnostic_text_output_format::on_diagram.
(auto_diagnostic_group::~auto_diagnostic_group): Replace call to
end_group_cb with call to m_output_format->on_end_group.
(diagnostic_text_output_format::~diagnostic_text_output_format):
New, based on default_diagnostic_final_cb.
(diagnostic_text_output_format::on_begin_diagnostic): New, based
on code from diagnostic_report_diagnostic.
(diagnostic_text_output_format::on_end_diagnostic): Likewise.
(diagnostic_text_output_format::on_diagram): New, based on code
from diagnostic_emit_diagram.
* diagnostic.h (class diagnostic_output_format): New.
(class diagnostic_text_output_format): New.
(diagnostic_context::begin_diagnostic): Move to...
(diagnostic_context::m_text_callbacks::begin_diagnostic): ...here.
(diagnostic_context::start_span): Move to...
(diagnostic_context::m_text_callbacks::start_span): ...here.
(diagnostic_context::end_diagnostic): Move to...
(diagnostic_context::m_text_callbacks::end_diagnostic): ...here.

[Bug fortran/111644] [13 regression] many failures after r13-7923-gd9b3269bdccac2

2023-10-02 Thread seurer at gcc dot gnu.org via Gcc-bugs

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

seurer at gcc dot gnu.org changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|WAITING |RESOLVED

--- Comment #3 from seurer at gcc dot gnu.org ---
Fixed now, thanks!

[pushed] diagnostics: fix missing init of set_locations_cb

2023-10-02 Thread David Malcolm

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r14-4366-gc64693fb885f21.

gcc/ChangeLog:
* diagnostic.cc (diagnostic_initialize): Initialize
set_locations_cb to nullptr.
---
 gcc/diagnostic.cc | 1 +
 1 file changed, 1 insertion(+)

diff --git a/gcc/diagnostic.cc b/gcc/diagnostic.cc
index 00183b10700..28ab74ff23e 100644
--- a/gcc/diagnostic.cc
+++ b/gcc/diagnostic.cc
@@ -245,6 +245,7 @@ diagnostic_initialize (diagnostic_context *context, int 
n_opts)
   context->begin_group_cb = NULL;
   context->end_group_cb = NULL;
   context->final_cb = default_diagnostic_final_cb;
+  context->set_locations_cb = nullptr;
   context->ice_handler_cb = NULL;
   context->includes_seen = NULL;
   context->m_client_data_hooks = NULL;
-- 
2.26.3

[Bug target/111649] [14 Regression] Bootstrap failure in stage 1 on riscv--* since r14-4348-g9d249b7e31e

2023-10-02 Thread patrick at rivosinc dot com via Gcc-bugs

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

Patrick O'Neill  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #9 from Patrick O'Neill  ---
Builds no longer fail due to this issue.

There is some follow-up discussion on the mailing list about improving the
performance of the affected code using lazily allocation & dynamic
initialization:
https://inbox.sourceware.org/gcc-patches/da3d1e8c-3df2-2008-ad14-a3036b6f6...@rivosinc.com/T/#m65e9d134dfea988ad77b099cef83f194079078c4

[Bug testsuite/110951] [13/14] RISCV: rv32 newlib gcc.c-torture testsuite fails with xgcc: fatal error: Cannot find suitable multilib set for '-march=rv32imafdc_zicsr_zifencei'/'-mabi=ilp32d'

2023-10-02 Thread patrick at rivosinc dot com via Gcc-bugs

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

--- Comment #4 from Patrick O'Neill  ---
The root cause of the problem was that we were moving files between containers
after the build before the testsuite run and forgot to preserve the symlinks.

Question about function splitting

2023-10-02 Thread Hanke Zhang via Gcc

Hi, I have some questions about the strategy and behavior of function
splitting in gcc, like the following code:

int glob;
void f() {
  if (glob) {
printf("short path\n");
return;
  }
  // do lots of expensive things
  // ...
}

I hope it can be broken down like below, so that the whole function
can perhaps be inlined, which is more efficient.

int glob;
void f() {
  if (glob) {
printf("short path\n");
return;
  }
  f_part();
}

void f_part() {
  // do lots of expensive things
  // ...
}


But on the contrary, gcc splits it like these, which not only does not
bring any benefits, but may increase the time consumption, because the
function call itself is a more resource-intensive thing.

int glob;
void f() {
  if (glob) {
f_part();
return;
  }
  // do lots of expensive things
  // ...
}

void f_part() {
  printf("short path\n"); // just do this
}

Are there any options I can offer to gcc to change this behavior? Or
do I need to make some changes in ipa-split.cc?

[Bug bootstrap/111664] [14 regression] error in gcc/opt-read.awk after r14-4354-ge4a4b8e983bac8

2023-10-02 Thread sjames at gcc dot gnu.org via Gcc-bugs

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

Sam James  changed:

   What|Removed |Added

 CC||kito at gcc dot gnu.org,
   ||sjames at gcc dot gnu.org

--- Comment #1 from Sam James  ---
It's a gawk vs mawk issue, see
https://inbox.sourceware.org/gcc-patches/20231002080244.105205-1-kito.ch...@sifive.com/T/#u
for a patch.

[Bug bootstrap/111664] New: [14 regression] error in gcc/opt-read.awk after r14-4354-ge4a4b8e983bac8

2023-10-02 Thread seurer at gcc dot gnu.org via Gcc-bugs

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

Bug ID: 111664
   Summary: [14 regression] error in gcc/opt-read.awk after
r14-4354-ge4a4b8e983bac8
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:e4a4b8e983bac865eb435b11798e38d633b98942, r14-4354-ge4a4b8e983bac8

I am seeing this just on our big ending machines.

mawk -f /home/seurer/gcc/git/gcc-trunk/gcc/opt-functions.awk -f
/home/seurer/gcc/git/gcc-trunk/gcc/opt-read.awk \
   -f /home/seurer/gcc/git/gcc-trunk/gcc/opth-gen.awk \
   < optionlist > tmp-options.h
mawk: /home/seurer/gcc/git/gcc-trunk/gcc/opt-read.awk: line 134: syntax error
at or near [
mawk: /home/seurer/gcc/git/gcc-trunk/gcc/opth-gen.awk: line 415: syntax error
at or near [
mawk: /home/seurer/gcc/git/gcc-trunk/gcc/opth-gen.awk: line 417: syntax error
at or near [
mawk: /home/seurer/gcc/git/gcc-trunk/gcc/opth-gen.awk: line 440: syntax error
at or near [

commit e4a4b8e983bac865eb435b11798e38d633b98942
Author: Feng Wang 
Date:   Tue Sep 12 09:18:05 2023 +

RISC-V:Optimize the MASK opt generation

[Bug target/111235] [Armv7-a]: Control-dependency between atomic accesses removed by -O1.

2023-10-02 Thread sjames at gcc dot gnu.org via Gcc-bugs

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

Sam James  changed:

   What|Removed |Added

 CC||sjames at gcc dot gnu.org

--- Comment #3 from Sam James  ---
(In reply to Luke Geeson from comment #1)
> Correction 
> We will follow up by reporting the bug for GCC.
> ->
> We have reported this in LLVM as well

Could you include the link? Thanks.

[Bug target/111600] [14 Regression] RISC-V bootstrap time regression

2023-10-02 Thread kito at gcc dot gnu.org via Gcc-bugs

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

Kito Cheng  changed:

   What|Removed |Added

 CC||kito at gcc dot gnu.org

--- Comment #13 from Kito Cheng  ---
I guess we may need something like this g:703417a0 for those generator for md
file?

Re: [PATCH] RFC: Add late-combine pass [PR106594]

2023-10-02 Thread Robin Dapp

Hi Richard,

cool, thanks.  I just gave it a try with my test cases and it does what
it is supposed to do, at least if I disable the register pressure check :)
A cursory look over the test suite showed no major regressions and just
some overly specific tests.

My test case only works before split, though, as the UNSPEC predicates will
prevent further combination afterwards.

Right now the (pre-RA) code combines every instance disregarding the actual
pressure and just checking if the "new" value does not occupy more registers
than the old one.

- Shouldn't the "pressure" also depend on the number of available hard regs
(i.e. an nregs = 2 is not necessarily worse than nregs = 1 if we have 32
hard regs in the new class vs 16 in the old one)?

- I assume/hope you expected my (now obsolete) fwprop change could be re-used?
Otherwise we wouldn't want to unconditionally "propagate" into a loop for 
example?
For my test case the combination of the vec_duplicate into all insns leads
to "high" register pressure that we could avoid.

How should we continue here?  I suppose you'll first want to get this version
to the trunk before complicating it further.

Regards
 Robin

[Bug target/111235] [Armv7-a]: Control-dependency between atomic accesses removed by -O1.

2023-10-02 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Wilco Dijkstra :

https://gcc.gnu.org/g:0731889c026bfe8d55c4851422ca5ec9d037f7a0

commit r14-4365-g0731889c026bfe8d55c4851422ca5ec9d037f7a0
Author: Wilco Dijkstra 
Date:   Fri Sep 29 13:21:10 2023 +0100

Arm: Block predication on atomics [PR111235]

The v7 memory ordering model allows reordering of conditional atomic
instructions.  To avoid this, make all atomic patterns unconditional.
Expand atomic loads and stores for all architectures so the memory access
can be wrapped into an UNSPEC.

Reviewed-by: Ramana Radhakrishnan 

gcc/ChangeLog:
PR target/111235
* config/arm/constraints.md: Remove Pf constraint.
* config/arm/sync.md (arm_atomic_load): Add new pattern.
(arm_atomic_load_acquire): Likewise.
(arm_atomic_store): Likewise.
(arm_atomic_store_release): Likewise.
(atomic_load): Switch patterns to define_expand.
(atomic_store): Likewise.
(arm_atomic_loaddi2_ldrd): Remove predication.
(arm_load_exclusive): Likewise.
(arm_load_acquire_exclusive): Likewise.
(arm_load_exclusivesi): Likewise.
(arm_load_acquire_exclusivesi): Likewise.
(arm_load_exclusivedi): Likewise.
(arm_load_acquire_exclusivedi): Likewise.
(arm_store_exclusive): Likewise.
(arm_store_release_exclusivedi): Likewise.
(arm_store_release_exclusive): Likewise.
* config/arm/unspecs.md: Add VUNSPEC_LDR and VUNSPEC_STR.

gcc/testsuite/ChangeLog:
PR target/111235
* gcc.dg/rtl/arm/stl-cond.c: Remove test.
* gcc.target/arm/atomic_loaddi_7.c: Fix dmb count.
* gcc.target/arm/atomic_loaddi_8.c: Likewise.
* gcc.target/arm/pr111235.c: Add new test.

[Bug target/111600] [14 Regression] RISC-V bootstrap time regression

2023-10-02 Thread rdapp at gcc dot gnu.org via Gcc-bugs

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

Robin Dapp  changed:

   What|Removed |Added

 CC||law at gcc dot gnu.org

--- Comment #12 from Robin Dapp  ---
We're really at a point where just building becomes a burden and turnaround
times are annoyingly high.  My suspicion is that the large number of modes
combined with the number of insn patterns slows us down.  Juzhe added a lot of
VLS patterns (or rather added VLS modes to existing patterns) around the
Cauldron and this is where we saw the largest relative slowdown.

Maybe we need to bite the bullet and not use the convenience helpers anymore or
at least very sparingly?  I'm going to make some experiments on Wednesday to
see where that gets us.

Re: [PATCH 1/5] OpenMP, NVPTX: memcpy[23]D bias correction

2023-10-02 Thread Julian Brown

On Wed, 27 Sep 2023 00:57:58 +0200
Thomas Schwinge  wrote:

> On 2023-09-06T02:34:30-0700, Julian Brown 
> wrote:
> > This patch works around behaviour of the 2D and 3D memcpy
> > operations in the CUDA driver runtime.  Particularly in Fortran,
> > the "base pointer" of an array (used for either source or
> > destination of a host/device copy) may lie outside of data that is
> > actually stored on the device.  The fix is to make sure that we use
> > the first element of data to be transferred instead, and adjust
> > parameters accordingly.  
> 
> Do you (a) have a stand-alone test case for this (that is, not
> depending on your other pending patches, so that this could go in
> directly -- together with the before-FAIL test case).

Thanks for the reply! Here's a version with a stand-alone test case.

> Do you (b)
> know if is this a bug in our use of the CUDA Driver API or rather in
> CUDA itself?  If the latter, have you reported this to Nvidia?

I don't think the CUDA behaviour is *wrong*, as such -- at least to the
C/C++ way of thinking (or indeed a graphics-oriented way of thinking),
one would normally think of an array as having a zero-based origin, and
these 2D/3D memory copies would be intended as a way of updating just a
part of an array (or texture) that has full duplicate copies on both
the host and device.  Our use-case just happens to be a bit different,
both because Fortran (internally) represents an array by a zero-based
origin but may use 1-based (or whatever-based) indices, and because we
support partial mappings of host arrays on the device in all three
supported languages -- which amounts to much the same thing, actually.

That said, it *could* be fixed in CUDA, though probably not in all the
versions currently deployed out there in the world.  So I guess we'd
still need a patch like this anyway.

Julian
commit f6fd3ad060bbe5c57661cd861d009dbc2b415778
Author: Julian Brown 
Date:   Wed Aug 23 23:46:29 2023 +

OpenMP, NVPTX: memcpy[23]D bias correction

This patch works around behaviour of the 2D and 3D memcpy operations in
the CUDA driver runtime.  Particularly in Fortran, the "base pointer"
of an array (used for either source or destination of a host/device copy)
may lie outside of data that is actually stored on the device.  The fix
is to make sure that we use the first element of data to be transferred
instead, and adjust parameters accordingly.

2023-10-02  Julian Brown  

libgomp/
* plugin/plugin-nvptx.c (GOMP_OFFLOAD_memcpy2d): Adjust parameters to
avoid out-of-bounds array checks in CUDA runtime.
(GOMP_OFFLOAD_memcpy3d): Likewise.
* testsuite/libgomp.c-c++-common/memcpyxd-bias-1.c: New test.

diff --git a/libgomp/plugin/plugin-nvptx.c b/libgomp/plugin/plugin-nvptx.c
index 00d4241ae02..cefe288a8aa 100644
--- a/libgomp/plugin/plugin-nvptx.c
+++ b/libgomp/plugin/plugin-nvptx.c
@@ -1827,6 +1827,35 @@ GOMP_OFFLOAD_memcpy2d (int dst_ord, int src_ord, size_t dim1_size,
   data.srcXInBytes = src_offset1_size;
   data.srcY = src_offset0_len;

+  if (data.srcXInBytes != 0 || data.srcY != 0)
+{
+  /* Adjust origin to the actual array data, else the CUDA 2D memory
+	 copy API calls below may fail to validate source/dest pointers
+	 correctly (especially for Fortran where the "virtual origin" of an
+	 array is often outside the stored data).  */
+  if (src_ord == -1)
+	data.srcHost = (const void *) ((const char *) data.srcHost
+  + data.srcY * data.srcPitch
+  + data.srcXInBytes);
+  else
+	data.srcDevice += data.srcY * data.srcPitch + data.srcXInBytes;
+  data.srcXInBytes = 0;
+  data.srcY = 0;
+}
+
+  if (data.dstXInBytes != 0 || data.dstY != 0)
+{
+  /* As above.  */
+  if (dst_ord == -1)
+	data.dstHost = (void *) ((char *) data.dstHost
+ + data.dstY * data.dstPitch
+ + data.dstXInBytes);
+  else
+	data.dstDevice += data.dstY * data.dstPitch + data.dstXInBytes;
+  data.dstXInBytes = 0;
+  data.dstY = 0;
+}
+
   CUresult res = CUDA_CALL_NOCHECK (cuMemcpy2D, );
   if (res == CUDA_ERROR_INVALID_VALUE)
 /* If pitch > CU_DEVICE_ATTRIBUTE_MAX_PITCH or for device-to-device
@@ -1895,6 +1924,44 @@ GOMP_OFFLOAD_memcpy3d (int dst_ord, int src_ord, size_t dim2_size,
   data.srcY = src_offset1_len;
   data.srcZ = src_offset0_len;

+  if (data.srcXInBytes != 0 || data.srcY != 0 || data.srcZ != 0)
+{
+  /* Adjust origin to the actual array data, else the CUDA 3D memory
+	 copy API call below may fail to validate source/dest pointers
+	 correctly (especially for Fortran where the "virtual origin" of an
+	 array is often outside the stored data).  */
+  if (src_ord == -1)
+	data.srcHost
+	  = (const void *) ((const char *) data.srcHost
+			+ (data.srcZ * data.srcHeight + data.srcY)
+			  * data.srcPitch
+			+ data.srcXInBytes);
+  else
+	data.srcDevice
+	  += (data.srcZ * data.srcHeight + data.srcY)

[Bug c++/111660] [14 Regression] Compilation of constexpr function returning enum takes exponential time with -std=c++2a

2023-10-02 Thread mpolacek at gcc dot gnu.org via Gcc-bugs

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

Marek Polacek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org

Re: [PATCH v2] RISC-V: Implement TLS Descriptors.

2023-10-02 Thread Kito Cheng

Just one nit and one more comment for doc:

Could you add some doc something like that? mostly I grab from other
target, so you can just included in the patch.

diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
index 31f2234640f..39396668da2 100644
--- a/gcc/doc/install.texi
+++ b/gcc/doc/install.texi
@@ -1174,6 +1174,9 @@ Specify the default TLS dialect, for systems
were there is a choice.
For ARM targets, possible values for @var{dialect} are @code{gnu} or
@code{gnu2}, which select between the original GNU dialect and the GNU TLS
descriptor-based dialect.
+For RISC-V targets, possible values for @var{dialect} are @code{trad} or
+@code{desc}, which select between the traditional GNU dialect and the GNU TLS
+descriptor-based dialect.

@item --enable-multiarch
Specify whether to enable or disable multiarch support.  The default is
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 4085fc90907..459e266d426 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -1239,7 +1239,8 @@ See RS/6000 and PowerPC Options.
-minline-atomics  -mno-inline-atomics
-minline-strlen  -mno-inline-strlen
-minline-strcmp  -mno-inline-strcmp
--minline-strncmp  -mno-inline-strncmp}
+-minline-strncmp  -mno-inline-strncmp
+-mtls-dialect=desc  -mtls-dialect=trad}

@emph{RL78 Options}
@gccoptlist{-msim  -mmul=none  -mmul=g13  -mmul=g14  -mallregs
@@ -29538,6 +29539,17 @@ which register to use as base register for
reading the canary,
and from what offset from that base register. There is no default
register or offset as this is entirely for use within the Linux
kernel.
+
+@opindex mtls-dialect=desc
+@item -mtls-dialect=desc
+Use TLS descriptors as the thread-local storage mechanism for dynamic accesses
+of TLS variables.  This is the default.
+
+@opindex mtls-dialect=trad
+@item -mtls-dialect=traditional
+Use traditional TLS as the thread-local storage mechanism for dynamic accesses
+of TLS variables.
+
@end table

@node RL78 Options




> +(define_insn "@tlsdesc"
> +  [(set (reg:P A0_REGNUM)
> +   (unspec:P
> +   [(match_operand:P 0 "symbolic_operand" "")
> +(match_operand:P 1 "const_int_operand")]
> +   UNSPEC_TLSDESC))
> +   (clobber (reg:SI T0_REGNUM))]

P rather than SI here.

> +  "TARGET_TLSDESC"
> +  {
> +return ".LT%1: auipc\ta0, %%tlsdesc_hi(%0)\;"
> +   "\tt0,%%tlsdesc_load_lo(.LT%1)(a0)\;"
> +   "addi\ta0,a0,%%tlsdesc_add_lo(.LT%1)\;"
> +   "jalr\tt0,t0,%%tlsdesc_call(.LT%1)";
> +  }
> +  [(set_attr "type" "multi")
> +   (set_attr "length" "16")
> +   (set_attr "mode" "")])
> +
>  (define_insn "auipc"
>[(set (match_operand:P   0 "register_operand" "=r")
> (unspec:P

Re: [PATCH] RISC-V: Use stdint-gcc.h in rvv testsuite

2023-10-02 Thread Kito Cheng

> > On Tue, Sep 26, 2023 at 10:59 AM Patrick O'Neill  
> > wrote:
> >> stdint.h can be replaced with stdint-gcc.h to resolve some missing
> >> system headers in non-multilib installations.
> >>
> >> Tested using glibc rv32gcv and rv64gcv on r14-4258-gc9837443075.
> >>
> >> gcc/ChangeLog:
> >>
> >>  * config/riscv/riscv_vector.h (__RISCV_VECTOR_H): Replace
> >>  stdint.h with stdint-gcc.h
> > I don't think this will work when testing an installed compiler which I do.
> >
> > Thanks,
> > Andrew
> In the riscv target testsuite (gcc.target/riscv) all occurrences of
> #include  are currently constrained to the rvv/ subdirectory.
> All non-vector tests use #include  rather than
> #include . Have you encountered any issues when testing
> installations with non-vector tests?

I think the concern is to replace stdint.h with stdint-gcc.h for riscv_vector.h,
that means users MAY include stdint-gcc.h *AND* stdint.h, stdint.h the later
one generally is provided by libc, and stdint-gcc.h typically are not included.

Other than the changes in "riscv_vector.h", everything else looks fine to me.

[Bug c++/111660] [14 Regression] Compilation of constexpr function returning enum takes exponential time with -std=c++2a

2023-10-02 Thread ppalka at gcc dot gnu.org via Gcc-bugs

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

Patrick Palka  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org,
   ||ppalka at gcc dot gnu.org

--- Comment #11 from Patrick Palka  ---
(In reply to Andrew Pinski from comment #8)
> I suspect r14-4140-g6851e3423c2b5e introduced the compile time slowness.

Confirmed.

RE: [PATCH]middle-end: Recursively check is_trivially_copyable_or_pair in vec.h

2023-10-02 Thread Tamar Christina

> -Original Message-
> From: Jakub Jelinek 
> Sent: Monday, October 2, 2023 2:21 PM
> To: Tamar Christina 
> Cc: gcc-patches@gcc.gnu.org; nd ; jwak...@redhat.com
> Subject: Re: [PATCH]middle-end: Recursively check
> is_trivially_copyable_or_pair in vec.h
> 
> On Mon, Oct 02, 2023 at 01:38:53PM +0100, Tamar Christina wrote:
> > Hi All,
> >
> > I recently committed a patch that uses a nested std::pair in the second
> argument.
> > It temporarily adds a second ranking variable for sorting and then later 
> > drops
> it.
> >
> > This hits the newly added assert in vec.h.  This assert made some
> > relaxation for std::pair but doesn't allow this case through.  The
> > patch allows a recursive std::pair in the second argument which fixes
> bootstrap.
> 
> I must say I still don't understand why using a struct ifcvt_arg_entry { tree 
> arg;
> unsigned len, occur; }; with comments describing what the members mean
> wouldn't be a better fix, in the sorting function what exactly means
> x{1,2}.second.first and x{1,2}.second.second isn't easily understandable,
> neither from the identifiers nor from any comments.
> Seems because you use 2 separate vectors, one with just tree elements and
> another with those tree elements + 2 unsigned values cached from it for the
> sorting purpose and then rewrite the original tree vector after sorting, I 
> don't
> really see why nested std::pair would be a better match for it than a named
> structure.  Furthermore, why populate args first, then compute the extra 2
> integers in another loop pushing to argsKV and finally overwrite args with
> sorted values?  Can't the first loop push tree with the 2 integers already?  
> And
> what is the point of not using this structure later on when both args and
> argsKV vectors are live until the end of the same function?
> Can't you either pass that argsKV to others, having just one vector, or at 
> least
> release the other vector when you don't really need it?
> Formatting style, swap? arg1 : arg0 isn't correctly formatted, missing space
> before ?.
> 
> Also, ArgEntry is CamelCase which we (usually) don't use in GCC and
> additionally doesn't seem to be unique enough for ODR purposes.
> Ditto argsKV.

Ok, since these will take a lot longer to test and do I've reverted the patch
for now since bootstrap was broken.

Thanks,
Tamar

> 
> > It should also still maintain the invariant that was being tested here
> > since the nested arguments should still be trivially copyable.
> >
> > Bootstrapped on aarch64-none-linux-gnu, x86_64-linux-gnu, and no issues.
> >
> > Ok for master?
> >
> > Thanks,
> > Tamar
> >
> > gcc/ChangeLog:
> >
> > vec.h (struct is_trivially_copyable_or_pair): Check recursively in
> 
> Missing "* " above.
> 
> > second arg.
> 
>   Jakub

Re: [PATCH]middle-end: Recursively check is_trivially_copyable_or_pair in vec.h

2023-10-02 Thread Jakub Jelinek

On Mon, Oct 02, 2023 at 01:38:53PM +0100, Tamar Christina wrote:
> Hi All,
> 
> I recently committed a patch that uses a nested std::pair in the second 
> argument.
> It temporarily adds a second ranking variable for sorting and then later 
> drops it.
> 
> This hits the newly added assert in vec.h.  This assert made some relaxation 
> for
> std::pair but doesn't allow this case through.  The patch allows a recursive
> std::pair in the second argument which fixes bootstrap.

I must say I still don't understand why using a
struct ifcvt_arg_entry { tree arg; unsigned len, occur; };
with comments describing what the members mean wouldn't be a better fix,
in the sorting function what exactly means x{1,2}.second.first and
x{1,2}.second.second isn't easily understandable, neither from the
identifiers nor from any comments.
Seems because you use 2 separate vectors, one with just tree elements and
another with those tree elements + 2 unsigned values cached from it for the
sorting purpose and then rewrite the original tree vector after sorting, I
don't really see why nested std::pair would be a better match for it than
a named structure.  Furthermore, why populate args first, then compute
the extra 2 integers in another loop pushing to argsKV and finally overwrite
args with sorted values?  Can't the first loop push tree with the 2 integers
already?  And what is the point of not using this structure later on when
both args and argsKV vectors are live until the end of the same function?
Can't you either pass that argsKV to others, having just one vector, or
at least release the other vector when you don't really need it?
Formatting style, swap? arg1 : arg0 isn't correctly formatted, missing space
before ?.

Also, ArgEntry is CamelCase which we (usually) don't use in GCC and
additionally doesn't seem to be unique enough for ODR purposes.
Ditto argsKV.

> It should also still maintain the invariant that was being tested here since
> the nested arguments should still be trivially copyable.
> 
> Bootstrapped on aarch64-none-linux-gnu, x86_64-linux-gnu, and no issues.
> 
> Ok for master?
> 
> Thanks,
> Tamar
> 
> gcc/ChangeLog:
> 
>   vec.h (struct is_trivially_copyable_or_pair): Check recursively in

Missing "* " above.

>   second arg.

Jakub

[Bug other/44209] [meta-bug] Some warnings are not linked to diagnostics options

2023-10-02 Thread manu at gcc dot gnu.org via Gcc-bugs

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

--- Comment #9 from Manuel López-Ibáñez  ---
For the sake of other potential readers: Patches should be submitted to
gcc-patc...@gcc.gnu.org and reviewers do not review patches in bugzilla.
Nevertheless, it is a good idea to add the link to the mailing list archive
here in bugzilla so the patch is not forgotten.

For more details, please read:
https://gcc.gnu.org/wiki/GettingStarted#Basics:_Contributing_to_GCC_in_10_easy_steps

How to submit and ping patches: https://gcc.gnu.org/contribute.html#patches

See other suggestions on how to interact with the GCC community here:
https://gcc.gnu.org/wiki/Community

[Bug c/111654] Introduce clang's invalid-noreturn warning

2023-10-02 Thread manu at gcc dot gnu.org via Gcc-bugs

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

--- Comment #4 from Manuel López-Ibáñez  ---
(In reply to Julian Waters from comment #2)
> (In reply to Manuel López-Ibáñez from comment #1)
> Yeah, I did try submitting it to gcc-patches, but it simply went ignored for
> forever, so I decided to submit the patch through the bug system instead,
> like others have done. I implemented it as numeric values to avoid inventing
> new names for -Woption and because it was easier to implement for a gcc
> beginner like myself, so worded warnings are likely to take me longer to
> implement

Apologies, I was not aware of that. 

I think it is a good idea to add the link to the mailing list here in bugzilla
so it is not lost in the mailing list archive.

Unfortunately, gcc does not have any patch tracking system so it is up to
submitters to ping patches (the submitter is the one interested in seeing the
patch committed). See for example:
https://gcc.gnu.org/pipermail/gcc-patches/2023-August/627958.html 

It may take 4 to 10 pings to get the patch reviewed. It helps sometimes to
describe the area the patch touches in the subject. In your case, I would write
"[C family]".

It helps reviewers if you mention how the patch was tested and also if the
patch is attached as plain-text (not as application/*):
https://gcc.gnu.org/contribute.html#patches

See other suggestions on how to interact with the GCC community here:
https://gcc.gnu.org/wiki/Community

[PATCH]middle-end: Recursively check is_trivially_copyable_or_pair in vec.h

2023-10-02 Thread Tamar Christina

Hi All,

I recently committed a patch that uses a nested std::pair in the second 
argument.
It temporarily adds a second ranking variable for sorting and then later drops 
it.

This hits the newly added assert in vec.h.  This assert made some relaxation for
std::pair but doesn't allow this case through.  The patch allows a recursive
std::pair in the second argument which fixes bootstrap.

It should also still maintain the invariant that was being tested here since
the nested arguments should still be trivially copyable.

Bootstrapped on aarch64-none-linux-gnu, x86_64-linux-gnu, and no issues.

Ok for master?

Thanks,
Tamar

gcc/ChangeLog:

vec.h (struct is_trivially_copyable_or_pair): Check recursively in
second arg.

--- inline copy of patch -- 
diff --git a/gcc/vec.h b/gcc/vec.h
index d509639292b..dcc18c99bfb 100644
--- a/gcc/vec.h
+++ b/gcc/vec.h
@@ -1199,7 +1199,7 @@ namespace vec_detail
   template
   struct is_trivially_copyable_or_pair >
   : std::integral_constant::value
-&& std::is_trivially_copyable::value> { };
+&& is_trivially_copyable_or_pair::value> { };
 }
 #endif




-- 
diff --git a/gcc/vec.h b/gcc/vec.h
index d509639292b..dcc18c99bfb 100644
--- a/gcc/vec.h
+++ b/gcc/vec.h
@@ -1199,7 +1199,7 @@ namespace vec_detail
   template
   struct is_trivially_copyable_or_pair >
   : std::integral_constant::value
-&& std::is_trivially_copyable::value> { };
+&& is_trivially_copyable_or_pair::value> { };
 }
 #endif

[Bug bootstrap/111663] profiledbootstrap fails on master: gcc/genmodes.cc:2152:1: error: ‘gcc/build/genmodes.gcda’ profile count data file not found [-Werror=missing-profile]

2023-10-02 Thread slyfox at gcc dot gnu.org via Gcc-bugs

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

--- Comment #1 from Sergei Trofimovich  ---
Proposed the change as
https://gcc.gnu.org/pipermail/gcc-patches/2023-October/631790.html

[PATCH] Makefile.tpl: disable -Werror for feedback stage [PR111663]

2023-10-02 Thread Sergei Trofimovich

From: Sergei Trofimovich 

Without the change profiled bootstrap fails for various warnings on
master branch as:

$ ../gcc/configure
$ make profiledbootstrap
...
gcc/genmodes.cc: In function ‘int main(int, char**)’:
gcc/genmodes.cc:2152:1: error: ‘gcc/build/genmodes.gcda’ profile count data 
file not found [-Werror=missing-profile]
...
gcc/gengtype-parse.cc: In function ‘void parse_error(const char*, ...)’:
gcc/gengtype-parse.cc:142:21: error: ‘%s’ directive argument is null 
[-Werror=format-overflow=]

The change removes -Werror just like autofeedback does today.

/

PR bootstrap/111663
* Makefile.tpl (STAGEfeedback_CONFIGURE_FLAGS): Disable -Werror.
* Makefile.in: Regenerate.
---
 Makefile.in  | 4 
 Makefile.tpl | 4 
 2 files changed, 8 insertions(+)

diff --git a/Makefile.in b/Makefile.in
index 2f136839c35..e0e3c4c8fe8 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -638,6 +638,10 @@ STAGEtrain_TFLAGS = $(filter-out 
-fchecking=1,$(STAGE3_TFLAGS))
 
 STAGEfeedback_CFLAGS = $(STAGE4_CFLAGS) -fprofile-use 
-fprofile-reproducible=parallel-runs
 STAGEfeedback_TFLAGS = $(STAGE4_TFLAGS)
+# Disable warnings as errors for a few reasons:
+# - sources for gen* binaries do not have .gcda files available
+# - inlining decisions generate extra warnings
+STAGEfeedback_CONFIGURE_FLAGS = $(filter-out 
--enable-werror-always,$(STAGE_CONFIGURE_FLAGS))
 
 STAGEautoprofile_CFLAGS = $(filter-out -gtoggle,$(STAGE2_CFLAGS)) -g
 STAGEautoprofile_TFLAGS = $(STAGE2_TFLAGS)
diff --git a/Makefile.tpl b/Makefile.tpl
index 5872dd03f2c..8b7783bb4f1 100644
--- a/Makefile.tpl
+++ b/Makefile.tpl
@@ -561,6 +561,10 @@ STAGEtrain_TFLAGS = $(filter-out 
-fchecking=1,$(STAGE3_TFLAGS))
 
 STAGEfeedback_CFLAGS = $(STAGE4_CFLAGS) -fprofile-use 
-fprofile-reproducible=parallel-runs
 STAGEfeedback_TFLAGS = $(STAGE4_TFLAGS)
+# Disable warnings as errors for a few reasons:
+# - sources for gen* binaries do not have .gcda files available
+# - inlining decisions generate extra warnings
+STAGEfeedback_CONFIGURE_FLAGS = $(filter-out 
--enable-werror-always,$(STAGE_CONFIGURE_FLAGS))
 
 STAGEautoprofile_CFLAGS = $(filter-out -gtoggle,$(STAGE2_CFLAGS)) -g
 STAGEautoprofile_TFLAGS = $(STAGE2_TFLAGS)
-- 
2.42.0

[Bug bootstrap/111663] New: profiledbootstrap fails on master: gcc/genmodes.cc:2152:1: error: ‘gcc/build/genmodes.gcda’ profile count data file not found [-Werror=missing-profile]

2023-10-02 Thread slyfox at gcc dot gnu.org via Gcc-bugs

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

Bug ID: 111663
   Summary: profiledbootstrap fails on master:
gcc/genmodes.cc:2152:1: error:
‘gcc/build/genmodes.gcda’ profile count data file not
found [-Werror=missing-profile]
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: slyfox at gcc dot gnu.org
  Target Milestone: ---

It is the same issue diagnosed by Martin in https://gcc.gnu.org/PR87932#c2

The only difference here is the failure of profiledbootstrap on master by
default (until you disable -Werror).

The reproducer:

$ ~/dev/git/gcc/configure --disable-multilib --enable-languages=c,c++
CC='gcc -O2' CXX='g++ -O2'
$ make profiledbootstrap

...
gcc/gcc/sort.cc: In function ‘void reorder45(sort_ctx*, char*, char*, char*,
char*, char*) [with sort_ctx = sort_r_ctx]’:
gcc/gcc/sort.cc:313:1: error: ‘gcc/build/sort.gcda’ profile count data file not
found [-Werror=missing-profile]
  313 | }
  | ^
gcc/gcc/genmodes.cc: In function ‘int main(int, char**)’:
gcc/gcc/genmodes.cc:2152:1: error: ‘gcc/build/genmodes.gcda’ profile count data
file not found [-Werror=missing-profile]
 2152 | }
  | ^
gcc/gcc/gengtype-parse.cc: In function ‘void parse_file(const char*)’:
gcc/gcc/gengtype-parse.cc:1186:1: error: ‘gcc/build/gengtype-parse.gcda’
profile count data file not found [-Werror=missing-profile]
 1186 | }
  | ^
cc1plus: all warnings being treated as errors
make[3]: *** [Makefile:2949: build/gengenrtl.o] Ошибка 1
gcc/gcc/gengtype-parse.cc: In function ‘void parse_error(const char*, ...)’:
gcc/gcc/gengtype-parse.cc:142:21: error: ‘%s’ directive argument is null
[-Werror=format-overflow=]
  142 |   fprintf (stderr, "%s:%d: parse error: ",
  | ^~

Stable branches work just because -Werror is disabled.

Note that autofeedback has a similar problem and it works it around with
disabling -Werror:

 # Disable warnings as errors since inlining decisions with -fauto-profile
 # may result in additional warnings.
 STAGEautofeedback_CONFIGURE_FLAGS = $(filter-out
--enable-werror-always,$(STAGE_CONFIGURE_FLAGS))

I suggest doling the same for `profiledbootstrap` as:

--- a/Makefile.tpl
+++ b/Makefile.tpl
@@ -561,6 +561,10 @@ STAGEtrain_TFLAGS = $(filter-out
-fchecking=1,$(STAGE3_TFLAGS))

 STAGEfeedback_CFLAGS = $(STAGE4_CFLAGS) -fprofile-use
-fprofile-reproducible=parallel-runs
 STAGEfeedback_TFLAGS = $(STAGE4_TFLAGS)
+# Disable warnings as errors for a few reasons:
+# - sources for gen* binaries do not have .gcda files available
+# - inlining decisions generate extra warnings
+STAGEfeedback_CONFIGURE_FLAGS = $(filter-out
--enable-werror-always,$(STAGE_CONFIGURE_FLAGS))

 STAGEautoprofile_CFLAGS = $(filter-out -gtoggle,$(STAGE2_CFLAGS)) -g
 STAGEautoprofile_TFLAGS = $(STAGE2_TFLAGS)

[Bug c++/111662] Rejects valid: cv-qualifiers are not removed from function parameters of variadic templated function types

2023-10-02 Thread janschultke at googlemail dot com via Gcc-bugs

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

--- Comment #2 from Jan Schultke  ---
Bug was originally discovered here:
https://stackoverflow.com/questions/77214665/problem-creating-template-function-alias-with-const-value-template-arguments/77215223#77215223

[Bug c++/111662] Rejects valid: cv-qualifiers are not removed from function parameters of variadic templated function types

2023-10-02 Thread janschultke at googlemail dot com via Gcc-bugs

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

--- Comment #1 from Jan Schultke  ---
See https://godbolt.org/z/Kaf7jETaY

[Bug c++/111662] New: Rejects valid: cv-qualifiers are not removed from function parameters of variadic templated function types

2023-10-02 Thread janschultke at googlemail dot com via Gcc-bugs

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

Bug ID: 111662
   Summary: Rejects valid: cv-qualifiers are not removed from
function parameters of variadic templated function
types
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: janschultke at googlemail dot com
  Target Milestone: ---

## Code to reproduce

template
void f(Ts...) {}

void(*pfi)(int) = ; // OK
void(*pfci)(int) = ; // error

void(*pcfi)(const int) = ; // OK
void(*pcfci)(const int) = ; // error

> :5:21: error: no matches converting function 'f' to type 'void 
> (*)(int)'
> 5 | void(*pfci)(int) = ; // error
>   | ^~~~
> :2:6: note: candidate is: 'template void f(Ts ...)'
> 2 | void f(Ts...) {}
>   |  ^

## Explanation

The error is nonsensical because the type of  is already
void(*)(int). No conversion is required.

According to [dcl.fct] p5, cv-qualifiers are not part of the function type:
> After producing the list of parameter types,
> any top-level cv-qualifiers modifying a parameter type are deleted
> when forming the function type.

Variadic function templates are not exempt from this rule, and GCC should not
reject this code. Making f non-templated, or using a single T parameter instead
of a Ts... parameter pack makes this code compile.

[Bug middle-end/50481] builtin to reverse the bit order

2023-10-02 Thread xry111 at gcc dot gnu.org via Gcc-bugs

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

Xi Ruoyao  changed:

   What|Removed |Added

 CC||xry111 at gcc dot gnu.org

--- Comment #9 from Xi Ruoyao  ---
Useful for LoongArch too.  And now we already have bitreverse RTX code since
r14-1586.

Re: [PATCH v6] RISC-V:Optimize the MASK opt generation

2023-10-02 Thread Gerald Pfeifer

On Mon, 2 Oct 2023, Kito Cheng wrote:
> Thanks for reporting this issue, I just realized multidimensional
> arrays are gawk extensions, could you try the attached patch to see if
> it can resolve the issue?

Yes, with that patch applied the build proceeds far beyond that point
(still running).

Thanks for the quick fix!

Gerald

[Bug middle-end/51446] -fno-trapping-math generates NaN constant with different sign

2023-10-02 Thread amonakov at gcc dot gnu.org via Gcc-bugs

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

Alexander Monakov  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org

--- Comment #21 from Alexander Monakov  ---
Bug 111655 is not a dup, I left a comment and reopened.

[Bug target/111655] [11/12/13/14 Regression] wrong code generated for __builtin_signbit and 0./0. on x86-64 -O2

2023-10-02 Thread amonakov at gcc dot gnu.org via Gcc-bugs

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

Alexander Monakov  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org
 Ever confirmed|0   |1
Summary|wrong code generated for|[11/12/13/14 Regression]
   |__builtin_signbit and 0./0. |wrong code generated for
   |on x86-64 -O2   |__builtin_signbit and 0./0.
   ||on x86-64 -O2
 Resolution|DUPLICATE   |---
 Status|RESOLVED|NEW
   Last reconfirmed||2023-10-02

--- Comment #9 from Alexander Monakov  ---
It's true that the sign of 0./0 is unpredictable, but we can fold it only when
the division is being eliminated by the folding. 

It's fine to fold

  t = 0./0;
  s = __builtin_signbit(t);

to

  s = 0

with t eliminated from IR, but it's not OK to fold

  t = 0./0
  s = __builtin_signbit(t);

to

  t = 0./0
  s = 0

because the resulting program runs as if 0./0 was evaluated twice, first to a
positive NaN (which was used for signbit), then to a negative NaN (which fed
the following computations). This is not allowed.

This bug was incorrectly classified as a dup. The fix is either to not fold
this, or fold only when we know that the division will be eliminated (e.g. the
only use was in the signbit). Reopening.

[Bug tree-optimization/109154] [13/14 regression] jump threading de-optimizes nested floating point comparisons

2023-10-02 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

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

--- Comment #69 from CVS Commits  ---
The master branch has been updated by Tamar Christina :

https://gcc.gnu.org/g:19610580d49f3d2d8d511fba55b39efa0764dfc2

commit r14-4361-g19610580d49f3d2d8d511fba55b39efa0764dfc2
Author: Tamar Christina 
Date:   Mon Oct 2 11:48:26 2023 +0100

ifcvt: replace C++ sort with vec::qsort [PR109154]

As requested later on, this replaces the C++ sort with vec::qsort.

gcc/ChangeLog:

PR tree-optimization/109154
* tree-if-conv.cc (INCLUDE_ALGORITHM): Remove.
(cmp_arg_entry): New.
(predicate_scalar_phi): Use it.

[Bug fortran/111661] New: [OpenACC] Detach+Attach of DT component gives libgomp: [0x405140,96] is not mapped

2023-10-02 Thread burnus at gcc dot gnu.org via Gcc-bugs

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

Bug ID: 111661
   Summary: [OpenACC] Detach+Attach of DT component gives libgomp:
[0x405140,96] is not mapped
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: openacc
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
CC: patrick.be...@univ-grenoble-alpes.fr,
tschwinge at gcc dot gnu.org
  Target Milestone: ---

Reported by Patrick. The following snippet gives:

libgomp: [0x406180,96] is not mapped

with GCC (mainline) and reportedly likewise GCC 13.2 but working with the
Nvidia and Cray compiler (see comments in the snipped). [Same result with an
older OG13 build: 13.1.1 20230710 [OG13].]


The problem seems to be the 'acc update' command. Here,
  0x406180
is the host address of 'tab':
  406180- tab - host
 1847B20- tab%val - host
  130414- tab - device
  1304140200- tab%val - device
  406180- tab - host
 18FF8C0- tab%val - host

libgomp: [0x406180,96] is not mapped


In other words, the DETACH seems to not only DETACH 'tab%val' but also somehow
unmap 'tab'?

#pragma omp target oacc_exit_data map(delete:tab.val.data [len: 88])
map(delete:MEM  [(real(kind=8)[0:] *)_34] [len: _33])
map(to:tab.val [pointer set, len: 88]) map(force_detach:tab.val.data [bias: 0])
finalize

...
  #pragma omp target oacc_update map(force_to:tab [len: 96])



!--cut---
use iso_c_binding
implicit none

type r2tab
 double precision, dimension(:,:), allocatable :: val
 integer :: dim1
 integer :: dim2
 end type r2tab
   type(r2tab) :: tab
   integer :: i,j
   integer(c_intptr_t) :: iloc(2)

   !$acc enter data copyin(tab)
   tab%dim1 = 10
   tab%dim2 = 20
   allocate (tab%val(tab%dim1,tab%dim2))
print '(z16,a)', loc(tab), "- tab - host"
print '(z16,a)', loc(tab%val), "- tab%val - host"
   !$acc enter data copyin(tab%val)
!$acc serial copyout(iloc)
iloc(1) = loc(tab)
iloc(2) = loc(tab%val)
!$acc end serial
print '(z16,a)', iloc(1), "- tab - device"
print '(z16,a)', iloc(2), "- tab%val - device"


!...   
   !$acc exit data delete(tab%val) finalize
! Works as is with nvfortran and CCE ftn but gfortran 13 requires
! additionally:
!  !$acc exit data delete(tab) finalize

   tab%dim1=11
   tab%dim2=30
   deallocate(tab%val)
   allocate (tab%val(tab%dim1,tab%dim2))
print '(z16,a)', loc(tab), "- tab - host"
print '(z16,a)', loc(tab%val), "- tab%val - host"
! For nvfortran and ftn:
   !$acc update device(tab)
! gfortran with the change above requires instead:
! !$acc enter data copyin(tab)

   !$acc enter data create(tab%val)
!$acc parallel loop
  do j = 1, tab%dim2
do i = 1, tab%dim1
  tab%val(i,j) = j * 100 + i
end do
  end do
!$acc end  parallel loop
!$acc exit data copyout(tab%val) finalize
!$acc exit data delete(tab)

  do j = 1, tab%dim2
do i = 1, tab%dim1
  if (tab%val(i,j) /= j * 100 + i) error stop
end do
  end do
end

[Bug c/111654] Introduce clang's invalid-noreturn warning

2023-10-02 Thread sjames at gcc dot gnu.org via Gcc-bugs

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

--- Comment #3 from Sam James  ---
It would be worth mentioning that then.

Anyway:
*
https://inbox.sourceware.org/gcc-patches/cap2b4gmq7btqtequuuok7ojt8p3kdbdvpudrmo_nt95wumw...@mail.gmail.com/
*
https://inbox.sourceware.org/gcc-patches/cap2b4gmfj0gx_aahmu4xcnq2l6doohr8pftzpyq4mccdzh-...@mail.gmail.com/

[Bug c/111654] Introduce clang's invalid-noreturn warning

2023-10-02 Thread tanksherman27 at gmail dot com via Gcc-bugs

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

--- Comment #2 from Julian Waters  ---
(In reply to Manuel López-Ibáñez from comment #1)
> (In reply to Julian Waters from comment #0)
> > Created attachment 56022 [details]
> > Patch to add invalid-noreturn to gcc
> 
> Patches should be submitted to gcc-patc...@gcc.gnu.org
> 
> For more details, please read:
> https://gcc.gnu.org/wiki/GettingStarted#Basics:
> _Contributing_to_GCC_in_10_easy_steps
> 
> Except for clang compatibility, I believe the consensus is that numerical
> levels are not user-friendly. I think it would be better to have:
> 
> -Wnoreturn-implicit-return
> -Wnoreturn-explicit-return
> 
> -Winvalid-noreturn enables / disables both.

Yeah, I did try submitting it to gcc-patches, but it simply went ignored for
forever, so I decided to submit the patch through the bug system instead, like
others have done. I implemented it as numeric values to avoid inventing new
names for -Woption and because it was easier to implement for a gcc beginner
like myself, so worded warnings are likely to take me longer to implement

1 2 >

1 - 100 of 125 matches

Mail list logo