[Bug middle-end/105469] "execution reached an unreachable program point" with -flto

[remi.coulom at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Rémi Coulom  ---
(In reply to Richard Biener from comment #1)
> I can reproduce what you observe with -O3 -fwhole-program
> -fsanitize=unreachable
> (without the sanitize it gets into an infinite loop).  -fno-ipa-cp-clone
> avoids
> the issue (whatever it is exactly).
> 
> Can you attach un-preprocessed source as well?  You seem to be not using any
> non-standard header files.

Thanks for checking my code.

The code is available on github:
https://github.com/Remi-Coulom/joedb

Necessary files to replicate the bug can be found there:
https://github.com/Remi-Coulom/joedb/tree/master/doc/source/tutorial/gcc_bug

repro.cpp and all_includes.h should be enough.

I produced repro.cpp by preprocessing bug.cpp and pruning a lot of code. I
suppose repro.cpp should be enough for your purpose. If you ever wish to
compile bug.cpp you'll have to compile joedb first by running "./generate.sh"
in doc/source/tutorial.

[Bug tree-optimization/103116] SLP vectoriser fails to peel for gaps

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Biener  ---
We could make peeling for gaps handle this by making it not a flag but indicate
the number of vector(!?) iterations we need to peel.  We're doing the "correct"
thing in adjusting the IV increment via

  if (slp_perm
  && (group_size != scalar_lanes
  || !multiple_p (nunits, group_size)))
{
  /* We don't yet generate such SLP_TREE_LOAD_PERMUTATIONs for
 variable VF; see vect_transform_slp_perm_load.  */
  unsigned int const_vf = vf.to_constant ();
  unsigned int const_nunits = nunits.to_constant ();
  vec_num = CEIL (group_size * const_vf, const_nunits);
  group_gap_adj = vf * group_size - nunits * vec_num;

The problem also shows up for loops like

  for (int i = 0; i < COUNT; ++i)
{
  x[i * 4] = y[i * 3] + 1;
  x[i * 4 + 1] = y[i * 3] + 2;
  x[i * 4 + 2] = y[i * 3 + 1] + 3;
  x[i * 4 + 3] = y[i * 3 + 2] + 4;
}

where we cannot use a smaller vector type.

We could also use masked loads if available of course (not sure about the
cost of that vs peeling for gaps).

A conservative fix would be to detect when peeling for gaps as implemented
is good enough and do that and otherwise reject vectorization.

[Bug debug/105158] ftree-ccp (CFG cleanup) drops DWARF const value attribute at -Og/-O1/-O2/-O3

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

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

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

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

commit r13-99-g1ba68f78c9d2510eb095f7d8a90c87cd5fd4183d
Author: Richard Biener 
Date:   Tue Apr 5 15:23:54 2022 +0200

debug/105158 - improve debug stmt retaining for forwarder removal

Currently when we cannot move debug stmt from a forwarder to the
destination block we drop/reset them.  But in some cases as for
the testcase we can move them to the predecessor when that has
a single successor and we can insert after the last stmt of the
block.  That allows us to preserve debug info here.

2022-04-05  Richard Biener  

PR debug/105158
* tree-cfgcleanup.cc (move_debug_stmts_from_forwarder):
Move debug stmts to the predecessor if moving to the
destination is not possible.
(remove_forwarder_block): Adjust.
(remove_forwarder_block_with_phi): Likewise.

[Bug debug/105158] ftree-ccp (CFG cleanup) drops DWARF const value attribute at -Og/-O1/-O2/-O3

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

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug sanitizer/105471] New: A few hwasan failures

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

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

Bug ID: 105471
   Summary: A few hwasan failures
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org,
marxin at gcc dot gnu.org, matmal01 at gcc dot gnu.org
  Target Milestone: ---

I've just noticed there are some test failures that are there likely for some
time:

FAIL: c-c++-common/hwasan/alloca-gets-different-tag.c   -O2 -flto
-fuse-linker-plugin -fno-fat-lto-objects  execution test
FAIL: c-c++-common/hwasan/alloca-outside-caught.c   -O2 -flto
-fuse-linker-plugin -fno-fat-lto-objects  output pattern test

==52332==ERROR: HWAddressSanitizer: SEGV on unknown address 0x205001fcad
(pc 0x4006de20 bp 0xca50 sp 0xca50 T52332)
==52332==The signal is caused by a WRITE memory access.
#0 0x4006de20 in __sanitizer::internal_memset(void*, int, unsigned
long) ../../../../libsanitizer/sanitizer_common/sanitizer_libc.cpp:94
#1 0x400603f0 in __hwasan::TagMemoryAligned(unsigned long, unsigned
long, unsigned char) ../../../../libsanitizer/hwasan/hwasan_linux.cpp:428
#2 0x400838 in alloca_different_tag
/home/marxin/Programming/gcc/gcc/testsuite/c-c++-common/hwasan/alloca-gets-different-tag.c:27
#3 0x400688 in main
/home/marxin/Programming/gcc/gcc/testsuite/c-c++-common/hwasan/alloca-gets-different-tag.c:61
#4 0x4073b280 in __libc_start_call_main (/lib64/libc.so.6+0x2b280)
#5 0x4073b358 in __libc_start_main@@GLIBC_2.34
(/lib64/libc.so.6+0x2b358)
#6 0x4006ec in _start
(/home/marxin/Programming/gcc/objdir/gcc/testsuite/gcc4/alloca-gets-different-tag.exe+0x4006ec)

HWAddressSanitizer can not provide additional info.
SUMMARY: HWAddressSanitizer: SEGV
../../../../libsanitizer/sanitizer_common/sanitizer_libc.cpp:94 in
__sanitizer::internal_memset(void*, int, unsigned long)
==52332==ABORTING
FAIL: c-c++-common/hwasan/alloca-gets-different-tag.c   -O2 -flto
-fuse-linker-plugin -fno-fat-lto-objects  execution test

FAIL: c-c++-common/hwasan/alloca-outside-caught.c   -O2 -flto
-fuse-linker-plugin -fno-fat-lto-objects  output pattern test
Output was:
HWAddressSanitizer:DEADLYSIGNAL
==53458==ERROR: HWAddressSanitizer: SEGV on unknown address 0x105001fcc8
(pc 0x4006de20 bp 0xcc10 sp 0xcc10 T53458)
==53458==The signal is caused by a WRITE memory access.
#0 0x4006de20 in __sanitizer::internal_memset(void*, int, unsigned
long) ../../../../libsanitizer/sanitizer_common/sanitizer_libc.cpp:94
#1 0x400603f0 in __hwasan::TagMemoryAligned(unsigned long, unsigned
long, unsigned char) ../../../../libsanitizer/hwasan/hwasan_linux.cpp:428
#2 0x400850 in check_alloca c-c++-common/hwasan/alloca-outside-caught.c:10
#3 0x4006c8 in main c-c++-common/hwasan/alloca-outside-caught.c:18
#4 0x4073b280 in __libc_start_call_main (/lib64/libc.so.6+0x2b280)
#5 0x4073b358 in __libc_start_main@@GLIBC_2.34
(/lib64/libc.so.6+0x2b358)
#6 0x40072c in _start
(gcc/objdir/gcc/testsuite/gcc4/alloca-outside-caught.exe+0x40072c)

[Bug c++/105470] ranged for loop whitespace parsing

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

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

--- Comment #7 from Jonathan Wakely  ---
Yes, or use TheMapType::const_iterator. If you're going to name the type
explicitly, you need to be sure to use the correct type.

[Bug target/104662] arm: ice in simd_valid_immediate

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Christophe Lyon :

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

commit r13-102-ge2285af309000b74da0f7dc756a0b55e5f0b1b56
Author: Christophe Lyon 
Date:   Tue Apr 19 17:34:04 2022 +0200

arm: Restrict support of vectors of boolean immediates (PR target/104662)

This simple patch avoids the ICE described in the PR:
internal compiler error: in simd_valid_immediate, at
config/arm/arm.cc:12866

with an early exit from simd_valid_immediate if we are trying to
handle a vector of booleans and MVE is not enabled.

We still get an ICE when compiling the existing
gcc.dg/rtl/arm/mve-vxbi.c without -march=armv8.1-m.main+mve:

error: unrecognizable insn:
(insn 7 5 8 2 (set (reg:V4BI 114)
(const_vector:V4BI [
(const_int 1 [0x1])
(const_int 0 [0]) repeated x2
(const_int 1 [0x1])
])) -1
 (nil))
during RTL pass: ira

but there's little we can do since the testcase explicitly creates
vectors of booleans which do need MVE.

That is the reason why I do not add a testcase.

2022-04-19  Christophe Lyon  

PR target/104662
* config/arm/arm.cc (simd_valid_immediate): Exit when input is a
vector of booleans and MVE is not enabled.

[Bug target/104662] arm: ice in simd_valid_immediate

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

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

Christophe Lyon  changed:

   What|Removed |Added

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

--- Comment #4 from Christophe Lyon  ---
Fixed on trunk.

[Bug target/105472] New: [13 regression] .note.GNU-stack breaks many Solaris/x86 tests

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

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

Bug ID: 105472
   Summary: [13 regression] .note.GNU-stack breaks many
Solaris/x86 tests
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
CC: hjl.tools at gmail dot com
  Target Milestone: ---
Target: i386-pc-solaris2.11, x86_64-pc-solaris2.11

Between 20220502 (1cb220498e1f59021dab36c39c5d726e9f070c6a) and 20220503
(2680f5eec23805ab8a344f942ca5a7e180d57905),
many tests began to FAIL on Solaris/x86 with /bin/as:

+FAIL: gcc.target/x86_64/abi/test_3_element_struct_and_unions.c compilation, 
-O0 
[...]

(332 tests total).  The failure is always the same:

Assembler:
   
"/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.target/x86_64/abi/asm-support.S",
line 85 : Syntax error
Near line: " .section .note.GNU-stack,"",@progbits"

This happens because with /bin/as, '-' isn't valid in section names.

However, even with gas which can assemble the test, this doesn't really make
sense: Solaris ld doesn't know or care about .note.GNU-stack, so this has no
effect.  Instead, the Solaris security extensions framework is used, which
defaults to non-exec stack on Solaris 11 anyway:

$ sxadm status nxstack
EXTENSION   STATUSFLAGS
nxstack enabled (all) u-c--

On top of that, ld provides -z sx=nxstack to control the behaviour on an
per-executable basis.

gld doesn't know about all this, of course, but let's cross that bridge when
the binutils 2.39 release approaches.

The usual way throughout the code base is to guard .note.GNU-stack with
__ELF__ && __linux__ to avoid all this.

[Bug target/105472] [13 regression] .note.GNU-stack breaks many Solaris/x86 tests

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

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |13.0

[Bug target/105472] [13 regression] .note.GNU-stack breaks many Solaris/x86 tests

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

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

Martin Liška  changed:

   What|Removed |Added

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

[Bug fortran/105473] New: semicolon allowed when list-directed read integer with decimal='point'

[john.harper at vuw dot ac.nz via Gcc-bugs]

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

Bug ID: 105473
   Summary: semicolon allowed when list-directed read integer with
decimal='point'
   Product: gcc
   Version: 9.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: john.harper at vuw dot ac.nz
  Target Milestone: ---

List-directed reading of a number should give an error if it reads a semicolon
and decimal is not COMMA but this 9-line program gave the output shown below
it.
(The ifort compiler gave a positive value of ios, which I believe was correct.)

! Does list-directed reading an integer allow some non-integer input?
  implicit none
  integer n,ios
  character(1):: testinput = ';'
  print *,'testinput = "',testinput,'"'
  read(testinput,*,decimal='point',iostat=ios) n
  print *,'n=',n,' ios=',ios
  if(ios>0) print *,'testinput was not an integer'
end program

john@johns-laptop:~/Jfh$ ./a.out
 testinput = ";"
 n=  1458129152  ios=   0
john@johns-laptop:~/Jfh$

[Bug tree-optimization/103116] SLP vectoriser fails to peel for gaps

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

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

--- Comment #4 from Richard Biener  ---
The issue is currently visible in gcc.dg/vect/slp-perm-12.c which uses a VF of
2 and

  vect__1.20_88 = MEM  [(short int *)vectp_tptr.18_90];
  vectp_tptr.18_87 = vectp_tptr.18_90 + 16;
  vect__1.21_86 = MEM  [(short int *)vectp_tptr.18_87];
  vectp_tptr.18_85 = vectp_tptr.18_90 + 32;
  vect__1.22_84 = MEM  [(short int *)vectp_tptr.18_85];
  vectp_tptr.18_83 = vectp_tptr.18_90 + 28;
  vect__1.23_82 = VEC_PERM_EXPR ;

[Bug sanitizer/105471] A few hwasan failures

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

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

--- Comment #1 from Andrew Pinski  ---
Is this on aarch64 and if so what page size is the kernel set to?

[Bug bootstrap/105474] New: GCC fails to bootstrap with --disable-libstdcxx

[creatorsmithmdt at gmail dot com via Gcc-bugs]

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

Bug ID: 105474
   Summary: GCC fails to bootstrap with --disable-libstdcxx
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: creatorsmithmdt at gmail dot com
  Target Milestone: ---

On a Debian WSL2 environment (identified as x86_64-pc-linux-gnu and
5.10.102.1-microsoft-standard-WSL2), gcc fails bootstrapping when configured
like so: ../gcc/configure --disable-libstdcxx --enable-languages=c,c++. 

g++ -std=c++11   -g -O2   -DIN_GCC -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common
 -DHAVE_CONFIG_H  -DGENERATOR_FILE -static-libstdc++ -static-libgcc  -o
build/genchecksum \
build/genchecksum.o .././libiberty/libiberty.a
mawk -f ../../gcc/gcc/opt-functions.awk -f ../../gcc/gcc/opt-read.awk \
   -f ../../gcc/gcc/optc-save-gen.awk \
   -v header_name="config.h system.h coretypes.h tm.h" < optionlist >
options-save.cc
/usr/bin/ld: .././libiberty/libiberty.a(hashtab.o): relocation R_X86_64_32S
against `.rodata' can not be used when making a PIE object; recompile with
-fPIE
/usr/bin/ld: .././libiberty/libiberty.a(xmalloc.o): relocation R_X86_64_32
against `.rodata.str1.1' can not be used when making a PIE object; recompile
with -fPIE
collect2: error: ld returned 1 exit status
make[3]: *** [Makefile:3013: build/genhooks] Error 1
make[3]: *** Waiting for unfinished jobs
/usr/bin/ld: .././libiberty/libiberty.a(md5.o): relocation R_X86_64_32 against
`.rodata' can not be used when making a PIE object; recompile with -fPIE
/usr/bin/ld: .././libiberty/libiberty.a(xstrerror.o): relocation R_X86_64_32
against `.rodata.str1.1' can not be used when making a PIE object; recompile
with -fPIE
collect2: error: ld returned 1 exit status
make[3]: *** [Makefile:3013: build/genchecksum] Error 1
rm gfdl.pod gcc.pod gcov-dump.pod gcov-tool.pod fsf-funding.pod gpl.pod cpp.pod
gcov.pod lto-dump.pod
make[3]: Leaving directory '/home/zopolis4/gccbuild/gcc'
make[2]: *** [Makefile:4954: all-stage2-gcc] Error 2
make[2]: Leaving directory '/home/zopolis4/gccbuild'
make[1]: *** [Makefile:24086: stage2-bubble] Error 2
make[1]: Leaving directory '/home/zopolis4/gccbuild'
make: *** [Makefile:1023: all] Error 2

[Bug sanitizer/105471] A few hwasan failures

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Liška  ---
(In reply to Andrew Pinski from comment #1)
> Is this on aarch64 and if so what page size is the kernel set to?

Yes.

$ getconf PAGESIZE
4096

$ uname -a
Linux lnt-altra.arch.suse.cz 5.16.10-1-default #1 SMP Thu Feb 17 05:36:42 UTC
2022 (fc3f7ab) aarch64 aarch64 aarch64 GNU/Linux

[Bug middle-end/105469] "execution reached an unreachable program point" with -flto

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

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

--- Comment #3 from Martin Liška  ---
Reducing that right now..

[Bug bootstrap/105474] GCC fails to bootstrap with --disable-libstdcxx

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

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

--- Comment #1 from Richard Biener  ---
Does it work when not bootstrapping (--disable-bootstrap)?  Because since GCC
is written in C++ now we'll need our own standard library when using the host
built GCC to build stage2+.

Now, the specific failure building stage2 genchecksum is odd - is this the
full command, really using the host g++, you quote?

[Bug middle-end/105469] "execution reached an unreachable program point" with -flto

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

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

--- Comment #4 from Jakub Jelinek  ---
-fno-devirtualize also makes it go away.
Without that, the __builtin_unreachable() call in question is created in:
#0  0x77ad4424 in __memset_avx2_unaligned_erms () from /lib64/libc.so.6
#1  0x00fee86e in ggc_internal_alloc (size=144, f=0x0, s=0, n=1) at
../../gcc/ggc-page.cc:1400
#2  0x012bf869 in ggc_internal_cleared_alloc (size=144, f=0x0, s=0,
n=1) at ../../gcc/ggc-common.cc:114
#3  0x00c9f446 in ggc_internal_cleared_alloc (s=144) at
../../gcc/ggc.h:147
#4  0x012d69e5 in ggc_alloc_cleared_gimple_statement_stat (s=144) at
../../gcc/ggc.h:329
#5  0x012cc892 in gimple_alloc (code=GIMPLE_CALL, num_ops=5) at
../../gcc/gimple.cc:156
#6  0x012d00ae in gimple_copy (stmt=) at
../../gcc/gimple.cc:1913
#7  0x0183e098 in remap_gimple_stmt (stmt=,
id=0x7fffd1e0) at ../../gcc/tree-inline.cc:1862
#8  0x0183e996 in copy_bb (id=0x7fffd1e0, bb=, num=..., den=...) at ../../gcc/tree-inline.cc:2051
#9  0x01841ee7 in copy_cfg_body (id=0x7fffd1e0,
entry_block_map=, exit_block_map=, 
new_entry=) at ../../gcc/tree-inline.cc:3085
#10 0x01842b2a in copy_body (id=0x7fffd1e0,
entry_block_map=, exit_block_map=, 
new_entry=) at ../../gcc/tree-inline.cc:3338
#11 0x01847993 in expand_call_inline (bb=, stmt=, id=0x7fffd1e0,
to_purge=0x7fffd1c0)
at ../../gcc/tree-inline.cc:5123
when copying the
  OBJ_TYPE_REF(_9;(struct Writable)writable_7(D)->10B) (writable_7(D), 0);
call (line 1345 in repro.cpp) and later on this one is replaced by
__builtin_unreachable:
#0  gimple_call_set_fndecl (gs=0x7fffe8621090, decl=) at ../../gcc/gimple.h:3198
#1  0x010b7521 in cgraph_edge::redirect_call_stmt_to_callee (
e= -> )>)
at ../../gcc/cgraph.cc:1555
#2  0x01841af2 in redirect_all_calls (id=0x7fffd1e0,
bb=) at ../../gcc/tree-inline.cc:3002
#3  0x018423c7 in copy_cfg_body (id=0x7fffd1e0,
entry_block_map=, exit_block_map=, 
new_entry=) at ../../gcc/tree-inline.cc:3173
#4  0x01842b2a in copy_body (id=0x7fffd1e0,
entry_block_map=, exit_block_map=, 
new_entry=) at ../../gcc/tree-inline.cc:3338
#5  0x01847993 in expand_call_inline (bb=, stmt=, id=0x7fffd1e0,
to_purge=0x7fffd1c0)
at ../../gcc/tree-inline.cc:5123
#6  0x0184874c in gimple_expand_calls_inline (bb=, id=0x7fffd1e0, to_purge=0x7fffd1c0) at
../../gcc/tree-inline.cc:5318
#7  0x01848f1c in optimize_inline_calls (fn=) at ../../gcc/tree-inline.cc:5490
#8  0x0141b1ee in inline_transform (node=) at ../../gcc/ipa-inline-transform.cc:790

[Bug bootstrap/105474] GCC fails to bootstrap with --disable-libstdcxx

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
I'd say this is a user error.  You can either bootstrap the compiler but then
you need libstdc++ because that is needed for C++ support which is needed
during the bootstrapping, or you don't and then can avoid building libstdc++.

[Bug sanitizer/105471] A few hwasan failures

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
Maybe PR 101744 was closed too soon.

[Bug other/105404] new version of zlib

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

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

--- Comment #8 from Martin Liška  ---
(In reply to David Binderman from comment #7)
> (In reply to Martin Liška from comment #6)
> > Can't see the warning when I build the current zlib library with clang.
> 
> You might need to switch on -Wall or (more likely) -Wextra.

Well, I use default options for that.

> 
> > Can you please paste a build log?
> 
> Not easily. Here is one example warning, amongst many:
> 
> ../../trunk.git/zlib/uncompr.c:86:13: warning: a function declaration
> without a prototype is deprecated in all versions of C and is not supported
> in C2x [-Wdeprecated-non-prototype]
> 
> As I say, pattern /zlib/.*-Wdeprecated-non-prototype would probably work.

Sure, please send a patch for it.

[Bug c++/105475] New: ICE in coerce_template_parms, at cp/pt.cc:9183

[asolokha at gmx dot com via Gcc-bugs]

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

Bug ID: 105475
   Summary: ICE in coerce_template_parms, at cp/pt.cc:9183
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: C++-Coroutine, ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

g++ 13.0.0 20220501 snapshot (g:75bbc3da3e5f75f683fa33e309045c582efd20eb) ICEs
when compiling test/CodeGenCoroutines/coro-newpm-pipeline.cpp or
test/CodeGenCoroutines/coro-always-inline.cpp w/ -fcoroutines:

namespace std {

struct handle {};

struct awaitable {
  bool await_ready() noexcept { return false; }
  void await_suspend(handle) noexcept {}
  bool await_resume() noexcept { return true; }
};

template  struct coroutine_handle {
  static handle from_address(void *address) noexcept { return {}; }
};

template  struct coroutine_traits {
  struct promise_type {
awaitable initial_suspend() { return {}; }
awaitable final_suspend() noexcept { return {}; }
void return_void() {}
T get_return_object() { return T(); }
void unhandled_exception() {}
  };
};
} // namespace std

void foo() { co_return; }

% g++-13.0.0 -fcoroutines -c test/CodeGenCoroutines/coro-newpm-pipeline.cpp
test/CodeGenCoroutines/coro-newpm-pipeline.cpp: In function 'void foo()':
test/CodeGenCoroutines/coro-newpm-pipeline.cpp:43:14: internal compiler error:
in coerce_template_parms, at cp/pt.cc:9183
   43 | void foo() { co_return; }
  |  ^
0x706e6c coerce_template_parms
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220501/work/gcc-13-20220501/gcc/cp/pt.cc:9183
0xb532b5 lookup_template_class_1
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220501/work/gcc-13-20220501/gcc/cp/pt.cc:9966
0xb55150 lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220501/work/gcc-13-20220501/gcc/cp/pt.cc:10353
0x9adfce instantiate_coro_handle_for_promise_type
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220501/work/gcc-13-20220501/gcc/cp/coroutines.cc:400
0x9b099e coro_promise_type_found_p
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220501/work/gcc-13-20220501/gcc/cp/coroutines.cc:455
0x9b277b finish_co_return_stmt(unsigned int, tree_node*)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220501/work/gcc-13-20220501/gcc/cp/coroutines.cc:1331
0xadbc28 cp_parser_jump_statement
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220501/work/gcc-13-20220501/gcc/cp/parser.cc:14303
0xadbc28 cp_parser_statement
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220501/work/gcc-13-20220501/gcc/cp/parser.cc:12312
0xadbd7d cp_parser_statement_seq_opt
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220501/work/gcc-13-20220501/gcc/cp/parser.cc:12850
0xadbe57 cp_parser_compound_statement
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220501/work/gcc-13-20220501/gcc/cp/parser.cc:12802
0xafca45 cp_parser_function_body
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220501/work/gcc-13-20220501/gcc/cp/parser.cc:25076
0xafca45 cp_parser_ctor_initializer_opt_and_function_body
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220501/work/gcc-13-20220501/gcc/cp/parser.cc:25127
0xafd9fa cp_parser_function_definition_after_declarator
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220501/work/gcc-13-20220501/gcc/cp/parser.cc:31259
0xafecb8 cp_parser_function_definition_from_specifiers_and_declarator
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220501/work/gcc-13-20220501/gcc/cp/parser.cc:31175
0xafecb8 cp_parser_init_declarator
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220501/work/gcc-13-20220501/gcc/cp/parser.cc:22598
0xad87f9 cp_parser_simple_declaration
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220501/work/gcc-13-20220501/gcc/cp/parser.cc:15280
0xb09f85 cp_parser_declaration
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220501/work/gcc-13-20220501/gcc/cp/parser.cc:14966
0xb0a969 cp_parser_toplevel_declaration
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220501/work/gcc-13-20220501/gcc/cp/parser.cc:14987
0xb0a969 cp_parser_translation_unit
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220501/work/gcc-13-20220501/gcc/cp/parser.cc:5010
0xb0a969 c_parse_file()
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220501/work/gcc-13-20220501/gcc/cp/parser.cc:48113

[Bug middle-end/105469] "execution reached an unreachable program point" with -flto

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

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

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

namespace std {
template  struct char_traits;
template > class basic_ostream;
struct ios_base {
  struct Init {
Init();
  };
};
template  struct basic_ostream {
  void operator<<(const void *);
};
extern basic_ostream cerr;
ios_base::Init __ioinit;
} // namespace std
enum Commit_Level { no_commit };
struct Writable {
  virtual void drop_fieldtimestampvalid_data() {}
  virtual void checkpoint(Commit_Level) {}
};
struct Posix_File {
  Posix_File();
  ~Posix_File();
};
Posix_File::Posix_File() {}
Posix_File::~Posix_File() {}
struct Readonly_Journal {
  Readonly_Journal();
  void play_until_checkpoint(Writable &writable) {
writable.checkpoint(no_commit);
std::cerr << "";
  }
};
Readonly_Journal::Readonly_Journal() {}
struct Writable_Journal : Readonly_Journal {
  Writable_Journal();
  ~Writable_Journal();
};
Writable_Journal::Writable_Journal() {}
Writable_Journal::~Writable_Journal() {}
struct Connection {
  virtual void push(Readonly_Journal &, long, bool) = 0;
};
template  struct Trans_NS_joedb_Client {
  Connection &connection;
  Client_Data data;
  Trans_NS_joedb_Client(Connection &, Posix_File file)
  : connection(connection), data(connection, file) {
std::cerr << &data;
data.update();
  }
};
struct Local_Connection : Connection {
  Posix_File file;
  void push(Readonly_Journal &, long, bool) {}
};
struct Generic_File_Database : Writable {
  Writable_Journal journal;
  Generic_File_Database();
  void checkpoint(Commit_Level) {}
};
struct Client_Data : Generic_File_Database {
  Client_Data(Connection &, Posix_File) {}
  void update() { journal.play_until_checkpoint(*this); }
};
struct Client : Trans_NS_joedb_Client {
  Posix_File Client_local_file;
  Client() : Trans_NS_joedb_Client(connection, Client_local_file) {}
};
Generic_File_Database::Generic_File_Database() {}
struct Buggy_Client : Local_Connection, Client {};

int main() { Buggy_Client(); }

[Bug c++/105476] New: internal compiler error: in build_deduction_guide

[ispavlick at gmail dot com via Gcc-bugs]

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

Bug ID: 105476
   Summary: internal compiler error: in build_deduction_guide
   Product: gcc
   Version: 11.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ispavlick at gmail dot com
  Target Milestone: ---

Reference to a preprocessed file (size limits do not allow uploading here)
https://drive.google.com/file/d/1y8_Ctd0-VxdZHHhgHen2s7b2DjGpyCC8/view?usp=sharing
 

$ gcc -std=gnu++20 -x c++-cpp-output 3.ii -o res
/home/pavlick/wrk/sftable/temp/3.cpp: In function ‘int main()’:
/home/pavlick/wrk/sftable/temp/3.cpp:18:9: internal compiler error: in
build_deduction_guide, at cp/pt.c:28659
   18 | };
  | ^
0xe4c988 internal_error(char const*, ...)
???:0
0xe42d02 fancy_abort(char const*, int, char const*)
???:0
0x10358fb cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
???:0
0x14e7873 c_parse_file()
???:0
0x14c9d9e c_common_parse_file()
???:0
Please submit a full bug report,

[Bug middle-end/105469] "execution reached an unreachable program point" with -flto

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

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

--- Comment #6 from Martin Liška  ---
g++ repro.ii -fsanitize=undefined -O3 -fwhole-program && ./a.out
0x7fffdb38repro.ii:29:24: runtime error: execution reached an unreachable
program point
#0 0x401300 in main (/home/marxin/Programming/testcases/a.out+0x401300)
#1 0x7751f62f in __libc_start_call_main
../sysdeps/nptl/libc_start_call_main.h:58
#2 0x7751f6ef in __libc_start_main_impl ../csu/libc-start.c:392
#3 0x401384 in _start (/home/marxin/Programming/testcases/a.out+0x401384)

[Bug middle-end/105469] "execution reached an unreachable program point" with -flto

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #7 from Martin Liška  ---
Backtrace with debuginfo:

$ g++ repro.ii -fsanitize=undefined -O3 -fwhole-program -g && ./a.out
0x7fffdb38repro.ii:29:24: runtime error: execution reached an unreachable
program point
#0 0x401300 in Readonly_Journal::play_until_checkpoint(Writable&)
/home/marxin/Programming/testcases/repro.ii:29
#1 0x401300 in Client_Data::update()
/home/marxin/Programming/testcases/repro.ii:63
#2 0x401300 in
Trans_NS_joedb_Client::Trans_NS_joedb_Client(Connection&,
Posix_File) /home/marxin/Programming/testcases/repro.ii:49
#3 0x401300 in Client::Client()
/home/marxin/Programming/testcases/repro.ii:67
#4 0x401300 in Buggy_Client::Buggy_Client()
/home/marxin/Programming/testcases/repro.ii:70
#5 0x401300 in main /home/marxin/Programming/testcases/repro.ii:72
#6 0x7751f62f in __libc_start_call_main
../sysdeps/nptl/libc_start_call_main.h:58
#7 0x7751f6ef in __libc_start_main_impl ../csu/libc-start.c:392
#8 0x401384 in _start (/home/marxin/Programming/testcases/a.out+0x401384)

[Bug c++/105475] ICE in coerce_template_parms, at cp/pt.cc:9183

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Liška  ---
It's there since the beginning of coroutines (r10-6063-g49789fd08378e3ff).

[Bug middle-end/105469] "execution reached an unreachable program point" with -flto

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

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

--- Comment #8 from Richard Biener  ---
The original testcase has

   void lock() override = 0;
   void unlock() override = 0;
   void lock() final override
   void unlock() final override

and a few more override.  The reduced one has nothing like that (but maybe it's
misreduced).  Removing 'final' doesn't avoid the issue though.

It might be this is a bad interaction of speculative devirt and inlining,
-fno-devirtualize-speculatively is enough to prevent the bug.

[Bug c++/105476] internal compiler error: in build_deduction_guide

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Liška  ---
Reducing that right now...

[Bug tree-optimization/105477] New: RISC-V: Regression: Useless moves in conditional select return

[christophm30 at gmail dot com via Gcc-bugs]

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

Bug ID: 105477
   Summary: RISC-V: Regression: Useless moves in conditional
select return
   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: ---

Commit 3a7ba8fd triggers a regression so that on RISC-V two useless move
instructions are generated.

Test code:
"""
long test(long a, long b, long c)
{
  return (!c ? a : b);
}
"""

GCC 10.2.0, GCC 11 or upstream/master before 3a7ba8fd generates (rv64gc + -O3):
test:
beq a2,zero,.L2
mv  a0,a1
.L2:
ret

Current upstream/master generates:
:
   0:   87aamv  a5,a0
   2:   852emv  a0,a1
   4:   e211bneza2,8 <.L2>
   6:   853emv  a0,a5
<.L2>:
   8:   8082ret

This might be an issue in the ifcvt code (in combination of the RISC-V backend)
or something where the RISC-V backend needs to improve.

Some context to this issue:
* The mentioned change (3a7ba8fd) is not problematic at all and fixes an issue
PR104960
* PR105314 reports a similar issue, that is also triggered by the same change

[Bug middle-end/105469] "execution reached an unreachable program point" with -flto

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

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

--- Comment #9 from Martin Liška  ---
It's the 1st devirtualization that happens:

Polymorphic call context combine:Outer type:struct Buggy_Client offset 192
With context:Outer type (dynamic):struct
Trans_NS_joedb_Client (maybe in construction) offset 64 Speculative outer
type:struct Client_Data at offset 0
Second type is base of first
First context does not permit base -> invalid
No devirtualization target in play_until_checkpoint.constprop/106
Introduced new external node (void __builtin_unreachable()/107).
***dbgcnt: lower limit 1 reached for devirt.***
***dbgcnt: upper limit 1 reached for devirt.***

[Bug middle-end/105469] "execution reached an unreachable program point" with -flto

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||jamborm at gcc dot gnu.org

--- Comment #10 from Martin Liška  ---
Maybe interacts with IPA CP -fno-ipa-cp helps here.

[Bug rtl-optimization/105477] RISC-V: Regression: Useless moves in conditional select return

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

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

Richard Biener  changed:

   What|Removed |Added

  Component|tree-optimization   |rtl-optimization
   Keywords||missed-optimization
 Target||riscv

--- Comment #1 from Richard Biener  ---
could also be condition RTL expansion generating slightly different RTL IL.

[Bug middle-end/105469] "execution reached an unreachable program point" with -flto since r5-7027-g0b986c6ac777aa4e

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

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

Martin Liška  changed:

   What|Removed |Added

Summary|"execution reached an   |"execution reached an
   |unreachable program point"  |unreachable program point"
   |with -flto  |with -flto since
   ||r5-7027-g0b986c6ac777aa4e

--- Comment #11 from Martin Liška  ---
Likely started with r5-7027-g0b986c6ac777aa4e, it is looping before the
revision.

[Bug middle-end/105469] "execution reached an unreachable program point" with -flto since r5-7027-g0b986c6ac777aa4e

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

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

--- Comment #12 from Jakub Jelinek  ---
On the original testcase I see
First context does not permit base -> invalid
No devirtualization target in void
joedb::Readonly_Journal::play_until_checkpoint.constprop(joedb::Writable&)/2704
It is unclear why play_until_checkpoint would be cloned, it doesn't have any
args that would be IPA-CP propagated.  The checkpoint virtual call has, but
until it is devirtualized we can't optimize it.

[Bug c++/105476] internal compiler error: in build_deduction_guide

[ispavlick at gmail dot com via Gcc-bugs]

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

--- Comment #2 from pavlick  ---
One moment, i will do reduction.

[Bug c++/105476] internal compiler error: in build_deduction_guide

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

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

--- Comment #3 from Martin Liška  ---
(In reply to pavlick from comment #2)
> One moment, i will do reduction.

I'm almost done.

[Bug c++/105476] internal compiler error: in build_deduction_guide

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

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

Martin Liška  changed:

   What|Removed |Added

   Keywords|needs-reduction |

--- Comment #4 from Martin Liška  ---
$ cat pr105476.ii
template  struct Visitor_functor;
template  struct Events {
  template  struct Visitor : Visitor_functor::type_t... {};
};
using ev_t = Events;
ev_t::Visitor v {
  {}
};

$ g++ pr105476.ii -c -std=gnu++20
pr105476.ii:8:1: internal compiler error: in build_deduction_guide, at
cp/pt.cc:29278
8 | };
  | ^
0x75c539 build_deduction_guide
/home/marxin/Programming/gcc/gcc/cp/pt.cc:29278
0xbc1035 do_class_deduction
/home/marxin/Programming/gcc/gcc/cp/pt.cc:30049
0xbc1035 do_auto_deduction(tree_node*, tree_node*, tree_node*, int,
auto_deduction_context, tree_node*, int)
/home/marxin/Programming/gcc/gcc/cp/pt.cc:30180
0xa9cc9b cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
/home/marxin/Programming/gcc/gcc/cp/decl.cc:8119
0xb95ab7 cp_parser_init_declarator
/home/marxin/Programming/gcc/gcc/cp/parser.cc:22837
0xb6ee96 cp_parser_simple_declaration
/home/marxin/Programming/gcc/gcc/cp/parser.cc:15280
0xba1050 cp_parser_declaration
/home/marxin/Programming/gcc/gcc/cp/parser.cc:14966
0xba1b6b cp_parser_toplevel_declaration
/home/marxin/Programming/gcc/gcc/cp/parser.cc:14987
0xba1b6b cp_parser_translation_unit
/home/marxin/Programming/gcc/gcc/cp/parser.cc:5010
0xba1b6b c_parse_file()
/home/marxin/Programming/gcc/gcc/cp/parser.cc:48113
0xce5d69 c_common_parse_file()
/home/marxin/Programming/gcc/gcc/c-family/c-opts.cc:1240
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/105478] New: malloc error abort when using -fstack-arrays

[m.a.hulsen at tue dot nl via Gcc-bugs]

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

Bug ID: 105478
   Summary: malloc error abort when using -fstack-arrays
   Product: gcc
   Version: 11.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: m.a.hulsen at tue dot nl
  Target Milestone: ---

The code below gives

a.out(78480,0x10ea3f600) malloc: *** error for object 0x7ff8800a8000: pointer
being freed was not allocated
a.out(78480,0x10ea3f600) malloc: *** set a breakpoint in malloc_error_break to
debug

Program received signal SIGABRT: Process abort signal.

when compiled and build with "gfortran -fstack-arrays".

Code:

module mesh_m
  implicit none
  type element_t
integer, allocatable, dimension(:,:) :: sidvert
  end type element_t
  type geometry_t
type(element_t) :: element
  end type geometry_t
  type mesh_t
type(geometry_t), allocatable, dimension(:) :: curves
  end type mesh_t
contains
  subroutine copy_element_basic ( element1, element )
type(element_t), intent(in) :: element1
type(element_t), intent(out) :: element
  end subroutine copy_element_basic
  subroutine copy_element_array_basic ( element1, element )
type(element_t), dimension(:), intent(in) :: element1
type(element_t), dimension(:), intent(out) :: element
integer :: i
do i = 1, size(element1)
  call copy_element_basic ( element1(i), element(i) )
end do
  end subroutine copy_element_array_basic
end module mesh_m
program bug
  use mesh_m
  type(mesh_t) :: mesh1, mesh
  allocate(mesh1%curves(4))
  allocate(mesh%curves(4))
  call copy_element_array_basic ( mesh1%curves(:)%element, &
  mesh%curves(:)%element )
end program bug

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

[jiawei at iscas dot ac.cn via Gcc-bugs]

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

--- Comment #14 from jiawei  ---
(In reply to palmer from comment #13)
> I just posted a patch
>  that
> removes the undefined behavior from this test case, with that it links on
> RISC-V.

LGTM, it's really help, thanks a lot.

[Bug c++/105476] ICE in build_deduction_guide since r10-4719-g9b41ebbcdf9e3328

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org
Summary|internal compiler error: in |ICE in
   |build_deduction_guide   |build_deduction_guide since
   ||r10-4719-g9b41ebbcdf9e3328

--- Comment #5 from Martin Liška  ---
Started with r10-4719-g9b41ebbcdf9e3328, it was rejected before the revision.

[Bug fortran/105478] malloc error abort when using -fstack-arrays

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Liška  ---
I see the crash even w/o -fstack-arrays for all compilers I have (4.9.0+).

[Bug target/105479] New: ICE in subreg_size_lowpart_offset, at emit-rtl.cc:1673

[asolokha at gmx dot com via Gcc-bugs]

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

Bug ID: 105479
   Summary: ICE in subreg_size_lowpart_offset, at emit-rtl.cc:1673
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code, ra
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---
Target: aarch64-linux-gnu

gfortran 13.0.0 20220501 snapshot (g:75bbc3da3e5f75f683fa33e309045c582efd20eb)
ICEs when compiling the following testcase, extracted from
test/f90_correct/src/ei10.F90 from the Classic Flang test suite, w/ -mcpu=a64fx
-O2 -fnon-call-exceptions -ftrapv:

subroutine copy_str_to_result( str, result)
  integer :: result(:)
  character(len=*) :: str
  integer :: i

  do i=1,len(str)
 result(i) = iachar(str(i:i))
  enddo

end subroutine

% aarch64-linux-gnu-gfortran-13.0.0 -mcpu=a64fx -O2 -fnon-call-exceptions
-ftrapv -c vdhfytlt.f90
during RTL pass: reload
vdhfytlt.f90:10:14:

   10 | end subroutine
  |  ^
internal compiler error: in subreg_size_lowpart_offset, at emit-rtl.cc:1673
0x6d94a8 subreg_size_lowpart_offset(poly_int<2u, unsigned long>, poly_int<2u,
unsigned long>)
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20220501/work/gcc-13-20220501/gcc/emit-rtl.cc:1673
0xb8d4fa gen_lowpart_SUBREG(machine_mode, rtx_def*)
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20220501/work/gcc-13-20220501/gcc/emit-rtl.cc:1037
0xdea08f emit_spill_move
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20220501/work/gcc-13-20220501/gcc/lra-constraints.cc:1245
0xdec749 split_reg
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20220501/work/gcc-13-20220501/gcc/lra-constraints.cc:5915
0xded2e9 split_if_necessary
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20220501/work/gcc-13-20220501/gcc/lra-constraints.cc:6101
0xdfb200 inherit_in_ebb
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20220501/work/gcc-13-20220501/gcc/lra-constraints.cc:6633
0xdfb200 lra_inheritance()
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20220501/work/gcc-13-20220501/gcc/lra-constraints.cc:6958
0xde1d4c lra(_IO_FILE*)
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20220501/work/gcc-13-20220501/gcc/lra.cc:2404
0xd98189 do_reload
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20220501/work/gcc-13-20220501/gcc/ira.cc:5940
0xd98189 execute
   
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20220501/work/gcc-13-20220501/gcc/ira.cc:6126

[Bug c++/105476] ICE in build_deduction_guide since r10-4719-g9b41ebbcdf9e3328

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

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

Patrick Palka  changed:

   What|Removed |Added

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

[Bug tree-optimization/103116] SLP vectoriser fails to peel for gaps

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

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

--- Comment #5 from rsandifo at gcc dot gnu.org  
---
(In reply to Richard Biener from comment #3)
> We could make peeling for gaps handle this by making it not a flag but
> indicate the number of vector(!?) iterations we need to peel.
I think it'd be better to keep it in scalar iterations if possible.
For example, we still need to peel for gaps when using masked LD2s
if only the first vector result is needed.  But we do only need to
peel 1 scalar iteration, rather than a whole vector's worth.

But yeah, agree that moving from 0-or-1 to a general number sounds good.

[Bug tree-optimization/103116] SLP vectoriser fails to peel for gaps

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #6 from rguenther at suse dot de  ---
On Wed, 4 May 2022, rsandifo at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103116
> 
> --- Comment #5 from rsandifo at gcc dot gnu.org  
> ---
> (In reply to Richard Biener from comment #3)
> > We could make peeling for gaps handle this by making it not a flag but
> > indicate the number of vector(!?) iterations we need to peel.
> I think it'd be better to keep it in scalar iterations if possible.
> For example, we still need to peel for gaps when using masked LD2s
> if only the first vector result is needed.  But we do only need to
> peel 1 scalar iteration, rather than a whole vector's worth.
> 
> But yeah, agree that moving from 0-or-1 to a general number sounds good.

Yep.  I'll keep that for GCC 13, the posted fix should be what we can
reasonably easy backport.

[Bug tree-optimization/103116] SLP vectoriser fails to peel for gaps

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

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

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

https://gcc.gnu.org/g:52b7b86f8c72eb19e637f1e72ffd10f39b8cb829

commit r13-110-g52b7b86f8c72eb19e637f1e72ffd10f39b8cb829
Author: Richard Biener 
Date:   Wed May 4 10:43:07 2022 +0200

tree-optimization/103116 - SLP permutes and peeling for gaps

The testcase shows that we can end up with a contiguous access across
loop iterations but by means of permutations the elements accessed
might only cover parts of a vector.  In this case we end up with
GROUP_GAP == 0 but still need to avoid accessing excess elements
in the last loop iterations.  Peeling for gaps is designed to cover
this but a single scalar iteration might not cover all of the excess
elements.  The following ensures peeling for gaps is done in this
situation and when that isn't sufficient because we need to peel
more than one iteration (gcc.dg/vect/pr103116-2.c), fail the SLP
vectorization.

2022-05-04  Richard Biener  

PR tree-optimization/103116
* tree-vect-stmts.cc (get_group_load_store_type): Handle the
case we need peeling for gaps even though GROUP_GAP is zero.

* gcc.dg/vect/pr103116-1.c: New testcase.
* gcc.dg/vect/pr103116-2.c: Likewise.

[Bug tree-optimization/104658] Inefficient vectorization using mask CTORs

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

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

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

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

commit r13-111-geca04dc8555f5fae462fbd16386da9aaf38a0711
Author: Richard Biener 
Date:   Tue Feb 22 16:02:27 2022 +0100

tree-optimization/104658 - avoid mixing mask & non-mask vector defs

When pattern recognition fails to sanitize all defs of a mask
producing operation and the respective def is external or constant
we end up trying to produce a VECTOR_BOOLEAN_TYPE_P constructor
which in turn ends up exposing stmts like

   _135 = _49 ? -1 : 0;

which isn't handled well in followup SLP and generates awful code.

We do rely heavily on pattern recognition to sanitize mask vs.
data uses of bools but that fails here which means we also should
fail vectorization.  That avoids ICEing because of such stmts
and it also avoids generating weird code which makes the
vectorization not profitable.

The following patch simply disallows external VECTOR_BOOLEAN_TYPE_P
defs and arranges the promote to external code to instead promote
mask uses to extern (that's just a short-cut here).

I've also looked at aarch64 and with SVE and a fixed vector length
for the gcc.target/i386/pr101636.c testcase.  I see similar vectorization
(using ) there but it's hard to decide whether the
old, the new or no vectorization is better for this.  The code
generated with traditional integer masks isn't as awkward but we
still get the != 0 promotion done for each scalar element which
doesn't look like intended - this operation should be visible upfront.

That also means some cases will now become a missed optimization
that needs to be fixed by bool pattern recognition.  But that can
possibly be delayed to GCC 13.

2022-02-22  Richard Biener  

PR tree-optimization/104658
* tree-vect-slp.cc (vect_slp_convert_to_external): Do not
create VECTOR_BOOLEAN_TYPE_P extern defs.  Reset the vector
type on nodes we promote.
(vectorizable_bb_reduc_epilogue): Deal with externalized
root.
* tree-vect-stmts.cc (vect_maybe_update_slp_op_vectype): Do
not allow VECTOR_BOOLEAN_TYPE_P extern defs.

* gcc.target/i386/pr104658.c: New testcase.

[Bug tree-optimization/103116] SLP vectoriser fails to peel for gaps

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

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||13.0

--- Comment #8 from Richard Biener  ---
Fixed on trunk sofar, queued for backporting.

[Bug target/105480] New: Vectorized `isnan` appears to trigger FPE on ppc64le

[sebastian-gcc at sipsolutions dot net via Gcc-bugs]

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

Bug ID: 105480
   Summary: Vectorized `isnan` appears to trigger FPE on ppc64le
   Product: gcc
   Version: 11.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sebastian-gcc at sipsolutions dot net
  Target Milestone: ---

Compiling for ppc64le with `-O3` seems to use the `xvcmpgedp` instruction which
ends up setting the FPE flags.  I have created an example in godbolt:

https://godbolt.org/z/n8PfPPP1d

Clang will produce similar code (using the same instruction), but when enabling
`-ftrapping-math` (as they always want...) will switch to `vcmpgtud`.

I think the same issue happens with `==` and `!=` which (IIRC) should not trap.

[Bug tree-optimization/104658] Inefficient vectorization using mask CTORs

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

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug modula2/101392] cc1gm2 -fdump-system-exports SEGV on Solaris/SPARC

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

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

--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #2 from Gaius Mulley  ---
> I've just git pushed a fix to assign main_input_filename before each
> compilation.  Tested on Debian/amd64 which passed with no regression test
> errors.
> I'll try out a Solaris/sparc combination next.

Good.  However, as of 20220424, a sparc-sun-solaris2.11 build went
beyond this error, hitting PR modula2/105392 instead.

sparcv9-sun-solaris2.11 is even better: the build finishes successfully
and only runs into a non-M2 bug (PR middle-end/105409) affecting a
considerable number of 32-bit tests.

[Bug target/105480] Vectorized `isnan` appears to trigger FPE on ppc64le

[sebastian-gcc at sipsolutions dot net via Gcc-bugs]

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

--- Comment #1 from seberg  ---
Actually, I think I likely misanalyzed, the actual code in question where I
found this was doing something like:


while (n--) {
 if (isnan(*input)) {
 *out = 1;
 }
 else {
 *out = (long)(*input)
 }
}

So probably it is rather the branch that gets optimized away.  I will try to
post a better example.

[Bug c++/105470] ranged for loop whitespace parsing

[roland at logikalsolutions dot com via Gcc-bugs]

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

--- Comment #8 from Roland Hughes  ---
(In reply to Marek Polacek from comment #1)
> Can you please provide a stand-alone test case?

I will work on this over the weekend.

[Bug c++/105470] ranged for loop whitespace parsing

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

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

--- Comment #9 from Marek Polacek  ---
(In reply to Roland Hughes from comment #8)
> (In reply to Marek Polacek from comment #1)
> > Can you please provide a stand-alone test case?
> 
> I will work on this over the weekend.

Looks like that's not necessary anymore.  Jon already explained why.

[Bug c++/105470] ranged for loop whitespace parsing

[roland at logikalsolutions dot com via Gcc-bugs]

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

--- Comment #10 from Roland Hughes  ---
(In reply to Marek Polacek from comment #1)
> 
> The warning is completely correct, and the code should be fixed.
> 
> for ( const std::pair &it : someMap )
> 
> This iterates over a map, with values of type:
> 
> std::pair
> 

No, it doesn't.

[code]
roland@roland-HP-EliteDesk-800-G2-SFF:~/sf_projects/roland_hughes-csscintilla$
grep -irn GetKeyMap *
copperspice/CsScintillaEditBase/CsScintillaEditBase.cpp:1031:// the fact
GetKeyMap() returns const means we can't use an iterator
copperspice/CsScintillaEditBase/CsScintillaEditBase.cpp:1034:for ( const
std::pair &it : sqt->kmap.GetKeyMap() )
copperspice/CsScintillaEditBase/CsScintillaEditBase.cpp:1059:auto
findResult = std::find_if( std::begin( sqt->kmap.GetKeyMap() ),
copperspice/CsScintillaEditBase/CsScintillaEditBase.cpp:1060:  
 std::end( sqt->kmap.GetKeyMap() ),
copperspice/CsScintillaEditBase/CsScintillaEditBase.cpp:1066:if (
findResult != std::end( sqt->kmap.GetKeyMap() ) )
copperspice/CsScintillaEditBase/CsScintillaEditBase.cpp:4314:const
std::map
&CsScintillaEditBase::GetKeyMap() const noexcept
copperspice/CsScintillaEditBase/CsScintillaEditBase.cpp:4316:return
sqt->kmap.GetKeyMap();
copperspice/CsScintillaEditBase/CsScintillaEditBase.h:79:const
std::map &GetKeyMap()
const noexcept;
src/KeyMap.h:60:const std::map
&GetKeyMap() const noexcept;
src/KeyMap.cxx:50:const std::map &KeyMap::GetKeyMap()
const noexcept {
[/code]


There is no definition of that map anywhere in the codebase where KeyModifiers
is declared const.

The method being called returns a const & to the entire map, but there is no
const declared within the map.

[Bug c++/105470] ranged for loop whitespace parsing

[roland at logikalsolutions dot com via Gcc-bugs]

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

--- Comment #11 from Roland Hughes  ---
(In reply to Marek Polacek from comment #9)
> (In reply to Roland Hughes from comment #8)
> > (In reply to Marek Polacek from comment #1)
> > > Can you please provide a stand-alone test case?
> > 
> > I will work on this over the weekend.
> 
> Looks like that's not necessary anymore.  Jon already explained why.

It is actually necessary, see my other comment.

There is no declaration anywhere in the code base where the map contains a
constant value.

This is not resolved.

[Bug c++/105481] New: ICE: unexpected expression of kind template_parm_index

[chfast at gmail dot com via Gcc-bugs]

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

Bug ID: 105481
   Summary: ICE: unexpected expression of kind template_parm_index
   Product: gcc
   Version: 11.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chfast at gmail dot com
  Target Milestone: ---

I get 

intx_reduced.cpp: In substitution of ‘template
uint f(const T&) [with unsigned int N = N; T = uint;
 = ]’:
intx_reduced.cpp:18:31:   required from here
intx_reduced.cpp:13:5: internal compiler error: unexpected expression ‘N’ of
kind template_parm_index
   13 | typename = typename std::enable_if>::value>::type>
  | ^~~~


for code:

#include 

template 
struct uint
{
   int words_[N];
};

template 
uint f(const uint& y) noexcept;

template >::value>::type>
uint f(const T& y) noexcept;

using X = uint<1>;

X (*fp)(X const&) noexcept = &f;


The reduced version (cvise):

template  struct integral_constant {
  static constexpr _Tp value = __v;
};
using true_type = integral_constant;
using false_type = integral_constant;
template  using __bool_constant = integral_constant;
template  struct conditional;
template  struct __or_;
template 
struct __or_<_B1, _B2> : conditional<_B1::value, _B1, _B2>::type {};
template  struct is_const;
template  struct is_array : false_type {};
template 
struct is_function : __bool_constant::value> {};
template  struct is_const : true_type {};
template , is_array<_To>>::value>
struct __is_convertible_helper {
  template  static true_type __test(int);
  typedef decltype(__test<_To>(0)) type;
};
template 
struct is_convertible : __is_convertible_helper<_From, _To>::type {};
template  struct enable_if { typedef _Tp type; };
template 
struct conditional {
  typedef _Iffalse type;
};
template  struct uint;
template  uint f(const uint &);
template <
unsigned N, typename T,
typename = typename enable_if>::value>::type>
uint f(T);
using X = uint<1>;
X (*fp)(X const &) = f;

[Bug c++/105481] [9/10/11/12/13 Regression] ICE: unexpected expression of kind template_parm_index

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

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Priority|P3  |P2
   Target Milestone|--- |9.5
 Ever confirmed|0   |1
   Keywords||ice-on-valid-code
 CC||jason at gcc dot gnu.org,
   ||mpolacek at gcc dot gnu.org
   Last reconfirmed||2022-05-04
Summary|ICE: unexpected expression  |[9/10/11/12/13 Regression]
   |of kind template_parm_index |ICE: unexpected expression
   ||of kind template_parm_index

--- Comment #1 from Marek Polacek  ---
Started with r269826.  GCC 7 and clang++ compile this.

[Bug c++/105481] [9/10/11/12/13 Regression] ICE: unexpected expression of kind template_parm_index

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #2 from Marek Polacek  ---
(In reply to Marek Polacek from comment #1)
> Started with r269826.  GCC 7 and clang++ compile this.

So not a dup of bug 86918 it seems.

[Bug modula2/105410] gm2 doesn't always honor -save-temps

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

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

Gaius Mulley  changed:

   What|Removed |Added

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

--- Comment #1 from Gaius Mulley  ---
Thanks for the bug report.  All fixed now I believe - just git pushed fixes to
the modula-2 branch.

[Bug c++/105482] New: Regression with `>=` in a template argument

[pdimov at gmail dot com via Gcc-bugs]

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

Bug ID: 105482
   Summary: Regression with `>=` in a template argument
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pdimov at gmail dot com
  Target Milestone: ---

The current GCC trunk in C++11 or C++14 mode gives an error when including
boost/mp11/algorithm.hpp (from Boost 1.79):

opt/compiler-explorer/libs/boost_1_79_0/boost/mp11/algorithm.hpp:445:102:
error: '>=' should be '> =' to terminate a template argument list
  445 | struct mp_take_c_impl, typename std::enable_if= 10>::type>
  |
 ^~
  |
 > =
/opt/compiler-explorer/libs/boost_1_79_0/boost/mp11/algorithm.hpp:445:107:
error: template argument 3 is invalid
  445 | struct mp_take_c_impl, typename std::enable_if= 10>::type>
  |
  ^
/opt/compiler-explorer/libs/boost_1_79_0/boost/mp11/algorithm.hpp:445:114:
error: expected unqualified-id before '>' token
  445 | struct mp_take_c_impl, typename std::enable_if= 10>::type>
  |
 ^

See e.g. https://godbolt.org/z/nE9754and and
https://github.com/boostorg/mp11/issues/73.

GCC 11 works, as does trunk in C++17 mode or later.

[Bug c++/105482] Regression with `>=` in a template argument

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #1 from Marek Polacek  ---
dup

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

[Bug c++/105436] [13 Regression] parse error with >= operator expression in template argument list in C++14 mode since r13-40

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

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

Marek Polacek  changed:

   What|Removed |Added

 CC||pdimov at gmail dot com

--- Comment #7 from Marek Polacek  ---
*** Bug 105482 has been marked as a duplicate of this bug. ***

[Bug c++/105470] ranged for loop whitespace parsing

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

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

--- Comment #12 from Jonathan Wakely  ---
(In reply to Roland Hughes from comment #10)
> There is no definition of that map anywhere in the codebase where
> KeyModifiers is declared const.

That's just how std::map works.

std::map::value_type is std::pair.
See the definition of value_type at
https://en.cppreference.com/w/cpp/container/map

So when you iterate over a map the values you get back are pair.

> The method being called returns a const & to the entire map, but there is no
> const declared within the map.

There is in the map's value_type though, and that's what you iterate over with
the range-based for loop.

[Bug libstdc++/104719] Use of `std::move` in libstdc++ leads to worsened debug performance

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

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

--- Comment #15 from CVS Commits  ---
The master branch has been updated by Jonathan Wakely :

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

commit r13-113-gef8d5ac08b5e60f35c52087d88c0235c8ce6b65b
Author: Jonathan Wakely 
Date:   Fri Mar 25 10:28:28 2022 +

libstdc++: Simplify std::array accessors [PR104719]

This removes the __array_traits::_S_ref and __array_traits::_S_ptr
accessors, which only exist to make the special case of std::array
syntactically well-formed.

By changing the empty type used as the std::array::_M_elems data
member to support operator[] and conversion to a pointer, we can write
code using the natural syntax. The indirection through _S_ref and
_S_ptr is removed for the common case, and a function call is only used
for the special case of zero-size arrays.

The invalid member access for zero-sized arrays is changed to use
__builtin_trap() instead of a null dereference. This guarantees a
runtime error if it ever gets called, instead of undefined behaviour
that is likely to get optimized out as unreachable.

libstdc++-v3/ChangeLog:

PR libstdc++/104719
* include/std/array (__array_traits::_S_ref): Remove.
(__array_traits::_S_ptr): Remove.
(__array_traits::_Type): Define operator[] and operator T*
to provide an array-like API.
(array::_AT_Type): Remove public typeef.
(array::operator[], array::at, array::front, array::back): Use
index operator to access _M_elems instead of _S_ref.
(array::data): Use implicit conversion from _M_elems to pointer.
(swap(array&, array&)): Use __enable_if_t helper.
(get): Use index operator to access _M_elems.
* testsuite/23_containers/array/tuple_interface/get_neg.cc:
Adjust dg-error line numbers.

[Bug libstdc++/104719] Use of `std::move` in libstdc++ leads to worsened debug performance

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

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

--- Comment #16 from CVS Commits  ---
The master branch has been updated by Jonathan Wakely :

https://gcc.gnu.org/g:22399ad6edcd4a2903b05196b59eec3159ceaa38

commit r13-114-g22399ad6edcd4a2903b05196b59eec3159ceaa38
Author: Jonathan Wakely 
Date:   Wed Apr 27 16:09:06 2022 +0100

libstdc++: Add always_inline to the simplest std::array accessors
[PR104719]

libstdc++-v3/ChangeLog:

PR libstdc++/104719
* include/std/array (array::size(), array::max_size())
(array::empty(), array::data()): Add  always_inline attribute.

[Bug libstdc++/104719] Use of `std::move` in libstdc++ leads to worsened debug performance

[unlvsur at live dot com via Gcc-bugs]

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

cqwrteur  changed:

   What|Removed |Added

 CC||unlvsur at live dot com

--- Comment #17 from cqwrteur  ---
(In reply to Jonathan Wakely from comment #14)
> I have a patch to remove indirections in std::array which I'll commit for
> GCC 13.

shouldn't it also add [[__gnu__::__artificial__]] attribute?

[Bug libstdc++/104719] Use of `std::move` in libstdc++ leads to worsened debug performance

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

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

--- Comment #18 from Jonathan Wakely  ---
No.

[Bug c++/105436] [13 Regression] parse error with >= operator expression in template argument list in C++14 mode since r13-40

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

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

--- Comment #8 from CVS Commits  ---
The trunk branch has been updated by Marek Polacek :

https://gcc.gnu.org/g:79a1a01cbd0e4a491d7078783131e3f88ca7158d

commit r13-115-g79a1a01cbd0e4a491d7078783131e3f88ca7158d
Author: Marek Polacek 
Date:   Fri Apr 29 17:03:41 2022 -0400

c++: parse error with >= in template argument list [PR105436]

This patch fixes an oversight whereby we treated >= as the end of
a template argument.  This causes problems in C++14, because in
cp_parser_template_argument we go different ways for C++14 and C++17:

  /* It must be a non-type argument.  In C++17 any constant-expression is
 allowed.  */
  if (cxx_dialect > cxx14)
goto general_expr;

so in this testcase in C++14 we get "N" as the template argument but in
C++17 it is the whole "N >= 5" expression.  So in C++14 the remaining
">= 5" triggered the newly-added diagnostic.

PR c++/105436

gcc/cp/ChangeLog:

* parser.cc (cp_parser_next_token_ends_template_argument_p): Don't
return true for CPP_GREATER_EQ.

gcc/testsuite/ChangeLog:

* g++.dg/parse/template31.C: New test.

[Bug c++/105436] [13 Regression] parse error with >= operator expression in template argument list in C++14 mode since r13-40

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #9 from Marek Polacek  ---
Fixed.

[Bug c++/96765] Base class constructor cast to derived should cause a warning

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

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

Jason Merrill  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #2 from Jason Merrill  ---
Hmm, is the cast undefined, actually?  I thought you were right, but now can't
find any wording to that effect.  I see

[expr.static.cast] If the prvalue of type “pointer to cv1 B” points to a B that
is actually a base class subobject of an object of type D, the resulting
pointer points to the enclosing object of type D. Otherwise, the behavior is
undefined.

But this B is a base of a D.  Then

[class.cdtor] For an object with a non-trivial constructor, referring to any
non-static member or base class of the object before the constructor begins
execution results in undefined behavior.

but D() has begun execution.  Then

[class.cdtor] During the construction of an object, if the value of the object
or any of its subobjects is accessed through a glvalue that is not obtained,
directly or indirectly, from the constructor’s this pointer, the value of the
object or subobject thus obtained is unspecified.

but 'this' in the Base ctor seems to count as obtained indirectly from 'this'
in the Derived ctor.

Then [class.cdtor] paragraph 4 talks about virtual functions, which this is
not.

What rule makes this undefined?

[Bug libstdc++/105440] c++20: std::string's destructor not a constant expression when it should

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Keywords||rejects-valid
   Last reconfirmed||2022-05-04
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
   Target Milestone|--- |12.2

[Bug c++/105483] New: injected-class-name and constructors diagnostic

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

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

Bug ID: 105483
   Summary: injected-class-name and constructors diagnostic
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

Consider:

struct X { };

void
g ()
{
  X::X x;
}

for which we emit

d.cc: In function ‘void g()’:
d.cc:6:3: error: ‘X::__ct ’ names the constructor, not the type
6 |   X::X x;
  |   ^
d.cc:6:7: error: expected ‘;’ before ‘x’
6 |   X::X x;
  |   ^~
  |   ;
d.cc:6:9: error: statement cannot resolve address of overloaded function
6 |   X::X x;
  | ^

which is too verbose and prints the internal "__ct" name.  For comparison:

$ xclang++ -c d.cc
d.cc:6:6: error: qualified reference to 'X' is a constructor name rather than a
type in this context
  X::X x;
 ^

[Bug c++/105476] ICE in build_deduction_guide since r10-4719-g9b41ebbcdf9e3328

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

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

Patrick Palka  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code

--- Comment #6 from Patrick Palka  ---
ICE-on-valid version:

template struct Visitor_functor;

template<> struct Visitor_functor {
  using type_t = int;
};

template struct Events {
  template struct Visitor {
Visitor_functor::type_t t;
  };
};

using ev_t = Events;
ev_t::Visitor v = { {} };

[Bug c++/105436] [13 Regression] parse error with >= operator expression in template argument list in C++14 mode since r13-40

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

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

--- Comment #10 from Jakub Jelinek  ---
Thanks and sorry.

[Bug tree-optimization/105484] New: [12/13 Regression] ICE: verify_flow_info failed: BB 2 cannot throw but has an EH edge with -Os -march=cannonlake -fnon-call-exceptions -fno-tree-dce -fno-tree-forwp

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 105484
   Summary: [12/13 Regression] ICE: verify_flow_info failed: BB 2
cannot throw but has an EH edge with -Os
-march=cannonlake -fnon-call-exceptions -fno-tree-dce
-fno-tree-forwprop
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu

Created attachment 52927
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52927&action=edit
reduced testcase

Compiler output:
$ x86_64-pc-linux-gnu-gcc -Os -march=cannonlake -fnon-call-exceptions
-fno-tree-dce -fno-tree-forwprop testcase.c 
testcase.c: In function 'foo':
testcase.c:6:1: error: BB 2 cannot throw but has an EH edge
6 | foo (int i)
  | ^~~
during GIMPLE pass: isel
testcase.c:6:1: internal compiler error: verify_flow_info failed
0xee6463 verify_flow_info()
/repo/gcc-trunk/gcc/cfghooks.cc:284
0x12f730a execute_function_todo
/repo/gcc-trunk/gcc/passes.cc:2097
0x12f788b execute_todo
/repo/gcc-trunk/gcc/passes.cc:2139
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r13-112-20220504095402-g9c6a4beeed5-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/13.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--disable-bootstrap --with-cloog --with-ppl --with-isl
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r13-112-20220504095402-g9c6a4beeed5-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.0.0 20220504 (experimental) (GCC)

[Bug tree-optimization/105484] [11/12/13 Regression] ICE: verify_flow_info failed: BB 2 cannot throw but has an EH edge with -Os -march=cannonlake -fnon-call-exceptions -fno-tree-dce -fno-tree-forwpro

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

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
Summary|[12/13 Regression] ICE: |[11/12/13 Regression] ICE:
   |verify_flow_info failed: BB |verify_flow_info failed: BB
   |2 cannot throw but has an   |2 cannot throw but has an
   |EH edge with -Os|EH edge with -Os
   |-march=cannonlake   |-march=cannonlake
   |-fnon-call-exceptions   |-fnon-call-exceptions
   |-fno-tree-dce   |-fno-tree-dce
   |-fno-tree-forwprop  |-fno-tree-forwprop since
   ||r11-5074-g287cc750b0887e86
 CC||crazylht at gmail dot com,
   ||marxin at gcc dot gnu.org
   Last reconfirmed||2022-05-04
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
With -Os -march=cannonlake -fnon-call-exceptions -fno-tree-dce
-fno-tree-forwprop -c -fexceptions it started with r11-5074-g287cc750b0887e86.

[Bug target/105485] New: ICE: Segmentation fault in pcrel-opt.md:get_insn_name()

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

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

Bug ID: 105485
   Summary: ICE: Segmentation fault in
pcrel-opt.md:get_insn_name()
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pthaugen at gcc dot gnu.org
  Target Milestone: ---
  Host: powerpc64le-linux-gnu
Target: powerpc64le-linux-gnu
 Build: powerpc64le-linux-gnu

pthaugen@pike:~/temp$ cat err.c
template  void __builtin_vec_vslv();
typedef  __attribute__((altivec(vector__))) char T;
void b() {
  T c, d;
  __builtin_vec_vslv(c, d);
}


pthaugen@pike:~/temp$ ~/install/gcc/trunk/bin/g++ -mcpu=power9 -S -O2 err.c
during GIMPLE pass: lower
err.c: In function ‘void b()’:
err.c:3:6: internal compiler error: Segmentation fault
3 | void b() {
  |  ^
0x10fca4e3 crash_signal
/home/pthaugen/src/gcc/trunk/gcc/gcc/toplev.cc:322
0x11cd9a10 get_insn_name(int)
/home/pthaugen/src/gcc/trunk/gcc/gcc/config/rs6000/pcrel-opt.md:134798
0x11635f87 rs6000_gimple_fold_builtin(gimple_stmt_iterator*)
   
/home/pthaugen/src/gcc/trunk/gcc/gcc/config/rs6000/rs6000-builtin.cc:1301
0x10b3c017 gimple_fold_call
/home/pthaugen/src/gcc/trunk/gcc/gcc/gimple-fold.cc:5559
0x10b3e00b fold_stmt_1
/home/pthaugen/src/gcc/trunk/gcc/gcc/gimple-fold.cc:6298
0x11e5ce17 lower_stmt
/home/pthaugen/src/gcc/trunk/gcc/gcc/gimple-low.cc:390
0x11e5ce17 lower_sequence
/home/pthaugen/src/gcc/trunk/gcc/gcc/gimple-low.cc:217
0x11e5bf03 lower_gimple_bind
/home/pthaugen/src/gcc/trunk/gcc/gcc/gimple-low.cc:475
0x11e5dc33 lower_function_body
/home/pthaugen/src/gcc/trunk/gcc/gcc/gimple-low.cc:110
0x11e5dc33 execute
/home/pthaugen/src/gcc/trunk/gcc/gcc/gimple-low.cc:195
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.


pthaugen@pike:~/temp$ ~/install/gcc/trunk/bin/g++ -v
Using built-in specs.
COLLECT_GCC=/home/pthaugen/install/gcc/trunk/bin/g++
COLLECT_LTO_WRAPPER=/home/pthaugen/install/gcc/trunk/libexec/gcc/powerpc64le-unknown-linux-gnu/13.0.0/lto-wrapper
Target: powerpc64le-unknown-linux-gnu
Configured with: /home/pthaugen/src/gcc/trunk/gcc/configure
--prefix=/home/pthaugen/install/gcc/trunk --enable-decimal-float --enable-lto
--with-as=/usr/bin/as --with-ld=/usr/bin/ld --enable-languages=c,fortran,c++
--disable-multilib --disable-libsanitizer --with-cpu=power8 --disable-bootstrap
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 13.0.0 20220504 (experimental) [master r13-118-g4a206161072] (GCC)

[Bug c++/64679] Spurious redefinition error when parsing not-quite-most-vexing-parse declarations

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

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

--- Comment #4 from CVS Commits  ---
The trunk branch has been updated by Marek Polacek :

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

commit r13-121-ga733dea9e7c39352ce9f72059938833eaa819467
Author: Marek Polacek 
Date:   Fri Apr 29 15:01:12 2022 -0400

c++: wrong parse with functors [PR64679]

Consider

  struct F {
F(int) {}
F operator()(int) const { return *this; }
  };

and

  F(i)(0)(0);

where we're supposed to first call the constructor and then invoke
the operator() twice.  However, we parse this as an init-declarator:
"(i)" looks like a perfectly valid declarator, then we see an '(' and
think it must be an initializer, so we commit and we're toast.  My
fix is to look a little bit farther before deciding we've seen an
initializer.

This is only a half of c++/64679, the other part of the PR is unrelated:
there the problem is that we are calling pushdecl while parsing
tentatively (in cp_parser_parameter_declaration_list), which is bad.

PR c++/64679

gcc/cp/ChangeLog:

* parser.cc (cp_parser_init_declarator): Properly handle a series
of
operator() calls, they are not part of an init-declarator.

gcc/testsuite/ChangeLog:

* g++.dg/parse/functor1.C: New test.

[Bug c++/100825] function signature constraints are not a part of mangled name

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

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

--- Comment #12 from Jonathan Wakely  ---
At the very least, GCC should give better errors instead of just letting the
assembler complain. Clang tells you where the conflicting definitions come
from, e.g. for the code in comment 1:

1.C:7:23: error: definition with same mangled name '_Z3fooIiEvv' as another
definition
template  void foo() requires true {} //2
  ^
1.C:1:23: note: previous definition is here
template  void foo() {} //1
  ^
1 error generated.


Similarly with EDG:

eccp: diagnostics generated from compilation of 1.int.c:
1.C:7:65: error: redefinition of ‘_Z3fooIiEvv’
7 | template  void foo() requires true {} //2
  | ^   
1.C:1:65: note: previous definition of ‘_Z3fooIiEvv’ with type ‘void(void)’
1 | template  void foo() {} //1
  | ^   
eccp: end of diagnostics from compilation of 1.int.c
eccp: gcc compilation of 1.int.c returned an exit status of 1


These are both much better than the result with GCC:

/tmp/ccnRtmjt.s: Assembler messages:
/tmp/ccnRtmjt.s:59: Error: symbol `_Z3fooIiEvv' is already defined

[Bug testsuite/105486] New: new test case gcc.dg/vect/bb-slp-pr104240.c from r13-89-gb3e98eb3396e16 fails

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

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

Bug ID: 105486
   Summary: new test case gcc.dg/vect/bb-slp-pr104240.c from
r13-89-gb3e98eb3396e16 fails
   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:b3e98eb3396e16ae8b20c94916bc2bd7862d2c97, r13-89-gb3e98eb3396e16
make  -k check-gcc RUNTESTFLAGS="dg.exp=gcc.dg/pr102950.c"
FAIL: gcc.dg/pr102950.c (test for excess errors)
# of unexpected failures1


FAIL: gcc.dg/vect/bb-slp-pr104240.c -flto -ffat-lto-objects  scan-tree-dump
slp2 "optimized: basic block"
FAIL: gcc.dg/vect/bb-slp-pr104240.c -flto -ffat-lto-objects  scan-tree-dump
slp2 "optimized: basic block"
FAIL: gcc.dg/vect/bb-slp-pr104240.c scan-tree-dump slp2 "optimized: basic
block"
FAIL: gcc.dg/vect/bb-slp-pr104240.c scan-tree-dump slp2 "optimized: basic
block"


Seeing this on all powerpc64 machines.

commit b3e98eb3396e16ae8b20c94916bc2bd7862d2c97 (HEAD, refs/bisect/bad)
Author: Roger Sayle 
Date:   Tue May 3 14:38:50 2022 -0400

PR tree-optimization/102950: Improved EVRP for signed BIT_XOR_EXPR.

[Bug c++/105476] ICE in build_deduction_guide since r10-4719-g9b41ebbcdf9e3328

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

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by Patrick Palka :

https://gcc.gnu.org/g:8a98e3ff7e80bf2936f163d50309fd88d72564a0

commit r13-123-g8a98e3ff7e80bf2936f163d50309fd88d72564a0
Author: Patrick Palka 
Date:   Wed May 4 17:08:08 2022 -0400

c++: ICE during aggr CTAD for member tmpl [PR105476]

Here we're crashing from maybe_aggr_guide ultimately because
processing_template_decl isn't set when partially instantiating the
guide's parameter list; this causes us to force completion of the
dependent type Visitor_functior, which of course fails and results
in an unexpected error_mark_node (the instantation should always succeed).

PR c++/105476

gcc/cp/ChangeLog:

* pt.cc (maybe_aggr_guide): Set processing_template_decl when
partially instantiating the guide's parameter list.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/class-deduction-aggr13.C: New test.
* g++.dg/cpp2a/class-deduction-aggr13a.C: New test.

[Bug c++/105476] ICE in build_deduction_guide since r10-4719-g9b41ebbcdf9e3328

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

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

Patrick Palka  changed:

   What|Removed |Added

   Target Milestone|--- |12.2

--- Comment #8 from Patrick Palka  ---
Fixed for GCC 13 so far, will also backport for 12.2.

[Bug bootstrap/105487] New: Sysroots without 32bit components cause mysterious errors

[psmith at gnu dot org via Gcc-bugs]

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

Bug ID: 105487
   Summary: Sysroots without 32bit components cause mysterious
errors
   Product: gcc
   Version: 11.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: psmith at gnu dot org
  Target Milestone: ---

I first reported this issue here:
https://gcc.gnu.org/pipermail/gcc/2020-August/233361.html
I said I would file a bug but I don't see any evidence that I ever did so.

It's still present in GCC 11.3.  It actually isn't limited to bootstrap,
either: if you set to a sysroot that doesn't contain any 32bit values, and thus
doesn't contain the /sysroot/usr/lib directory at all but only has
/sysroot/usr/lib64, then you can't compile GCC itself against that sysroot and,
if you have a built GCC, you can't compile programs against that sysroot.

I have hacked a workaround by creating an empty /sysroot/usr/lib directory in
my sysroot, but it took me the better part of a day to figure out the
problem... even though I had already figured this out less than two years ago. 
It would be nice to avoid the problem.

While building GCC, you will get this relatively obscure error trying to build
libgcc_s.so:

ld: error: cannot open crti.o: No such file or directory
ld: error: cannot open crtn.o: No such file or directory
ld: error: cannot find -lc

If you debug it, you'll see that /sysroot/usr/lib64/crti.o does exist (same
with the others) so you will be confused.  If you look more carefully and add
-v to see search paths, you'll find that the path we use to locate 64bit
content is a relative path to the /sysroot/usr/lib directory:

   ... -L/sysroot/usr/lib/../lib64

instead using the direct path:

   ... -L/sysroot/usr/lib64

So, if you don't HAVE a /sysroot/usr/lib directory (because you aren't
supporting 32bit builds and have no need for it) your builds will fail.

[Bug bootstrap/105487] Sysroots without 32bit components cause mysterious errors

[psmith at gnu dot org via Gcc-bugs]

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

--- Comment #1 from Paul Smith  ---
Ugh, when I wrote "doesn't contain any 32bit values" I meant "doesn't contain
any 32bit files".

[Bug bootstrap/105487] Sysroots without 32bit components cause mysterious errors

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

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

--- Comment #2 from Andrew Pinski  ---
I don't think there is anything GCC can do here really. If you don't have a
correct sysroot, it is not a GCC bug. Requring usr/lib is because all
directories are relative to that directory.

[Bug c++/104470] [10/11/12/13 Regression] internal compiler error: Segmentation fault compiling std::variant with -std=c++20

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

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by Jason Merrill :

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

commit r13-124-ga47ab705c2c9f07f08fde499d6be4682efe4b626
Author: Jason Merrill 
Date:   Tue Apr 26 18:32:51 2022 -0400

c++: alias CTAD refactoring [PR104470]

In my previous PR104470 patch I added yet another place that needs to
handle
dependent member rewriting for deduction guides; this patches centralizes
rewriting into maybe_dependent_member_ref.  tsubst_baselink still has its
own handling because that's simpler than teaching
maybe_dependent_member_ref
about BASELINKs.

PR c++/104470

gcc/cp/ChangeLog:

* pt.cc (maybe_dependent_member_ref): Handle types.
(tsubst, tsubst_copy): Use it.
(tsubst_aggr_type, instantiate_alias_template): Don't handle
tf_dguide here.

[Bug libstdc++/105387] libstdc++: with -fno-rtti, pointer type info class incorrectly matches non-pointer type info classes

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

[Bug c/105488] New: Function definition is not generated OR function is not inlined

[pavel.morozkin at gmail dot com via Gcc-bugs]

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

Bug ID: 105488
   Summary: Function definition is not generated OR function is
not inlined
   Product: gcc
   Version: 11.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pavel.morozkin at gmail dot com
  Target Milestone: ---

Note: probably this is a duplicate.

This code:
inline void f(void)
{
}

int main(void)
{
  f();
}

leads to this code:
.file   "t609.c"
.text
.def__main; .scl2;  .type   32; .endef
.globl  main
.defmain;   .scl2;  .type   32; .endef
.seh_proc   main
main:
pushq   %rbp
.seh_pushreg%rbp
movq%rsp, %rbp
.seh_setframe   %rbp, 0
subq$32, %rsp
.seh_stackalloc 32
.seh_endprologue
call__main
callf
movl$0, %eax
addq$32, %rsp
popq%rbp
ret
.seh_endproc
.ident  "GCC: (GNU) 11.1.0"
.deff;  .scl2;  .type   32; .endef

Here we see that "call f" is present, while "f:" is absent.

As a result:
$ gcc t609.c
ld: /tmp/cc8z1GjU.o:t609.c:(.text+0xe): undefined reference to `f'
collect2: error: ld returned 1 exit status

I think that:
- either function definition is not generated,
- either function is not inlined.

[Bug c/105488] Function definition is not generated OR function is not inlined

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Right, in C99, inline by itself just says inline or emit a call to the function
and have the definition in a different Translation unit.

Note C90 didn't have inline and GNU90 has different sematics for inline than
C99.

[Bug c/105488] Function definition is not generated OR function is not inlined

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

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

--- Comment #2 from Jonathan Wakely  ---
See https://gcc.gnu.org/gcc-5/porting_to.html#inline

[Bug bootstrap/105487] Sysroots without 32bit components cause mysterious errors

[psmith at gnu dot org via Gcc-bugs]

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

--- Comment #3 from Paul Smith  ---
There's nothing "incorrect" about a sysroot that doesn't have /usr/lib in it. 
If you have a 64bit system and you don't need to run 32bit binaries, then
/usr/lib will be empty and everything will be in /usr/lib64.

[Bug bootstrap/105487] Sysroots without 32bit components cause mysterious errors

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

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

--- Comment #4 from Andrew Pinski  ---
It is incorrect as that is required. Simple as that.

[Bug fortran/105473] semicolon allowed when list-directed read integer with decimal='point'

[jvdelisle2 at gmail dot com via Gcc-bugs]

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

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle2 at gmail dot com

--- Comment #1 from Jerry DeLisle  ---
Well, looks like we are allowing as an extension.

$ gfortran -std=f95 pr105473.f90 
pr105473.f90:6:27:

6 |   read(testinput,*,decimal='point',iostat=ios) n
  |   1
Error: Fortran 2003: DECIMAL= at (1) not allowed in Fortran 95

If you set n to some value so that it is 'defined' per the standards like this:

! Does list-directed reading an integer allow some non-integer input?
  implicit none
  integer n,ios
  character(1):: testinput = ';'
  n = 999
  print *,'testinput = "',testinput,'"'
  read(testinput,*,decimal='point',iostat=ios) n
  print *,'n=',n,' ios=',ios
  if(ios>0) print *,'testinput was not an integer'
end program

$ gfortran pr105473.f90 
[jerry@amdr pr105473]$ ./a.out 
 testinput = ";"
 n= 999  ios=   0

You will see that nothing is read into n at all.  The list read is just ended.

[Bug fortran/105473] semicolon allowed when list-directed read integer with decimal='point'

[jvdelisle2 at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Jerry DeLisle  ---
I should add, I am not saying this is right or wrong.  The error message refers
to F2003.

$ gfortran -std=f2003 pr105473.f90 
[jerry@amdr pr105473]$ ./a.out 
 testinput = ";"
 n= 999  ios=   0

It is being allowed with the later standard flag.  We will have to dig through
the standard as well as look at the error checking that is in place to answer
the question.

[Bug fortran/105473] semicolon allowed when list-directed read integer with decimal='point'

[harper at msor dot vuw.ac.nz via Gcc-bugs]

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

--- Comment #3 from harper at msor dot vuw.ac.nz ---
Thank you. Of course the program did not compile with -std=f95 because 
there was no decimal='point' option then. But with -std=f2003 or f2008 or 
f2018, and with or without n = 999 before the read statement, ios was 
always 0 after it. I had thought that extensions to the relevant standard 
were supposed to be disallowed when one compiled with a std= version. 
Ifort gave a positive value of ios, which the f2003, f2008 and f2018 
standards all require for that program.

On Thu, 5 May 2022, jvdelisle2 at gmail dot com wrote:

> Date: Thu, 5 May 2022 02:14:42 +
> From: jvdelisle2 at gmail dot com 
> To: John Harper 
> Subject: [Bug fortran/105473] semicolon allowed when list-directed read
> integer with decimal='point'
> Resent-Date: Thu, 5 May 2022 14:14:52 +1200 (NZST)
> Resent-From: 
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105473
>
> Jerry DeLisle  changed:
>
>   What|Removed |Added
> 
> CC||jvdelisle2 at gmail dot com
>
> --- Comment #1 from Jerry DeLisle  ---
> Well, looks like we are allowing as an extension.
>
> $ gfortran -std=f95 pr105473.f90
> pr105473.f90:6:27:
>
>6 |   read(testinput,*,decimal='point',iostat=ios) n
>  |   1
> Error: Fortran 2003: DECIMAL= at (1) not allowed in Fortran 95
>
> If you set n to some value so that it is 'defined' per the standards like 
> this:
>
> ! Does list-directed reading an integer allow some non-integer input?
>  implicit none
>  integer n,ios
>  character(1):: testinput = ';'
>  n = 999
>  print *,'testinput = "',testinput,'"'
>  read(testinput,*,decimal='point',iostat=ios) n
>  print *,'n=',n,' ios=',ios
>  if(ios>0) print *,'testinput was not an integer'
> end program
>
> $ gfortran pr105473.f90
> [jerry@amdr pr105473]$ ./a.out
> testinput = ";"
> n= 999  ios=   0
>
> You will see that nothing is read into n at all.  The list read is just ended.
>
> -- 
> You are receiving this mail because:
> You reported the bug.
>


-- John Harper, School of Mathematics and Statistics
Victoria Univ. of Wellington, PO Box 600, Wellington 6140, New Zealand.
e-mail john.har...@vuw.ac.nz phone +64(0) 4 463 5276

[Bug middle-end/105469] "execution reached an unreachable program point" with -flto since r5-7027-g0b986c6ac777aa4e

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #13 from Andrew Pinski  ---
(In reply to Martin Liška from comment #11)
> Likely started with r5-7027-g0b986c6ac777aa4e, it is looping before the
> revision.

No, that revision just caused -fsanitize=unreachable to catch it (see PR
61591).

[Bug target/105484] [11/12/13 Regression] ICE: verify_flow_info failed: BB 2 cannot throw but has an EH edge with -Os -march=cannonlake -fnon-call-exceptions -fno-tree-dce -fno-tree-forwprop since r11

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Hongtao.liu  ---
I'll take a look.