[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 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 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/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 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 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/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

[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/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 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 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 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 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/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 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/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 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 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)

[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=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 rtl-optimization/29144] Missing if-conversion. If-conversion dependent on operand order. Inconsistent if-conversion.

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #4 from Andrew Pinski  ---
a, c is really just another case of PR 64700.

b and d are already optimized on the gimple level by PRE to:
```
  _10 = a_4(D) - b_5(D);
  if (c_3(D) != 0)
goto ; [50.00%]
  else
goto ; [50.00%]

   [local count: 536870913]:
  r_7 = o_6(D) + _10;

   [local count: 1073741824]:
  # r_2 = PHI <_10(2), r_7(3)>
```


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64700
[Bug 64700] Sink common code through PHI

[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 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/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/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 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/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 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 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 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/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 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=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 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

   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, _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 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 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 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 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 libstdc++/109822] Converting std::experimental::simd masks yields an error

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

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

Alexandre Oliva  changed:

   What|Removed |Added

 CC||aoliva at gcc dot gnu.org

--- Comment #7 from Alexandre Oliva  ---
This test fails on powerpc targets when VSX support is unavailable.

[Bug bootstrap/110085] New: make clean inside the gcc directory when configured with m2 language and for sh-elf messes up

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

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

Bug ID: 110085
   Summary: make clean inside the gcc directory when configured
with m2 language and for sh-elf messes up
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

make clean does:
# Delete files used by the "multilib" facility (including libgcc subdirs).
-rm -f multilib.h tmpmultilib*
-if [ "x$(MULTILIB_DIRNAMES)" != x ] ; then \
  rm -rf $(MULTILIB_DIRNAMES); \
else if [ "x$(MULTILIB_OPTIONS)" != x ] ; then \
  rm -rf `echo $(MULTILIB_OPTIONS) | sed -e 's/\// /g'`; \
fi ; fi


and one of the MULTILIB_DIRNAMES for sh-elf is m2 but m2 is also the name of
the language.

I think that part of the gcc/Makefile.in can be removed now (since libgcc is
not built inside the gcc directory for years now) but I am not 100% sure.

[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 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 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 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/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/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 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 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 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 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 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 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 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=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/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/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 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 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 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|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org

--- Comment #25 from Richard Biener  ---
I'm testing a backport.

[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 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 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 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 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 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 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 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 middle-end/110091] New: bogus -Wdangling-pointer on non-pointer values

[patrickdepinguin at gmail dot com via Gcc-bugs]

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

Bug ID: 110091
   Summary: bogus -Wdangling-pointer on non-pointer values
   Product: gcc
   Version: 12.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: patrickdepinguin at gmail dot com
  Target Milestone: ---

Following reduced testcase gives a bogus -Wdangling-pointer:

struct tEntry
{
int value;
};

struct tOut
{
int outvalue;
};
extern struct tOut *out;

extern int otherfunc(struct tEntry *);
extern void anotherfunc(int val);

void bar()
{
struct tEntry entry = { 0 };

if (otherfunc() != 0)
{
return;
}

if (out)
{
out->outvalue = entry.value;
}

anotherfunc(5);
}

void foo()
{
bar();
}



$ gcc -O2  -Wall -Werror /opt/test.c
/opt/test.c: In function 'bar':
/opt/test.c:26:30: error: dangling pointer to 'entry' may be used
[-Werror=dangling-pointer=]
   26 | out->outvalue = entry.value;
  | ~^~
/opt/test.c:17:19: note: 'entry' declared here
   17 | struct tEntry entry = { 0 };
  |   ^
In function 'bar',
inlined from 'foo' at /opt/test.c:34:5:
/opt/test.c:26:30: error: dangling pointer to 'entry' may be used
[-Werror=dangling-pointer=]
   26 | out->outvalue = entry.value;
  | ~^~
/opt/test.c: In function 'foo':
/opt/test.c:17:19: note: 'entry' declared here
   17 | struct tEntry entry = { 0 };
  |   ^
cc1: all warnings being treated as errors


entry is a local struct, initialized to 0, and passed as pointer to an external
function.
But the use being warned about is not using any pointer.


Tested with 12.2.0 (Debian), 12.2.1 (Gentoo), 12.3.0 (official gcc docker
image), 13.1.0 (official gcc docker image).

[Bug tree-optimization/110087] Missing if conversion

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #4 from Andrew Pinski  ---
I have a patch that converts this into the or.

[Bug target/106769] PPCLE: vec_extract(vector unsigned int) unnecessary rldicl after mfvsrwz

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

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

Peter Bergner  changed:

   What|Removed |Added

 CC||aagarwa at gcc dot gnu.org,
   ||bergner at gcc dot gnu.org

--- Comment #2 from Peter Bergner  ---
I wonder if Ajit's REE changes catch this unneeded zero extension?

[Bug middle-end/110094] Support __builtin_mem*_inline

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

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

--- Comment #2 from Andrew Pinski  ---
Also there is no definition of what a compile time constant is.

The option supports non constant cases too.

[Bug c++/110070] Code quality regression with for (int i: {1,2,4,6})

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

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #3 from Jason Merrill  ---
Fixed for GCC 14 so far.

[Bug rtl-optimization/110095] New: RISC-V: unrecognizable insn during RTL pass: vregs with -O2 -mcpu=sifive-u74

[matoro_gcc_bugzilla at matoro dot tk via Gcc-bugs]

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

Bug ID: 110095
   Summary: RISC-V: unrecognizable insn during RTL pass: vregs
with -O2 -mcpu=sifive-u74
   Product: gcc
   Version: 13.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: matoro_gcc_bugzilla at matoro dot tk
  Target Milestone: ---

Not sure if this is a regression or not.  Minimized test case produced with
cvise.

$ cat test3.i
double CastDoubleToLong_x;
long __attribute__DrawAffineImage_x;
long CastDoubleToLong() {
  if (CastDoubleToLong_x)
return 0;
  return CastDoubleToLong_x;
}
void __attribute__DrawAffineImage() {
  for (; __attribute__DrawAffineImage_x <= CastDoubleToLong();)
;
}

$ riscv64-unknown-linux-gnu-gcc -O2 -mcpu=sifive-u74 -c test3.i
test3.i: In function ‘__attribute__DrawAffineImage’:
test3.i:11:1: error: unrecognizable insn:
   11 | }
  | ^
(insn 9 8 10 2 (set (reg:DI 140)
(if_then_else:DI (eq:DF (reg:DF 136 [ CastDoubleToLong_x.0_4 ])
(reg:DF 142))
(reg:DI 141)
(const_int 0 [0]))) -1
 (nil))
during RTL pass: vregs
test3.i:11:1: internal compiler error: in extract_insn, at recog.cc:2791
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
See  for instructions.

Passing -fdisable-rtl-vregs does not fix the problem as the same issue appears
in sched1 pass; there is a little bit more context in the output.

$ riscv64-unknown-linux-gnu-gcc -O2 -mcpu=sifive-u74 -c test3.i
-fdisable-rtl-vregs   
cc1: note: disable pass rtl-vregs for functions in the range of [0, 4294967295]
test3.i: In function ‘__attribute__DrawAffineImage’:
test3.i:11:1: error: unrecognizable insn:
   11 | }
  | ^
(insn 9 8 12 2 (set (reg:DI 140)
(if_then_else:DI (eq:DF (reg:DF 136 [ CastDoubleToLong_x.0_4 ])
(reg:DF 142))
(reg:DI 141)
(const_int 0 [0]))) -1
 (expr_list:REG_DEAD (reg:DF 142)
(expr_list:REG_DEAD (reg:DI 141)
(expr_list:REG_DEAD (reg:DF 136 [ CastDoubleToLong_x.0_4 ])
(expr_list:REG_EQUAL (if_then_else:DI (eq:DF (reg:DF 136 [
CastDoubleToLong_x.0_4 ])
(const_double:DF 0.0 [0x0.0p+0]))
(reg:DI 141)
(const_int 0 [0]))
(nil))
during RTL pass: sched1
test3.i:11:1: internal compiler error: in extract_insn, at recog.cc:2791
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
See  for instructions.

Reducing optimization to -O1 removes the issue:
$ riscv64-unknown-linux-gnu-gcc -O1 -mcpu=sifive-u74 -c test3.i

Removing CPU tuning also removes the issue:
$ riscv64-unknown-linux-gnu-gcc -O2 -c test3.i

Clang has no problems (though I'm not sure if it actually supports optimization
for this CPU or if it's a no-op):
$ clang -O2 -mcpu=sifive-u74 -c test3.i


$ gcc --version --verbose
Using built-in specs.
COLLECT_AS_OPTIONS='--version'
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/riscv64-unknown-linux-gnu/13/lto-wrapper
gcc (Gentoo 13.1.1_p20230527 p3) 13.1.1 20230527
Copyright (C) 2023 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


Target: riscv64-unknown-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-13.1.1_p20230527/work/gcc-13-20230527/configure
--host=riscv64-unknown-linux-gnu --build=riscv64-unknown-linux-gnu
--prefix=/usr --bindir=/usr/riscv64-unknown-linux-gnu/gcc-bin/13
--includedir=/usr/lib/gcc/riscv64-unknown-linux-gnu/13/include
--datadir=/usr/share/gcc-data/riscv64-unknown-linux-gnu/13
--mandir=/usr/share/gcc-data/riscv64-unknown-linux-gnu/13/man
--infodir=/usr/share/gcc-data/riscv64-unknown-linux-gnu/13/info
--with-gxx-include-dir=/usr/lib/gcc/riscv64-unknown-linux-gnu/13/include/g++-v13
--with-python-dir=/share/gcc-data/riscv64-unknown-linux-gnu/13/python
--enable-languages=c,c++ --enable-obsolete --enable-secureplt --disable-werror
--with-system-zlib --enable-nls --without-included-gettext
--disable-libunwind-exceptions --enable-checking=release
--with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo
13.1.1_p20230527 p3' --with-gcc-major-version-only --disable-esp
--enable-libstdcxx-time --enable-lto --disable-libstdcxx-pch --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
--disable-multilib --disable-fixed-point --with-abi=lp64d --enable-libgomp
--disable-libssp --disable-libada --disable-cet --disable-systemtap
--disable-valgrind-annotations --disable-vtable-verify --disable-libvtv
--without-zstd --with-isl --disable-isl-version-check 

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

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

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

Alex Coplan  changed:

   What|Removed |Added

 CC||acoplan at gcc dot gnu.org

--- Comment #8 from Alex Coplan  ---
Thanks for the follow-up fix and apologies for the mid-air collision, I didn't
see the %zu problem on the target I was testing.

[Bug target/110061] libatomic: 128-bit atomics should be lock-free on AArch64

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

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

--- Comment #9 from Wilco  ---
(In reply to Xi Ruoyao from comment #8)
> (In reply to Wilco from comment #7)
> > I don't see the issue you have here. GCC for x86/x86_64 has been using
> > compare exchange for atomic load (which always does a write even if the
> > compare fails) for many years.
> 
> No we don't, since r7-6454.

Incorrect - libatomic still uses cmpxchg16b depending on the CPU.

> > The question is, do you believe compilers should provide users with fast and
> > efficient atomics they need? Or do you want to force every application to
> > implement their own version of 128-bit atomics?
> 
> But a compiler must generate correct code first.  They can use the wonderful
> inline assembly because they know CAS is safe in their case, but the
> compiler does not know.

Many developers consider locking atomics fundamentally incorrect. If we emit
lock-free atomics they don't need to write inline assembler.

[Bug target/110096] Would be nice if __builtin_ia32_pause had a portable equivalent as it's applicable to ARM

[pdimov at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Peter Dimov  ---
How does the user know when to include `arm_acle.h`?

[Bug fortran/100607] ICE with SELECT RANK

[sgk at troutmask dot apl.washington.edu via Gcc-bugs]

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

--- Comment #12 from Steve Kargl  ---
On Fri, Jun 02, 2023 at 06:06:59PM +, anlauf at gcc dot gnu.org wrote:
> 
> --- Comment #11 from anlauf at gcc dot gnu.org ---
> Fixed.
> 

Thanks for taking care of the commit.