[Bug libstdc++/110050] experimental/simd/pr109822_cast_functions.cc fails on arm after g:668d43502f465d48adbc1fe2956b979f36657e5f

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #6 from Richard Biener  ---
Fixed I suppose.

[Bug libstdc++/110050] experimental/simd/pr109822_cast_functions.cc fails on arm after g:668d43502f465d48adbc1fe2956b979f36657e5f

[mkretz at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #7 from Matthias Kretz (Vir)  ---
Yes, I still need to backport because the new test is also present on the
branches.

[Bug middle-end/110055] Dangling pointer warning inside std::vector on RISC-V

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #6 from Richard Biener  ---
confirmed - that's quite an odd thing.  gimplify_init_constructor creates this
constant pool entry, not sure who ends up ending its lifetime.

[Bug middle-end/110055] Dangling pointer warning inside std::vector on RISC-V

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #7 from Richard Biener  ---
The clobber is built by gimplify_target_expr and TARGET_EXPR_SLOT is changed
in place to the static variable.

Does the following fix the RISC-V issue?

diff --git a/gcc/gimplify.cc b/gcc/gimplify.cc
index ade6e335da7..aece89a3e9b 100644
--- a/gcc/gimplify.cc
+++ b/gcc/gimplify.cc
@@ -7154,8 +7154,10 @@ gimplify_target_expr (tree *expr_p, gimple_seq *pre_p,
gimple_seq *post_p)
gimplify_and_add (init, &init_pre_p);

   /* Add a clobber for the temporary going out of scope, like
-gimplify_bind_expr.  */
+gimplify_bind_expr.  But only if we did not promote the
+temporary to static storage.  */
   if (gimplify_ctxp->in_cleanup_point_expr
+ && !TREE_STATIC (temp)
  && needs_to_live_in_memory (temp))
{
  if (flag_stack_reuse == SR_ALL)

[Bug rtl-optimization/58517] ifcvt (after combine) puts ccreg clobbering insn between ccset insn and ccreg use

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #11 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #9)
> The reason why r6-3654-g6b7e867187889 didn't fix this case is because it was
> not looking into clobbers only the set side. 
> 
> Note the conditional in my patch should have been
> if (reg_overlap_mentioned_p (DF_REF_REG (def), cond))
> 
> Maybe it should be bb_valid_for_noce_process_p instead, I am not 100% sure
> on that.

This does not fix the issue as (In reply to Andrew Pinski from comment #9)
> The reason why r6-3654-g6b7e867187889 didn't fix this case is because it was
> not looking into clobbers only the set side. 
> 
> Note the conditional in my patch should have been
> if (reg_overlap_mentioned_p (DF_REF_REG (def), cond))
> 
> Maybe it should be bb_valid_for_noce_process_p instead, I am not 100% sure
> on that.

This patch is not enough. Though the patch in comment #4 is not enough any more
either.

[Bug target/110059] When SPEC is used to test the GCC (10.3.1), the test result of subitem 548 fluctuates abnormally.

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #5 from Richard Biener  ---
The "after revert" numbers fluctuate more, so not sure what you are after.

[Bug target/109972] RISC-V: Could use umodsi3/udivsi3/divsi3 libcalls for 32-bit division/remainder on RV64 without M extension

[kito at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from Kito Cheng  ---
We care but it's lower priority compare to other configuration, so create bug
to tracking here should be best solution for now :P

[Bug tree-optimization/110062] missed vectorization in graphicsmagick

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org
 Status|UNCONFIRMED |WAITING
 Ever confirmed|0   |1
   Last reconfirmed||2023-06-02

--- Comment #2 from Richard Biener  ---
Can you produce a testcase for the loop?

[Bug c++/110064] spurious missing initializer for member for anonymous

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||diagnostic
   Last reconfirmed||2023-06-02
  Known to fail||11.3.0, 12.3.0, 13.1.0,
   ||14.0
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
I suppose it's the field for the B base (which is empty).  Confirmed.

[Bug tree-optimization/110067] [14 Regression] Wrong code on pixman-0.42.2

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Priority|P3  |P1
   Last reconfirmed||2023-06-02
 Ever confirmed|0   |1

[Bug fortran/87477] [meta-bug] [F03] issues concerning the ASSOCIATE statement

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Paul Thomas :

https://gcc.gnu.org/g:3c2eba4b7a2355ed5099e35332388206c484744d

commit r14-1487-g3c2eba4b7a2355ed5099e35332388206c484744d
Author: Paul Thomas 
Date:   Fri Jun 2 08:41:45 2023 +0100

Fortran: Fix some problems blocking associate meta-bug [PR87477]

2023-06-02  Paul Thomas  

gcc/fortran
PR fortran/87477
* parse.cc (parse_associate): Replace the existing evaluation
of the target rank with calls to gfc_resolve_ref and
gfc_expression_rank. Identify untyped target function results
with structure constructors by finding the appropriate derived
type.
* resolve.cc (resolve_symbol): Allow associate variables to be
assumed shape.

gcc/testsuite/
PR fortran/87477
* gfortran.dg/associate_54.f90 : Cope with extra error.

PR fortran/102109
* gfortran.dg/pr102109.f90 : New test.

PR fortran/102112
* gfortran.dg/pr102112.f90 : New test.

PR fortran/102190
* gfortran.dg/pr102190.f90 : New test.

PR fortran/102532
* gfortran.dg/pr102532.f90 : New test.

PR fortran/109948
* gfortran.dg/pr109948.f90 : New test.

PR fortran/99326
* gfortran.dg/pr99326.f90 : New test.

[Bug fortran/102112] Cannot associate with component of associate target

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Paul Thomas :

https://gcc.gnu.org/g:3c2eba4b7a2355ed5099e35332388206c484744d

commit r14-1487-g3c2eba4b7a2355ed5099e35332388206c484744d
Author: Paul Thomas 
Date:   Fri Jun 2 08:41:45 2023 +0100

Fortran: Fix some problems blocking associate meta-bug [PR87477]

2023-06-02  Paul Thomas  

gcc/fortran
PR fortran/87477
* parse.cc (parse_associate): Replace the existing evaluation
of the target rank with calls to gfc_resolve_ref and
gfc_expression_rank. Identify untyped target function results
with structure constructors by finding the appropriate derived
type.
* resolve.cc (resolve_symbol): Allow associate variables to be
assumed shape.

gcc/testsuite/
PR fortran/87477
* gfortran.dg/associate_54.f90 : Cope with extra error.

PR fortran/102109
* gfortran.dg/pr102109.f90 : New test.

PR fortran/102112
* gfortran.dg/pr102112.f90 : New test.

PR fortran/102190
* gfortran.dg/pr102190.f90 : New test.

PR fortran/102532
* gfortran.dg/pr102532.f90 : New test.

PR fortran/109948
* gfortran.dg/pr109948.f90 : New test.

PR fortran/99326
* gfortran.dg/pr99326.f90 : New test.

[Bug fortran/102109] Associate to construct compound object results in incorrect type inferred

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Paul Thomas :

https://gcc.gnu.org/g:3c2eba4b7a2355ed5099e35332388206c484744d

commit r14-1487-g3c2eba4b7a2355ed5099e35332388206c484744d
Author: Paul Thomas 
Date:   Fri Jun 2 08:41:45 2023 +0100

Fortran: Fix some problems blocking associate meta-bug [PR87477]

2023-06-02  Paul Thomas  

gcc/fortran
PR fortran/87477
* parse.cc (parse_associate): Replace the existing evaluation
of the target rank with calls to gfc_resolve_ref and
gfc_expression_rank. Identify untyped target function results
with structure constructors by finding the appropriate derived
type.
* resolve.cc (resolve_symbol): Allow associate variables to be
assumed shape.

gcc/testsuite/
PR fortran/87477
* gfortran.dg/associate_54.f90 : Cope with extra error.

PR fortran/102109
* gfortran.dg/pr102109.f90 : New test.

PR fortran/102112
* gfortran.dg/pr102112.f90 : New test.

PR fortran/102190
* gfortran.dg/pr102190.f90 : New test.

PR fortran/102532
* gfortran.dg/pr102532.f90 : New test.

PR fortran/109948
* gfortran.dg/pr109948.f90 : New test.

PR fortran/99326
* gfortran.dg/pr99326.f90 : New test.

[Bug fortran/99326] [10/11/12/13/14 Regression] ICE in gfc_build_dummy_array_decl, at fortran/trans-decl.c:1299

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Paul Thomas :

https://gcc.gnu.org/g:3c2eba4b7a2355ed5099e35332388206c484744d

commit r14-1487-g3c2eba4b7a2355ed5099e35332388206c484744d
Author: Paul Thomas 
Date:   Fri Jun 2 08:41:45 2023 +0100

Fortran: Fix some problems blocking associate meta-bug [PR87477]

2023-06-02  Paul Thomas  

gcc/fortran
PR fortran/87477
* parse.cc (parse_associate): Replace the existing evaluation
of the target rank with calls to gfc_resolve_ref and
gfc_expression_rank. Identify untyped target function results
with structure constructors by finding the appropriate derived
type.
* resolve.cc (resolve_symbol): Allow associate variables to be
assumed shape.

gcc/testsuite/
PR fortran/87477
* gfortran.dg/associate_54.f90 : Cope with extra error.

PR fortran/102109
* gfortran.dg/pr102109.f90 : New test.

PR fortran/102112
* gfortran.dg/pr102112.f90 : New test.

PR fortran/102190
* gfortran.dg/pr102190.f90 : New test.

PR fortran/102532
* gfortran.dg/pr102532.f90 : New test.

PR fortran/109948
* gfortran.dg/pr109948.f90 : New test.

PR fortran/99326
* gfortran.dg/pr99326.f90 : New test.

[Bug fortran/102190] Syntax error reported in associate construct

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Paul Thomas :

https://gcc.gnu.org/g:3c2eba4b7a2355ed5099e35332388206c484744d

commit r14-1487-g3c2eba4b7a2355ed5099e35332388206c484744d
Author: Paul Thomas 
Date:   Fri Jun 2 08:41:45 2023 +0100

Fortran: Fix some problems blocking associate meta-bug [PR87477]

2023-06-02  Paul Thomas  

gcc/fortran
PR fortran/87477
* parse.cc (parse_associate): Replace the existing evaluation
of the target rank with calls to gfc_resolve_ref and
gfc_expression_rank. Identify untyped target function results
with structure constructors by finding the appropriate derived
type.
* resolve.cc (resolve_symbol): Allow associate variables to be
assumed shape.

gcc/testsuite/
PR fortran/87477
* gfortran.dg/associate_54.f90 : Cope with extra error.

PR fortran/102109
* gfortran.dg/pr102109.f90 : New test.

PR fortran/102112
* gfortran.dg/pr102112.f90 : New test.

PR fortran/102190
* gfortran.dg/pr102190.f90 : New test.

PR fortran/102532
* gfortran.dg/pr102532.f90 : New test.

PR fortran/109948
* gfortran.dg/pr109948.f90 : New test.

PR fortran/99326
* gfortran.dg/pr99326.f90 : New test.

[Bug fortran/102532] [10/11/12/13/14 Regression] ICE in gfc_get_corank, at fortran/expr.c:5769

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Paul Thomas :

https://gcc.gnu.org/g:3c2eba4b7a2355ed5099e35332388206c484744d

commit r14-1487-g3c2eba4b7a2355ed5099e35332388206c484744d
Author: Paul Thomas 
Date:   Fri Jun 2 08:41:45 2023 +0100

Fortran: Fix some problems blocking associate meta-bug [PR87477]

2023-06-02  Paul Thomas  

gcc/fortran
PR fortran/87477
* parse.cc (parse_associate): Replace the existing evaluation
of the target rank with calls to gfc_resolve_ref and
gfc_expression_rank. Identify untyped target function results
with structure constructors by finding the appropriate derived
type.
* resolve.cc (resolve_symbol): Allow associate variables to be
assumed shape.

gcc/testsuite/
PR fortran/87477
* gfortran.dg/associate_54.f90 : Cope with extra error.

PR fortran/102109
* gfortran.dg/pr102109.f90 : New test.

PR fortran/102112
* gfortran.dg/pr102112.f90 : New test.

PR fortran/102190
* gfortran.dg/pr102190.f90 : New test.

PR fortran/102532
* gfortran.dg/pr102532.f90 : New test.

PR fortran/109948
* gfortran.dg/pr109948.f90 : New test.

PR fortran/99326
* gfortran.dg/pr99326.f90 : New test.

[Bug fortran/109948] [13/14 Regression] ICE(segfault) in gfc_expression_rank() from gfc_op_rank_conformable()

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #18 from CVS Commits  ---
The master branch has been updated by Paul Thomas :

https://gcc.gnu.org/g:3c2eba4b7a2355ed5099e35332388206c484744d

commit r14-1487-g3c2eba4b7a2355ed5099e35332388206c484744d
Author: Paul Thomas 
Date:   Fri Jun 2 08:41:45 2023 +0100

Fortran: Fix some problems blocking associate meta-bug [PR87477]

2023-06-02  Paul Thomas  

gcc/fortran
PR fortran/87477
* parse.cc (parse_associate): Replace the existing evaluation
of the target rank with calls to gfc_resolve_ref and
gfc_expression_rank. Identify untyped target function results
with structure constructors by finding the appropriate derived
type.
* resolve.cc (resolve_symbol): Allow associate variables to be
assumed shape.

gcc/testsuite/
PR fortran/87477
* gfortran.dg/associate_54.f90 : Cope with extra error.

PR fortran/102109
* gfortran.dg/pr102109.f90 : New test.

PR fortran/102112
* gfortran.dg/pr102112.f90 : New test.

PR fortran/102190
* gfortran.dg/pr102190.f90 : New test.

PR fortran/102532
* gfortran.dg/pr102532.f90 : New test.

PR fortran/109948
* gfortran.dg/pr109948.f90 : New test.

PR fortran/99326
* gfortran.dg/pr99326.f90 : New test.

[Bug middle-end/109505] (t | 15) & svcntb() causes an OOM/ICE

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #26 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Richard Biener
:

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

commit r11-10840-gbfa476528ceeac96865a48c49f3f1a15d566d209
Author: Richard Biener 
Date:   Wed Feb 23 13:47:01 2022 +0100

middle-end/109505 - backport match.pd ! support for GENERIC

The patch adds support for the ! modifier to GENERIC, backported
from r12-7361-gfdc46830f1b793.

2023-06-02  Richard Biener  

PR tree-optimization/109505
* doc/match-and-simplify.texi: Amend ! documentation.
* genmatch.c (expr::gen_transform): Code-generate ! support
for GENERIC.
(parser::parse_expr): Allow ! for GENERIC.

[Bug middle-end/109505] (t | 15) & svcntb() causes an OOM/ICE

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #27 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Richard Biener
:

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

commit r11-10841-gca4a4cc0060cb8ae1a326d6dbfcd9459452e1574
Author: Jakub Jelinek 
Date:   Sun May 21 13:36:56 2023 +0200

match.pd: Ensure (op CONSTANT_CLASS_P CONSTANT_CLASS_P) is simplified
[PR109505]

On the following testcase we hang, because POLY_INT_CST is
CONSTANT_CLASS_P,
but BIT_AND_EXPR with it and INTEGER_CST doesn't simplify and the
(x | CST1) & CST2 -> (x & CST2) | (CST1 & CST2)
simplification actually relies on the (CST1 & CST2) simplification,
otherwise it is a deoptimization, trading 2 ops for 3 and furthermore
running into
/* Given a bit-wise operation CODE applied to ARG0 and ARG1, see if both
   operands are another bit-wise operation with a common input.  If so,
   distribute the bit operations to save an operation and possibly two if
   constants are involved.  For example, convert
 (A | B) & (A | C) into A | (B & C)
   Further simplification will occur if B and C are constants.  */
simplification which simplifies that
(x & CST2) | (CST1 & CST2) back to
CST2 & (x | CST1).
I went through all other places I could find where we have a simplification
with 2 CONSTANT_CLASS_P operands and perform some operation on those two,
while the other spots aren't that severe (just trade 2 operations for
another 2 if the two constants don't simplify, rather than as in the above
case trading 2 ops for 3), I still think all those spots really intend
to optimize only if the 2 constants simplify.

So, the following patch adds to those a ! modifier to ensure that,
even at GENERIC that modifier means !EXPR_P which is exactly what we want
IMHO.

2023-05-21  Jakub Jelinek  

PR tree-optimization/109505
* match.pd ((x | CST1) & CST2 -> (x & CST2) | (CST1 & CST2),
Combine successive equal operations with constants,
(A +- CST1) +- CST2 -> A + CST3, (CST1 - A) +- CST2 -> CST3 - A,
CST1 - (CST2 - A) -> CST3 + A): Use ! on ops with 2
CONSTANT_CLASS_P
operands.

* gcc.target/aarch64/sve/pr109505.c: New test.

(cherry picked from commit f211757f6fa9515e3fd1a4f66f1a8b48e500c9de)

[Bug middle-end/109505] (t | 15) & svcntb() causes an OOM/ICE

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
  Known to work||11.4.1

--- Comment #28 from Richard Biener  ---
Fixed.

[Bug bootstrap/82856] --enable-maintainter-mode broken by incompatiblity of gcc's required automake and modern Perl

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #15 from CVS Commits  ---
The master branch has been updated by Thomas Schwinge :

https://gcc.gnu.org/g:9edb6725717d668d144b2075f0dabf03ac4ec3d8

commit r14-1488-g9edb6725717d668d144b2075f0dabf03ac4ec3d8
Author: Thomas Schwinge 
Date:   Mon May 15 20:55:11 2023 +0200

Back to requiring "Perl version 5.6.1 (or later)" [PR82856]

With Subversion r265695 (Git commit
22e052725189a472e4e86ebb6595278a49f4bcdd)
"Update GCC to autoconf 2.69, automake 1.15.1 (PR bootstrap/82856)" we're
back
to normal; per Automake 1.15.1 'configure.ac' still "[...] perl 5.6 or
better
is required [...]".

PR bootstrap/82856
gcc/
* doc/install.texi (Perl): Back to requiring "Perl version 5.6.1
(or
later)".

[Bug gcov-profile/110074] -fprofile-arcs profiles arcs generated by -fsanitize=bounds

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from Richard Biener  ---
The profiling code cannot tell that apart, and yes, with sanitize recover we
should.  In principle we could detect all sanitizer calls to be in cold paths
during profile estimation and have a profile instrumentation mode ignoring
statically predicted (with good quality) branches.  But that would mean to
build a shadow CFG to compute the counter inserts then.

[Bug testsuite/66005] libgomp make check time is excessive

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #17 from CVS Commits  ---
The master branch has been updated by Thomas Schwinge :

https://gcc.gnu.org/g:04abe1944d30eb18a2060cfcd9695d085f7b4752

commit r14-1490-g04abe1944d30eb18a2060cfcd9695d085f7b4752
Author: Thomas Schwinge 
Date:   Mon May 15 20:00:07 2023 +0200

Support parallel testing in libgomp: fallback Perl 'flock' [PR66005]

Follow-up to commit 6c3b30ef9e0578509bdaf59c13da4a212fe6c2ba
"Support parallel testing in libgomp, part II [PR66005]"
("..., and enable if 'flock' is available for serializing execution
testing"),
where we saw:

> On my Dell Precision 7530 laptop:
>
> $ uname -srvi
> Linux 5.15.0-71-generic #78-Ubuntu SMP Tue Apr 18 09:00:29 UTC 2023
x86_64
> $ grep '^model name' < /proc/cpuinfo | uniq -c
>  12 model name  : Intel(R) Core(TM) i7-8850H CPU @ 2.60GHz
> $ nvidia-smi -L
> GPU 0: Quadro P1000 (UUID: GPU-e043973b-b52a-d02b-c066-a8fdbf64e8ea)
>
> ... [...]: case (c) standard configuration, no offloading
> configured, [...]

> $ \time make check-target-libgomp
>
> Case (c), baseline; [...]:
>
> 1180.98user 110.80system 19:36.40elapsed 109%CPU (0avgtext+0avgdata
505148maxresident)k
> 1133.22user 111.08system 19:35.75elapsed 105%CPU (0avgtext+0avgdata
505212maxresident)k
>
> Case (c), parallelized [using 'flock']:
>
> [...]
> -j12 GCC_TEST_PARALLEL_SLOTS=12
> 2591.04user 192.64system 4:44.98elapsed 976%CPU (0avgtext+0avgdata
505216maxresident)k
> 2581.23user 195.21system 4:47.51elapsed 965%CPU (0avgtext+0avgdata
505212maxresident)k

Quite the same when instead of 'flock' using this fallback Perl 'flock':

2565.23user 194.35system 4:46.77elapsed 962%CPU (0avgtext+0avgdata
505216maxresident)k
2549.38user 200.20system 4:46.08elapsed 961%CPU (0avgtext+0avgdata
505216maxresident)k

PR testsuite/66005
gcc/
* doc/install.texi: Document (optional) Perl usage for parallel
testing of libgomp.
libgomp/
* testsuite/lib/libgomp.exp: 'flock' through stdout.
* testsuite/flock: New.
* configure.ac (FLOCK): Point to that if no 'flock' available, but
'perl' is.
* configure: Regenerate.

[Bug fortran/83154] ICE: associate and coarrays

[pault at gcc dot gnu.org via Gcc-bugs]

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #3 from Paul Thomas  ---
Fixed on 12.2.1 20230321 through to trunk.

It must have been fixed as a result of other work on associate.

Paul

[Bug fortran/87477] [meta-bug] [F03] issues concerning the ASSOCIATE statement

[pault at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87477
Bug 87477 depends on bug 83154, which changed state.

Bug 83154 Summary: ICE: associate and coarrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83154

   What|Removed |Added

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

[Bug fortran/83700] [Meta-bug] Fortran Coarray issues

[pault at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83700
Bug 83700 depends on bug 83154, which changed state.

Bug 83154 Summary: ICE: associate and coarrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83154

   What|Removed |Added

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

[Bug tree-optimization/110080] [13/14 Regression] Missed Dead Code Elimination at -Os when using __builtin_unreachable since r13-6945-g429a7a88438

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |13.2
   Keywords||missed-optimization

[Bug tree-optimization/110067] [14 Regression] Wrong code on pixman-0.42.2

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #7 from Hongtao.liu  ---
A patch is posted at
https://gcc.gnu.org/pipermail/gcc-patches/2023-June/620324.html

[Bug fortran/85510] [10/11/12/13/14 Regression][Coarray] Linking error when accessing a coindexed variable inside an associate block

[pault at gcc dot gnu.org via Gcc-bugs]

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

Paul Thomas  changed:

   What|Removed |Added

 CC||pault at gcc dot gnu.org

--- Comment #10 from Paul Thomas  ---
(In reply to Damian Rouson from comment #0)
> The code below compiles without error with -fcoarray=single; whereas
> compiling with -fcoarray=lib generates the link-time error message shown
> with the gfortran 7.2.0 and with the trunk dated 20180412.  The gfortran
> command comes from the output of the OpenCoarrays command 'caf --show'. Some
> of the paths have been shortened manually for presentation purposes:
> 

Hi Damian,

Could you check, please, whether or not this still fails?

Thanks

Paul

[Bug rtl-optimization/58517] ifcvt (after combine) puts ccreg clobbering insn between ccset insn and ccreg use

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

  Attachment #55237|0   |1
is obsolete||

--- Comment #12 from Andrew Pinski  ---
Created attachment 55239
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55239&action=edit
Patch which does work on this

Though, I need to double to make sure it works for other cases still.
sh is the case where we have a non-CC mode register for the flags which is why
this was harder than other targets.

[Bug fortran/87477] [meta-bug] [F03] issues concerning the ASSOCIATE statement

[pault at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87477
Bug 87477 depends on bug 87430, which changed state.

Bug 87430 Summary: [10/11/12/13/14 Regression] ICE in fortran/trans-types.c:1157
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87430

   What|Removed |Added

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

[Bug fortran/87430] [10/11/12/13/14 Regression] ICE in fortran/trans-types.c:1157

[pault at gcc dot gnu.org via Gcc-bugs]

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

Paul Thomas  changed:

   What|Removed |Added

 CC||pault at gcc dot gnu.org
 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #9 from Paul Thomas  ---
Fixed on 13-branch through to trunk.

Gives a fatal error now: " i at (1) has no default type"

Paul

[Bug gcov-profile/110082] Coverage analysis vs. offloading compilation

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

 CC||sebastian.huber@embedded-br
   ||ains.de

--- Comment #1 from Richard Biener  ---
Sebastian was also working in this area.  Note that when you do it as proposed
the code will appear as having no coverage (the counters will be allocated at
the host side but nothing will increment them).

I suppose the very same issue exists for -fprofile-generate/use then where
this will then cause the offload code to be optimized for size because
it's cold (unless you use -fprofile-partial-training)?

[Bug fortran/87460] [F03] accepts-invalid bug with ASSOCIATE and array argument

[pault at gcc dot gnu.org via Gcc-bugs]

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

Paul Thomas  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 CC||pault at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #4 from Paul Thomas  ---
Fixed back to 10.2.1 20210315 at least.

This must be a case of co-lateral repair!

Paul

[Bug fortran/87477] [meta-bug] [F03] issues concerning the ASSOCIATE statement

[pault at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87477
Bug 87477 depends on bug 87460, which changed state.

Bug 87460 Summary: [F03] accepts-invalid bug with ASSOCIATE and array argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87460

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

[Bug fortran/89645] No IMPLICIT type error with: ASSOCIATE( X => function() )

[pault at gcc dot gnu.org via Gcc-bugs]

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

Paul Thomas  changed:

   What|Removed |Added

 CC||pault at gcc dot gnu.org

--- Comment #2 from Paul Thomas  ---
Hi Ian,

This is one of two PRs (cf. 99065) that expose a really nasty fault with
gfortran parsing. If you interchange 's' and 'fun', you will find that the
testcase compiles and runs.

The fixup for intrinsic types works fine but, unfortunately, the derived type
is need for parsing the associate block itself.

I am girding my loins to fight the good fight.

Thanks for this posting.

Paul

[Bug fortran/93338] [10/11/12/13/14 Regression] ICE in make_ssa_name_fn, at tree-ssanames.c:282

[pault at gcc dot gnu.org via Gcc-bugs]

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #14 from Paul Thomas  ---
Since this is "auto-fixed" back to 12-branch, I am closing this PR.

Thanks for the report.

Paul

[Bug fortran/87477] [meta-bug] [F03] issues concerning the ASSOCIATE statement

[pault at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87477
Bug 87477 depends on bug 93338, which changed state.

Bug 93338 Summary: [10/11/12/13/14 Regression] ICE in make_ssa_name_fn, at 
tree-ssanames.c:282
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93338

   What|Removed |Added

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

[Bug fortran/95068] [10/11/12/13/14 Regression] ICE in gfc_get_class_from_expr, at fortran/trans-expr.c:484

[pault at gcc dot gnu.org via Gcc-bugs]

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #6 from Paul Thomas  ---
This bug is "auto-fixed" on trunk. I will close the PR for housekeeping
purposes but will ensure that the backport of all recent associate patches do
fix this bug.

Thanks once more!

Paul

[Bug fortran/87477] [meta-bug] [F03] issues concerning the ASSOCIATE statement

[pault at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87477
Bug 87477 depends on bug 95068, which changed state.

Bug 95068 Summary: [10/11/12/13/14 Regression] ICE in gfc_get_class_from_expr, 
at fortran/trans-expr.c:484
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95068

   What|Removed |Added

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

[Bug fortran/99326] [10/11/12/13/14 Regression] ICE in gfc_build_dummy_array_decl, at fortran/trans-decl.c:1299

[pault at gcc dot gnu.org via Gcc-bugs]

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #7 from Paul Thomas  ---
This bug is "auto-fixed" on trunk. I will close the PR for housekeeping
purposes but will ensure that the backport of all recent associate patches do
fix this bug.

Thanks once more!

Paul

[Bug fortran/87477] [meta-bug] [F03] issues concerning the ASSOCIATE statement

[pault at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87477
Bug 87477 depends on bug 99326, which changed state.

Bug 99326 Summary: [10/11/12/13/14 Regression] ICE in 
gfc_build_dummy_array_decl, at fortran/trans-decl.c:1299
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99326

   What|Removed |Added

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

[Bug target/110086] New: ICE when optimization level is changed using optimize attribute

[senthil.thecoder at gmail dot com via Gcc-bugs]

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

Bug ID: 110086
   Summary: ICE when optimization level is changed using optimize
attribute
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: senthil.thecoder at gmail dot com
  Target Milestone: ---

Compiler crashes with an ICE for the below code. 

Already seen in regression runs (gcc.c-torture/compile/pr104327.c, for e.g.).

$ cat optimize-attrib.c 
void __attribute__((optimize("O0"))) foo() {
}
$ avr-gcc -mmcu=avr51 optimize-attrib.c -Os
optimize-attrib.c:1:1: internal compiler error: 'global_options' are modified
in local context
1 | void __attribute__((optimize("O0"))) foo() {
  | ^~~~
0xd1288b cl_optimization_compare(gcc_options*, gcc_options*)
/home/toolsbuild/build/gcc/gcc/options-save.cc:13139
0x832d0c handle_optimize_attribute
/home/toolsbuild/code/gcc/gcc/c-family/c-attribs.cc:5689
0x6e8b58 decl_attributes(tree_node**, tree_node*, int, tree_node*)
/home/toolsbuild/code/gcc/gcc/attribs.cc:878
0x70fb4c start_function(c_declspecs*, c_declarator*, tree_node*)
/home/toolsbuild/code/gcc/gcc/c/c-decl.cc:10095
0x78eb0c c_parser_declaration_or_fndef
/home/toolsbuild/code/gcc/gcc/c/c-parser.cc:2742
0x797ec7 c_parser_external_declaration
/home/toolsbuild/code/gcc/gcc/c/c-parser.cc:1925
0x7987bd c_parser_translation_unit
/home/toolsbuild/code/gcc/gcc/c/c-parser.cc:1779
0x7987bd c_parse_file()
/home/toolsbuild/code/gcc/gcc/c/c-parser.cc:24657
0x813840 c_common_parse_file()
/home/toolsbuild/code/gcc/gcc/c-family/c-opts.cc:1248
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug target/109954] x86-64's -m32 does not conform to documentation

[tschwinge at gcc dot gnu.org via Gcc-bugs]

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

Thomas Schwinge  changed:

   What|Removed |Added

 CC||redi at gcc dot gnu.org,
   ||tschwinge at gcc dot gnu.org

--- Comment #17 from Thomas Schwinge  ---
I'm still confused.

Conversely this means that the x86_64 'm32' multilib isn't actually "code that
runs on any i386 system", right?  (Unless configured with suitable
'--with-arch-32=[32-bit x86]'.)

However, 'gcc/config/i386/i386.opt':

m32
Target RejectNegative Negative(m64) InverseMask(ISA_64BIT)
Var(ix86_isa_flags) Save
Generate 32bit i386 code.

Note: "32bit i386 code".

And, 'gcc/config/i386/x86-64.h'

#define ASM_SPEC "%{m16|m32:--32} %{m64:--64} %{mx32:--x32}"

Per 'info as':

The i386 version of 'as' has a few machine dependent options:

'--32 | --x32 | --64'
 Select the word size, either 32 bits or 64 bits.  '--32' implies
 Intel i386 architecture, while '--x32' and '--64' imply AMD x86-64
 architecture with 32-bit or 64-bit word-size respectively.

Note: "'--32' implies Intel i386 architecture" (thus, 32-bit x86 code?), again.

All that similar for the other related options, as has been mentioned already.

---

Do we need a different default '--with-arch-32=[...]' -- like a number of other
GCC configurations seem to be doing?  For example:

i[34567]86-*-solaris2* | x86_64-*-solaris2*)
[...]
with_arch_32=${with_arch_32:-pentium4}

mips*-img-linux*)
[...]
with_arch_32="mips32r6"
with_arch_64="mips64r6"

[Bug debug/110073] [14 regression] btfout.cc format errors break bootstrap

[iains at gcc dot gnu.org via Gcc-bugs]

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

Iain Sandoe  changed:

   What|Removed |Added

   Last reconfirmed||2023-06-02
 Ever confirmed|0   |1
 CC||iains at gcc dot gnu.org
 Target|i386-pc-solaris2.11 |i386-pc-solaris2.11,
   ||x86_64-apple-darwin*
 Status|UNCONFIRMED |NEW

--- Comment #2 from Iain Sandoe  ---
there seems to be a second fail on x86_64 darwin on line 970.

[Bug fortran/87477] [meta-bug] [F03] issues concerning the ASSOCIATE statement

[pault at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87477
Bug 87477 depends on bug 102109, which changed state.

Bug 102109 Summary: Associate to construct compound object results in incorrect 
type inferred
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102109

   What|Removed |Added

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

[Bug fortran/102109] Associate to construct compound object results in incorrect type inferred

[pault at gcc dot gnu.org via Gcc-bugs]

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #3 from Paul Thomas  ---
Hi Brad,

This is fixed on trunk (14-branch). I am going to close the PR for housekeeping
purposes but will be sure to include the patch in a cumulative backport.

Thanks for the report.

Paul

[Bug fortran/102109] Associate to construct compound object results in incorrect type inferred

[pault at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #4 from Paul Thomas  ---
Hi Brad,

This is fixed on trunk (14-branch). I am going to close the PR for housekeeping
purposes but will be sure to include the patch in a cumulative backport.

Thanks for the report.

Paul

[Bug target/109954] x86-64's -m32 does not conform to documentation

[jakub at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #18 from Jakub Jelinek  ---
i386 is an overloaded term, sometimes it means just i386 CPUs and not i486 and
later,
at other times it means the all CPUs capable of running i386 32-bit code,
sometimes it means ia32.
I don't think it would be a good idea to change the defaults, that would do
more harm than good and all users can pick their own defaults if they don't
like the defaults.

[Bug fortran/87477] [meta-bug] [F03] issues concerning the ASSOCIATE statement

[pault at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87477
Bug 87477 depends on bug 102112, which changed state.

Bug 102112 Summary: Cannot associate with component of associate target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102112

   What|Removed |Added

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

[Bug fortran/102112] Cannot associate with component of associate target

[pault at gcc dot gnu.org via Gcc-bugs]

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #3 from Paul Thomas  ---
Hi Brad,

This is fixed on trunk (14-branch). I am going to close the PR for housekeeping
purposes but will be sure to include the patch in a cumulative backport.

Thanks for the report.

Paul

[Bug fortran/102190] Syntax error reported in associate construct

[pault at gcc dot gnu.org via Gcc-bugs]

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #3 from Paul Thomas  ---
Hi Brad,

This is fixed on trunk (14-branch). I am going to close the PR for housekeeping
purposes but will be sure to include the patch in a cumulative backport.

Thanks for the report.

Paul

[Bug fortran/87477] [meta-bug] [F03] issues concerning the ASSOCIATE statement

[pault at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87477
Bug 87477 depends on bug 102190, which changed state.

Bug 102190 Summary: Syntax error reported in associate construct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102190

   What|Removed |Added

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

[Bug fortran/102532] [10/11/12/13/14 Regression] ICE in gfc_get_corank, at fortran/expr.c:5769

[pault at gcc dot gnu.org via Gcc-bugs]

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

Paul Thomas  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED

--- Comment #4 from Paul Thomas  ---
Hi Gerhard,

This is fixed on trunk (14-branch). I am going to close the PR for housekeeping
purposes but will be sure to include the patch in a cumulative backport.

Thanks for the report.

Paul

[Bug fortran/87477] [meta-bug] [F03] issues concerning the ASSOCIATE statement

[pault at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87477
Bug 87477 depends on bug 102532, which changed state.

Bug 102532 Summary: [10/11/12/13/14 Regression] ICE in gfc_get_corank, at 
fortran/expr.c:5769
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102532

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

[Bug target/109954] x86-64's -m32 does not conform to documentation

[jbeulich at suse dot com via Gcc-bugs]

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

--- Comment #19 from jbeulich at suse dot com ---
(In reply to Thomas Schwinge from comment #17)
> I'm still confused.
> 
> Conversely this means that the x86_64 'm32' multilib isn't actually "code
> that runs on any i386 system", right?  (Unless configured with suitable
> '--with-arch-32=[32-bit x86]'.)
> 
> However, 'gcc/config/i386/i386.opt':
> 
> m32
> Target RejectNegative Negative(m64) InverseMask(ISA_64BIT)
> Var(ix86_isa_flags) Save
> Generate 32bit i386 code.
> 
> Note: "32bit i386 code".

I think this wants correcting. Just "32-bit code" is accurate (with the
intentions explained throughout this bug) and then no longer misleading.

> Per 'info as':
> 
> The i386 version of 'as' has a few machine dependent options:
> 
> '--32 | --x32 | --64'
>  Select the word size, either 32 bits or 64 bits.  '--32' implies
>  Intel i386 architecture, while '--x32' and '--64' imply AMD x86-64
>  architecture with 32-bit or 64-bit word-size respectively.
> 
> Note: "'--32' implies Intel i386 architecture" (thus, 32-bit x86 code?),
> again.

Whereas no, in the x86 assembler it's different: No matter whether i386 or
x86-64, by default all extensions are enabled.

[Bug target/109954] x86-64's -m32 does not conform to documentation

[arsen at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #20 from Arsen Arsenović  ---
I agree, it's probably better to just update all references to be clear that
-m32 generates IA32 code, rather than i?86 code.

IMO, for multilib, it's reasonable to target the same CPU as -m64 in terms of
available extensions (as applicable), but in a different mode.

[Bug fortran/104430] [10 Regression] ICE in gfc_conv_component_ref, at fortran/trans-expr.cc:2742 since r9-3522-gd0477233215e37de

[pault at gcc dot gnu.org via Gcc-bugs]

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #9 from Paul Thomas  ---
I am closing this one but have flagged up the inclusion of the testcase in
comment  #7 for inclusion in the testsuite.

Cheers

Paul

[Bug fortran/87477] [meta-bug] [F03] issues concerning the ASSOCIATE statement

[pault at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87477
Bug 87477 depends on bug 104430, which changed state.

Bug 104430 Summary: [10 Regression] ICE in gfc_conv_component_ref, at 
fortran/trans-expr.cc:2742 since r9-3522-gd0477233215e37de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104430

   What|Removed |Added

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

[Bug fortran/106048] [10/11/12/13/14 Regression] ICE in ubsan_encode_value, at ubsan.cc:143 / verify_gimple failed

[pault at gcc dot gnu.org via Gcc-bugs]

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #3 from Paul Thomas  ---
This is fixed back to 12-branch. Closing.

Thanks for the report.

Paul

--- Comment #4 from Paul Thomas  ---
This is fixed back to 12-branch. Closing.

Thanks for the report.

Paul

[Bug fortran/87477] [meta-bug] [F03] issues concerning the ASSOCIATE statement

[pault at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87477
Bug 87477 depends on bug 106048, which changed state.

Bug 106048 Summary: [10/11/12/13/14 Regression] ICE in ubsan_encode_value, at 
ubsan.cc:143 / verify_gimple failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106048

   What|Removed |Added

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

[Bug fortran/106048] [10/11/12/13/14 Regression] ICE in ubsan_encode_value, at ubsan.cc:143 / verify_gimple failed

[pault at gcc dot gnu.org via Gcc-bugs]

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #3 from Paul Thomas  ---
This is fixed back to 12-branch. Closing.

Thanks for the report.

Paul

--- Comment #4 from Paul Thomas  ---
This is fixed back to 12-branch. Closing.

Thanks for the report.

Paul

[Bug target/110083] [14 Regression] ICEs for testcase on fp-int-convert*timode after r14-1466-g3635e8c67e1

[roger at nextmovesoftware dot com via Gcc-bugs]

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

Roger Sayle  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |roger at 
nextmovesoftware dot com
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2023-06-02
 Ever confirmed|0   |1

--- Comment #1 from Roger Sayle  ---
The latent issue exposed by my change is that REG_EQUAL notes on comparisons
are not (correctly) being updated during the STV pass.  The temporary work
around is -mno-stv, but I'm working on a patch so that the TImode
const_wide_int in the REG_EQUAL note is converted into a suitable CONST_VECTOR.

The silver lining is that using CCZmode for ptest is finding more optimization
opportunities than before, so that's a good thing.

[Bug fortran/109948] [13/14 Regression] ICE(segfault) in gfc_expression_rank() from gfc_op_rank_conformable()

[pault at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #19 from Paul Thomas  ---
(In reply to anlauf from comment #16)
> (In reply to Paul Thomas from comment #15)
> > Created attachment 55225 [details]
> > Fix for this PR
> > 
> > The attached patch substantially tidies up parse_associate and fixes:
> 
> LGTM!
> 
> I was close to proposing a hack for gfc_expression_rank that checks
> whether the variable's select_type_temporary, select_rank_temporary and
> associate_var attributes to decide which ref to evaluate.  But your
> patch seems to be a much better approach.
> 
> BTW: after your patch, the attribute assoc->rankguessed is no longer set.
> It is tested in two locations in resolve_assoc_var(resolve.cc), where
> it might be removed after your fix.

On the latter => yes indeed!

I see that I had a fix for pr109451, which was never submitted. I am going to
shake the dust off the patch and will set about removing rankguessed.

Thanks

Paul

[Bug fortran/109948] [13/14 Regression] ICE(segfault) in gfc_expression_rank() from gfc_op_rank_conformable()

[pault at gcc dot gnu.org via Gcc-bugs]

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #20 from Paul Thomas  ---
Fixed on trunk. I am closing the PR for housekeeping purposes but will include
the patch in future backports.

Thanks for the report.

Paul

[Bug fortran/87477] [meta-bug] [F03] issues concerning the ASSOCIATE statement

[pault at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87477
Bug 87477 depends on bug 109948, which changed state.

Bug 109948 Summary: [13/14 Regression] ICE(segfault) in gfc_expression_rank() 
from gfc_op_rank_conformable()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109948

   What|Removed |Added

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

[Bug rtl-optimization/110087] New: Missing if conversion

[ubizjak at gmail dot com via Gcc-bugs]

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

Bug ID: 110087
   Summary: Missing if conversion
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ubizjak at gmail dot com
  Target Milestone: ---

Following testcase:

--cut here--
#include 

_Bool foo (void);

_Bool bar (_Bool r)
{
  if (foo ())
r = true;

  return r;
}
--cut here--

compiles for x86_64 target (-O2) to:

movl%edi, %ebx
callfoo
testb   %al, %al
cmove   %ebx, %eax

More optimal code would be:

movl%edi, %ebx
callfoo
orb %bl, %al

[Bug rtl-optimization/110087] Missing if conversion

[ubizjak at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Uroš Bizjak  ---
BTW: If the result of foo is random, then cmove gets badly predicted.
Considering the problems with cmove on x86 (even without bad prediction), the
above optimization can be quite important. Clang does it.

[Bug tree-optimization/110087] Missing if conversion

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

  Component|rtl-optimization|tree-optimization
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Keywords||missed-optimization
   Last reconfirmed||2023-06-02
 CC||pinskia at gcc dot gnu.org

--- Comment #2 from Richard Biener  ---
  _Bool _1;

   :
  _1 = foo ();
  if (_1 != 0)
goto ; [INV]
  else
goto ; [INV]

   :

   :
  # r_2 = PHI 
  return r_2;

I wonder if we should address this in PHI-OPT and transform it to

 r_2 = r_5(D) | _1;

there?  There's zero_one_valued_p we could use for both the
tested value and the value or-ed into.

We already have

/* ((x & 0x1) == 0) ? y : z  y -> (-(typeof(y))(x & 0x1) & z)  y */

and

/* ((x & 0x1) == 0) ? z  y : y -> (-(typeof(y))(x & 0x1) & z)  y */

[Bug target/110086] ICE when optimization level is changed using optimize attribute

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #1 from Richard Biener  ---
That's usually a hint of a bug in the target specific option processing code.

Do you have 5 minutes

[Dev Survey via Gcc-bugs]

Dear Developers,
We kindly request your participation in a short survey that will take just a 
few minutes of your time.

Your feedback is crucial in helping us improve our products/services and 
enhance your overall experience. By sharing your thoughts, you'll play a 
significant role in shaping our future endeavors.
To access the survey, simply click on the following link: 
https://rebrand.ly/jofbro0


| 
| 
| 
|  |  |

 |

 |
| 
|  | 
Developer Tools Survey (Anonymous)

This survey is to understand the kind of tools developers like to have in their 
day to day workflows
 |

 |

 |




Thank you in advance for your valuable input. We truly appreciate your time and 
contribution 
Best regards,Developer Teams

[Bug testsuite/109951] [14 Regression] libgomp, testsuite: non-native multilib c++ tests fail on Darwin.

[tschwinge at gcc dot gnu.org via Gcc-bugs]

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

Thomas Schwinge  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #6 from Thomas Schwinge  ---

"Consider '--with-build-sysroot=[...]' for target libraries' build-tree testing
(instead of build-time 'CC' etc.) [PR109951]".

[Bug testsuite/66005] libgomp make check time is excessive

[tschwinge at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #18 from Thomas Schwinge  ---
(In reply to Iain Sandoe from
)
> I am also somewhat puzzled by what conditions I need to take advantage of
> the parallel running?
> Darwin has /usr/bin/getconf and AFAICT the number of cpus is reported OK
> both at runtime and during config

(That's not actually relevant for libgomp parallel testing.)

> but it seems to be determined to run a single process.

That's the fail-safe default if there's no 'flock' executable available --
which I suspect is the case on your Darwin systems?  My recent commit
r14-1490-g04abe1944d30eb18a2060cfcd9695d085f7b4752 "Support parallel testing in
libgomp: fallback Perl 'flock' [PR66005]" should've addressed that case (if you
have Perl).

[Bug testsuite/109951] [14 Regression] libgomp, testsuite: non-native multilib c++ tests fail on Darwin.

[tschwinge at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #7 from Thomas Schwinge  ---
(In reply to Iain Sandoe from comment #4)
> I am also somewhat puzzled by what conditions I need to take advantage of
> the parallel running?
> Darwin has /usr/bin/getconf and AFAICT the number of cpus is reported OK
> both at runtime and during config, but it seems to be determined to run a
> single process.

Answered in  -- sorry,
forgot to put you in CC.

[Bug tree-optimization/110087] Missing if conversion

[amonakov at gcc dot gnu.org via Gcc-bugs]

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

Alexander Monakov  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org

--- Comment #3 from Alexander Monakov  ---
(In reply to Uroš Bizjak from comment #1)
> BTW: If the result of foo is random, then cmove gets badly predicted.
> Considering the problems with cmove on x86 (even without bad prediction),
> the above optimization can be quite important. Clang does it.

There is no prediction involved in execution of CMOV. It is one ALU uop with
latency 1 on any recent x86, or two uops with latency 1 on Haswell, going back
to Intel Core: https://uops.info/html-instr/CMOVZ_R32_R32.html

If you convert a control dependency to a data dependency with CMOV you may end
up with slower code due to longer dependency chains, but this is not the case
here.

[Bug testsuite/66005] libgomp make check time is excessive

[iains at gcc dot gnu.org via Gcc-bugs]

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

Iain Sandoe  changed:

   What|Removed |Added

 CC||iains at gcc dot gnu.org

--- Comment #19 from Iain Sandoe  ---
(In reply to Thomas Schwinge from comment #18)
> (In reply to Iain Sandoe from
> )
> > I am also somewhat puzzled by what conditions I need to take advantage of
> > the parallel running?
> > Darwin has /usr/bin/getconf and AFAICT the number of cpus is reported OK
> > both at runtime and during config
> 
> (That's not actually relevant for libgomp parallel testing.)
> 
> > but it seems to be determined to run a single process.
> 
> That's the fail-safe default if there's no 'flock' executable available --
> which I suspect is the case on your Darwin systems?  My recent commit
> r14-1490-g04abe1944d30eb18a2060cfcd9695d085f7b4752 "Support parallel testing
> in libgomp: fallback Perl 'flock' [PR66005]" should've addressed that case
> (if you have Perl).

thanks. yes flock used to exist on Darwin but was removed some time ago (like
10+ years) so a replacement is needed - and Perl is available so let's see.

[Bug target/110088] New: [avr] Improve operation with const on l-reg after move from d-reg

[gjl at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 110088
   Summary: [avr] Improve operation with const on l-reg after move
from d-reg
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gjl at gcc dot gnu.org
  Target Milestone: ---

The register allocator might generate code that moves a value from a d-reg to
an l-reg, and then performs operation like PLUS, IOR, AND with a constant.  So
we have a sequence like:

lreg = dreg
lreg = lreg  const

This is expensive because lreg cannot handle const and needs a QI scratch to
load bytes of const.  Instead, if dreg dies after the first insn, better code
is:

dreg = dreg  const
lreg = dreg

An RTL peephole can catch this.

[Bug target/110088] [avr] Improve operation with const on l-reg after move from d-reg

[gjl at gcc dot gnu.org via Gcc-bugs]

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

Georg-Johann Lay  changed:

   What|Removed |Added

 Target||avr
   Keywords||missed-optimization
   Priority|P3  |P5

[Bug gcov-profile/110082] Coverage analysis vs. offloading compilation

[tschwinge at gcc dot gnu.org via Gcc-bugs]

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

Thomas Schwinge  changed:

   What|Removed |Added

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

--- Comment #2 from Thomas Schwinge  ---
(In reply to Richard Biener from comment #1)
> Note that when you do it as
> proposed the code will appear as having no coverage (the counters will be
> allocated at the host side but nothing will increment them).

ACK, our customer does understand this.

I infer correctly that the "do it as proposed" does seem fine to you:

(In reply to me from comment #0)
> My idea is to abstract the "increment the edge execution count" operations
> into some new GIMPLE/IFN code (?), and then later, once the offloading code
> has been split off, lower it to the current form (host-side), or no-op
> (device-side).  I'd appreciate a quick review if that approach makes sense?

[Bug rtl-optimization/101188] [postreload] Uses content of a clobbered register

[uweigand at gcc dot gnu.org via Gcc-bugs]

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

Ulrich Weigand  changed:

   What|Removed |Added

 CC||uweigand at gcc dot gnu.org

--- Comment #12 from Ulrich Weigand  ---
Sorry for not responding earlier, I've been out on vacation.

I think your root cause analysis is correct.  In this part of code:

  if (success)
delete_insn (insn);
  changed |= success;
  insn = next;
  move2add_record_mode (reg);
  reg_offset[regno]
= trunc_int_for_mode (added_offset + base_offset,
  mode);
  continue;

the intent seems to be to manually update the move2add data structures to
account for the effects of "next", because the default logic is now skipped for
the "next" insn.  That's why in particular the reg mode and offset are manually
calculated.

This manual logic however is really only correct if "next" is actually just a
simple SET.  Reading the comment before the whole loop:
  /* For simplicity, we only perform this optimization on
 straightforward SETs.  */
makes me suspect the original author assumed that "next" is in fact a
straightforward SET here as well.  This is however not true due to behavior of
the "single_set" extractor.  (I'm wondering if "single_set" used to be defined
differently back in the days?)

Your fix does look correct to me as far as handling parallel CLOBBERs go. 
However, looking at "single_set", it seems there is yet another case: the
extractor also accepts a parallel of two or more SETs, as long as all except
one of those SETs have destinations that are dead.  These cases would still not
be handled correctly with your patch, I think.

I'm wondering whether it is even worthwhile to attempt to cover those cases. 
Maybe a more straightforward fix would be to keep in line with the
above-mentioned comment about "straightforward SETs" and just check for a
single SET directly instead of using "single_set" here.  Do you think this
would miss any important optimizations?

[Bug c/102989] Implement C2x's n2763 (_BitInt)

[jakub at gcc dot gnu.org via Gcc-bugs]

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

Jakub Jelinek  changed:

   What|Removed |Added

  Attachment #55169|0   |1
is obsolete||

--- Comment #53 from Jakub Jelinek  ---
Created attachment 55240
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55240&action=edit
gcc14-bitint-wip.patch

Further updates.  This introduces a new bitintlower (and bitintlower0) pass,
categorizes
_BitInt types into 4 categories (small, which are kept as is as they work out
of the box, middle, which have already more than one limb, but there exists
DImode or TImode
type which is supported and covers the precision, here lowering is done by
casting to
INTEGER_TYPE and back, large which is up to double that size (so it will be
lowered to straight line code) and huge, which will use loops.  The lowering is
so far implemented for the middle _BitInts.
Added some runtime testsuite coverage for the small and middle _BitInts (so on
x86-64 up to 128 bits).

[Bug gcov-profile/110082] Coverage analysis vs. offloading compilation

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #3 from rguenther at suse dot de  ---
On Fri, 2 Jun 2023, tschwinge at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110082
> 
> Thomas Schwinge  changed:
> 
>What|Removed |Added
> 
>  Ever confirmed|0   |1
>Last reconfirmed||2023-06-02
>  Status|UNCONFIRMED |NEW
> 
> --- Comment #2 from Thomas Schwinge  ---
> (In reply to Richard Biener from comment #1)
> > Note that when you do it as
> > proposed the code will appear as having no coverage (the counters will be
> > allocated at the host side but nothing will increment them).
> 
> ACK, our customer does understand this.
> 
> I infer correctly that the "do it as proposed" does seem fine to you:
> 
> (In reply to me from comment #0)
> > My idea is to abstract the "increment the edge execution count" operations
> > into some new GIMPLE/IFN code (?), and then later, once the offloading code
> > has been split off, lower it to the current form (host-side), or no-op
> > (device-side).  I'd appreciate a quick review if that approach makes sense?

Yes, I think this is a reasonable way to do this - I'll note there's
IPA pass analysis that might need adjustments to correctly capture
the semantics of the internal functions.

I suppose you want to apply this generally, not only to offloaded
functions and when offloading is enabled?

I briefly considered whether it's possible/useful to move profile
instrumentation to the main IPA _transform_ stage but I guess
this will unnecessarily complicate the intricate web of things
there.  Profile read for -fprofile-use would then still need to
happen at IPA analysis phase so keeping meta-data between
compile and LTRANS phase in-sync to make that working out nicely
would be another challenge.

[Bug target/110088] [avr] Improve operation with const on l-reg after move from d-reg

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Georg-Johann Lay :

https://gcc.gnu.org/g:7bf89a919fdab9e18b7ad3efaa1a79f1d7520ddf

commit r14-1492-g7bf89a919fdab9e18b7ad3efaa1a79f1d7520ddf
Author: Georg-Johann Lay 
Date:   Fri Jun 2 12:41:07 2023 +0200

target/110088: Improve operation of l-reg with const after move from d-reg.

After reload, there may be sequences like
   lreg = dreg
   lreg = lreg  const
with an LD_REGS dreg, non-LD_REGS lreg, and  in PLUS, IOR, AND.
If dreg dies after the first insn, it is possible to use
   dreg = dreg  const
   lreg = dreg
instead which is more efficient.

gcc/
PR target/110088
* config/avr/avr.md: Add an RTL peephole to optimize operations on
non-LD_REGS after a move from LD_REGS.
(piaop): New code iterator.

[Bug c/102989] Implement C2x's n2763 (_BitInt)

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #54 from rguenther at suse dot de  ---
On Fri, 2 Jun 2023, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989
> 
> Jakub Jelinek  changed:
> 
>What|Removed |Added
> 
>   Attachment #55169|0   |1
> is obsolete||
> 
> --- Comment #53 from Jakub Jelinek  ---
> Created attachment 55240
>   --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55240&action=edit
> gcc14-bitint-wip.patch
> 
> Further updates.  This introduces a new bitintlower (and bitintlower0) pass,
> categorizes
> _BitInt types into 4 categories (small, which are kept as is as they work out
> of the box, middle, which have already more than one limb, but there exists
> DImode or TImode
> type which is supported and covers the precision, here lowering is done by
> casting to
> INTEGER_TYPE and back, large which is up to double that size (so it will be
> lowered to straight line code) and huge, which will use loops.  The lowering 
> is
> so far implemented for the middle _BitInts.
> Added some runtime testsuite coverage for the small and middle _BitInts (so on
> x86-64 up to 128 bits).

At least for -Os we probably want to consider moving everything but 
small and maybe middle to out of line library functions?

[Bug gcov-profile/110082] Coverage analysis vs. offloading compilation

[jakub at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #4 from Jakub Jelinek  ---
(In reply to rguent...@suse.de from comment #3)
> I suppose you want to apply this generally, not only to offloaded
> functions and when offloading is enabled?

It could be done just for the functions that aren't host only, i.e.
the offloading kernels or declare target functions, what the offloading LTO
streams out.

[Bug c/102989] Implement C2x's n2763 (_BitInt)

[jakub at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #55 from Jakub Jelinek  ---
(In reply to rguent...@suse.de from comment #54)
> At least for -Os we probably want to consider moving everything but 
> small and maybe middle to out of line library functions?

Not sure about that, we need to judge the space savings vs. having all those
routines
in libgcc_s.so.1 where the size price would be paid by all processes even when
they don't use the large/huge _BitInt at all.
I certainly plan to have multiplication and division/modulo on libgcc_s.so.1.
Admittedly, some entrypoints could be just in libgcc.a and not libgcc_s.so.1.
Don't we already have a case for that - the DFP stuff?
There are very cheap operations (say bitwise &/|/^/~) which have no
dependencies in between limbs, then some with small dependencies (e.g. +/- or
shifts or rotates by constant), but e.g. already shifts/rotates by variable
count is already going to be ugly at least for the huge ones.

[Bug target/110088] [avr] Improve operation with const on l-reg after move from d-reg

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from CVS Commits  ---
The releases/gcc-13 branch has been updated by Georg-Johann Lay
:

https://gcc.gnu.org/g:7cbaf2f96ec884d60e02d5d2a8a2f44ae0d390fd

commit r13-7408-g7cbaf2f96ec884d60e02d5d2a8a2f44ae0d390fd
Author: Georg-Johann Lay 
Date:   Fri Jun 2 12:41:07 2023 +0200

target/110088: Improve operation of l-reg with const after move from d-reg.

After reload, there may be sequences like
   lreg = dreg
   lreg = lreg  const
with an LD_REGS dreg, non-LD_REGS lreg, and  in PLUS, IOR, AND.
If dreg dies after the first insn, it is possible to use
   dreg = dreg  const
   lreg = dreg
instead which is more efficient.

gcc/
PR target/110088
* config/avr/avr.md: Add an RTL peephole to optimize operations on
non-LD_REGS after a move from LD_REGS.
(piaop): New code iterator.

[Bug target/110088] [avr] Improve operation with const on l-reg after move from d-reg

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Georg-Johann Lay
:

https://gcc.gnu.org/g:6f8e64989c2418bb8a4050fc1f50039a7b9a0225

commit r12-9674-g6f8e64989c2418bb8a4050fc1f50039a7b9a0225
Author: Georg-Johann Lay 
Date:   Fri Jun 2 12:41:07 2023 +0200

target/110088: Improve operation of l-reg with const after move from d-reg.

After reload, there may be sequences like
   lreg = dreg
   lreg = lreg  const
with an LD_REGS dreg, non-LD_REGS lreg, and  in PLUS, IOR, AND.
If dreg dies after the first insn, it is possible to use
   dreg = dreg  const
   lreg = dreg
instead which is more efficient.

gcc/
PR target/110088
* config/avr/avr.md: Add an RTL peephole to optimize operations on
non-LD_REGS after a move from LD_REGS.
(piaop): New code iterator.

[Bug target/110088] [avr] Improve operation with const on l-reg after move from d-reg

[gjl at gcc dot gnu.org via Gcc-bugs]

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

Georg-Johann Lay  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED

--- Comment #4 from Georg-Johann Lay  ---
Fixed in v12.4 and v13.2+.

[Bug middle-end/110089] New: sub-optimal code for attempting to produce JNA (jump on CF or ZF)

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 110089
   Summary: sub-optimal code for attempting to produce JNA (jump
on CF or ZF)
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

void bar ();
void foo (unsigned int n, unsigned s)
{
  do
{
  bar (MIN (n, s));
}
  while (!__builtin_usub_overflow (n, s, &n) && n != 0);
}

tries to construct a loop processing N elements S at a time and in the
last iteration N' < S elements.  The x86 sub instruction sets CF and ZF
so a jump on CF or ZF aka JNA (aka ! GT) should be possible but I can't
arrive at that code gen.

We expand from

  # n_4 = PHI 
  _1 = n_4 % s_8(D);
  bar (_1);
  _10 = .SUB_OVERFLOW (n_4, s_8(D));
  _2 = REALPART_EXPR <_10>;
  _3 = IMAGPART_EXPR <_10>;
  _11 = _2 != 0;
  _15 = _3 ^ 1;
  _12 = (_Bool) _15;
  _13 = _11 & _12;
  if (_13 != 0)
goto ; [89.30%]

but that's all too complicated for combine or compare-elim

[Bug middle-end/110089] sub-optimal code for attempting to produce JNA (jump on CF or ZF)

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

 Target||x86_64-*-*

--- Comment #1 from Richard Biener  ---
What's the idea how we synthesize these kind of conditional jumps?

[Bug target/110083] [14 Regression] ICEs for testcase on fp-int-convert*timode after r14-1466-g3635e8c67e1

[roger at nextmovesoftware dot com via Gcc-bugs]

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

--- Comment #2 from Roger Sayle  ---
Created attachment 55241
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55241&action=edit
proposed patch

This patch fixes the problem.  Bootstrap and regression tests underway.

[Bug middle-end/110089] sub-optimal code for attempting to produce JNA (jump on CF or ZF)

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

 Target|x86_64-*-*  |x86_64-*-*, powerpc*
 CC||linkw at gcc dot gnu.org

--- Comment #2 from Richard Biener  ---
powerpc could use subf. and jgt?  This is for the downward iterating IV for
partial-vector-usage=2 loop vectorization.

[Bug rtl-optimization/101188] [postreload] Uses content of a clobbered register

[gjl at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #13 from Georg-Johann Lay  ---
(In reply to Ulrich Weigand from comment #12)
> I think your root cause analysis is correct.  In this part of code:
> 
>   if (success)
> delete_insn (insn);
>   changed |= success;
>   insn = next;
>   move2add_record_mode (reg);
>   reg_offset[regno]
> = trunc_int_for_mode (added_offset + base_offset,
>   mode);
>   continue;
> 
> the intent seems to be to manually update the move2add data structures to
> account for the effects of "next", because the default logic is now skipped
> for the "next" insn.  That's why in particular the reg mode and offset are
> manually calculated.
> 
> This manual logic however is really only correct if "next" is actually just
> a simple SET.  Reading the comment before the whole loop:
>   /* For simplicity, we only perform this optimization on
>  straightforward SETs.  */
> makes me suspect the original author assumed that "next" is in fact a
> straightforward SET here as well.

That would render the optimization far less likely, e..g in the case of clobber
of CCmode regs.  I understodd the comment as only referring to "insn", not
necessarily to "next".

> This is however not true due to behavior
> of the "single_set" extractor.  (I'm wondering if "single_set" used to be
> defined differently back in the days?)
> Your fix does look correct to me as far as handling parallel CLOBBERs go. 
> However, looking at "single_set", it seems there is yet another case: the
> extractor also accepts a parallel of two or more SETs, as long as all except
> one of those SETs have destinations that are dead.  These cases would still
> not be handled correctly with your patch, I think.
> 
> I'm wondering whether it is even worthwhile to attempt to cover those cases.
> Maybe a more straightforward fix would be to keep in line with the
> above-mentioned comment about "straightforward SETs" and just check for a
> single SET directly instead of using "single_set" here.  Do you think this
> would miss any important optimizations?

Not sure about how many optimizations this would kill.  Many insns are
parallells that also set CCmode regs which don't interfere with this
optimization, but only considering SETs would skip all such optimizations on
targets that can have CCmode during reload (avr is not one of them).

Also I don't have a test case for your scenario.  I can reproduce the bug back
to v5 on avr and maybe it is even older.  As it appears, this PR lead to no
hickups on any other target, so for now I'd like to keep the fix restricted to
what I can test.

I already started a review this morning:
https://gcc.gnu.org/pipermail/gcc-patches/2023-June/620446.html

[Bug middle-end/110089] sub-optimal code for attempting to produce JNA (jump on CF or ZF)

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

 CC||uros at gcc dot gnu.org

--- Comment #3 from Richard Biener  ---
That said, writing it the way the vectorizer currently emits it is

void bar ();
void foo (unsigned int n, unsigned s)
{
  unsigned oldn;
  do
{
  bar (n % s);
  oldn = n;
  n = n - s;
}
  while (oldn > s);
}

which results in (on x86):

.L2:
movl%ebx, %eax
xorl%edx, %edx
divl%ebp
xorl%eax, %eax
movl%edx, %edi
callbar
movl%ebx, %eax
subl%ebp, %ebx
cmpl%eax, %ebp
jb  .L2

where the sub and the cmp should be combinable.  combine sees the following
but it doesn't try 12 -> 13 (since we set 84 in 13 which is used in 12)
and thus also not 12 -> 13 -> 15.  Also there's no "combine" incentive
for this since the 15 doesn't use 84 (12 -> 15 fails).

(insn 12 11 13 3 (set (reg/v:SI 83 [ n ])
(reg/v:SI 84 [ n ])) 89 {*movsi_internal}
 (nil))  
(insn 13 12 15 3 (parallel [
(set (reg/v:SI 84 [ n ])
(minus:SI (reg/v:SI 84 [ n ])
(reg/v:SI 85 [ s ])))
(clobber (reg:CC 17 flags))
]) "t.c":9:9 330 {*subsi_1}
 (expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)))  
(insn 15 13 16 3 (set (reg:CC 17 flags)
(compare:CC (reg/v:SI 85 [ s ])
(reg/v:SI 83 [ n ]))) "t.c":11:15 discrim 1 11 {*cmpsi_1}
 (expr_list:REG_DEAD (reg/v:SI 83 [ n ])
(nil)))
(jump_insn 16 15 17 3 (set (pc)
(if_then_else (ltu (reg:CC 17 flags)
(const_int 0 [0]))
(label_ref:DI 14)
(pc))) "t.c":11:15 discrim 1 1002 {*jcc}
 (expr_list:REG_DEAD (reg:CC 17 flags)
(int_list:REG_BR_PROB 955630228 (nil)))

cmpelim sees basically the same IL:

(insn 12 11 13 3 (set (reg/v:SI 0 ax [orig:83 n ] [83])
(reg/v:SI 3 bx [orig:84 n ] [84])) 89 {*movsi_internal}
 (nil))
(insn 13 12 15 3 (parallel [
(set (reg/v:SI 3 bx [orig:84 n ] [84])
(minus:SI (reg/v:SI 3 bx [orig:84 n ] [84])
(reg/v:SI 6 bp [orig:85 s ] [85])))
(clobber (reg:CC 17 flags))
]) "t.c":9:9 330 {*subsi_1}
 (nil))
(insn 15 13 16 3 (set (reg:CC 17 flags)
(compare:CC (reg/v:SI 6 bp [orig:85 s ] [85])
(reg/v:SI 0 ax [orig:83 n ] [83]))) "t.c":11:15 discrim 1 11
{*cmpsi_1}
 (nil))
(jump_insn 16 15 25 3 (set (pc)
(if_then_else (ltu (reg:CC 17 flags)
(const_int 0 [0]))
(label_ref:DI 14)
(pc))) "t.c":11:15 discrim 1 1002 {*jcc}

[Bug rtl-optimization/110079] [10/11/12/13/14 Regression] ICE with -freorder-blocks-and-partition and inline-asm goto

[yancheng.li at foxmail dot com via Gcc-bugs]

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

--- Comment #2 from yancheng.li at foxmail dot com ---
I want to try to solve this problem, but I am not very familiar with RTL
optimization. Could someone give me some guidance?
For example, is this an omission in the reorder-blocks-and-partition
optimization, or another reason?

[Bug middle-end/110089] sub-optimal code for attempting to produce JNA (jump on CF or ZF)

[amonakov at gcc dot gnu.org via Gcc-bugs]

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

Alexander Monakov  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org

--- Comment #4 from Alexander Monakov  ---
If 'min' is needed anyway you can use it in subtraction:

void bar ();
void foo (unsigned int n, unsigned s)
{
  do
{
  np = MIN (n, s);
  bar (np);
}
  while (n -= np);
}

but getting the sub-jcc trick to work should yield more efficient code.

[Bug target/109971] [14 regression] Several powerpc64 vector test cases fail after r14-1242-gf574e2dfae7905

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #11 from CVS Commits  ---
The master branch has been updated by Pan Li :

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

commit r14-1493-gbffc52838e393a775e13dc48162669b0f43ebe09
Author: Ju-Zhe Zhong 
Date:   Thu Jun 1 12:36:17 2023 +0800

VECT: Change flow of decrement IV

Follow Richi's suggestion, I change current decrement IV flow from:

do {
   remain -= MIN (vf, remain);
} while (remain != 0);

into:

do {
   old_remain = remain;
   len = MIN (vf, remain);
   remain -= vf;
} while (old_remain >= vf);

to enhance SCEV.

Include fixes from kewen.

This patch will need to wait for Kewen's test feedback.

Testing on X86 is on-going

Co-Authored by: Kewen Lin  

  PR tree-optimization/109971

gcc/ChangeLog:

* tree-vect-loop-manip.cc (vect_set_loop_controls_directly): Change
decrement IV flow.
(vect_set_loop_condition_partial_vectors): Ditto.

[Bug analyzer/110090] New: -fanalyze sometimes assumes contradictory conditions to be valid at the same time during path exploration

[girgias at php dot net via Gcc-bugs]

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

Bug ID: 110090
   Summary: -fanalyze sometimes assumes contradictory conditions
to be valid at the same time during path exploration
   Product: gcc
   Version: 13.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: girgias at php dot net
  Target Milestone: ---

Hello,

I've run -fanalyze on the php-src code base and the analyzer will flag issues
which cannot happen as it will explore a branch where some variable/value is
assumed to be false, but then explore a branch where it assumes this same
variable/value to be true, resulting in a false positive warning.

The command used to build php-src was the following one:

./configure --disable-all CFLAGS="-fanalyzer
-Wno-analyzer-use-of-uninitialized-value -ggdb3" -C --enable-debug

And one relevant extract which shows this issue is:

/home/girgias/Dev/php-src/ext/date/php_date.c:3112:9: note: in expansion of
macro ‘RETURN_STR’
| 3112 | RETURN_STR(date_format(format, format_len, dateobj->time,
dateobj->time->is_localtime));
|  | ^~
|
+--> ‘date_format’: events 7-18
   |
   |  675 | static zend_string *date_format(const char *format, size_t
format_len, timelib_time *t, bool localtime)
   |  | ^~~
   |  | |
   |  | (7) entry to ‘date_format’
   |..
   |  681 | timelib_time_offset *offset = NULL;
   |  |  ~~
   |  |  |
   |  |  (8) ‘offset’ is NULL
   |..
   |  686 | if (!format_len) {
   |  |~ 
   |  ||
   |  |(9) following ‘false’ branch (when ‘format_len
!= 0’)...
   |..
   |  690 | if (localtime) {
   |  |~ 
   |  ||
   |  |(10) ...to here
   |  |(11) following ‘false’ branch (when ‘localtime
== 0’)...
   |..
   |  712 | for (i = 0; i < format_len; i++) {
   |  |  ~  ~~
   |  ||  |
   |  ||  (13) following ‘true’ branch (when ‘i
< format_len’)...
   |  |(12) ...to here
   |  713 | rfc_colon = 0;
   |  | ~
   |  |   |
   |  |   (14) ...to here
   |  714 | switch (format[i]) {
   |  | ~~
   |  | |
   |  | (15) following ‘case 101:’ branch...
   |..
   |  786 | case 'e': if (!localtime) {
   |  |  ~
   |  | ||
   |  | |(17) following ‘false’
branch...
   |  | (16) ...to here
   |..
   |  789 |   switch
(t->zone_type) {
   |  |  

   |  |   
|
   |  |   
(18) ...to here
   |
 ‘date_format’: event 19



As you can see, on the bit where it analyzes line 690 it assumes localtime ==
0, thus following the false branch.
However, when analysing the if condition on line 786 it *also* follows the
false branch when this cannot happen as localtime == 0 and therefore *must* go
through the true branch.

A lot of the noise, and false positives within php-src seem to come from issues
similar to this.

[Bug middle-end/110089] sub-optimal code for attempting to produce JNA (jump on CF or ZF)

[ubizjak at gmail dot com via Gcc-bugs]

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

--- Comment #5 from Uroš Bizjak  ---
The important pattern in i386.md is *sub2, which allows CCGOCmode
compare. This means that garbage in Overlow and Carry flags are allowed.

In ix86_cc_modes_compatible, CCmode is returned for combination of CCCmode and
CCZmode. This is admittely not optimal, but it was OK untill now for testing of
separate bits. Maybe we should add new combined mode for CCZ and CCC flags?