[Bug debug/91239] gcc generates invalid .debug_macro sections (according to lld folks)

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||matz at gcc dot gnu.org

--- Comment #4 from Richard Biener  ---
It seems to work with lld (version 9 and 11) for me:

Contents of the .debug_macro section:

  Offset:  0x0
  Version: 4
  Offset size: 4
  Offset into .debug_line: 0xe8

 DW_MACRO_import - offset : 0x23
 DW_MACRO_start_file - lineno: 0 filenum: 1 filename: r.cc
 DW_MACRO_start_file - lineno: 0 filenum: 2 filename:
/usr/include/stdc-predef.h
 DW_MACRO_import - offset : 0x9ed
 DW_MACRO_end_file
 DW_MACRO_start_file - lineno: 1 filenum: 3 filename: r.h
 DW_MACRO_import - offset : 0xa09
 DW_MACRO_end_file
 DW_MACRO_end_file

but I also only see section type relocations and obviously those have to
work and be redirected to the prevailing comdat group.  So - it doesn't
reproduce for me with your testcase.

[Bug c++/105256] [9/10 Regression] ICE compiling firefox-99

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

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[9/10/11 Regression] ICE|[9/10 Regression] ICE
   |compiling firefox-99|compiling firefox-99
 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org

--- Comment #32 from Jakub Jelinek  ---
Fixed for 11.3 as well.

[Bug c++/105256] [9/10/11 Regression] ICE compiling firefox-99

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

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

--- Comment #31 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Jakub Jelinek
:

https://gcc.gnu.org/g:691af15031e00227ba6d5935c1d737026cda4129

commit r11-9891-g691af15031e00227ba6d5935c1d737026cda4129
Author: Jakub Jelinek 
Date:   Tue Apr 19 18:27:41 2022 +0200

c++: Fix up CONSTRUCTOR_PLACEHOLDER_BOUNDARY handling [PR105256]

The CONSTRUCTOR_PLACEHOLDER_BOUNDARY bit is supposed to separate
PLACEHOLDER_EXPRs that should be replaced by one object or subobjects of it
(variable, TARGET_EXPR slot, ...) from other PLACEHOLDER_EXPRs that should
be replaced by different objects or subobjects.
The bit is set when finding PLACEHOLDER_EXPRs inside of a CONSTRUCTOR, not
looking into nested CONSTRUCTOR_PLACEHOLDER_BOUNDARY ctors, and we prevent
elision of TARGET_EXPRs (through TARGET_EXPR_NO_ELIDE) whose initializer
is a CONSTRUCTOR_PLACEHOLDER_BOUNDARY ctor.  The following testcase ICEs
though, we don't replace the placeholders in there at all, because
CONSTRUCTOR_PLACEHOLDER_BOUNDARY isn't set on the TARGET_EXPR_INITIAL
ctor, but on a ctor nested in such a ctor.  replace_placeholders should be
run on the whole TARGET_EXPR slot.

So, the following patch fixes it by moving the
CONSTRUCTOR_PLACEHOLDER_BOUNDARY
bit from nested CONSTRUCTORs to the CONSTRUCTOR containing those (but only
if it is closely nested, if there is some other tree sandwiched in between,
it doesn't do it).

2022-04-19  Jakub Jelinek  

PR c++/105256
* typeck2.c (process_init_constructor_array,
process_init_constructor_record, process_init_constructor_union):
Move
CONSTRUCTOR_PLACEHOLDER_BOUNDARY flag from CONSTRUCTOR elements to
the
containing CONSTRUCTOR.

* g++.dg/cpp0x/pr105256.C: New test.

(cherry picked from commit eb03e424598d30fed68801af6d6ef6236d32e32e)

[Bug middle-end/105316] Seemingly bogus -Wdangling-pointer from ppc/ppc64 kernel printk with gcc12

[raj.khem at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Khem Raj  ---
ah yes. Thanks

[Bug tree-optimization/105312] [12 Regression] ICE in gimple_expand_vec_cond_expr on arm-linux

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|attribute__((optimize("-O3" |[12 Regression] ICE in
   |))) |gimple_expand_vec_cond_expr
   |stress_matrix_xy_identity   |on arm-linux
   |compiling stress-ng for arm |
   Target Milestone|--- |12.0
  Component|middle-end  |tree-optimization
   Keywords||ice-on-valid-code

[Bug middle-end/105316] Seemingly bogus -Wdangling-pointer from ppc/ppc64 kernel printk with gcc12

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|UNCONFIRMED |RESOLVED

--- Comment #1 from Andrew Pinski  ---
The warning is correct __str goes out of the scope when the statement
expression ends.

[Bug middle-end/105316] New: Seemingly bogus -Wdangling-pointer from ppc/ppc64 kernel printk with gcc12

[raj.khem at gmail dot com via Gcc-bugs]

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

Bug ID: 105316
   Summary: Seemingly bogus -Wdangling-pointer from ppc/ppc64
kernel printk with gcc12
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: raj.khem at gmail dot com
  Target Milestone: ---

I have reduced this case from ppc kernel 5.15, this breaks the kernel build as
the warning is treated as error. 

ftrace.i
==

int _printk(const char *fmt, ...);

static void ftrace_modify_code() {
 _printk("replaced (%s)", ({ char __str[sizeof(" ")]; __str;
}));
}


=

powerpc64le-yoe-linux-musl-gcc -c ftrace.i -Werror=dangling-pointer 
ftrace.i: In function 'ftrace_modify_code':
ftrace.i:4:2: error: using a dangling pointer to '__str'
[-Werror=dangling-pointer=]
4 |  _printk("replaced (%s)", ({ char __str[sizeof(" ")];
__str; }));
  | 
^~~
ftrace.i:4:35: note: '__str' declared here
4 |  _printk("replaced (%s)", ({ char __str[sizeof(" ")];
__str; }));
  |   ^
cc1: some warnings being treated as errors

[Bug testsuite/105267] [12 regression] gcc.target/powerpc/pr56605.c fails after r12-8128-g6b7cc7294770ec

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

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

Kewen Lin  changed:

   What|Removed |Added

 CC||linkw at gcc dot gnu.org

--- Comment #2 from Kewen Lin  ---
As Seurer's notes on PR105313, this fails on both BE and LE machines.

[Bug testsuite/105267] [12 regression] gcc.target/powerpc/pr56605.c fails after r12-8128-g6b7cc7294770ec

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

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

--- Comment #1 from Kewen Lin  ---
*** Bug 105313 has been marked as a duplicate of this bug. ***

[Bug testsuite/105313] [12 regression] gcc.target/powerpc/pr56605.c fails after r12-8128-g6b7cc7294770ec

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

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

Kewen Lin  changed:

   What|Removed |Added

 CC||linkw at gcc dot gnu.org
 Resolution|--- |DUPLICATE
 Status|UNCONFIRMED |RESOLVED

--- Comment #2 from Kewen Lin  ---
Dup of PR105267.

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

[Bug go/105315] go build fail on ppc: has no member named 'gregs'; did you mean 'regs'?

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

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

--- Comment #1 from Jiu Fu Guo  ---
The failure compiling command is about -m32:

/home/guojiufu/gcc/build/gcc-mainline-base/./gcc/xgcc
-B/home/guojiufu/gcc/build/gcc-mainline-base/./gcc/
-B/home/guojiufu/gcc/install/gcc-mainline-base/powerpc64-unknown-linux-gnu/bin/
-B/home/guojiufu/gcc/install/gcc-mainline-base/powerpc64-unknown-linux-gnu/lib/
-isystem
/home/guojiufu/gcc/install/gcc-mainline-base/powerpc64-unknown-linux-gnu/include
-isystem
/home/guojiufu/gcc/install/gcc-mainline-base/powerpc64-unknown-linux-gnu/sys-include
-m32 -DHAVE_CONFIG_H -I. -I/home/guojiufu/gcc/gcc-mainline-base/libgo -I
/home/guojiufu/gcc/gcc-mainline-base/libgo/runtime
-I/home/guojiufu/gcc/gcc-mainline-base/libgo/../libffi/include
-I../libffi/include -pthread -L../libatomic/.libs -fexceptions
-fnon-call-exceptions -Wall -Wextra -Wwrite-strings -Wcast-qual -Werror
-D_GNU_SOURCE -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I
/home/guojiufu/gcc/gcc-mainline-base/libgo/../libgcc -I
/home/guojiufu/gcc/gcc-mainline-base/libgo/../libbacktrace -I
../../../gcc/include -g -O2 -m32 -MT runtime/go-signal.lo -MD -MP -MF
runtime/.deps/go-signal.Tpo -c
/home/guojiufu/gcc/gcc-mainline-base/libgo/runtime/go-signal.c  -fPIC -DPIC -o
runtime/.libs/go-signal.o

[Bug go/105315] New: go build fail on ppc: has no member named 'gregs'; did you mean 'regs'?

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

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

Bug ID: 105315
   Summary: go build fail on ppc: has no member named 'gregs'; did
you mean 'regs'?
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: guojiufu at gcc dot gnu.org
CC: cmang at google dot com
  Target Milestone: ---

On P8 BE machine, I encounter a build failure.

libgo/runtime/go-signal.c:236:59: error: 'union uc_regs_ptr' has no member
named 'gregs'; did you mean 'regs'?
  236 | ret.sigpc = ((ucontext_t*)(context))->uc_mcontext.gregs[32];


The machine is:
Architecture:  ppc64
CPU op-mode(s):32-bit, 64-bit
Byte Order:Big Endian
Model name:POWER8 (architected), altivec supported

reproduce command:
$GCC_SRC/configure --enable-languages=c,c++,go --with-cpu=native
--with-long-double-128 --prefix=~/install/gcc-mainline-base
make -j 30


It may be the commit "r12-8168 af27d545dc6132dcd67d1ee854372ea9cfd2a225" which
cause this issue.

[Bug go/105302] gccgo for Windows using MinGW-w64

[ian at airs dot com via Gcc-bugs]

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

--- Comment #8 from Ian Lance Taylor  ---
Thanks.  Those suggested changes aren't going to make any difference as those
are text files anyhow.  One is a generated C header that #include'd by C files,
and the other is a dump file intended for human inspection.

The .gox files are not generated directly by the Go frontend.  They are
generated by writing out an object file in the usual way, and then using
objcopy to create the .gox file.  Ths form of .gox file is an object file that
only contains a single section.

[Bug go/105302] gccgo for Windows using MinGW-w64

[brechtsanders at users dot sourceforge.net via Gcc-bugs]

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

--- Comment #7 from Brecht Sanders  
---
I'm still trying to understand how it all works, but to avoid \n versus \r\n
issues on Windows I would already recommend these changes:
```
patch -ulbf gcc/go/gofrontend/gogo.cc << EOF
@@ -5252,3 +5252,3 @@
   std::ofstream out;
-  out.open(this->c_header_.c_str());
+  out.open(this->c_header_.c_str(), std::ios_base::binary);
   if (out.fail())
EOF
patch -ulbf gcc/go/gofrontend/ast-dump.cc << EOF
@@ -197,3 +197,3 @@
   dumpname += ".dump.ast";
-  out.open(dumpname.c_str());
+  out.open(dumpname.c_str(), std::ios_base::binary);

EOF
```
Unfortanately this doesn't solve the issue though.

I couldn't figure out yet where the code is that makes go_read_export_data in
gcc/go/go-backend.cc skip the part before the magic string...

[Bug debug/100446] GDB has problems reading GCC's debugging info level -g3

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

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

--- Comment #8 from Tom Tromey  ---
This behavior can also be affected by the choice of linker,
see bug #91239.

[Bug debug/87432] LTO produced debug info makes gdb slow

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

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

Tom Tromey  changed:

   What|Removed |Added

 CC||tromey at gcc dot gnu.org

--- Comment #2 from Tom Tromey  ---
(In reply to Richard Biener from comment #0)
> For example starting gdb on LTO bootstrapped cc1 takes s and ~1.8GB memory
> for me.  Setting a breakpoint on do_rpo_vn takes another 3s.  That feels a
> lot slower than doing this on a non-LTO bootstrapped cc1.
> 
> This bug is to track what _GCC_ can do better here.

Note that in gdb, those are two different code paths.

We recently rewrote the initial scan to be much faster (10x improvement
isn't uncommon).  This affects the startup time.

However, setting a breakpoint currently requires a full CU expansion.
That's still probably slow.  For gdb performance the best thing for
this case is if each CU is reasonably small.

[Bug debug/91239] gcc generates invalid .debug_macro sections (according to lld folks)

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

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

--- Comment #3 from Tom Tromey  ---
Created attachment 52836
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52836&action=edit
test program

I thought I'd upload the sources.  You can just untar.
Compile with "gcc -g3 -O0 r.cc z.cc -o z"
If you link with mold or lld, you'll see 0x0 imports in .debug_macros.
If you link with gold or the bfd ld, that won't happen.

While I think this behavior seems unwanted on the part of mold/lld,
on the other hand perhaps it really is allowed by ELF, I don't know.

[Bug tree-optimization/105314] ifcvt regression in noce_try_store_flag_mask

[christophm30 at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Christoph Müllner  ---
A first analysis in noce_try_store_flag_mask() showed the following observation
in case of the failing conversion into the branchless sequence:

* if_info->b == const0_rtx holds
* rtx_equal_p (if_info->a, if_info->x) does not hold

Assuming that the generic form would be "x := c ? x : 0", the second
observation seems odd.

[Bug tree-optimization/105314] New: ifcvt regression in noce_try_store_flag_mask

[christophm30 at gmail dot com via Gcc-bugs]

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

Bug ID: 105314
   Summary: ifcvt regression in noce_try_store_flag_mask
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: christophm30 at gmail dot com
  Target Milestone: ---

The function noce_try_store_flag_mask() in ifcvt.cc converts
"if (test) x = 0;" to "x &= -(test == 0);" (if costs permit that).

Commit 3a7ba8fd (which was introduced a month ago to fix PR104960) triggers a
regression so that the if-conversion can't be performed anymore.

On RISC-V this manifests as follows:
"""
long func(long a, long b, long c)
{
  if (c)
a = 0;
  return a;
}
"""

Old code:
 :
   0:   00163613seqza2,a2
   4:   40c00633neg a2,a2
   8:   8d71and a0,a0,a2
   a:   8082ret

New (branching) code:
 :
   0:   c211beqza2,4 <.L1>
   2:   4501li  a0,0
0004 <.L1>:
   4:   8082ret

Looking through the test suite, I could only find the file
"gcc.target/arm/ifcvt-size-check.c" which should be affected by this regression
as well. However, I haven't tested that.

[Bug gcov-profile/105282] [11 Regression] V_INDIR overflow causes ICE on -O0 -flto in stream_out_histogram_value, at value-prof.cc:340

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

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

Sergei Trofimovich  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2022-04-19
 Ever confirmed|0   |1

--- Comment #7 from Sergei Trofimovich  ---
(In reply to Martin Liška from comment #4)
> (In reply to Sergei Trofimovich from comment #2)
> > Proposed the fix as
> > https://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg283031.html
> 
> Next time, please use our official mailing list:
> https://gcc.gnu.org/pipermail/gcc-patches/2022-April/593287.html

Sounds good!

Proposed identical patch as a gcc-11 backport:
https://gcc.gnu.org/pipermail/gcc-patches/2022-April/593382.html

[Bug gcov-profile/105282] [11 Regression] V_INDIR overflow causes ICE on -O0 -flto in stream_out_histogram_value, at value-prof.cc:340

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

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

Sergei Trofimovich  changed:

   What|Removed |Added

Summary|[11/12 Regression] V_INDIR  |[11 Regression] V_INDIR
   |overflow causes ICE on -O0  |overflow causes ICE on -O0
   |-flto in|-flto in
   |stream_out_histogram_value, |stream_out_histogram_value,
   |at value-prof.cc:340|at value-prof.cc:340

--- Comment #6 from Sergei Trofimovich  ---
Should be fixed on gcc-12.

[Bug plugins/105171] gcc/toplev.c: `local_tick` can overflow and become -1

[jason at zx2c4 dot com via Gcc-bugs]

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

--- Comment #23 from Jason A. Donenfeld  ---
The output of crc32_string() is always >0 for that case (I think?). And the
case where the user passes an explicit "0" to -frandom-seed was already
considered to be "disabled" by the prior code. A 0 seed also plunges that
plugin's lfsr into the trivial linear subspace, rendering it inoperable. So all
things considered, 0 is a reasonable "off" value for us to use. There might be
some room for improvement -- starting with this bug report here -- but things
seem fine enough as-is (plus, the bikeshedding in this bug report already
doesn't make that road too appealing).

[Bug gcov-profile/105282] [11/12 Regression] V_INDIR overflow causes ICE on -O0 -flto in stream_out_histogram_value, at value-prof.cc:340

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

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Sergei Trofimovich :

https://gcc.gnu.org/g:90a29845bfe7d6002e6c2fd49a97820b00fbc4a3

commit r12-8199-g90a29845bfe7d6002e6c2fd49a97820b00fbc4a3
Author: Sergei Trofimovich 
Date:   Fri Apr 15 08:35:27 2022 +0100

gcov-profile: Allow negative counts of indirect calls [PR105282]

TOPN metrics are histograms that contain overall count and per-bucket
count. Overall count can be negative when two profiles merge and some
of per-bucket metrics are disacarded.

Noticed as an ICE on python PGO build where gcc crashes as:

during IPA pass: modref
a.c:36:1: ICE: in stream_out_histogram_value, at value-prof.cc:340
   36 | }
  | ^
stream_out_histogram_value(output_block*, histogram_value_t*)
gcc/value-prof.cc:340

gcc/ChangeLog:

PR gcov-profile/105282
* value-prof.cc (stream_out_histogram_value): Allow negative counts
on HIST_TYPE_INDIR_CALL.

[Bug debug/91239] gcc generates invalid .debug_macro sections (according to lld folks)

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

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

Tom Tromey  changed:

   What|Removed |Added

 Status|WAITING |NEW
 CC||tromey at gcc dot gnu.org

--- Comment #2 from Tom Tromey  ---
I separately discovered this problem when debugging an apparent gdb
slowdown, which I tracked down to a pathological .debug_macro section --
but only when I switched to using 'mold' to link.

> So how does a testcase look like? 
[...]
> Can you possibly share two source files and instructions to reproduce the
> conflicting comdats?

I filed a trivial example (three very short files) with mold:
https://github.com/rui314/mold/issues/438

I'm taking the liberty of moving this out of "WAITING".

[Bug testsuite/105313] [12 regression] gcc.target/powerpc/pr56605.c fails after r12-8128-g6b7cc7294770ec

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

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

seurer at gcc dot gnu.org changed:

   What|Removed |Added

 Target|powerpc64-linux-gnu |powerpc64-linux-gnu,
   ||powerpc64le-linux-gnu
  Build|powerpc64-linux-gnu |powerpc64-linux-gnu,
   ||powerpc64le-linux-gnu
   Host|powerpc64-linux-gnu |powerpc64-linux-gnu,
   ||powerpc64le-linux-gnu

--- Comment #1 from seurer at gcc dot gnu.org ---
update:  It fails on LE machines, too.

[Bug testsuite/105313] New: [12 regression] gcc.target/powerpc/pr56605.c fails after r12-8128-g6b7cc7294770ec

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

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

Bug ID: 105313
   Summary: [12 regression] gcc.target/powerpc/pr56605.c fails
after r12-8128-g6b7cc7294770ec
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:6b7cc7294770ecb57c0f3a116a27ce1aaff170b5, r12-8128-g6b7cc7294770ec
make  -k check-gcc RUNTESTFLAGS="--target_board=unix'{-m32,-m64}'
powerpc.exp=gcc.target/powerpc/pr56605.c"
FAIL: gcc.target/powerpc/pr56605.c scan-rtl-dump-times combine "\\(compare:CC
\\((?:and|zero_extend):(?:[SD]I) \\((?:sub)?reg:[SD]I" 1

This fails on powerpc64 BE machines.

commit 6b7cc7294770ecb57c0f3a116a27ce1aaff170b5
Author: Alexandre Oliva 
Date:   Tue Apr 12 22:41:45 2022 -0300

ppc: testsuite: PROMOTE_MODE fallout pr56605 [PR102146]

[Bug target/105136] [11/12 regression] Missed optimization regression with 32-bit adds and shifts

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||vmakarov at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
This started with r11-209-g74dc179a6da33cd00f6d4a93fbb97dc84f610126

[Bug target/104338] RISC-V: Subword atomics result in library calls

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

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

--- Comment #9 from Jonathan Wakely  ---
(In reply to RZ Pan (XieJiSS) from comment #7)
> I'm not sure why bugzilla lost sync with the mailing list.

There is no sync between gcc-patches and bugzilla, and never has been.

[Bug middle-end/105312] New: attribute__((optimize("-O3"))) stress_matrix_xy_identity compiling stress-ng for arm

[raj.khem at gmail dot com via Gcc-bugs]

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

Bug ID: 105312
   Summary: attribute__((optimize("-O3")))
stress_matrix_xy_identity compiling stress-ng for arm
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: raj.khem at gmail dot com
  Target Milestone: ---

GCC 12 gets into an ICE when compiling this testcase (reduced from stress-ng)

typedef float stress_matrix_type_t;
typedef unsigned int size_t;
static void __attribute__((optimize("-O3"))) stress_matrix_xy_identity(
 const size_t n,
 stress_matrix_type_t a[restrict n][n],
 stress_matrix_type_t b[restrict n][n],
 stress_matrix_type_t r[restrict n][n])
{
 register size_t i;
 (void)a;
 (void)b;
 for (i = 0; i < n; i++) {
  register size_t j;
  for (j = 0; j < n; j++)
   r[i][j] = (i == j) ? 1.0 : 0.0;
   return;
 }
}

===

arm-yoe-linux-musleabi-gcc -mthumb -mfpu=neon -mfloat-abi=hard -mcpu=cortex-a15
-fstack-protector-strong -D_FORTIFY_SOURCE=2 stress-matrix.i
during GIMPLE pass: isel
stress-matrix.i: In function 'stress_matrix_xy_identity':
stress-matrix.i:3:46: internal compiler error: in gimple_expand_vec_cond_expr,
at gimple-isel.cc:268
3 | static void __attribute__((optimize("-O3"))) stress_matrix_xy_identity(
  |  ^
0x15d4b28 internal_error(char const*, ...)
???:0
0x6005fb fancy_abort(char const*, int, char const*)
???:0
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/104338] RISC-V: Subword atomics result in library calls

[patrick at rivosinc dot com via Gcc-bugs]

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

Patrick O'Neill  changed:

   What|Removed |Added

  Attachment #52368|0   |1
is obsolete||

--- Comment #8 from Patrick O'Neill  ---
Created attachment 52835
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52835&action=edit
Patch v3

Patch submitted to mailing list.
Subject: [PATCH v3] RISC-V: Add support for inlining subword atomic operations.

[Bug c++/105300] segfault from static_assert with user-defined string suffix argument

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

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

Martin Liška  changed:

   What|Removed |Added

 Status|WAITING |NEW

[Bug c++/95986] Partial specialization of class template is not found when class template has NTTP of class type

[bence.kodaj at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Bence Kodaj  ---
For what it's worth #2: In gcc 11.2, instead of a failed static assertion, we
get an internal compiler error.

[Bug target/105257] [8/9/10/11 regression] ICE in final_scan_insn_1, at final.cc:2811

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

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[8/9/10/11/12 regression]   |[8/9/10/11 regression] ICE
   |ICE in final_scan_insn_1,   |in final_scan_insn_1, at
   |at final.cc:2811|final.cc:2811

--- Comment #9 from Jakub Jelinek  ---
Fixed on the trunk (so far).

[Bug target/105257] [8/9/10/11/12 regression] ICE in final_scan_insn_1, at final.cc:2811

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

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

--- Comment #8 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

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

commit r12-8197-geeca2b8bd03f57c59c6cf48bf6b9bd6dc86924f6
Author: Jakub Jelinek 
Date:   Tue Apr 19 18:58:59 2022 +0200

sparc: Preserve ORIGINAL_REGNO in epilogue_renumber [PR105257]

The following testcase ICEs, because the pic register is
(reg:DI 24 %i0 [109]) and is used in the delay slot of a return.
We invoke epilogue_renumber and that changes it to
(reg:DI 8 %o0) which no longer satisfies sparc_pic_register_p
predicate, so we don't recognize the insn anymore.

The following patch fixes that by preserving ORIGINAL_REGNO if
specified, so we get (reg:DI 8 %o0 [109]) instead.

2022-04-19  Jakub Jelinek  

PR target/105257
* config/sparc/sparc.cc (epilogue_renumber): If ORIGINAL_REGNO,
use gen_raw_REG instead of gen_rtx_REG and copy over also
ORIGINAL_REGNO.  Use return 0; instead of /* fallthrough */.

* gcc.dg/pr105257.c: New test.

[Bug target/105257] [8/9/10/11/12 regression] ICE in final_scan_insn_1, at final.cc:2811

[ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs]

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

--- Comment #7 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #6 from Eric Botcazou  ---
>> Will take a while to test though, gcc102 on GCCFarm isn't exactly fast even
>> with make -j256.
>
> Niagara 3... ouch!   Let me test it on a fast SPARC machine.

Indeed ;-)  A regtest completed successfully on my S7-2 system (-j96).

[Bug fortran/103662] [12 Regression] TBAA problem in Fortran FE triggering in gfortran.dg/unlimited_polymorphic_3.f03

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

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

--- Comment #18 from Jakub Jelinek  ---
! { dg-do run }
!
! Check that pointer assignments allowed by F2003:C717
! work and check null initialization of CLASS(*) pointers.
!
! Contributed by Tobias Burnus 
!
program main
  interface
subroutine foo(z)
  class(*), pointer, intent(in) :: z
end subroutine foo
  end interface
  type sq
sequence
integer :: i
  end type sq
  type(sq), target :: x
  class(*), pointer :: y, z
  x%i = 42
  y => x
  z => y ! unlimited => unlimited allowed
  call foo (z)
  call bar
contains
  subroutine bar
type t
end type t
type(t), pointer :: x
class(*), pointer :: ptr1 => null() ! pointer initialization
if (same_type_as (ptr1, x) .neqv. .FALSE.) STOP 1
  end subroutine bar

end program main


subroutine foo(tgt)
  class(*), pointer, intent(in) :: tgt
  type sq
sequence
integer :: i
  end type sq
  type(sq), pointer :: ptr
  ptr => tgt ! sequence type => unlimited allowed
  if (ptr%i .ne. 42) STOP 2
end subroutine foo

works with your patch and doesn't without it.
But, if I change sq in foo to s, it doesn't work anymore.  Though, seems even
type name and all member names are important, so I think we should just
change the testcase to the above and perhaps add another one with bind(c)
derived type instead of the sequence one.

[Bug libstdc++/105308] Specialize for_each

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

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

--- Comment #3 from Jonathan Wakely  ---
(In reply to Marc Glisse from comment #2)
> (In reply to Jonathan Wakely from comment #1)
> > That code comes from the PSTL project which is part of LLVM,
> > and maintained by Intel, so enhancements to it should ideally be done 
> > upstream.
> 
> But the code would need to use private interfaces of libstdc++'s _Rb_tree.
> Does PSTL contain a lot of special code, with one variant for libstdc++ /
> libc++ / other, that uses internals of the datastructures?

No, the core of it is portable, with some impl-specific headers to incorporate
it into either libstdc++ or libc++ (although I don't think libc++ actually uses
it yet).

So if we want to use the internals of our _Rb_tree then yes, we'll need some
downstream changes in our copy.

[Bug c++/105256] [9/10/11 Regression] ICE compiling firefox-99

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

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[9/10/11/12 Regression] ICE |[9/10/11 Regression] ICE
   |compiling firefox-99|compiling firefox-99

--- Comment #30 from Jakub Jelinek  ---
Fixed on the trunk so far.
Will test 11.3 backport overnight.

[Bug c++/105256] [9/10/11/12 Regression] ICE compiling firefox-99

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

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

--- Comment #29 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

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

commit r12-8196-geb03e424598d30fed68801af6d6ef6236d32e32e
Author: Jakub Jelinek 
Date:   Tue Apr 19 18:27:41 2022 +0200

c++: Fix up CONSTRUCTOR_PLACEHOLDER_BOUNDARY handling [PR105256]

The CONSTRUCTOR_PLACEHOLDER_BOUNDARY bit is supposed to separate
PLACEHOLDER_EXPRs that should be replaced by one object or subobjects of it
(variable, TARGET_EXPR slot, ...) from other PLACEHOLDER_EXPRs that should
be replaced by different objects or subobjects.
The bit is set when finding PLACEHOLDER_EXPRs inside of a CONSTRUCTOR, not
looking into nested CONSTRUCTOR_PLACEHOLDER_BOUNDARY ctors, and we prevent
elision of TARGET_EXPRs (through TARGET_EXPR_NO_ELIDE) whose initializer
is a CONSTRUCTOR_PLACEHOLDER_BOUNDARY ctor.  The following testcase ICEs
though, we don't replace the placeholders in there at all, because
CONSTRUCTOR_PLACEHOLDER_BOUNDARY isn't set on the TARGET_EXPR_INITIAL
ctor, but on a ctor nested in such a ctor.  replace_placeholders should be
run on the whole TARGET_EXPR slot.

So, the following patch fixes it by moving the
CONSTRUCTOR_PLACEHOLDER_BOUNDARY
bit from nested CONSTRUCTORs to the CONSTRUCTOR containing those (but only
if it is closely nested, if there is some other tree sandwiched in between,
it doesn't do it).

2022-04-19  Jakub Jelinek  

PR c++/105256
* typeck2.cc (process_init_constructor_array,
process_init_constructor_record, process_init_constructor_union):
Move
CONSTRUCTOR_PLACEHOLDER_BOUNDARY flag from CONSTRUCTOR elements to
the
containing CONSTRUCTOR.

* g++.dg/cpp0x/pr105256.C: New test.

[Bug c/105311] [12]Still generate memset even with -fno-tree-loop-distribute-patterns

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

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

--- Comment #1 from Andrew Pinski  ---
No member can be emitted for other reasons. This is a dup of a much much older
issue. Memset for this case has been emitting since at least 3.0.

[Bug fortran/103662] [12 Regression] TBAA problem in Fortran FE triggering in gfortran.dg/unlimited_polymorphic_3.f03

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

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

--- Comment #17 from Mikael Morin  ---
(In reply to Jakub Jelinek from comment #15)
> Now, the question is what is the Fortran unlimited polymorphic semantics, if
> one can store through one type and read through a different type which just
> has the same layout, or if it also has to use the same name etc., or if it
> is even acceptable to store through say a type with a pair of integers and
> read through a type with double precision etc.

I think the pointer assignments in foo are invalid:


10.2.2.3 Data pointer assignment
… If the pointer object is of a type with the BIND attribute or the SEQUENCE
attribute, the dynamic type of the pointer target shall be that type.

 => the dynamic type of tgt shall be respectively s and t

7.3.2.3 CLASS type specifier
… The dynamic type of an associated polymorphic pointer is the dynamic type of
its target.

 => the dynamic type of tgt is that of z
 => the dynamic type of z is that of y
 => the dynamic type of y is that of x, which is sq

7.5.2.4 Determination of derived types
… Data entities also have the same type if they are declared with reference to
different derived-type definitions that specify the same type name, all have
the SEQUENCE attribute or all have the BIND attribute, have no components with
PRIVATE accessibility, and have components that agree in order, name, and
attributes. Otherwise, they are of different derived types.

 => sq and s are different types (different component name)
 => sq and t are different types (different component name, bind(c), sequence)
 => s and t are different types (bind(c), sequence)


So ptr1 and ptr2 should either have type sq, or s and t should be changed to be
"compatible" with sq. And "compatible" is defined in the 7.5.2.4 excerpt above.

[Bug go/105302] gccgo for Windows using MinGW-w64

[ian at airs dot com via Gcc-bugs]

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

--- Comment #6 from Ian Lance Taylor  ---
The magic string itself is fine: it's the "v3;\n".  Perhaps there is some
problem locating it in the file.  Some of the relevant code is
go_read_export_data in gcc/go/go-backend.cc.  Try to find out what it returns.

[Bug fortran/105310] ICE when UNION is after the 8th field in a DEC STRUCTURE with -finit-derived -finit-local-zero

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

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

Fritz Reese  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2022-04-19
   Assignee|unassigned at gcc dot gnu.org  |foreese at gcc dot 
gnu.org

--- Comment #1 from Fritz Reese  ---
Created attachment 52834
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52834&action=edit
Patch which fixes the bug based on trunk

The bug is caused by gfc_conv_union_initializer in gcc/fortran/trans-expr.cc,
which accepts a pointer to a vector of constructor trees (vec*) as an argument, then appends one or two field constructors to the
vector. The problem is the use of CONSTRUCTOR_APPEND_ELT(v, ...) within
gfc_conv_union_initializer, which modifies the vector pointer v when a
reallocation of the vector occurs, but the pointer is passed by value.
Therefore, when a vector reallocation occurs, the vector caller's
(gfc_conv_structure) vector pointer is not updated and subsequently points to
freed memory. Chaos ensues.

The bug only occurs when gfc_conv_union_initializer itself triggers the
reallocation, which is whenever the vector is "full" (v->m_vecpfx.m_alloc ==
v->m_vecpfx.m_num). Since the vector defaults to allocating 8 elements and
doubles in size for every reallocation, the bug only occurs when there are 8,
16, 32, etc... fields with initializers prior to the union, causing the vector
of constructors to be resized when entering gfc_conv_union_initializer. The
-finit-derived and -finit-local-zero options together ensure each field has an
initializer, triggering the bug.

The patch fixes the bug by passing the vector pointer to
gfc_conv_union_initializer by reference, matching the signature of
vec_safe_push from within the CONSTRUCTOR_APPEND_ELT macro.

[Bug libstdc++/105308] Specialize for_each

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

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

--- Comment #2 from Marc Glisse  ---
(In reply to Jonathan Wakely from comment #1)
> I'm unclear what the request is.

The list isn't super clear to me either, any sensible specialization of a
standard algorithm for a standard container. Even simply
ranges::for_each(std::set,*) looks like it could be a bit faster with a
specialization instead of using iterators.

> Are you proposing this for the parallel
> std::for_each with an execution policy?

Yes, that's the first motivation.

> That code comes from the PSTL project which is part of LLVM,
> and maintained by Intel, so enhancements to it should ideally be done 
> upstream.

But the code would need to use private interfaces of libstdc++'s _Rb_tree. Does
PSTL contain a lot of special code, with one variant for libstdc++ / libc++ /
other, that uses internals of the datastructures?

[Bug c/105311] New: [12]Still generate memset even with -fno-tree-loop-distribute-patterns

[570070308 at qq dot com via Gcc-bugs]

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

Bug ID: 105311
   Summary: [12]Still generate memset even with
-fno-tree-loop-distribute-patterns
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: 570070308 at qq dot com
  Target Milestone: ---

I have read the https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56888 , according
to this, adding `-fno-tree-loop-distribute-patterns` will prevent gcc from
calling memset. However, the gcc still call memset with the code below:
```test.c
#include 
struct Page_Table_Page
{
uint64_t pts[511][512];
};

void init_ptp(struct Page_Table_Page*const ptp)
{
*ptp=(struct Page_Table_Page){{{0}}};
}
```
compile with:
```
gcc-12 -O3 test.c -S -fno-tree-loop-distribute-patterns -fno-builtin-memset
-fno-builtin -nodefaultlibs -nostdlib -ffreestanding
```

```test.s
init_ptp:
.LFB24:
.cfi_startproc
endbr64
subq$8, %rsp
.cfi_def_cfa_offset 16
movl$2093056, %edx
xorl%esi, %esi
callmemset@PLT
addq$8, %rsp
.cfi_def_cfa_offset 8
ret
```

The gcc-12 is installed by apt on Ubuntu 22.04.
The full compile log:
```
$ gcc-12 -O3 test.c -S -fno-tree-loop-distribute-patterns -fno-builtin-memset
-fno-builtin -nodefaultlibs -nostdlib -ffreestanding -v
Using built-in specs.
COLLECT_GCC=gcc-12
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
12-20220319-1ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-12/README.Bugs
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-12
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new
--enable-gnu-unique-object --disable-vtable-verify --enable-plugin
--enable-default-pie --with-system-zlib --enable-libphobos-checking=release
--with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch
--disable-werror --enable-cet --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none=/build/gcc-12-OcsLtf/gcc-12-12-20220319/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-12-OcsLtf/gcc-12-12-20220319/debian/tmp-gcn/usr
--enable-offload-defaulted --without-cuda-driver --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.0.1 20220319 (experimental) [master r12-7719-g8ca61ad148f]
(Ubuntu 12-20220319-1ubuntu1) 
COLLECT_GCC_OPTIONS='-O3' '-S' '-fno-tree-loop-distribute-patterns'
'-fno-builtin-memset' '-fno-builtin' '-nodefaultlibs' '-nostdlib'
'-ffreestanding' '-v' '-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/12/cc1 -quiet -v -imultiarch x86_64-linux-gnu
test.c -quiet -dumpbase test.c -dumpbase-ext .c -mtune=generic -march=x86-64
-O3 -version -fno-tree-loop-distribute-patterns -fno-builtin-memset
-fno-builtin -ffreestanding -o test.s -fasynchronous-unwind-tables -Wformat
-Wformat-security -fstack-clash-protection -fcf-protection
GNU C17 (Ubuntu 12-20220319-1ubuntu1) version 12.0.1 20220319 (experimental)
[master r12-7719-g8ca61ad148f] (x86_64-linux-gnu)
compiled by GNU C version 12.0.1 20220319 (experimental) [master
r12-7719-g8ca61ad148f], GMP version 6.2.1, MPFR version 4.1.0, MPC version
1.2.1, isl version isl-0.24-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory "/usr/lib/gcc/x86_64-linux-gnu/12/include-fixed"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-linux-gnu/12/../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/x86_64-linux-gnu/12/include
 /usr/local/include
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.
GNU C17 (Ubuntu 12-20220319-1ubuntu1) version 12.0.1 20220319 (experimental)
[master r12-7719-g8ca61ad148f] (x86_64-linux-gnu)
compiled by GNU C version 12.0.1 20220319 (experimental) [master
r12-7719-g8ca61ad148f], GMP version 6.2.1, MPFR version 4.1.0, MPC version
1.2.1, isl version isl-0.24-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 200a3dd46f0674d1a8fcf2b133bc6014
COMPILER_PATH=/usr/lib/gcc/x86_64-linux-gnu/12/:/usr/lib/gcc/x86_64-linux-gnu/12/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-g

[Bug fortran/101632] NON_RECURSIVE procedure prefix is unsupported. F2018 defaults to recursive procedures.

[everythingfunctional at protonmail dot com via Gcc-bugs]

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

Brad Richardson  changed:

   What|Removed |Added

 CC||everythingfunctional@proton
   ||mail.com

--- Comment #8 from Brad Richardson  ---
*** Bug 105309 has been marked as a duplicate of this bug. ***

[Bug fortran/105309] recursive should be the default now, or -fcheck=recursion is incorrect

[everythingfunctional at protonmail dot com via Gcc-bugs]

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

Brad Richardson  changed:

   What|Removed |Added

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

--- Comment #2 from Brad Richardson  ---
Duplicate

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

[Bug fortran/105309] recursive should be the default now, or -fcheck=recursion is incorrect

[everythingfunctional at protonmail dot com via Gcc-bugs]

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

--- Comment #1 from Brad Richardson  ---
After some more searching, I think this is actually a duplicate of 101632. I'll
close this one.

[Bug tree-optimization/105086] [12 Regression] Dead Code Elimination Regression at -Os (trunk vs. 11.2.0) 25

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P1  |P2

--- Comment #7 from Richard Biener  ---
Downgrading - lets defer to GCC 13 and consider backporting after GCC 12 is
released.

[Bug tree-optimization/104530] [12 Regression] Dead Code Elimination Regression at -O3 (trunk vs. 11.2.0)

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P1  |P2

--- Comment #4 from Richard Biener  ---
Downgrading, lets defer to GCC 13 (we can still backport if the solution is
suitable).

[Bug fortran/105310] New: ICE when UNION is after the 8th field in a DEC STRUCTURE with -finit-derived -finit-local-zero

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

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

Bug ID: 105310
   Summary: ICE when UNION is after the 8th field in a DEC
STRUCTURE with -finit-derived -finit-local-zero
   Product: gcc
   Version: 7.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: foreese at gcc dot gnu.org
  Target Milestone: ---

Created attachment 52833
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52833&action=edit
Test case exhibiting the ICE

Consider:

$ cat testunion.for
  PROGRAM TESTU
IMPLICIT NONE
STRUCTURE /FOO/
  INTEGER(4) :: a,b,c,d,e,f,g,h
  UNION
  MAP
  ENDMAP
  ENDUNION
ENDSTRUCTURE
RECORD /FOO/ bar
bar.a = 1
  END

$ gfortran -O0 -c -ffixed-form -finit-local-zero -finit-derived -fdec-structure
testunion.for
testunion.for:15:0:

   end

internal compiler error: Segmentation fault
0xa72a2f crash_signal
/data/gcc-7.4.0/gcc/toplev.c:337
0xcb6a54 compute_reloc_for_constant(tree_node*)
/data/gcc-7.4.0/gcc/varasm.c:4120
0xcb6b5c compute_reloc_for_constant(tree_node*)
/data/gcc-7.4.0/gcc/varasm.c:4174
0xcbc802 get_variable_section(tree_node*, bool)
/data/gcc-7.4.0/gcc/varasm.c:1148
0xcc0cb7 assemble_variable(tree_node*, int, int, int)
/data/gcc-7.4.0/gcc/varasm.c:2225
0xcc4ce2 varpool_node::assemble_decl()
/data/gcc-7.4.0/gcc/varpool.c:588
0x7426fc output_in_order
/data/gcc-7.4.0/gcc/cgraphunit.c:2289
0x742ac3 symbol_table::compile()
/data/gcc-7.4.0/gcc/cgraphunit.c:2530
0x744b16 symbol_table::compile()
/data/gcc-7.4.0/gcc/cgraphunit.c:2629
0x744b16 symbol_table::finalize_compilation_unit()
/data/gcc-7.4.0/gcc/cgraphunit.c:2626
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.


ICE occurs with 7.4 and higher, where the -fdec-structure and -finit-derived
options were introduced.

The ICE occurs at -O0 but not for higher optimization levels. The ICE occurs
only when there are (8*2^n) fields preceding the union, regardless of which
fields are in the union.

[Bug gcov-profile/105282] [11/12 Regression] V_INDIR overflow causes ICE on -O0 -flto in stream_out_histogram_value, at value-prof.cc:340

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug target/105257] [8/9/10/11/12 regression] ICE in final_scan_insn_1, at final.cc:2811

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug rtl-optimization/105231] [12 Regression] ICE: in rtl_verify_bb_insns, at cfgrtl.cc:2797 (flow control insn inside a basic block) with custom flags since r12-4767-g81342e95827f77c0

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

--- Comment #29 from Richard Biener  ---
Technically P1.

[Bug target/103938] [9/10/11/12 Regression] ICE with __builtin_prefetch and vectors

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug fortran/103662] [12 Regression] TBAA problem in Fortran FE triggering in gfortran.dg/unlimited_polymorphic_3.f03

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

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

--- Comment #16 from Richard Biener  ---
(In reply to Mikael Morin from comment #12)
> Created attachment 52828 [details]
> Fix attempt
> 
> I think the attached patch avoids the multiple declarations for
> __class_STAR_p,
> but the testsuite FAIL remains, so I must be missing important.
> Is there a -fdump-tree-types or something so that the problem can be seen in
> dumps (both for eyeballing and for matching with the testsuite)?

I agree with Jakub that this is good progression so we should probably get this
to a shape that is committable and commit it.

Btw - thanks for working on the Fortran frontend issues!

[Bug libstdc++/105308] Specialize for_each

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

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

--- Comment #1 from Jonathan Wakely  ---
I'm unclear what the request is. Are you proposing this for the parallel
std::for_each with an execution policy? That code comes from the PSTL project
which is part of LLVM, and maintained by Intel, so enhancements to it should
ideally be done upstream.

[Bug fortran/105309] New: recursive should be the default now, or -fcheck=recursion is incorrect

[everythingfunctional at protonmail dot com via Gcc-bugs]

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

Bug ID: 105309
   Summary: recursive should be the default now, or
-fcheck=recursion is incorrect
   Product: gcc
   Version: 11.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: everythingfunctional at protonmail dot com
  Target Milestone: ---

As of F2018, all procedures are recursive by default. However,
`-fcheck=recursion` still identifies procedures called recursively (directly or
indirectly) that do not specify `non_recursive` with `Fortran runtime error:
Recursive call to nonrecursive procedure`. All procedures should be assumed to
have the recursive attribute unless explicitly declared otherwise.

[Bug tree-optimization/105217] Likely wrong code with -D_FORTIFY_SOURCE=3 since r12-6482-g06bc1b0c539e3a60

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

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

--- Comment #5 from Siddhesh Poyarekar  ---
(In reply to Jakub Jelinek from comment #4)
> Then there is the case where we can clearly see that the pointer from malloc
> is passed to realloc or can trace it to such easily.  I'd say in that case
> it would be worthwhile to do some extra work.
> For __bos the simplest solution would be if we detect something like that
> (e.g. that the SSA_NAME passed to realloc has uses dominated by the realloc
> call (though, even figuring that can mean we e.g. mark gimple stmts in each
> bb with increasing uids to determine like reassoc what stmt is before
> another one) just to punt, say we don't know anything about the SSA_NAME's
> size, or use conservative choice from both malloc and realloc (maximum for
> bos0/bos1, minimum for bos2/bos3).
> For __bdos perhaps the same.  Another possibility would be to temporarily
> split the SSA_NAME passed to realloc, kind like old VRP was introducing
> ASSERT_EXPRs.
> So, basically when we see:
>   whatever = realloc (p_34, ...);
> rewrite that (temporarily?) to:
>   p_121 = p_34;
>   whatever = realloc (p_121, ...);
> and change all p_34 uses dominated by the realloc stmt to p_121, and add the
> p_121 = p_34; stmt to some hash table or otherwise mark it so that we
> wouldn't propagate the objsz knowledge from p_34 to p_121, but instead set
> it on the realloc call.  That won't cover the integral comparisons though
> I'm afraid...

This sounds like a gcc 13+ project.  Can we downgrade this since the reproducer
is technically invalid and we're only going to attempt to support a limited
subset of such uses?

[Bug libstdc++/105308] New: Specialize for_each

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

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

Bug ID: 105308
   Summary: Specialize for_each
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: enhancement
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: glisse at gcc dot gnu.org
  Target Milestone: ---

Hello,

with a balanced binary tree, as used for instance in std::set or std::map, it
is relatively easy to perform an operation in parallel on all elements (like
for_each): recurse on the 2 subtrees in parallel (and probably assign the top
node to one of the subtrees arbitrarily). Of course there are technical
details, we don't store the size of subtrees so we may want to decide in
advance how deep to switch to sequential, etc. Doing this requires accessing
details of the tree implementation and cannot be done by a user (plus, for_each
doesn't seem to be a customization point...).

I am still confused that we have the traditional for_each, the new for_each
with execution policy, the new range for_each, but no mixed range + execution
policy. This specialization would be easier to implement for a whole tree than
for an arbitrary subrange. It is still possible there, but likely less
balanced, and we may need a first pass to find the common ancestor and possibly
other relevant information (or check if the range is the whole container if
that's possible and only optimize that case).

Possibly some other containers could specialize for_each, although it isn't as
obvious.

Actually, even the sequential for_each could benefit from a specialization for
various containers. Recursing on subtrees is a bit cheaper than having the
iterator move up and down, forward_list could avoid pointing to the previous
element, dequeue could try to split at block boundaries, etc.

Other algorithms that iterate through a range like reduce, all_of, etc could
also benefit, hopefully most are simple wrappers around others so few would
need a specialization.

[Bug tree-optimization/104240] SLP discovery does not consider swapping comparisons

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

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

Bug 103941 Summary: uavgv2qi3_ceil is not used (SLP costing and patterns vs 
live stmts)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103941

   What|Removed |Added

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

[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations

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

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

Bug 103941 Summary: uavgv2qi3_ceil is not used (SLP costing and patterns vs 
live stmts)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103941

   What|Removed |Added

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

[Bug tree-optimization/103941] uavgv2qi3_ceil is not used (SLP costing and patterns vs live stmts)

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #6 from Richard Biener  ---
Fixed on trunk via the PR104010 regression fix.

[Bug tree-optimization/104010] [12 regression] short loop no longer vectorized with Neon after r12-3362

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

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/103941] uavgv2qi3_ceil is not used (SLP costing and patterns vs live stmts)

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

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Richard Biener :

https://gcc.gnu.org/g:353434b65ef7972172597d232ae17022d9a57244

commit r12-8195-g353434b65ef7972172597d232ae17022d9a57244
Author: Richard Biener 
Date:   Wed Apr 13 13:49:45 2022 +0200

tree-optimization/104010 - fix SLP scalar costing with patterns

When doing BB vectorization the scalar cost compute is derailed
by patterns, causing lanes to be considered live and thus not
costed on the scalar side.  For the testcase in PR104010 this
prevents vectorization which was done by GCC 11.  PR103941
shows similar cases of missed optimizations that are fixed by
this patch.

2022-04-13  Richard Biener  

PR tree-optimization/104010
PR tree-optimization/103941
* tree-vect-slp.cc (vect_bb_slp_scalar_cost): When
we run into stmts in patterns continue walking those
for uses outside of the vectorized region instead of
marking the lane live.

* gcc.target/i386/pr103941-1.c: New testcase.
* gcc.target/i386/pr103941-2.c: Likewise.

[Bug tree-optimization/104010] [12 regression] short loop no longer vectorized with Neon after r12-3362

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

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

--- Comment #15 from CVS Commits  ---
The master branch has been updated by Richard Biener :

https://gcc.gnu.org/g:353434b65ef7972172597d232ae17022d9a57244

commit r12-8195-g353434b65ef7972172597d232ae17022d9a57244
Author: Richard Biener 
Date:   Wed Apr 13 13:49:45 2022 +0200

tree-optimization/104010 - fix SLP scalar costing with patterns

When doing BB vectorization the scalar cost compute is derailed
by patterns, causing lanes to be considered live and thus not
costed on the scalar side.  For the testcase in PR104010 this
prevents vectorization which was done by GCC 11.  PR103941
shows similar cases of missed optimizations that are fixed by
this patch.

2022-04-13  Richard Biener  

PR tree-optimization/104010
PR tree-optimization/103941
* tree-vect-slp.cc (vect_bb_slp_scalar_cost): When
we run into stmts in patterns continue walking those
for uses outside of the vectorized region instead of
marking the lane live.

* gcc.target/i386/pr103941-1.c: New testcase.
* gcc.target/i386/pr103941-2.c: Likewise.

[Bug go/105302] gccgo for Windows using MinGW-w64

[brechtsanders at users dot sourceforge.net via Gcc-bugs]

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

--- Comment #5 from Brecht Sanders  
---
The generated internal/cpu.gox looks like the below dump. Can you see what the
issue is with the magic string?
```
: 6486 0100   5809  0200   d...X...
0010:  0500 2f34       /4..
0020:   1c09  3c00     <...
0030:     4000 3040 7633 3b0a  @.0@v3;.
0040: 7061 636b 6167 6520 6370 750a 706b 6770  package cpu.pkgp
0050: 6174 6820 696e 7465 726e 616c 2f63 7075  ath internal/cpu
0060: 0a69 6e69 7420 6370 7520 696e 7465 726e  .init cpu intern
0070: 616c 5f31 6370 752e 2e69 6d70 6f72 740a  al_1cpu..import.
0080: 7479 7065 7320 3134 2032 2033 3120 3130  types 14 2 31 10
0090: 2032 3220 3435 2034 3031 2032 3539 2031   22 45 401 259 1
00a0: 3531 2038 3920 3131 3220 3530 3320 3235  51 89 112 503 25
00b0: 2032 3120 3232 0a74 7970 6520 3120 2243   21 22.type 1 "C
00c0: 6163 6865 4c69 6e65 5061 6422 203c 7479  acheLinePad" .type 2 ().
00e0: 7479 7065 2033 2028 3f20 3c74 7970 6520  type 3 (? ).type 4 str
```

[Bug c++/105307] -fmax-errors truncated for concept diagnostics

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Liška  ---
So the 2 errors are printed with the following backtraces:

#0  error (gmsgid=gmsgid@entry=0x22ca610 "template constraint failure for %qD")
at /home/marxin/Programming/gcc/gcc/diagnostic.cc:1837
#1  0x00bf3177 in lookup_template_class_1 (complain=3,
entering_scope=, context=, in_decl=0x0,
arglist=0x77752ba0, d1=) at
/home/marxin/Programming/gcc/gcc/cp/pt.cc:10013
#2  lookup_template_class (d1=d1@entry=0x77fb3100,
arglist=arglist@entry=0x77752b80, in_decl=in_decl@entry=0x0,
context=context@entry=0x0, entering_scope=entering_scope@entry=0,
complain=complain@entry=35) at /home/marxin/Programming/gcc/gcc/cp/pt.cc:10350
#3  0x00c1de16 in finish_template_type (name=name@entry=0x77fb3100,
args=args@entry=0x77752b80, entering_scope=0) at
/home/marxin/Programming/gcc/gcc/cp/semantics.cc:3710
#4  0x00b81462 in cp_parser_template_id (parser=0x77639850,
template_keyword_p=, check_dependency_p=,
tag_type=, is_declaration=) at
/home/marxin/Programming/gcc/gcc/cp/parser.cc:18332
#5  0x00b81716 in cp_parser_class_name (parser=0x77639850,
typename_keyword_p=, template_keyword_p=,
tag_type=none_type, check_dependency_p=, class_head_p=, is_declaration=false, enum_ok=true) at
/home/marxin/Programming/gcc/gcc/cp/parser.cc:25711
#6  0x00b77ee8 in cp_parser_qualifying_entity (is_declaration=false,
type_p=false, check_dependency_p=true, template_keyword_p=false,
typename_keyword_p=false, parser=0x77639850) at
/home/marxin/Programming/gcc/gcc/cp/parser.cc:7116
#7  cp_parser_nested_name_specifier_opt (parser=,
typename_keyword_p=, check_dependency_p=,
type_p=, is_declaration=,
template_keyword_p=false) at /home/marxin/Programming/gcc/gcc/cp/parser.cc:6798
#8  0x00b9dc0f in cp_parser_template_introduction
(parser=0x77639850, member_p=) at
/home/marxin/Programming/gcc/gcc/cp/parser.cc:31443
#9  0x00ba0637 in cp_parser_declaration (parser=0x77639850,
prefix_attrs=) at
/home/marxin/Programming/gcc/gcc/cp/parser.cc:14960
#10 0x00ba116c in cp_parser_toplevel_declaration
(parser=0x77639850) at /home/marxin/Programming/gcc/gcc/cp/parser.cc:14987
#11 cp_parser_translation_unit (parser=0x77639850) at
/home/marxin/Programming/gcc/gcc/cp/parser.cc:5010
#12 c_parse_file () at /home/marxin/Programming/gcc/gcc/cp/parser.cc:48067
#13 0x00ce579a in c_common_parse_file () at
/home/marxin/Programming/gcc/gcc/c-family/c-opts.cc:1240
#14 0x01260424 in compile_file () at
/home/marxin/Programming/gcc/gcc/toplev.cc:452
#15 0x009cfdf1 in do_compile (no_backend=false) at
/home/marxin/Programming/gcc/gcc/toplev.cc:2168
#16 toplev::main (this=this@entry=0x7fffd88e, argc=,
argc@entry=16, argv=, argv@entry=0x7fffd9b8) at
/home/marxin/Programming/gcc/gcc/toplev.cc:2320
#17 0x009d1d65 in main (argc=16, argv=0x7fffd9b8) at
/home/marxin/Programming/gcc/gcc/main.cc:39

#0  error_at (loc=260416, gmsgid=0x22aa635 "%qD is not a member of %qT") at
/home/marxin/Programming/gcc/gcc/diagnostic.cc:1864
#1  0x00bc632d in tsubst_qualified_id (qualified_id=0x7776e000,
args=, complain=, in_decl=,
done=, address_p=) at
/home/marxin/Programming/gcc/gcc/tree.h:3958
#2  0x00bc7a89 in tsubst_copy_and_build (t=0x7776e000,
args=0x77752d00, complain=3, in_decl=0x0, function_p=,
integral_constant_expression_p=false) at
/home/marxin/Programming/gcc/gcc/cp/pt.cc:20352
#3  0x00bda73f in tsubst_expr (integral_constant_expression_p=false,
in_decl=0x0, complain=3, args=0x77752d00, t=0x7776e000) at
/home/marxin/Programming/gcc/gcc/cp/pt.cc:19482
#4  tsubst_expr (t=t@entry=0x7776e000, args=args@entry=0x77752d00,
complain=complain@entry=3, in_decl=in_decl@entry=0x0,
integral_constant_expression_p=integral_constant_expression_p@entry=false) at
/home/marxin/Programming/gcc/gcc/cp/pt.cc:18441
#5  0x00a3695c in tsubst_valid_expression_requirement
(t=0x7776e000, args=args@entry=0x77752d00, info=..., info=...) at
/home/marxin/Programming/gcc/gcc/cp/constraint.cc:1935
#6  0x00a39a37 in tsubst_simple_requirement (info=..., info=...,
args=0x77752d00, t=0x777529c0) at
/home/marxin/Programming/gcc/gcc/cp/constraint.cc:1958
#7  tsubst_requirement (info=..., args=0x77752d00, t=0x777529c0) at
/home/marxin/Programming/gcc/gcc/cp/constraint.cc:2155
#8  tsubst_requires_expr (t=, args=, info=...) at
/home/marxin/Programming/gcc/gcc/cp/constraint.cc:2282
#9  0x00a3a327 in diagnose_atomic_constraint (t=0x77752cc0,
args=0x77752d00, result=0x7762c2a0, info=...) at
/home/mar

[Bug c++/105304] [10/11/12 Regression] ICE segfault using ad-hoc concept with -Wall since r10-7441-ga7ea3d2ced786c45

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

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

Martin Liška  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
 CC||marxin at gcc dot gnu.org,
   ||ppalka at gcc dot gnu.org
Summary|ICE segfault using ad-hoc   |[10/11/12 Regression] ICE
   |concept with -Wall  |segfault using ad-hoc
   ||concept with -Wall since
   ||r10-7441-ga7ea3d2ced786c45
   Last reconfirmed||2022-04-19

--- Comment #1 from Martin Liška  ---
Started with r10-7441-ga7ea3d2ced786c45.

[Bug c++/105300] segfault from static_assert with user-defined string suffix argument

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

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

Martin Liška  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 CC||marxin at gcc dot gnu.org
   Last reconfirmed||2022-04-19
 Status|UNCONFIRMED |WAITING

--- Comment #1 from Martin Liška  ---
Is it really a valid code since clang rejects it?

$ clang++ pr105300.C -c
pr105300.C:2:27: error: string literal with user-defined suffix cannot be used
here
static_assert(false, "foo"_x);
  ^
1 error generated.

[Bug jit/105279] Using libgccjit produces a null pointer access in GCC's tree-optimization code

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

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2022-04-19
 CC||marxin at gcc dot gnu.org

--- Comment #2 from Martin Liška  ---
It really crashes in the unary minus_expr:

$ gcc pr105279.c -lgccjit && ./a.out
libgccjit.so: error: invalid (pointer) operands ‘minus_expr’
_1 = ip - &labels[0];
libgccjit.so: error: ‘verify_gimple’ failed
0x7648d684 verify_gimple_in_seq(gimple*)
/home/marxin/Programming/gcc/gcc/tree-cfg.cc:5213
0x76157045 gimplify_body(tree_node*, bool)
/home/marxin/Programming/gcc/gcc/gimplify.cc:16438
0x761571bc gimplify_function_tree(tree_node*)
/home/marxin/Programming/gcc/gcc/gimplify.cc:16509
0x75ed876e gcc::jit::playback::function::postprocess()
/home/marxin/Programming/gcc/gcc/jit/jit-playback.cc:1917
0x75ed9cac gcc::jit::playback::context::replay()
/home/marxin/Programming/gcc/gcc/jit/jit-playback.cc:3258
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 fortran/103662] [12 Regression] TBAA problem in Fortran FE triggering in gfortran.dg/unlimited_polymorphic_3.f03

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

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

--- Comment #15 from Jakub Jelinek  ---
Putting a breakpoint on new_alias_set, I see that
RECORD_TYPE sq gets alias set 1
RECORD_TYPE s gets alias set 9
RECORD_TYPE t gets alias set 10

Those are
  type sq
sequence
integer :: i
  end type sq
and
  type, bind(c) :: s
integer (c_int) :: k
  end type s
  type t
sequence
integer :: k
  end type t
in the testcase.  The testcase stores through the sq type and reads through
pointer to s and pointer to t type.  As the alias sets are different, for the
middle-end the testcase is invalid.
Now, the question is what is the Fortran unlimited polymorphic semantics, if
one can store through one type and read through a different type which just has
the same layout, or if it also has to use the same name etc., or if it is even
acceptable to store through say a type with a pair of integers and read through
a type with double precision etc.
GCC has types that can alias anything, so if the semantics is like that,
unlimited polymorphic middle-end pointers perhaps should use that.
Or the testcase is invalid and has to use type sq in foo as well.  Or we need
to ensure sq and s/t above have the same alias set.

[Bug c/105270] gcc hangs with error "symbol definition loop encountered"

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #2 from Martin Liška  ---
Can't reproduce that with:

as --version
GNU assembler (GNU Binutils; openSUSE Tumbleweed) 2.38.20220411-4

What version of binutils do you use?

[Bug fortran/103662] [12 Regression] TBAA problem in Fortran FE triggering in gfortran.dg/unlimited_polymorphic_3.f03

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

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

--- Comment #14 from Jakub Jelinek  ---
Looking at your patch, there is a positive change with your patch, in optimized
dump the z._data store is no longer removed:
 __attribute__((externally_visible))
 integer(kind=4) main (integer(kind=4) argc, character(kind=1) * * argv)
 {
+  struct sq x;
   struct __class__STAR_p z;
   static integer(kind=4) options.0[7] = {2116, 4095, 0, 1, 1, 0, 31};
   integer(kind=4) _7;
@@ -37,6 +38,7 @@ integer(kind=4) main (integer(kind=4) ar
[local count: 1073741824]:
   _gfortran_set_args (argc_2(D), argv_3(D));
   _gfortran_set_options (7, &options.0[0]);
+  z._data = &x;
   foo (&z);
   _7 = __vtab__STAR._hash;
   if (_7 == 58708456)
@@ -48,6 +50,7 @@ integer(kind=4) main (integer(kind=4) ar
   _gfortran_stop_numeric (1, 0);

[local count: 1073441178]:
+  x ={v} {CLOBBER(eol)};
   z ={v} {CLOBBER(eol)};
   return 0;
But yes, it is still not enough.
If I use -Os -fno-tree-dse rather than -Os with your patch, the incremental
difference in optimized dump is:
--- unlimited_polymorphic_3.f03.252t.optimized  2022-04-19 15:32:50.716092070
+0200
+++ unlimited_polymorphic_3.f03.252t.optimized  2022-04-19 15:33:07.994850946
+0200
@@ -1,4 +1,17 @@

+;; Function __copy_main_Sq (__copy_main_Sq.0, funcdef_no=2, decl_uid=4241,
cgraph_uid=2, symbol_order=2)
+
+__attribute__((fn spec (". r w ")))
+void __copy_main_Sq (struct sq & restrict src, struct sq & restrict dst)
+{
+   [local count: 1073741824]:
+  *dst_2(D) = *src_3(D);
+  return;
+
+}
+
+
+
 ;; Function foo (foo_, funcdef_no=0, decl_uid=4226, cgraph_uid=1,
symbol_order=1)

 __attribute__((fn spec (". r ")))
@@ -32,12 +45,16 @@ integer(kind=4) main (integer(kind=4) ar
 {
   struct sq x;
   struct __class__STAR_p z;
+  static struct __vtype_main_Sq __vtab_main_Sq = {._hash=85658372, ._size=4,
._extends=0B, ._def_init=&__def_init_main_Sq, ._copy=__copy_main_Sq,
._final=0B, ._deallocate=0B};
   static integer(kind=4) options.0[7] = {2116, 4095, 0, 1, 1, 0, 31};
   integer(kind=4) _7;

[local count: 1073741824]:
   _gfortran_set_args (argc_2(D), argv_3(D));
   _gfortran_set_options (7, &options.0[0]);
+  x.i = 42;
+  z._vptr = &__vtab_main_Sq;
+  z._len = 0;
   z._data = &x;
   foo (&z);
   _7 = __vtab__STAR._hash;

I think the _vptr and _len fields aren't ever read and so it is ok the stores
to them are optimized away, so I think it is the x.i = 42; store.

[Bug target/70321] [9/10/11/12 Regression] STV generates less optimized code

[roger at nextmovesoftware dot com via Gcc-bugs]

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

Roger Sayle  changed:

   What|Removed |Added

 CC||roger at nextmovesoftware dot 
com

--- Comment #23 from Roger Sayle  ---
Patch proposed at
https://gcc.gnu.org/pipermail/gcc-patches/2022-April/593174.html
(waiting for GCC 13 stage 1).

[Bug c++/105244] [9/10/11/12 Regression] ICE in implicitly_declare_fn, at cp/method.cc:3114

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
template 
struct S
{
  static T max ();
};

template 
struct V
{
  double a = S::max[0] ();
};

template 
V<>
foo ()
{
  return {};
}

int
main ()
{
  V<> b = foo ();
}

What happens is that synthesized_method_walk with diag = false calls get_nsdmi
with tf_none, and much deeper there is pointer_int_sum which has:
  if (complain && warn_pointer_arith)
pedwarn (loc, OPT_Wpointer_arith,
 "pointer to a function used in arithmetic");
  else if (!complain)
return error_mark_node;
So, if get_nsdmi were called with tf_warning_or_error, we'd pedwarn on it, but
we are quite and just return error_mark_node from get_nsdmi in that case.
So, we end up with raises = error_mark_node and enter:
  /* Can happen, e.g., in C++98 mode for an ill-formed non-static data
 member initializer (c++/89914).  Also, in C++98, we might have
 failed to deduce RAISES, so try again but complain this time.  */
  if (cxx_dialect < cxx11)
synthesized_method_walk (type, kind, const_p, &raises, nullptr,
 nullptr, nullptr, /*diag=*/true,
 &inherited_ctor, inherited_parms);
  /* We should have seen an error at this point.  */
  gcc_assert (seen_error ());
and ICE, because at this point whether we pedwarn or not depends on
-Wpointer-arith, and even if not, pedwarn can warn rather than error etc.

Not really sure what to do here, if it is intentional that with tf_none we are
stricter and fail even on things we could just warn or pedwarn without
-pedantic-errors.

[Bug middle-end/104880] [11 Regression] ICE in expand_expr_addr_expr_1, at expr.c:8231 since r11-165-geb72dc663e9070

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

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

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

https://gcc.gnu.org/g:4b790d6e2e3d886e3116bd5591d57b29dc059910

commit r11-9887-g4b790d6e2e3d886e3116bd5591d57b29dc059910
Author: Richard Biener 
Date:   Tue Apr 19 13:48:02 2022 +0200

tree-optimization/104880 - move testcase

This renames the testcase to something picked up by the suites regexp.

2022-04-19  Richard Biener  

PR tree-optimization/104880
* g++.dg/opt/pr104880.cc: Rename to ...
* g++.dg/opt/pr104880.C: ... this.

(cherry picked from commit 214d2860f4e1573f04ef57bfea59da0cc66883ce)

[Bug middle-end/104880] [11 Regression] ICE in expand_expr_addr_expr_1, at expr.c:8231 since r11-165-geb72dc663e9070

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

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by Richard Biener :

https://gcc.gnu.org/g:214d2860f4e1573f04ef57bfea59da0cc66883ce

commit r12-8192-g214d2860f4e1573f04ef57bfea59da0cc66883ce
Author: Richard Biener 
Date:   Tue Apr 19 13:48:02 2022 +0200

tree-optimization/104880 - move testcase

This renames the testcase to something picked up by the suites regexp.

2022-04-19  Richard Biener  

PR tree-optimization/104880
* g++.dg/opt/pr104880.cc: Rename to ...
* g++.dg/opt/pr104880.C: ... this.

[Bug libstdc++/105291] include/c++/12.0.1/debug/safe_unordered_container.h:71:28: error: captured variable '__local_end' cannot appear here

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|FIXED   |MOVED

--- Comment #6 from Jonathan Wakely  ---
Thanks, Corentin.

Let's say Resolution=MOVED, since nothing got fixed in GCC.

[Bug libstdc++/105291] include/c++/12.0.1/debug/safe_unordered_container.h:71:28: error: captured variable '__local_end' cannot appear here

[sbergman at redhat dot com via Gcc-bugs]

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

Stephan Bergmann  changed:

   What|Removed |Added

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

--- Comment #5 from Stephan Bergmann  ---
(In reply to corentinjabot from comment #4)
> Agreed, clang should implement the proposed resolution to CWG2569 very soon
> so there isn't anything that needs to change in libstdc++

Thanks; seen fixed with

"[Clang] Use of decltype(capture) in parameter-declaration-clause".

[Bug ipa/105306] [12 Regression] ICE: verify_cgraph_node failed (error: semantic interposition mismatch)

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

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

--- Comment #4 from Jakub Jelinek  ---
Created attachment 52832
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52832&action=edit
gcc12-pr105306.patch

Untested fix.  Initializing semantic_interposition flag from
flag_semantic_interposition works well only if all the cgraph nodes are created
while those fndecls are current_function_decl, but that isn't always the case.

[Bug target/100340] Bootstrap fails with Clang 12.0.5 (XCode 12.5)

[kirill at korins dot ky via Gcc-bugs]

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

--- Comment #31 from Kirill A. Korinsky  ---
Iain, you're right.

This is a differnt things vecause it uses xcode 7.2.1.

[Bug target/104707] gcc on riscv64 isn't passing entire library path to the linker

[jpalus+gcc at fastmail dot com via Gcc-bugs]

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

--- Comment #5 from Jan Palus  ---
> Arm linux multilib is just as complex as riscvs really.

Perhaps my understanding of multilib is wrong but I meant pure 32bit, single
arch environment.

[Bug c++/104996] [10/11/12 Regression] Overload resolution over rvalue/const lvalue array reference parameters for an init. list argument incorrectly picks the const lvalue ref. overload

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

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

--- Comment #6 from Jonathan Wakely  ---
v2 posted: https://gcc.gnu.org/pipermail/gcc-patches/2022-April/593336.html

Looks like it addresses the comments by Marek and Jason.

[Bug target/100340] Bootstrap fails with Clang 12.0.5 (XCode 12.5)

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

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

--- Comment #30 from Iain Sandoe  ---
(In reply to Kirill A. Korinsky from comment #29)
> To synchronise things.
> 
> The same issue is appears on Yosemite (10.10) on MacPort's build bots on
> gcc10-bootstrap port with backported Iain's patch to as:
>  -
> https://build.macports.org/builders/ports-10.10_x86_64-builder/builds/180787
>  - https://trac.macports.org/ticket/65033

this ^ seems to 404 for me.

I am slightly confused - are you saying that someone is using Xcode 12.5 on
Yosemite?
(I would be amazed if that was a supported configuration).

NOTE: there are still back ports queued for GCC-10 (which would appear in
10.4).

[Bug target/104707] gcc on riscv64 isn't passing entire library path to the linker

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

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Jan Palus from comment #3)
> I doubt this has anything to do with riscv or multilib. It's just gcc that
> assumes all linkers should lookup /lib and /usr/lib and skips them when
> passing library paths to linker:
> 
> https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/gcc.cc;
> h=bb07cc244e30fbeccc701816db888f497d65eb08;hb=refs/heads/master#l7931
> 
> I had the same issue on arm (32-bit) so no riscv, no multilib and dropping
> this logic fixes the issue.

Arm linux multilib is just as complex as riscvs really.

[Bug target/100340] Bootstrap fails with Clang 12.0.5 (XCode 12.5)

[kirill at korins dot ky via Gcc-bugs]

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

Kirill A. Korinsky  changed:

   What|Removed |Added

 CC||kirill at korins dot ky

--- Comment #29 from Kirill A. Korinsky  ---
To synchronise things.

The same issue is appears on Yosemite (10.10) on MacPort's build bots on
gcc10-bootstrap port with backported Iain's patch to as:
 - https://build.macports.org/builders/ports-10.10_x86_64-builder/builds/180787
 - https://trac.macports.org/ticket/65033

Anyway, I can't reproduce it on Yosemite that I have.

[Bug target/105257] [8/9/10/11/12 regression] ICE in final_scan_insn_1, at final.cc:2811

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

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

--- Comment #6 from Eric Botcazou  ---
> Updated version of the patch with /* fallthrough */ -> return 0; and
> which uses gen_rtx_REG if ORIGINAL_REGNO is 0 so that we can use a shared
> rtx in that case.

Thanks.

> Will take a while to test though, gcc102 on GCCFarm isn't exactly fast even
> with make -j256.

Niagara 3... ouch!   Let me test it on a fast SPARC machine.

[Bug target/104707] gcc on riscv64 isn't passing entire library path to the linker

[jpalus+gcc at fastmail dot com via Gcc-bugs]

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

--- Comment #3 from Jan Palus  ---
I doubt this has anything to do with riscv or multilib. It's just gcc that
assumes all linkers should lookup /lib and /usr/lib and skips them when passing
library paths to linker:

https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/gcc.cc;h=bb07cc244e30fbeccc701816db888f497d65eb08;hb=refs/heads/master#l7931

I had the same issue on arm (32-bit) so no riscv, no multilib and dropping this
logic fixes the issue.

[Bug target/105257] [8/9/10/11/12 regression] ICE in final_scan_insn_1, at final.cc:2811

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

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

Jakub Jelinek  changed:

   What|Removed |Added

  Attachment #52830|0   |1
is obsolete||

--- Comment #5 from Jakub Jelinek  ---
Created attachment 52831
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52831&action=edit
gcc12-pr105257.patch

Updated version of the patch with /* fallthrough */ -> return 0; and
which uses gen_rtx_REG if ORIGINAL_REGNO is 0 so that we can use a shared rtx
in that case.
Will take a while to test though, gcc102 on GCCFarm isn't exactly fast even
with make -j256.

[Bug target/105257] [8/9/10/11/12 regression] ICE in final_scan_insn_1, at final.cc:2811

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

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

--- Comment #4 from Eric Botcazou  ---
> The problem is that (reg:DI 24 %i0 [109]) in a delay slot of the return
> satisfies sparc_pic_register_p but epilogue_renumber turns that into:
> (reg:DI 8 %o0) which doesn't satisfy it.
> The attached patch fixes that by always copying over ORIGINAL_REGNO.

This looks good to me.  You might as well want to remove the ugly fallthrough.

[Bug target/105257] [8/9/10/11/12 regression] ICE in final_scan_insn_1, at final.cc:2811

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

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

Eric Botcazou  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-04-19

--- Comment #3 from Eric Botcazou  ---
This comes from the new implementation of the PIC support.

[Bug ipa/105306] [12 Regression] ICE: verify_cgraph_node failed (error: semantic interposition mismatch)

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

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

--- Comment #3 from Martin Liška  ---
Reduced test-case:

$ cat semantic.C
#pragma GCC optimize 0
template  void foo(T);
struct B {
  ~B() {}
};
struct C {
  B f;
};
template  struct E {
  void bar() { foo(g); }
  C g;
};
template class E;

$ g++ semantic.C  -c -Ofast
semantic.C:13:23: error: semantic interposition mismatch
   13 | template class E;
  |   ^
_ZN1BD1Ev/2 (B::~B()) @0x7778e220
  Type: function definition analyzed alias cpp_implicit_alias
  Visibility: externally_visible public weak comdat comdat_group:_ZN1BD5Ev
one_only
  Same comdat group as: _ZN1BD2Ev/1
  References: _ZN1BD2Ev/1 (alias) 
  Referring: 
  Availability: available
  Function flags:
  Called by: _ZN1CD2Ev/5 
  Calls: 
during IPA pass: visibility

[Bug ipa/105306] [12 Regression] ICE: verify_cgraph_node failed (error: semantic interposition mismatch)

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

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

--- Comment #2 from Jakub Jelinek  ---
Note, with -Ofast -fsemantic-interposition or -Ofast
-fno-semantic-interposition, there is no ICE with any of r12-1, r12-5411,
r12-5412 or r12-8189.

[Bug ipa/105306] [12 Regression] ICE: verify_cgraph_node failed (error: semantic interposition mismatch)

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 CC||jakub at gcc dot gnu.org
 Ever confirmed|0   |1
   Priority|P3  |P1
   Last reconfirmed||2022-04-19

--- Comment #1 from Jakub Jelinek  ---
Started with r12-5412-g458d2c689963d8461d84670a3d8988cd6ecbfd81

[Bug c++/105307] -fmax-errors truncated for concept diagnostics

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

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

Martin Liška  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2022-04-19
 Status|UNCONFIRMED |ASSIGNED
 CC||marxin at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org

--- Comment #1 from Martin Liška  ---
Let me take a llok.

[Bug libstdc++/105281] status of constexpr and for c++23

[de34 at live dot cn via Gcc-bugs]

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

Jiang An  changed:

   What|Removed |Added

 CC||de34 at live dot cn

--- Comment #2 from Jiang An  ---
A quick glance at c_global/cmath:

constexpr in libstdc++, non-constexpr in C++23:
Transcendental and non-rational function families, constexpr potentially
results in ODR-violation (Bug 102916):
exp
expm1
exp2
sin
cos
tan
sinh
cosh
tanh
log
log1p
log10
log2
asin
acos
atan
atan2
asinh
acosh
atanh
pow
sqrt
hypot (except for 3-argument overloads)
cbrt
tgamma
lgamma
erf
erfc

Functions that "depend strongly on rounding mode":
nearbyint
rint
lrint
llrint

constexpr in C++23, lack constexpr (for some overloads) in libstdc++:
abs
modf
remquo
frexp

Other functions made constexpr by P0533 seems suitably marked with constexpr in
libstdc++. I think lack of constexpr for modf, remquo, and frexp is because of
the C++11 constexpr rule (constexpr functions were required to be pure).

[Bug c++/43943] "warning: no return statement in function returning non-void" should be an error

[kdevel at vogtner dot de via Gcc-bugs]

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

Stefan  changed:

   What|Removed |Added

 CC||kdevel at vogtner dot de

--- Comment #8 from Stefan  ---
(In reply to Jonathan Wakely from comment #4)
> There are cases which are either not diagnosable or cannot be
> written, such as this example from Doug Gregor:
> 
> in generic code, there might not be a way to create a value with the
> appropriate type. For example:
> 
>template
>T maybe_call(std::function f) {
>if (f)
>return f();
>else
>abort_program();
> 
>// Cannot write a return here, because we have no way to
> create a value of type 'T'
>}

One can of course write a return there:

   template
   T maybe_call(std::function f)
   {
  if (f)
 return f();
  else
 abort_program();

  // Cannot write a return here, because we have no way to create a value
of type 'T'
  return f();
   }

which refactors nicely into

   template
   T maybe_call(std::function f)
   {
  if (! f)
 abort_program();
  return f();
   }

[Bug gcov-profile/105238] Regression: using -fprofile-dir: gcno files not ccache cachable anymore / gcovr report broken

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

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

Martin Liška  changed:

   What|Removed |Added

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

[Bug gcov-profile/105282] [11/12 Regression] V_INDIR overflow causes ICE on -O0 -flto in stream_out_histogram_value, at value-prof.cc:340

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

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

--- Comment #4 from Martin Liška  ---
(In reply to Sergei Trofimovich from comment #2)
> Proposed the fix as
> https://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg283031.html

Next time, please use our official mailing list:
https://gcc.gnu.org/pipermail/gcc-patches/2022-April/593287.html