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

[juergen.reuter at desy dot de via Gcc-bugs]

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

--- Comment #4 from Jürgen Reuter  ---
(In reply to Dominique d'Humieres from comment #3)
> Confirmed.

Merci, Dominique. Would you actually advise to compile without bootstrap and
start using gcc, or wait until the reason for the bootstrap failure is
understood and hopefully fixed?

[Bug target/94136] GCC doc for built-in function __builtin___clear_cache() not 100% correct

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

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

palmer at gcc dot gnu.org changed:

   What|Removed |Added

 CC||palmer at gcc dot gnu.org

--- Comment #4 from palmer at gcc dot gnu.org ---
IMO this isn't actually a documentation bug, it's a functionality bug.  I've
sent a patch, sorry it took a while -- I hadn't seen this one, but just
stumbled across Jim's mostly unrelated email and happened to find this bug.

[Bug middle-end/90323] powerpc should convert equivalent sequences to vec_sel()

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

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

--- Comment #16 from luoxhu at gcc dot gnu.org ---

> +2016-11-09  Segher Boessenkool  
> +
> +   * simplify-rtx.c (simplify_binary_operation_1): Simplify
> +   (xor (and (xor A B) C) B) to (ior (and A C) (and B ~C)) and
> +   (xor (and (xor A B) C) A) to (ior (and A ~C) (and B C)) if C
> +   is a const_int.


Is it a MUST that C be const here? For this case in PR90323, C is not a const 
actually.

l = l & ~mask;
l |= mask & r;

Trying 8, 9 -> 10:
8: r127:V4SI=r124:V4SI^r131:V4SI
  REG_DEAD r131:V4SI
9: r122:V4SI=r127:V4SI:V4SI
  REG_DEAD r130:V4SI
  REG_DEAD r127:V4SI
   10: r128:V4SI=r124:V4SI^r122:V4SI
  REG_DEAD r124:V4SI
  REG_DEAD r122:V4SI

[Bug target/100305] [10 Regression] aarch64: ICE in output_operand_lossage with -O3

[gilles.gouaillardet at gmail dot com via Gcc-bugs]

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

--- Comment #13 from Gilles Gouaillardet  
---
Thanks Richard for the quick fix.

I am happy to confirm that the latest trunk passes the three reproducers
included in this ticket.

However, the latest gcc-11 branch only passes the mini reproducer you posted
(and crashes with a similar stack trace with Andrew's reproducer and the one I
trimmed from GROMACS)

FWIW, I am still unable to build GROMACS 2021.1 with the latest trunk (both
neon and SVE, now checking x86_64), but this is a different issue (looks like a
C++ frontend issue, unless this is a legit error in the application).

[Bug c++/100335] Using statement of a ref-qualified method from base class: method not callable on derived object

[webrown.cpp at gmail dot com via Gcc-bugs]

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

--- Comment #4 from W E Brown  ---
I won't comment on any compiler's behavior, but do want to thank you for
reminding me of [namespace.udecl]/14:

"When a using-declarator brings declarations from a base class into a derived
class, member functions ... in the derived class override and/or hide member
functions .. with the same name, parameter-type-list ..., and ref-qualifier (if
any), in a base class"

Upon reflection, I believe that [namespace.udecl]/14 does not apply to the
original example because the ref-qualifier on Derived::method (i.e., none) is
not "the same" as the ref-qualifier on either Base::method.  Thus, there's no
overriding and/or hiding to be done there.

However, I believe that [namespace.udecl]/14 *does* apply to the example in
Comment 3, where Base::method and Derived::method do have "the same"
ref-qualifier (i.e., none).  There, Derived::method ought to hide Base::method
as [over.load]/2.3 seems be inapplicable.

In brief, I believe Comment 3's example ought compile due to
[namespace.udecl]/14, but the original example ought not compile due to
[over.load]/2.3.

[Bug middle-end/100267] gcc -O2 for avx512 instrincts generates extra warnings and less optimizations

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #5 from Hongtao.liu  ---
(In reply to Hongtao.liu from comment #4)
> (In reply to Hongtao.liu from comment #3)
> > After support v{,p}expand* thats w/o mask operands, codegen seems to be
> > optimal
> > 
> 
> I was wrong, without mask, it's just simple move.

finally optimized to

 _Z16dummyf1_avx512x8PK11flow_avx512:
.LFB5665:
.cfi_startproc
movl(%rdi), %edx
movq8(%rdi), %rax
vmovdqu (%rax,%rdx,8), %ymm0
vmovdqu 32(%rax,%rdx,8), %ymm1
vpaddq  %ymm1, %ymm0, %ymm0
ret

I'm testing the patch.

[Bug bootstrap/100327] [12 regression] bootstrap failure after r12-228

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

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

Michael Meissner  changed:

   What|Removed |Added

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

--- Comment #7 from Michael Meissner  ---
Patch committed on April 29th, 2021.

[Bug bootstrap/100345] gcc 11.1 build "make -n install" fails linking gcov undefined reference to std::__throw_bad_array_new_length()

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

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

--- Comment #4 from Andrew Pinski  ---
You are going to have to provide the whole build log to figure out why this is
happening.

Are you using a network mounted drive?  If so do they have the time syncronized
between them.

[Bug bootstrap/100345] gcc 11.1 build "make -n install" fails linking gcov undefined reference to std::__throw_bad_array_new_length()

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|other   |bootstrap

--- Comment #3 from Andrew Pinski  ---
For some reason it is relinking gcov. This normally does not happen.

[Bug c++/74765] missing uninitialized warning (parenthesis, TREE_NO_WARNING abuse)

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

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

Martin Sebor  changed:

   What|Removed |Added

   Last reconfirmed|2019-02-03 00:00:00 |2021-4-29
 Status|NEW |ASSIGNED
  Known to fail|7.3.0, 8.2.0, 9.0   |10.3.0, 11.0, 7.5.0, 8.4.0,
   ||9.3.0
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org

--- Comment #6 from Martin Sebor  ---
Reconfirming.  I'm working on a fix.

[Bug target/100348] New: RISC-V extra pointer adjustments for memcpy() from glibc

[brian.grayson at sifive dot com via Gcc-bugs]

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

Bug ID: 100348
   Summary: RISC-V extra pointer adjustments for memcpy() from
glibc
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: brian.grayson at sifive dot com
  Target Milestone: ---

Created attachment 50714
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50714=edit
Source C code for trimmed example

The wordcopy_fwd_aligned() portion of glibc contains generated code like the
following assembly dump:

.L16:
  ld  a6,16(a1)
  addi  a3,a5,24
  sd  a4,0(a0)
.L15:
  ld  a4,24(a1)
  addi  a0,a5,32
  sd  a6,0(a3)
.L14:
  ld  a6,32(a1)
  addi  a3,a5,40
  sd  a4,0(a0)
.L13:
  ld  a4,40(a1)
  addi  a0,a5,48
  sd  a6,0(a3)
.L12:
  ld  a6,48(a1)
  addi  a3,a5,56
  sd  a4,0(a0)

For some reason, gcc is able to do the proper immediate-offset thinking so that
the loads use different offsets and a fixed base register (until we get to the
bottom of the loop, and bump the a1 pointer), but for the stores, it bumps the
pointer each time. This adds 50% more instructions to the innermost loop of
memcpy() arguably a bit of code we should try to have optimal code for.

I've simplified the code here, to make it about as small as it can be and still
demonstrate the issue.

Here is the generated assembly, with my commentary to the right in comments:

.file   "simple.c"
.option nopic
.attribute arch, "rv64i2p0_m2p0_a2p0_f2p0_d2p0_c2p0"
.attribute unaligned_access, 0
.attribute stack_align, 16
.text
.align  1
.globl  not_really_wordcopy_fwd_aligned
.type   not_really_wordcopy_fwd_aligned, @function
not_really_wordcopy_fwd_aligned:
andia5,a2,3
li  a4,2
beq a5,a4,.L2
li  a4,3
beq a5,a4,.L3
li  a4,1
beq a5,a4,.L20
bne a2,zero,.L21
ret
.L20:
addia2,a2,-1
ld  a3,0(a1)
bne a2,zero,.L22
.L10:
sd  a3,0(a0)
.L23:
ret
.L3:
ld  a3,0(a1)
addia4,a1,-40
addia5,a0,-48
addia2,a2,5
addia1,a1,-8
addia7,a0,-16
j   .L7
.L11:
sd  a3,32(a5) // Uses an immediate offset off of a5. Good.
ld  a3,32(a4)
addia7,a5,32
addia1,a4,32
.L9:
sd  a3,40(a5) // Uses an immediate offset off of a5. Good again.
ld  a3,40(a4)
addia0,a5,48  // Uh-oh, bumping a pointer to be a5+48.
.L7:
sd  a3,0(a0)  // Uh-oh, using the pointer. Why not 48(a5)?
ld  a6,48(a4)
addia0,a5,56
mv  a3,a4
mv  a5,a7
mv  a4,a1
.L6:
sd  a6,0(a0)
addia2,a2,-4
ld  a3,56(a3)
mv  a0,a5
bne a2,zero,.L11
sd  a3,0(a0)
j   .L23
.L2:
ld  a6,0(a1)
addia3,a1,-48
addia2,a2,6
addia4,a1,-16
addia5,a0,-24
j   .L6
.L22:
addia4,a1,8
mv  a5,a0
j   .L11
.L21:
ld  a3,0(a1)
mv  a4,a1
addia5,a0,-8
addia1,a1,32
addia7,a0,24
j   .L9
.size   not_really_wordcopy_fwd_aligned,
.-not_really_wordcopy_fwd_aligned
.ident  "GCC: (SiFive GCC-Metal 10.2.0-2020.12.9) 10.2.0"

I realize that the different paths to L7 make this a bit confusing, but it
seems that since the only path to L7 is through the code at L3 or through the
fallthrough path where it is currently adjusting the pointer, the proper
adjustments could be made before, outside the loop, instead of each time.

In the full memcpy() source code, this behavior occurs multiple times, roughly
for every store, as shown at the top of this bug report.

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

[dominiq at lps dot ens.fr via Gcc-bugs]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2021-04-29
 CC||iains at gcc dot gnu.org

--- Comment #3 from Dominique d'Humieres  ---
Confirmed.

[Bug driver/100347] GCC 11 does not recognize skylake; translates "march=native" to "x86_64"

[schnetter at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Erik Schnetter  ---
Forgot to add: When I explicitly use "-march=skylake", everything works as
expected.

[Bug driver/100347] New: GCC 11 does not recognize skylake; translates "march=native" to "x86_64"

[schnetter at gmail dot com via Gcc-bugs]

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

Bug ID: 100347
   Summary: GCC 11 does not recognize skylake; translates
"march=native" to "x86_64"
   Product: gcc
   Version: 11.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: driver
  Assignee: unassigned at gcc dot gnu.org
  Reporter: schnetter at gmail dot com
  Target Milestone: ---

I just built GCC 11.1.0 (via Spack). I find that "-march=native" does not work
any more. It used to work with GCC 10.3 and earlier. The symptom is that
manually vectorized code does not compile any more.

This demonstrates the problem:

$ ./view-compilers/bin/gcc -march=native -Q --help=target | grep march
  -march=   x86-64
  Known valid arguments for -march= option:

This outputs "x86-64" where I expect "skylake".

$ ./view-compilers/bin/gcc --version
gcc (Spack GCC) 11.1.0
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

It works with an older version of GCC:

$ /opt/local/bin/gcc -march=native -Q --help=target | grep march
  -march=   skylake
  Known valid arguments for -march= option:

$ /opt/local/bin/gcc --version
gcc (MacPorts gcc10 10.3.0_0) 10.3.0
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

My system is a

$ uname -a
Darwin redshift.local 20.4.0 Darwin Kernel Version 20.4.0: Fri Mar  5 01:14:14
PST 2021; root:xnu-7195.101.1~3/RELEASE_X86_64 x86_64 i386 MacBookPro15,1
Darwin

[Bug other/100345] gcc 11.1 build "make -n install" fails linking gcov undefined reference to std::__throw_bad_array_new_length()

[bugs at pu dot net via Gcc-bugs]

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

--- Comment #2 from Mark Hittinger  ---
../gcc-11.1.0/configure \
   --prefix=/usr/local/gcc1110 \
   --disable-multilib \
   --enable-languages=c,c++,fortran

x64 fedora using binutils-2.36 and gcc 10.2

[Bug other/100345] gcc 11.1 build "make -n install" fails linking gcov undefined reference to std::__throw_bad_array_new_length()

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
 Ever confirmed|0   |1
   Last reconfirmed||2021-04-29

--- Comment #1 from Jonathan Wakely  ---
Please provide your configure command and details of the build environment.

[Bug testsuite/100346] New: [11 regression] printf tests fail after r11-6755

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

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

Bug ID: 100346
   Summary: [11 regression] printf tests fail after r11-6755
   Product: gcc
   Version: 11.1.1
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:3804e937b0e252a7e42632fe6d9f898f1851a49c, r11-6755

There are 3 similar failures starting with this revision on a powerpc64 power 9
LE system.  I tried this on some other systems (power 7, 8, and 10) and on all
of them the tests were flagged as unsupported so perhaps that is all that is
needed here?

commit 3804e937b0e252a7e42632fe6d9f898f1851a49c (HEAD)
Author: Mark Wielaard 
Date:   Tue Sep 29 15:52:44 2020 +0200

Default to DWARF5


make  -k check-gcc
RUNTESTFLAGS="execute.exp=gcc.c-torture/execute/user-printf.c"
FAIL: gcc.c-torture/execute/user-printf.c   -O3 -g  (test for excess errors)
# of expected passes15
# of unexpected failures1

spawn -ignore SIGHUP /home3/seurer/gcc/git/build/gcc-11-test/gcc/xgcc
-B/home3/seurer/gcc/git/build/gcc-11-test/gcc/
/home/seurer/gcc/git/gcc-11-test/gcc/testsuite/gcc.c-torture/execute/user-printf.c
-fdiagnostics-plain-output -O3 -g -w -lm -o ./user-printf.exe
/usr/bin/ld: Dwarf Error: Can't find .debug_ranges section.
/tmp/ccqaXtoD.o: In function `main':
user-printf.c:(.text.startup+0x20): warning: the use of `tmpnam' is dangerous,
better use `mkstemp'
FAIL: gcc.c-torture/execute/user-printf.c   -O3 -g  (test for excess errors)


make  -k check-gcc RUNTESTFLAGS="execute.exp=gcc.c-torture/execute/printf-2.c"
FAIL: gcc.c-torture/execute/printf-2.c   -O3 -g  (test for excess errors)
# of expected passes13
# of unexpected failures1

spawn -ignore SIGHUP /home3/seurer/gcc/git/build/gcc-11-test/gcc/xgcc
-B/home3/seurer/gcc/git/build/gcc-11-test/gcc/
/home/seurer/gcc/git/gcc-11-test/gcc/testsuite/gcc.c-torture/execute/printf-2.c
-fdiagnostics-plain-output -O3 -g -w -lm -o ./printf-2.exe
/usr/bin/ld: Dwarf Error: Can't find .debug_ranges section.
/tmp/ccDgL46Y.o: In function `main':
printf-2.c:(.text.startup+0x20): warning: the use of `tmpnam' is dangerous,
better use `mkstemp'
FAIL: gcc.c-torture/execute/printf-2.c   -O3 -g  (test for excess errors)
Excess errors:
/usr/bin/ld: Dwarf Error: Can't find .debug_ranges section.


make  -k check-gcc RUNTESTFLAGS="execute.exp=gcc.c-torture/execute/fprintf-2.c"
FAIL: gcc.c-torture/execute/fprintf-2.c   -O3 -g  (test for excess errors)
# of expected passes13
# of unexpected failures1

spawn -ignore SIGHUP /home3/seurer/gcc/git/build/gcc-11-test/gcc/xgcc
-B/home3/seurer/gcc/git/build/gcc-11-test/gcc/
/home/seurer/gcc/git/gcc-11-test/gcc/testsuite/gcc.c-torture/execute/fprintf-2.c
-fdiagnostics-plain-output -O3 -g -w -lm -o ./fprintf-2.exe
/usr/bin/ld: Dwarf Error: Can't find .debug_ranges section.
/tmp/ccki8IKn.o: In function `main':
fprintf-2.c:(.text.startup+0x20): warning: the use of `tmpnam' is dangerous,
better use `mkstemp'
FAIL: gcc.c-torture/execute/fprintf-2.c   -O3 -g  (test for excess errors)
Excess errors:
/usr/bin/ld: Dwarf Error: Can't find .debug_ranges section.

[Bug c++/100344] compiler ICE internal compiler error: in build_call_a, at cp/call.c:38

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #4 from cqwrteur  ---
Created attachment 50713
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50713=edit
Preprocess

sorry. the file was too large.

It looks like it is an issue related to constexpr evaluation.

[Bug c++/100344] compiler ICE internal compiler error: in build_call_a, at cp/call.c:38

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #3 from cqwrteur  ---
(In reply to Marek Polacek from comment #2)
> Testcase?

i can only provide preprocess file

[Bug c++/100344] compiler ICE internal compiler error: in build_call_a, at cp/call.c:38

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

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

Marek Polacek  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2021-04-29
 CC||mpolacek at gcc dot gnu.org

--- Comment #2 from Marek Polacek  ---
Testcase?

[Bug other/100345] New: gcc 11.1 build "make -n install" fails linking gcov undefined reference to std::__throw_bad_array_new_length()

[bugs at pu dot net via Gcc-bugs]

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

Bug ID: 100345
   Summary: gcc 11.1 build "make -n install" fails linking gcov
undefined reference to
std::__throw_bad_array_new_length()
   Product: gcc
   Version: 11.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bugs at pu dot net
  Target Milestone: ---

Attempting to build gcc-11.1 "make" succeeds but "make -n install" fails when
it attempts to link gcov with an undefined symbol 

std::__throw_bad_array_new_length()

I believe that the build is using the system default libstdc++.a rather than
the gcc-11 built version.

Modifying gcc-11.1.0-obj/gcc/Makefile to link gcov with

"-L ../x86_64-pc-linux-gnu/libstdc++-v3/src/.libs"

succeeds.

[Bug libstdc++/100334] atomic::notify_one() sometimes wakes wrong thread

[m.cencora at gmail dot com via Gcc-bugs]

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

--- Comment #5 from m.cencora at gmail dot com ---
Actually standard seems to require it - at least to my understanding of wait()
description in  in chapter 31.8.1: it explicitly states that waiting is
performed in a loop, and loop is exited only if value has changed from old.

So when we force notify_all for pooled waiters, then it may happen that a
thread for which value didn't change from 'old' will be woken, so we must
recheck the value.

[Bug c++/100344] compiler ICE internal compiler error: in build_call_a, at cp/call.c:38

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #1 from cqwrteur  ---
D:\hg\fast_io\.tmp\dragonboxtest>g++ -o a a.cc -Ofast -std=c++20 -s -flto
-march=native -Wall -Wextra
In file included from ../../include/fast_io_core_impl/codecvt/impl.h:7,
 from ../../include/fast_io_core.h:91,
 from ../../include/fast_io_freestanding.h:12,
 from ../../include/fast_io_hosted.h:17,
 from ../../include/fast_io.h:9,
 from a.cc:1:
../../include/fast_io_core_impl/codecvt/general.h: In instantiation of
'constexpr dest_char_type*
fast_io::details::codecvt::general_code_cvt_full(const src_char_type*, const
src_char_type*, dest_char_type*) [with fast_io::encoding_scheme src_encoding =
fast_io::encoding_scheme::execution_charset; fast_io::encoding_scheme encoding
= fast_io::encoding_scheme::utf_le; src_char_type = char; dest_char_type =
char16_t]':
../../include/fast_io_hosted/platforms/win32_path_dealer.h:25:109:   required
from 'constexpr fast_io::details::win32_path_dealer::win32_path_dealer(const
from_char_type*, std::size_t) [with from_char_type = char; std::size_t = long
long unsigned int]'
../../include/fast_io_hosted/platforms/win32.h:99:42:   required from 'void*
fast_io::details::win32_create_file_impl(fast_io::basic_cstring_view,
const fast_io::details::win32_open_mode&) [with char_type = char]'
../../include/fast_io_hosted/platforms/win32.h:775:69:   required from
'fast_io::basic_win32_file::basic_win32_file(fast_io::cstring_view,
fast_io::open_mode, fast_io::perms) [with ch_type = char; fast_io::cstring_view
= fast_io::basic_cstring_view]'
../../include/fast_io_hosted/file_loaders/win32_file_loader.h:61:13:   required
from 'auto
fast_io::win32::details::win32_load_file_impl(fast_io::basic_cstring_view,
fast_io::perms) [with char_type = char]'
../../include/fast_io_hosted/file_loaders/win32_file_loader.h:112:48:  
required from here
../../include/fast_io_core_impl/codecvt/general.h:430:98: internal compiler
error: in build_call_a, at cp/call.c:381
  430 | return
general_code_cvt_full(src_encoding),
  | 
^~
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug c++/100344] New: compiler ICE internal compiler error: in build_call_a, at cp/call.c:38

[unlvsur at live dot com via Gcc-bugs]

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

Bug ID: 100344
   Summary: compiler ICE internal compiler error: in build_call_a,
at cp/call.c:38
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: unlvsur at live dot com
  Target Milestone: ---

[Bug c++/100330] operator bool() is used when operator<() is available to do comparison

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
The crux of the problem is that bool is comparable using any of == != < > <=
and >= and your type is implicitly convertible to bool. That means your type is
comparable using any of == != < > <= >= too, but with weird results:

  vertex_description v1((void*)1), v2((void*)2);
  assert(v1 < v2);
  assert(v1 == v2);  // OK, but v1 < v2 also true!
  assert(v1 >= v2);  // OK, but v1 < v2 also true!

This means your class' comparisons are unusable. The only one with sensible
behaviour is operator< which doesn't use the bool conversion, but the result of
that operator is inconsistent with the results of the others.

In C++17 you could get away with this, and using the class as a key in an
associative container worked because it only ever used operator< and ignored
the others.

In C++20 comparisons work differently, and a type with broken/inconsistent
comparisons will cause problems in many places. Comparisons for std::pair (and
std::tuple, std::optional, and containers) assume your type has consistent
comparisons, and if it doesn't, things will break.

There are two ways to fix your class to work in C++20:

Make the conversion to bool explicit:

  explicit operator bool() const;

This has been recommended practice for a decade now, since C++11. Even before
then, implicit conversions to bool were known to be a problem (see
https://www.artima.com/articles/the-safe-bool-idiom which was written in 2004
and stated that an implicit conversion to bool makes your type comparable).

Or define all the comparisons for the type so that they behave consistently:

  bool operator<(const vertex_descriptor) const;
  bool operator>(const vertex_descriptor) const;
  bool operator<=(const vertex_descriptor) const;
  bool operator>=(const vertex_descriptor) const;
  bool operator==(const vertex_descriptor) const;
  bool operator!=(const vertex_descriptor) const;

For many types, this can be done very simply:

  bool operator==(const vertex_descriptor) const = default;
  auto operator<=>(const vertex_descriptor) const = default;

This will fix your type, and make pair have sensible
comparisons too.

[Bug c/100343] New: add -Wundefined-inline for inline function is used but not defined

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

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

Bug ID: 100343
   Summary: add -Wundefined-inline for inline function is used but
not defined
   Product: gcc
   Version: 11.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

Clang provides -Wundefined-inline to control the warning about used inline
functions for which no definition has been provided.  GCC doesn't provide any
option to control the warning.  This is a request to add -Wundefined-inline
with the same effect as in Clang, both in C++ and in C.

$ (set -x && cat t.C && clang -S -Wall t.C && gcc -S -Wall t.C)
+ cat t.C
inline int f ();
int g () { return f (); }
+ clang -S -Wall t.C
t.C:1:12: warning: inline function 'f' is not defined [-Wundefined-inline]
inline int f ();
   ^
t.C:2:19: note: used here
int g () { return f (); }
  ^
1 warning generated.
+ /build/gcc-master/gcc/xgcc -B /build/gcc-master/gcc -S -Wall t.C
t.C:1:12: warning: inline function ‘int f()’ used but never defined
1 | inline int f ();
  |^

[Bug c++/100335] Using statement of a ref-qualified method from base class: method not callable on derived object

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

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

--- Comment #3 from Jonathan Wakely  ---
I don't know if that rule applies here. If it did, this would be invalid too
(by [over.load]/2.1), but all compilers agree that this is OK:

struct Base {
  int method() {}
};

struct Derived : Base {
  using Base::method;
  void method() {}
};


I believe the relevant rule for my example is [namespace.udecl[/14 which says
that declarations from a base class are hidden by declarations in the derived
class with the same name, parameter clause and ref-qualifier (if any), and that
hidden names are excluded from the set introduced by the using-declaration.
Which means that Base::method() is hidden by Derived::method() and so not
introduced.

It looks like GCC is applying that same rule for the original example, so that
Derived::method() hides the Base::method() const& and Base::method const&&
declarations that would otherwise conflict. That means the only overload
candidate for test.method() is Derived::method() which can't be called on a
const object. However, [namespace.udecl]/14 seems clear that such hiding should
only happen if the ref-qualifers are the same.

Other compilers (Clang, EDG and MSVC) accept the original example, which I
can't explain. Either the overloads should conflict because of [over.load]/2.3
(and the definition of Derived should be ill-formed) or they should be hidden
and not visible in Derived (so the call to test.method() should be ill-formed).

[Bug c++/100335] Using statement of a ref-qualified method from base class: method not callable on derived object

[Daniel.Withopf at web dot de via Gcc-bugs]

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

--- Comment #2 from Daniel  ---
As an extra Info: the other compilers I tested (e.g. clang) accept the code
example as is.

But after reading the cited pet of the standard It seems that GCC is right in
rejecting this and the other compilers have an issue.

[Bug fortran/100183] Segmentation fault at runtime when passing an internal procedure as argument

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

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

--- Comment #6 from Iain Sandoe  ---
(In reply to anlauf from comment #5)
> (In reply to Iain Sandoe from comment #4)
> > gcc304 is the Apple M1 machine.  The GCC support there is highly
> > experimental and not in master -- please note that there are known issues
> > with the implementation.
> > 
> > see : https://github.com/iains/gcc-darwin-arm64/issues
> 
> So rather a target than a fortran issue?

The fortran folks have fixed a number of cases recently where the FE was
providing bad information to the ME .. which doesn't cause problems to most
targets, but did to aarch64-darwin.  I cannot rule out that this is another
case in that category (but not had a chance to analyse it yet).

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

[juergen.reuter at desy dot de via Gcc-bugs]

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

--- Comment #2 from Jürgen Reuter  ---
I just check, with --disable-bootstrap, gcc compiles to the end. Just the
checksums of the object files for bootstrap between stage 2 and 3 don't agree.

[Bug fortran/100183] Segmentation fault at runtime when passing an internal procedure as argument

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
 Ever confirmed|0   |1
   Last reconfirmed||2021-04-29

--- Comment #5 from anlauf at gcc dot gnu.org ---
(In reply to Iain Sandoe from comment #4)
> gcc304 is the Apple M1 machine.  The GCC support there is highly
> experimental and not in master -- please note that there are known issues
> with the implementation.
> 
> see : https://github.com/iains/gcc-darwin-arm64/issues

So rather a target than a fortran issue?

[Bug c++/100335] Using statement of a ref-qualified method from base class: method not callable on derived object

[webrown.cpp at gmail dot com via Gcc-bugs]

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

W E Brown  changed:

   What|Removed |Added

 CC||webrown.cpp at gmail dot com

--- Comment #1 from W E Brown  ---
According to C++20 [over.load]/2.3:

"Member function declarations ... cannot be overloaded if any of them, but not
all, have a ref-qualifier"

Therefore, the above example's Base class compiles because each of its
overloaded member functions has a ref-qualifier.  However, Derived::method is
not ref-qualified, so treating it as an overload of those Base functions would
violate the above-cited passage.

Accordingly, unless I've overlooked some exception to this rule, I respectfully
suggest this issue be closed as invalid.

[Bug fortran/100275] ICE in gfc_build_null_descriptor, at fortran/trans-array.c:417

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-04-29

[Bug libgcc/100341] build fails of error: '__LIBGCC_DF_EPSILON__' undeclared (first use in this function) for mingw-w64

[unlvsur at live dot com via Gcc-bugs]

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

cqwrteur  changed:

   What|Removed |Added

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

--- Comment #2 from cqwrteur  ---
close

[Bug libgcc/100341] build fails of error: '__LIBGCC_DF_EPSILON__' undeclared (first use in this function) for mingw-w64

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #1 from cqwrteur  ---
it looks we need to rebuild cross compiler before Canadian cross-compile
because the cross compiler itself might not provide the macros we need.

[Bug other/100338] [11/12 regression] Python error running test case after r11-2720

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

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

--- Comment #2 from seurer at gcc dot gnu.org ---
On a system where things fail (Ubuntu 20.04.1):

Python 2.7.18
GNU gdb (GDB) 11.0.50.20201107-git


On a working system (Ubuntu 18.04.5):

Python 2.7.17
GNU gdb (Ubuntu 8.1.1-0ubuntu1) 8.1.1

[Bug target/100342] New: [10/11 Regression] wrong code with -O2 -fno-dse -fno-forward-propagate -mno-sse2

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 100342
   Summary: [10/11 Regression] wrong code with -O2 -fno-dse
-fno-forward-propagate -mno-sse2
   Product: gcc
   Version: 11.1.1
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

Created attachment 50712
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50712=edit
semi-reduced testcase

I am failing to further reduce the testcase. I checked the code and I think the
behavior is fully defined. Also I am unable to find out what exactly goes
wrong; please close the PR if you don't want to spend time on this.

On master, it stopped failing between r12-100 (BAD) and r12-159 (OK); but it
might have been just papered over.

$ x86_64-pc-linux-gnu-gcc -O2 -fno-dse -fno-forward-propagate -mno-sse2
testcase.c -Wno-psabi
$ ./a.out 
Aborted

$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-11-branch/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-11-branch/binary-11-branch-20210427124134-gfb7c736c2f1-checking-yes-rtl-df-extra-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/11.1.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-11-branch//configure --enable-languages=c,c++
--disable-nls --enable-checking=yes,rtl,df,extra --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-libsanitizer
--disable-libstdcxx-pch
--prefix=/repo/gcc-11-branch//binary-11-branch-20210427124134-gfb7c736c2f1-checking-yes-rtl-df-extra-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.1.1 20210427 (GCC)

[Bug preprocessor/82359] #line does not allow C++14 quotes in number

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

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

Joseph S. Myers  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |12.0

--- Comment #5 from Joseph S. Myers  ---
Fixed for GCC 12.

[Bug libgcc/100341] New: build fails of error: '__LIBGCC_DF_EPSILON__' undeclared (first use in this function) for mingw-w64

[unlvsur at live dot com via Gcc-bugs]

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

Bug ID: 100341
   Summary: build fails of error: '__LIBGCC_DF_EPSILON__'
undeclared (first use in this function) for mingw-w64
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: unlvsur at live dot com
  Target Milestone: ---

Created attachment 50711
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50711=edit
error message

It looks like it is this patch that breaks the code
https://github.com/gcc-mirror/gcc/commit/54f0224d55a1b56dde092460ddf76913670e6efc#diff-b39028e53782355458efc72ceb1bd540350adb73d0db52e04372045adbd50d39

[Bug preprocessor/82359] #line does not allow C++14 quotes in number

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Joseph Myers :

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

commit r12-302-gb24d8acbfffe30f40e280f11f23adac81b1e7f0c
Author: Joseph Myers 
Date:   Thu Apr 29 19:50:47 2021 +

preprocessor: Handle digit separators in #line [PR82359]

As reported in bug 82359, the preprocessor does not allow C++ digit
separators in the line number in a #line directive, despite the
standard syntax for that directive using digit-sequence which allows
digit separators.

There is some confusion in that bug about whether C++ is meant to
allow digit separators there or not, but the last comment there
suggests they are meant to be allowed, and the version of digit
separators accepted for C2X at the March meeting explicitly mentions
digit separators in the #line specification to avoid any ambiguity
there.

This patch thus adds code to handle digit separators in the line
number in #line, as part of the preparation for enabling digit
separators in C2X mode.  The code changed does not contain any
conditionals for whether digit separators are supported in the chosen
language version, because that was handled earlier in pp-number lexing
and if they aren't supported they won't appear in the string passed to
that function.  It does however make sure not to allow adjacent digit
separators because those are only handled at a later stage of lexing
at present.  (Problems with how certain source character sequences
involving digit separators that don't actually match the pp-number
syntax get lexed as a pp-number and only diagnosed later, if at all,
are bugs 83873 and 97604, to be addressed separately.)

Making the change in this location will have the effect of allowing
digit separators in the "#   " form of
directive as well as #line; I don't think that's a problem.

Bootstrapped with no regressions for x86_64-pc-linux-gnu.

libcpp/
PR preprocessor/82359
* directives.c (strtolinenum): Handle digit separators.

gcc/testsuite/
PR preprocessor/82359
* g++.dg/cpp1y/digit-sep-line.C,
g++.dg/cpp1y/digit-sep-line-neg.C: New tests.

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

[juergen.reuter at desy dot de via Gcc-bugs]

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

--- Comment #1 from Jürgen Reuter  ---
After update to macOS Big Sur 11.3 with XCode 12.5 and Apple Clang
clang-1205.0.22.9, bootstrap doesn't work any more:
Comparing stages 2 and 3
warning: gcc/cc1obj-checksum.o differs
warning: gcc/cc1objplus-checksum.o differs
Bootstrap comparison failure!
gcc/tree-ssa-operands.o differs
gcc/tree-ssanames.o differs
[...]
lib/libz_a-deflate.o differs
zlib/libz_a-gzread.o differs
zlib/libz_a-inflate.o differs
zlib/libz_a-crc32.o differs
zlib/libz_a-inftrees.o differs

[Bug bootstrap/100340] New: Bootstrap fails with Clang 12.0.5 (XCode 12.5)

[juergen.reuter at desy dot de via Gcc-bugs]

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

Bug ID: 100340
   Summary: Bootstrap fails with Clang 12.0.5 (XCode 12.5)
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: juergen.reuter at desy dot de
  Target Milestone: ---

[Bug c++/100339] [8/9/10/11/12 Regression] Bogus "should have been declared inside" error with friend

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

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

Marek Polacek  changed:

   What|Removed |Added

 CC||nathan at gcc dot gnu.org
   Keywords||rejects-valid
Summary|Bogus "should have been |[8/9/10/11/12 Regression]
   |declared inside" error with |Bogus "should have been
   |friend  |declared inside" error with
   ||friend
   Priority|P3  |P2
   Target Milestone|--- |8.5

[Bug c++/100339] New: Bogus "should have been declared inside" error with friend

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

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

Bug ID: 100339
   Summary: Bogus "should have been declared inside" error with
friend
   Product: gcc
   Version: 11.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: ---

template
void fn (T);

class C {
  friend void ::fn(int);
  friend void ::fn<>(double);
  friend void ::fn(double *);
};

gives:

$ ./cc1plus -quiet q.C
q.C:5:23: error: ‘void fn(int)’ should have been declared inside ‘::’
5 |   friend void ::fn(int);
  |   ^

but ::fn(int) should refer to an instantiation of fn.

Started with r249385.

[Bug other/100338] [11/12 regression] Python error running test case after r11-2720

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

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

--- Comment #1 from Jonathan Wakely  ---
Some of these tests are sensitive to GDB and Python versions. Do they differ
between machines?

I'll take a look at this tomorrow.

[Bug other/100338] New: [11 regression] Python error running test case after r11-2720

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

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

Bug ID: 100338
   Summary: [11 regression] Python error running test case after
r11-2720
   Product: gcc
   Version: 11.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:91e6226f880b048275a7ceedef716e159c7cefd9, r11-2720
make  -k check RUNTESTFLAGS="xmethods.exp=libstdc++-xmethods/unique_ptr.cc"
FAIL: libstdc++-xmethods/unique_ptr.cc
# of expected passes1
# of unexpected failures1


commit 91e6226f880b048275a7ceedef716e159c7cefd9 (HEAD, refs/bisect/bad)
Author: Jonathan Wakely 
Date:   Fri Aug 7 17:13:56 2020 +0100

libstdc++: Remove inheritance from elements in std::tuple


This problem occurs on just one of our LE systems and I am not sure why.  Can
this be related to PR90520?  The error is different.


PASS: libstdc++-xmethods/unique_ptr.cc execution test
Spawning: gdb -nw -nx -quiet -batch -ex "python print(gdb.type_printers)"
spawn gdb -nw -nx -quiet -batch -ex python print(gdb.type_printers)^M
[]^M
spawn gdb -nx -nw -quiet -batch -x unique_ptr.gdb^M
Breakpoint 1 at 0x1afc: file
/home/seurer/gcc/git/gcc-11-test/libstdc++-v3/testsuite/libstdc++-xmethods/unique_ptr.cc,
line 60.^M
skipping: Breakpoint 1 at 0x1afc: file
/home/seurer/gcc/git/gcc-11-test/libstdc++-v3/testsuite/libstdc++-xmethods/unique_ptr.cc,
line 60.^M
^M
skipping: ^M
Breakpoint 1, main () at
/home/seurer/gcc/git/gcc-11-test/libstdc++-v3/testsuite/libstdc++-xmethods/unique_ptr.cc:60^M
skipping: Breakpoint 1, main () at
/home/seurer/gcc/git/gcc-11-test/libstdc++-v3/testsuite/libstdc++-xmethods/unique_ptr.cc:60^M
60return 0;  // Mark SPOT^M
skipping: 60  return 0;  // Mark SPOT^M
>FromTo  Syms Read   Shared Object Library^M
0x77fa13e0  0x77fd52c8  Yes (*) /lib64/ld64.so.2^M
skipping: FromTo  Syms Read   Shared Object
Library^M
skipping: 0x77fa13e0  0x77fd52c8  Yes (*)
/lib64/ld64.so.2^M
0x77d9c840  0x77ef74c8  Yes
/home/seurer/gcc/git/build/gcc-11-test/powerpc64le-unknown-linux-gnu/./libstdc++-v3/src/.libs/libstdc++.so.6^M
0x77b8fc20  0x77c44de0  Yes (*)
/lib/powerpc64le-linux-gnu/libm.so.6^M
0x77b42fc0  0x77b5091c  Yes
/home/seurer/gcc/git/build/gcc-11-test/gcc/libgcc_s.so.1^M
0x77927680  0x77ab7af4  Yes (*)
/lib/powerpc64le-linux-gnu/libc.so.6^M
(*): Shared library is missing debugging information.^M
skipping: 0x77d9c840  0x77ef74c8  Yes
/home/seurer/gcc/git/build/gcc-11-test/powerpc64le-unknown-linux-gnu/./libstdc++-v3/src/.libs/libstdc++.so.6^M
skipping: 0x77b8fc20  0x77c44de0  Yes (*)
/lib/powerpc64le-linux-gnu/libm.so.6^M
skipping: 0x77b42fc0  0x77b5091c  Yes
/home/seurer/gcc/git/build/gcc-11-test/gcc/libgcc_s.so.1^M
skipping: 0x77927680  0x77ab7af4  Yes (*)
/lib/powerpc64le-linux-gnu/libc.so.6^M
skipping: (*): Shared library is missing debugging information.^M
Python Exception  Attempt to take contents of a non-pointer
value.: ^M
skipping: Python Exception  Attempt to take contents of a
non-pointer value.: ^M
unique_ptr.gdb:10: Error in sourced command file:^M
Error while executing Python code.^M
FAIL: libstdc++-xmethods/unique_ptr.cc

[Bug c++/51344] [4.4/4.5/4.6/4.7 regression] cc1plus hangs when compiling

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

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

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

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

commit r12-299-ga0fdff3cf33f72848d3f894272431a5d49fe6a16
Author: Jason Merrill 
Date:   Fri Feb 5 10:36:49 2021 -0500

c++: Fix friend attributes [PR51344]

51344 was a problem with calling save_template_attributes twice for the
same
friend function: once from do_friend and once from grokmethod.  The 2012
patch for the bug avoided creating an infinite loop when this happens, but
it's better to avoid the duplication in the first place.  This also
restores
the dependent attributes to the beginning of the attribute list, as
originally intended.  And then apply_late_template_attributes can avoid
copying the non-dependent attributes.

gcc/cp/ChangeLog:

PR c++/51344
* decl2.c (grokfield): Call cplus_decl_attributes for friend.
(save_template_attributes): Use chainon.
* friend.c (do_friend): Remove attrlist parm.
* cp-tree.h (do_friend): Adjust.
* class.c (add_implicitly_declared_members): Adjust.
* decl.c (grokdeclarator): Adjust.
* pt.c (apply_late_template_attributes): Optimize.

[Bug c++/97974] [9/10 Regression] ICE tree check: expected overload, have function_decl in get_class_binding_direct, at cp/name-lookup.c:1332

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

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

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

https://gcc.gnu.org/g:58a92b789a77cdade1f41800efebf6e0686f9982

commit r12-298-g58a92b789a77cdade1f41800efebf6e0686f9982
Author: Jason Merrill 
Date:   Sat Apr 10 14:00:15 2021 -0400

c++: ICE with anonymous union [PR97974]

While working on the GCC 11 patch, it occurred to me that we could move
the errors about invalid members from finish_struct_anon_r to here, so we
properly get a diagnostic in g++.law/union4.C.

gcc/cp/ChangeLog:

PR c++/97974
* class.c (finish_struct_anon_r): Drop complain parm.
Remove non-field diagnostic.
(finish_struct_anon): Adjust.
* decl.c (fixup_anonymous_aggr): Move non-field diagnostic here.

gcc/testsuite/ChangeLog:

PR c++/97974
* g++.old-deja/g++.law/union4.C: Add expected diagnostic.

[Bug debug/100304] [11/12 Regression] -fcompare-debug failure (length) with custom flags

[zsojka at seznam dot cz via Gcc-bugs]

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

--- Comment #3 from Zdenek Sojka  ---
(In reply to Jakub Jelinek from comment #1)
> Can't reproduce this one.

Were you testing with a clean build, or did you have PR100303 fix applied?
On master, it stopped failing for me between r12-285 (BAD) and r12-293 (OK).

[Bug target/100331] 128 bit arithmetic --- suboptimal after shifting when referencing other variables

[mbenfield at google dot com via Gcc-bugs]

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

Michael Benfield  changed:

   What|Removed |Added

 CC||mbenfield at google dot com

--- Comment #2 from Michael Benfield  ---
Given code with unused variables/parameters of some struct type in C that warns
for `-Wunused-variable`, the identical code warns in C++. But the same is not
true of `-Wunused-but-set-variable`: code that warns in C will not warn in C++.
This seems inconsistent to me; I suspect the code should warn in both
languages.

Similar comments apply to `-Wunused-parameter` and
`-Wunused-but-set-parameter`. 

Given this code in both gcc-test.c and gcc-test.cpp:

struct S { 
  int x;
};

void f_unused_but_set(struct S p1) {
  struct S s;
  p1 = s; 

  struct S v1;
  v1 = s;
} 

void f_unused(struct S p2) { 
  struct S v2; 
}

and compiling with `gcc -fsyntax-only -Wunused -Wextra gcc-test.c`, for
gcc-test.c, we get warnings for all of p1, v1, p2, v2, while for gcc-test.cpp
we get warnings only for p2 and v2.

[Bug c++/68942] overly strict use of deleted function before argument-dependent lookup (ADL)

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

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

Patrick Palka  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |12.0

--- Comment #3 from Patrick Palka  ---
Fixed for GCC 12, thanks for the bug report.

[Bug c++/68942] overly strict use of deleted function before argument-dependent lookup (ADL)

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

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

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

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

commit r12-295-gefeca0ac4155b76ce713155f190422aac20537c5
Author: Patrick Palka 
Date:   Thu Apr 29 13:43:00 2021 -0400

c++: Overeager use of deleted function before ADL [PR68942]

Here, at template definition time, ordinary name lookup for 'foo(t)'
finds only the deleted function, and so we form a CALL_EXPR thereof.
Later at instantiation time, when initially substituting into this
CALL_EXPR with T=N::A, we end up calling mark_used on this deleted
function (since it's the only function in the overload set), triggering
a bogus "use of deleted function error", before we get to augment the
overload set via ADL.

This patch fixes this issue by using the tf_conv flag to disable
mark_used during the initial substitution into the callee of a
CALL_EXPR when KOENIG_P, since at this point we're still figuring out
which functions are candidates.

gcc/cp/ChangeLog:

PR c++/68942
* pt.c (tsubst_copy_and_build) : When KOENIG_P,
set tf_conv during the initial substitution into the function.

gcc/testsuite/ChangeLog:

PR c++/68942
* g++.dg/template/koenig12.C: New test.

[Bug tree-optimization/94589] Optimize (i<=>0)>0 to i>0

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

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

--- Comment #17 from Jakub Jelinek  ---
Created attachment 50710
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50710=edit
gcc12-pr94589-wip.patch

WIP patch that just matches those spaceship comparisons followed by single use
comparison of that with -1/0/1, but doesn't yet perform any of the
optimizations.

[Bug c++/94102] Variadic template deduction guide issue - error: 'In instantiation of'

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #5 from Marek Polacek  ---
Reduced test added.

[Bug c++/94102] Variadic template deduction guide issue - error: 'In instantiation of'

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

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

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

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

commit r12-294-gf24702258fc78ac37b3e8154d76239cccd30c422
Author: Marek Polacek 
Date:   Thu Apr 29 13:30:39 2021 -0400

c++: Add testcase for already fixed PR [PR94102]

We correctly accept this testcase since r11-1571.

gcc/testsuite/ChangeLog:

PR c++/94102
* g++.dg/cpp1z/class-deduction87.C: New test.

[Bug target/99401] Rebuilding the compiler with itself fails at -O2

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

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

Brecht Sanders  changed:

   What|Removed |Added

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

--- Comment #8 from Brecht Sanders  
---
Recently released version 11.1.0 does build for Windows 32-bit with MinGW-w64
without issues.

[Bug fortran/100337] New: Should be able to pass non-present optional arguments to CO_BROADCAST

[everythingfunctional at protonmail dot com via Gcc-bugs]

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

Bug ID: 100337
   Summary: Should be able to pass non-present optional arguments
to CO_BROADCAST
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: everythingfunctional at protonmail dot com
  Target Milestone: ---

Attempting to write a CO_BROADCAST wrapper for a derived type, I found that
passing optional arguments to CO_BROADCAST caused a segfault if the arguments
were not present. This should be allowed. See the following minimal example

module iso_varying_string
implicit none

type :: varying_string
character(len=1), allocatable :: characters(:)
contains
procedure :: co_broadcast => co_broadcast_varying_string
end type
contains
subroutine co_broadcast_varying_string(a, source_image, stat, errmsg)
class(varying_string), intent(inout) :: a
integer, intent(in) :: source_image
integer, intent(out), optional :: stat
character(len=*), intent(inout), optional :: errmsg

integer :: string_length

if (this_image() == source_image) string_length = size(a%characters)

call co_broadcast(string_length, source_image, stat, errmsg)

if (present(stat)) then
if (stat /= 0) return
end if

if (this_image() /= source_image) then
allocate(a%characters(string_length))
end if

call co_broadcast(a%characters, source_image, stat, errmsg)
end subroutine
end module

program main
use iso_varying_string, only: varying_string

implicit none

character(len=*), parameter :: MESSAGE = "Hello, World!"
integer :: i
type(varying_string) :: the_string

if (this_image() == 1) the_string%characters = [(MESSAGE(i:i), i = 1,
len(MESSAGE))]
call the_string%co_broadcast(1)
print *, the_string%characters
end program

Compiling and executing with gfortran produces the following:

$ gfortran -fcoarray=single -g example.f90
$ ./a.out 

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Backtrace for this error:
#0  0x7fed85487d01 in ???
#1  0x7fed85486ed5 in ???
#2  0x7fed852be94f in ???
#3  0x55cd33d21683 in __iso_varying_string_MOD_co_broadcast_varying_string
at /home/brad/tmp/co_broadcast_optional/example.f90:20
#4  0x55cd33d21872 in MAIN__
at /home/brad/tmp/co_broadcast_optional/example.f90:43
#5  0x55cd33d21915 in main
at /home/brad/tmp/co_broadcast_optional/example.f90:35
zsh: segmentation fault (core dumped)  ./a.out

Note that using opencoarrays this program works, as follows:

$ caf example.f90 
$ cafrun -n 2 ./a.out 
 Hello, World!
 Hello, World!

[Bug target/46250] ICE: in extract_insn, at recog.c:2110 (unrecognizable insn) with -fPIC -mcmodel=large and __thread variable

[zsojka at seznam dot cz via Gcc-bugs]

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

Zdenek Sojka  changed:

   What|Removed |Added

  Known to work||5.5.0, 6.5.0, 7.5.0

--- Comment #7 from Zdenek Sojka  ---
No longer fails for me since at least 5.5.0.

[Bug target/58067] ICE in GFortran recog.c:2158

[zsojka at seznam dot cz via Gcc-bugs]

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

Zdenek Sojka  changed:

   What|Removed |Added

 CC||zsojka at seznam dot cz

--- Comment #13 from Zdenek Sojka  ---
Even the original fortran testcase does not fail in 8.3.1, 9.3.0, 10.3.0,
11.1.0 for me.

[Bug libstdc++/100334] atomic::notify_one() sometimes wakes wrong thread

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

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

--- Comment #4 from Thomas Rodgers  ---
This analysis is likely correct, except for -

"- protect from spurious wakeups in __waiter_pool::_M_do_wait by rechecking if
the value has changed from old, if not then wait again"

An earlier version of this code did this, but was subject to ABA problems, and 
the standard doesn't require that we do this -

"(23.3) — Blocks until it is unblocked by an atomic notifying operation or is
unblocked spuriously."

[Bug debug/100303] [11 Regression] -fcompare-debug failure (length) with -O -fno-dce -ftracer

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

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

Summary|[11/12 Regression]  |[11 Regression]
   |-fcompare-debug failure |-fcompare-debug failure
   |(length) with -O -fno-dce   |(length) with -O -fno-dce
   |-ftracer|-ftracer

--- Comment #4 from rsandifo at gcc dot gnu.org  
---
Fixed on trunk so far.

[Bug debug/100303] [11/12 Regression] -fcompare-debug failure (length) with -O -fno-dce -ftracer

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Richard Sandiford :

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

commit r12-292-gc97351c0cf4872cc0e99e73ed17fb16659fd38b3
Author: Richard Sandiford 
Date:   Thu Apr 29 17:24:57 2021 +0100

rtl-ssa: Fix -fcompare-debug failure [PR100303]

This patch fixes an oversight in the handling of debug instructions
in rtl-ssa.  At the moment (and whether this is a good idea or not
remains to be seen), we maintain a linear RPO sequence of definitions
and non-debug uses.  If a register is defined more than once, we use
a degenerate phi to reestablish a previous definition where necessary.

However, debug instructions shouldn't of course affect codegen,
so we can't create a new definition just for them.  In those situations
we instead hang the debug use off the real definition (meaning that
debug uses do not follow a linear order wrt definitions).  Again,
it remains to be seen whether that's a good idea.

The problem in the PR was that we weren't taking this into account
when increasing (or potentially increasing) the live range of an
existing definition.  We'd create the phi even if it would only
be used by debug instructions.

The patch goes for the simple but inelegant approach of passing
a bool to say whether the use is a debug use or not.  I imagine
this area will need some tweaking based on experience in future.

gcc/
PR rtl-optimization/100303
* rtl-ssa/accesses.cc (function_info::make_use_available): Take a
boolean that indicates whether the use will only be used in
debug instructions.  Treat it in the same way that existing
cross-EBB debug references would be handled if so.
(function_info::make_uses_available): Likewise.
* rtl-ssa/functions.h (function_info::make_uses_available): Update
prototype accordingly.
(function_info::make_uses_available): Likewise.
* fwprop.c (try_fwprop_subst): Update call accordingly.

[Bug c++/100288] [11/12 Regression] g++-11 internal error and fails to precompile a concept

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

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

Patrick Palka  changed:

   What|Removed |Added

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

[Bug fortran/92482] BIND(C) with array-descriptor mishandled for type character

[ivan.tubert-brohman at schrodinger dot com via Gcc-bugs]

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

Ivan Tubert-Brohman  changed:

   What|Removed |Added

 CC||ivan.tubert-brohman@schrodi
   ||nger.com

--- Comment #3 from Ivan Tubert-Brohman  ---
I also encountered this issue. I was trying the example given by Metcalf et al.
on _Modern Fortran Explained_ (2018), section 21.4, "Assumed character length":

  interface
 subroutine err_msg(string) bind(c)
use iso_c_binding
character(*, c_char), intent(in):: string
 end subroutine err_msg
  end interface

The example worked with the Intel Fortran compiler, but with gfortran 11.1 I
get

  Error: Character argument ‘string’ at (1) must be length 1 because procedure
‘err_msg’ is BIND(C)

I only comment to confirm that both a famous author and an alternative compiler
implementation agree with the interpretation of the standard that this should
work. :-)

[Bug tree-optimization/94589] Optimize (i<=>0)>0 to i>0

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

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

--- Comment #16 from Jakub Jelinek  ---
Writing a phiopt patch now.

[Bug target/100336] New: file trunk/gcc/config/i386/i386-isa.def doesn't get installed ok ?

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 100336
   Summary: file trunk/gcc/config/i386/i386-isa.def doesn't get
installed ok ?
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

I had a go a couple of days ago of compiling the new Linux kernel-5.12
with x86_64 gcc dated 20210426. I got this error:

/home/dcb/gcc/results.20210426/lib/gcc/x86_64-pc-linux-gnu/12.0.0/plugin/include/config/i386/i386.h:2197:10:
fatal error: i386-isa.def: No such file or directory

I bodged it by copying the relevant file out of the gcc trunk development tree 
into the results directory:

$ cp /home/dcb/gcc/trunk.git/gcc/config/i386/i386-isa.def
/home/dcb/gcc/results.20210429.asan.ubsan/lib/gcc/x86_64-pc-linux-gnu/12.0.0/plugin/include/config/i386/
$

My best guess is that the "make install" should do this copy.

[Bug bootstrap/100327] [12 regression] bootstrap failure after r12-228

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

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

Michael Meissner  changed:

   What|Removed |Added

  Attachment #50708|0   |1
is obsolete||
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2021-04-29
   Assignee|unassigned at gcc dot gnu.org  |meissner at gcc dot 
gnu.org

--- Comment #6 from Michael Meissner  ---
Created attachment 50709
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50709=edit
Use FLT128 constants for complex KFmode division.

This patch uses the FLT128 constants that are already defined for building
_divkf3.c instead of trying expect the constants to be defined as __LIBGCC_KF. 
The __LIBGCC_KF constants are not defined.

I am starting a build now with this patch.

[Bug target/100321] [OpenMP][nvptx, SIMT] (Con't) Reduction fails with optimization and 'loop'/'for simd' but not with 'for'

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

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

--- Comment #4 from Tom de Vries  ---
During lower_rec_input_clauses in omp-low.c, the reduction clause is handled:
...
case OMP_CLAUSE_REDUCTION:
case OMP_CLAUSE_IN_REDUCTION:
  /* OpenACC reductions are initialized using the   
 GOACC_REDUCTION internal function.  */
  if (is_gimple_omp_oacc (ctx->stmt))
break;
  if (OMP_CLAUSE_REDUCTION_PLACEHOLDER (c))
...

AFAICT, the problem is that the the SIMT handling code is added only in the
!OMP_CLAUSE_REDUCTION_PLACEHOLDER (c) case.

For this test-case, the OMP_CLAUSE_REDUCTION_PLACEHOLDER (c) path is taken
instead.

So, something like this reflects the current state:
...
diff --git a/gcc/omp-low.c b/gcc/omp-low.c
index 7b122059c6e..a0561800977 100644
--- a/gcc/omp-low.c
+++ b/gcc/omp-low.c
@@ -6005,6 +6005,11 @@ lower_rec_input_clauses (tree clauses, gimple_seq
*ilist, gimple_seq *dlist,
  tree placeholder = OMP_CLAUSE_REDUCTION_PLACEHOLDER (c);
  gimple *tseq;
  tree ptype = TREE_TYPE (placeholder);
+ if (sctx.is_simt)
+   {
+ sorry ("SIMT not fully implemented");
+ abort ();
+   }
  if (cond)
{
  x = error_mark_node;
...

[Bug c++/95486] ICE for alias CTAD with non-dependent argument and constrained constructor

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

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

--- Comment #12 from Patrick Palka  ---
(In reply to Johel Ernesto Guerrero Peña from comment #11)
> Thank you. But the first CE link: https://godbolt.org/z/cPWdGW, and with the
> addition in Comment 2: https://godbolt.org/z/Gezh5h5W4, they still ICE.

Hmm, these CE links are still using 10.1.  These examples should compile fine
with a recent GCC built from the 10 release branch (which I don't think CE
provides unfortunately).

[Bug target/100321] [OpenMP][nvptx, SIMT] (Con't) Reduction fails with optimization and 'loop'/'for simd' but not with 'for'

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

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

--- Comment #3 from Tom de Vries  ---
C example:
...
/* { dg-additional-options "-foffload=-latomic" } */

#include 

struct s
{
  int i;
};

#pragma omp declare reduction(+: struct s: omp_out.i += omp_in.i)

int
main (void)
{
  const int N0 = 32768;

  printf ("Expected: %d\n", N0);

  struct s counter_N0 = { 0 };
#pragma omp target
#pragma omp for simd reduction(+: counter_N0)
  for (int i0 = 0 ; i0 < N0 ; i0++ )
counter_N0.i += 1;
  printf ("Got : %d\n", counter_N0.i);

  return 0;
}
...

[Bug target/100312] __builtin_ia32_maskloadpd256 and friends should be pure

[ubizjak at gmail dot com via Gcc-bugs]

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

Uroš Bizjak  changed:

   What|Removed |Added

   Assignee|rguenth at gcc dot gnu.org |ubizjak at gmail dot com
 Target|x86_64-*-* i?86-*-* |x86
   Target Milestone|--- |12.0
 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #4 from Uroš Bizjak  ---
Fixed.

[Bug target/100085] Bad code for union transfer from __float128 to vector types

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

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

--- Comment #5 from Steven Munroe  ---
Any progress on this?

[Bug bootstrap/100327] [12 regression] bootstrap failure after r12-228

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

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

--- Comment #5 from Michael Meissner  ---
Unfortunately the patch does not work because there aren't suffixes for IFmode
and KFmode.

[Bug c++/100335] New: Using statement of a ref-qualified method from base class: method not callable on derived object

[Daniel.Withopf at web dot de via Gcc-bugs]

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

Bug ID: 100335
   Summary: Using statement of a ref-qualified method from base
class: method not callable on derived object
   Product: gcc
   Version: 10.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Daniel.Withopf at web dot de
  Target Milestone: ---

The following code examples defines 2 ref-qualified method with identical names
in a base class (const& and const&&). Derived also defines a (non-const) method
with the same name and adds a "using Base::method;"

With all gcc Versions I tested (10.3, 9.3, 8.3, 7.5), the compilation with
--std=c++11 or --std=c++14 fails if the method in the derived class does not
have a ref-qualifier.

class Base {
public:
  void method() const&& {}
  void method() const& {}
};

class Derived : public Base {
public:
  using Base::method;
  // this leads to a compiler error
  void method() {}

  // with a ref-qualifier the code is compiling
  //  void method() & {}
};

int main() {
const Derived test;
test.method();
}

I believe that this is incorrect and the code should also compile when the
method in the Derived class has no ref-qualifier.

[Bug target/100312] __builtin_ia32_maskloadpd256 and friends should be pure

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Uros Bizjak :

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

commit r12-290-gfd5d57946036c967dae292330fa0aa856a58fb4b
Author: Uros Bizjak 
Date:   Thu Apr 29 16:43:33 2021 +0200

i386: Mark x86 masked load builtins pure [PR100312]

Mark x86 AVX and AVX2 masked load builtins pure to enable dead code
elimination and more appropriate alias analysis.

2021-04-29  Uroš Bizjak  
Richard Biener  
gcc/
PR target/100312
* config/i386/i386-builtin.def (IX86_BUILTIN_MASKLOADPD)
(IX86_BUILTIN_MASKLOADPS, IX86_BUILTIN_MASKLOADPD256)
(IX86_BUILTIN_MASKLOADPS256, IX86_BUILTIN_MASKLOADD)
(IX86_BUILTIN_MASKLOADQ, IX86_BUILTIN_MASKLOADD256)
(IX86_BUILTIN_MASKLOADQ256): Move from SPECIAL_ARGS
to PURE_ARGS category.
* config/i386/i386-builtins.c (ix86_init_mmx_sse_builtins):
Handle PURE_ARGS category.
* config/i386/i386-expand.c (ix86_expand_builtin): Ditto.

[Bug libstdc++/100334] atomic::notify_one() sometimes wakes wrong thread

[m.cencora at gmail dot com via Gcc-bugs]

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

--- Comment #3 from m.cencora at gmail dot com ---
If my analysis is correct then:
 - we need to force __all = true param in __waiter_pool_base::_M_notify,
 - protect from spurious wakeups in __waiter_pool::_M_do_wait by rechecking if
the value has changed from old, if not then wait again

[Bug bootstrap/100327] [12 regression] bootstrap failure after r12-228

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

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

Michael Meissner  changed:

   What|Removed |Added

 CC||meissner at gcc dot gnu.org

--- Comment #4 from Michael Meissner  ---
Created attachment 50708
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50708=edit
patch to define floating point constants for KFmode and IFmode.

I am about to kick off a bootstrap with this patch.

[Bug libstdc++/100334] atomic::notify_one() sometimes wakes wrong thread

[m.cencora at gmail dot com via Gcc-bugs]

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

--- Comment #2 from m.cencora at gmail dot com ---
I have adapted the test to gcc trunk, but I am not entirely sure it is correct,
because I don't have gcc trunk locally, I was just testing this on wandbox.org

The problem is even bigger here, because it seems that besides wrong thread is
woken up,
also wrong std::atomic instance finishes the wait() call!

#include 
#include 
#include 
#include 
#include 
#include 

void verify(bool cond, std::source_location loc =
std::source_location::current())
{
if (!cond)
{
std::cout << "Failed at line " << loc.line() << '\n';
//std::abort();
}
}


void emptyDeleter(void *)
{}

template 
struct atomics_sharing_same_waiter
{
   std::atomic tmp[49 * 4] = {};
   std::shared_ptr> a[4] = {
  { [0], emptyDeleter },
  { [16 * 4], emptyDeleter },
  { [32 * 4], emptyDeleter },
  { [48 * 4], emptyDeleter }
   };
};

constexpr unsigned key(void * a)
{
constexpr uintptr_t __ct = 16;
return (uintptr_t(a) >> 2) % __ct;
}

int main()
{
// all atomic share the same waiter
atomics_sharing_same_waiter atomics;
for (auto& atom : atomics.a)
{
   atom->store(0);
}

std::cout << "atom0 " << atomics.a[0].get() << " key " <<
key(atomics.a[0].get()) << '\n';
std::cout << "atom1 " << atomics.a[1].get() << " key " <<
key(atomics.a[1].get()) << '\n';
std::cout << "atom2 " << atomics.a[2].get() << " key " <<
key(atomics.a[2].get()) << '\n';
std::cout << "atom3 " << atomics.a[3].get() << " key " <<
key(atomics.a[3].get()) << '\n';


verify(::__detail::__waiter_pool_base::_S_for(reinterpret_cast(atomics.a[0].get())) == 
   ::__detail::__waiter_pool_base::_S_for(reinterpret_cast(atomics.a[1].get(;

auto fut0 = std::async(std::launch::async, [&] {
atomics.a[0]->wait(0);
});

auto fut1 = std::async(std::launch::async, [&] {
atomics.a[1]->wait(0);
});

auto fut2 = std::async(std::launch::async, [&] {
atomics.a[2]->wait(0);
});

auto fut3 = std::async(std::launch::async, [&] {
atomics.a[3]->wait(0);
});

// make sure the all threads already await
std::this_thread::sleep_for(std::chrono::milliseconds{100});

atomics.a[2]->store(1);
atomics.a[2]->notify_one(); // changing to notify_all() doesn't help on gcc
trunk

verify(std::future_status::timeout ==
fut0.wait_for(std::chrono::milliseconds{100}));
verify(atomics.a[0]->load() == 0);
verify(std::future_status::timeout ==
fut1.wait_for(std::chrono::milliseconds{100}));
verify(atomics.a[1]->load() == 0);
verify(std::future_status::ready ==
fut2.wait_for(std::chrono::milliseconds{100}));
verify(atomics.a[2]->load() == 1);
verify(std::future_status::timeout ==
fut3.wait_for(std::chrono::milliseconds{100}));
verify(atomics.a[3]->load() == 0);

atomics.a[0]->store(1);
atomics.a[0]->notify_one();
atomics.a[1]->store(1);
atomics.a[1]->notify_one();
atomics.a[3]->store(1);
atomics.a[3]->notify_one();
}

[Bug target/99401] Rebuilding the compiler with itself fails at -O2

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

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

--- Comment #7 from Jakub Jelinek  ---
Maybe dup of PR99872 ?

[Bug libstdc++/100334] atomic::notify_one() sometimes wakes wrong thread

[m.cencora at gmail dot com via Gcc-bugs]

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

--- Comment #1 from m.cencora at gmail dot com ---
This test assumes previous waiter implementation (I used gcc-11 available from
Ubuntu 21.04), latest atomic_wait impl has the same problem, it is just that
waiter is selected in a different way, and create_atomics would have to be
adjusted to accordingly (e.g. allocate 49 atomics in a single vector, and
0,16,32,48 instances should share same waiter instance).

[Bug tree-optimization/94589] Optimize (i<=>0)>0 to i>0

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #15 from Jakub Jelinek  ---
C testcase (though surely we need C++ one too because with C++ there are
aggregates and inline functions involved):

int f1 (int x, int y) { int a = x == y ? 0 : x < y ? -1 : 1; return a == 0; }
int f2 (int x, int y) { int a = x == y ? 0 : x < y ? -1 : 1; return a < 0; }
int f3 (int x, int y) { int a = x == y ? 0 : x < y ? -1 : 1; return a > 0; }
int f4 (int x, int y) { int a = x == y ? 0 : x < y ? -1 : 1; return a != 0; }
int f5 (int x, int y) { int a = x == y ? 0 : x < y ? -1 : 1; return a <= 0; }
int f6 (int x, int y) { int a = x == y ? 0 : x < y ? -1 : 1; return a >= 0; }
int f7 (int x, int y) { int a = x == y ? 0 : x < y ? -1 : 1; return a == -1; }
int f8 (int x, int y) { int a = x == y ? 0 : x < y ? -1 : 1; return a != -1; }
int f9 (int x, int y) { int a = x == y ? 0 : x < y ? -1 : 1; return a == 1; }
int f10 (int x, int y) { int a = x == y ? 0 : x < y ? -1 : 1; return a != 1; }
int f11 (float x, float y) { int a = x == y ? 0 : x < y ? -1 : 1; return a ==
0; }
int f12 (float x, float y) { int a = x == y ? 0 : x < y ? -1 : 1; return a < 0;
}
int f13 (float x, float y) { int a = x == y ? 0 : x < y ? -1 : 1; return a > 0;
}
int f14 (float x, float y) { int a = x == y ? 0 : x < y ? -1 : 1; return a !=
0; }
int f15 (float x, float y) { int a = x == y ? 0 : x < y ? -1 : 1; return a <=
0; }
int f16 (float x, float y) { int a = x == y ? 0 : x < y ? -1 : 1; return a >=
0; }
int f17 (float x, float y) { int a = x == y ? 0 : x < y ? -1 : 1; return a ==
-1; }
int f18 (float x, float y) { int a = x == y ? 0 : x < y ? -1 : 1; return a !=
-1; }
int f19 (float x, float y) { int a = x == y ? 0 : x < y ? -1 : 1; return a ==
1; }
int f20 (float x, float y) { int a = x == y ? 0 : x < y ? -1 : 1; return a !=
1; }

[Bug libstdc++/100334] New: atomic::notify_one() sometimes wakes wrong thread

[m.cencora at gmail dot com via Gcc-bugs]

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

Bug ID: 100334
   Summary: atomic::notify_one() sometimes wakes wrong thread
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: m.cencora at gmail dot com
  Target Milestone: ---

If waiter pool implementation is used in std::atomic::wait/notify for given
T, then notify_one must underneath call notify_all to make sure that proper
thread is awaken.
I.e. if multiple threads call atomic::wait() on different atomic
instances, but all of them share same waiter, then notify_one on only one of
atomics will possibly wake the wrong thread.
This can lead to program hangs, deadlocks, etc.

Following test app reproduces the bug:
g++-11 -std=c++20 -lpthread

#include 
#include 
#include 
#include 
#include 
#include 

void verify(bool cond, std::source_location loc =
std::source_location::current())
{
if (!cond)
{
std::cout << "Failed at line " << loc.line() << '\n';
std::abort();
}
}

template 
struct atomics_sharing_same_waiter
{
   std::unique_ptr> a[4];
};

unsigned get_waiter_key(void * ptr)
{
   return std::_Hash_impl::hash(ptr) & 0xf;
}

template 
atomics_sharing_same_waiter create_atomics()
{
   std::vector>> non_matching_atomics;

   atomics_sharing_same_waiter atomics;
   atomics.a[0] = std::make_unique>(0);

   auto key = get_waiter_key(atomics.a[0].get());
   for (auto i = 1u; i < 4u; ++i)
   {
  while (true)
  {
 auto atom = std::make_unique>(0);
 if (get_waiter_key(atom.get()) == key)
 {
atomics.a[i] = std::move(atom);
break;
 }
 else
 {
non_matching_atomics.push_back(std::move(atom));
 }
  }
   }

   return atomics;
}


int main()
{
// all atomic share the same waiter
auto atomics = create_atomics();

auto fut0 = std::async(std::launch::async, [&] {
atomics.a[0]->wait(0);
});

auto fut1 = std::async(std::launch::async, [&] {
atomics.a[1]->wait(0);
});

auto fut2 = std::async(std::launch::async, [&] {
atomics.a[2]->wait(0);
});

auto fut3 = std::async(std::launch::async, [&] {
atomics.a[3]->wait(0);
});

// make sure the all threads already await
std::this_thread::sleep_for(std::chrono::milliseconds{100});

atomics.a[2]->store(1);
atomics.a[2]->notify_one(); // changing to notify_all() allows this test to
pass

verify(std::future_status::timeout ==
fut0.wait_for(std::chrono::milliseconds{100}));
verify(std::future_status::timeout ==
fut1.wait_for(std::chrono::milliseconds{100}));
verify(std::future_status::ready ==
fut2.wait_for(std::chrono::milliseconds{100}));
verify(std::future_status::timeout ==
fut3.wait_for(std::chrono::milliseconds{100}));

atomics.a[0]->store(1);
atomics.a[0]->notify_one();
atomics.a[1]->store(1);
atomics.a[1]->notify_one();
atomics.a[3]->store(1);
atomics.a[3]->notify_one();
}

[Bug tree-optimization/94589] Optimize (i<=>0)>0 to i>0

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

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

--- Comment #14 from Richard Biener  ---
#include 
bool k(int a, int b){
  auto c = (a <=> b);
  return c>0;
}

Produces

   [local count: 1073741824]:
  if (a_1(D) == b_3(D))
goto ; [34.00%]
  else
goto ; [66.00%]

   [local count: 708669601]:
  if (a_1(D) < b_3(D))
goto ; [50.00%]
  else
goto ; [50.00%]

   [local count: 354334801]:

   [local count: 1073741824]:
  # prephitmp_8 = PHI <0(2), 0(3), 1(4)>
  return prephitmp_8;

from PRE (or the proposed patch) where it is not matched further.  This kind
of patters could be handled by phiopt.

[Bug target/100331] 128 bit arithmetic --- suboptimal after shifting when referencing other variables

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

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed||2021-04-29
  Known to fail||12.0
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
 Target||x86_64-*-*
   Keywords||missed-optimization

--- Comment #1 from Richard Biener  ---
Confirmed with GCC head.

[Bug libgomp/81778] libgomp.c/for-5.c failure on nvptx -- illegal memory access

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

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

Tom de Vries  changed:

   What|Removed |Added

 Resolution|--- |FIXED
   Target Milestone|--- |12.0
 Status|NEW |RESOLVED

--- Comment #12 from Tom de Vries  ---
Fixed in
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=fc14ff611181c274584c7963bc597a6ca50c20a1

[Bug tree-optimization/100173] telecom/viterb00data_1 has 16.92% regression compared O2 -ftree-vectorize -fvect-cost-model=very-cheap to O2 on CLX/ICX, 9% regression on znver3

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

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

--- Comment #5 from Richard Biener  ---
(In reply to Hongtao.liu from comment #4)
> > but yes, cselim will also sink the first store, moving it across the
> 
> Can we also sink loads?

loads are usually hoisted, not sunk.

> assign pointer to another temp pointer in both if
> and else bb, and then load val from this temp pointer. those assignments
> that in if and else branch would be finially transformed to conditional mov. 

Hmm, so conditional move is faster.  No, I don't think we'd do this at
the moment and I'm not sure we want in general (since aggressive
if-conversion tends to be bad).

> performance can benifit 100% with below change.
> 
>  for (i = 0; i < (1<<5)/2; i++) {
> 
> esMetricIn = *pBranchMetric++;
> 
> esMetric1 = pIn1->m_esPathMetric - esMetricIn;
> esMetric2 = pIn2->m_esPathMetric + esMetricIn;
> 
> e_s16 *t1p = (esMetric1 >= esMetric2) ? &(pIn1->m_esState) :
> &(pIn2->m_esState);
> e_s16 t1  = (esMetric1 >= esMetric2) ? esMetric1 : esMetric2;
> pOut->m_esPathMetric = t1;
> pOut->m_esState = *t1p << 1;
> pOut++;
> 
> esMetric1 = pIn1->m_esPathMetric + esMetricIn;
> esMetric2 = pIn2->m_esPathMetric - esMetricIn;
> 
> e_s16 *t2p = (esMetric1 >= esMetric2) ? &(pIn1->m_esState) :
> &(pIn2->m_esState);
> e_s16 t2  = (esMetric1 >= esMetric2) ? esMetric1 : esMetric2;
> pOut->m_esPathMetric = t2;
> pOut->m_esState = *t2p << 1;
> pOut++;
> 
> pIn1++;
> pIn2++;
>   }

[Bug tree-optimization/94589] Optimize (i<=>0)>0 to i>0

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

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

--- Comment #13 from Richard Biener  ---
Created attachment 50707
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50707=edit
prototype

For reference this is the prototype patch I mentioned.  I wasn't entirely happy
and wanted to explore the ??? in the commit message.

[Bug middle-end/90773] Improve piecewise operation

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

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by H.J. Lu :

https://gcc.gnu.org/g:985b3a6837dee7001e6b618f073ed74f0edf5787

commit r12-285-g985b3a6837dee7001e6b618f073ed74f0edf5787
Author: H.J. Lu 
Date:   Mon Jun 10 09:57:15 2019 -0700

Generate offset adjusted operation for op_by_pieces operations

Add an overlap_op_by_pieces_p target hook for op_by_pieces operations
between two areas of memory to generate one offset adjusted operation
in the smallest integer mode for the remaining bytes on the last piece
operation of a memory region to avoid doing more than one smaller
operations.

Pass the RTL information from the previous iteration to m_constfn in
op_by_pieces operation so that builtin_memset_[read|gen]_str can
generate the new RTL from the previous RTL.

Tested on Linux/x86-64.

gcc/

PR middle-end/90773
* builtins.c (builtin_memcpy_read_str): Add a dummy argument.
(builtin_strncpy_read_str): Likewise.
(builtin_memset_read_str): Add an argument for the previous RTL
information and generate the new RTL from the previous RTL info.
(builtin_memset_gen_str): Likewise.
* builtins.h (builtin_strncpy_read_str): Update the prototype.
(builtin_memset_read_str): Likewise.
* expr.c (by_pieces_ninsns): If targetm.overlap_op_by_pieces_p()
returns true, round up size and alignment to the widest integer
mode for maximum size.
(pieces_addr::adjust): Add a pointer to by_pieces_prev argument
and pass it to m_constfn.
(op_by_pieces_d): Add m_push and m_overlap_op_by_pieces.
(op_by_pieces_d::op_by_pieces_d): Add a bool argument to
initialize m_push.  Initialize m_overlap_op_by_pieces with
targetm.overlap_op_by_pieces_p ().
(op_by_pieces_d::run): Pass the previous RTL information to
pieces_addr::adjust and generate overlapping operations if
m_overlap_op_by_pieces is true.
(PUSHG_P): New.
(move_by_pieces_d::move_by_pieces_d): Updated for op_by_pieces_d
change.
(store_by_pieces_d::store_by_pieces_d): Updated for op_by_pieces_d
change.
(can_store_by_pieces): Use by_pieces_constfn on constfun.
(store_by_pieces): Use by_pieces_constfn on constfun.  Updated
for op_by_pieces_d change.
(clear_by_pieces_1): Add a dummy argument.
(clear_by_pieces): Updated for op_by_pieces_d change.
(compare_by_pieces_d::compare_by_pieces_d): Likewise.
(string_cst_read_str): Add a dummy argument.
* expr.h (by_pieces_constfn): Add a dummy argument.
(by_pieces_prev): New.
* target.def (overlap_op_by_pieces_p): New target hook.
* config/i386/i386.c (TARGET_OVERLAP_OP_BY_PIECES_P): New.
* doc/tm.texi.in: Add TARGET_OVERLAP_OP_BY_PIECES_P.
* doc/tm.texi: Regenerated.

gcc/testsuite/

PR middle-end/90773
* g++.dg/pr90773-1.h: New test.
* g++.dg/pr90773-1a.C: Likewise.
* g++.dg/pr90773-1b.C: Likewise.
* g++.dg/pr90773-1c.C: Likewise.
* g++.dg/pr90773-1d.C: Likewise.
* gcc.target/i386/pr90773-1.c: Likewise.
* gcc.target/i386/pr90773-2.c: Likewise.
* gcc.target/i386/pr90773-3.c: Likewise.
* gcc.target/i386/pr90773-4.c: Likewise.
* gcc.target/i386/pr90773-5.c: Likewise.
* gcc.target/i386/pr90773-6.c: Likewise.
* gcc.target/i386/pr90773-7.c: Likewise.
* gcc.target/i386/pr90773-8.c: Likewise.
* gcc.target/i386/pr90773-9.c: Likewise.
* gcc.target/i386/pr90773-10.c: Likewise.
* gcc.target/i386/pr90773-11.c: Likewise.
* gcc.target/i386/pr90773-12.c: Likewise.
* gcc.target/i386/pr90773-13.c: Likewise.
* gcc.target/i386/pr90773-14.c: Likewise.

[Bug libstdc++/100259] ODR violations in

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|--- |FIXED
   Target Milestone|--- |9.4
 Status|NEW |RESOLVED

--- Comment #6 from Jonathan Wakely  ---
Fixed for 9.4, 10.4, 11.2 and trunk (but the networking code is still largely
broken/useless on the old branches and only likely to get fixed on trunk).

[Bug target/100333] arm: ICE (unrecognizable insn) with CMSE nonsecure call and -march=armv8.1-m.main

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

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

Alex Coplan  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Keywords||ice-on-valid-code
  Known to fail||12.0
   Last reconfirmed||2021-04-29
 Ever confirmed|0   |1
 Target||arm-eabi

--- Comment #1 from Alex Coplan  ---
Taking a look at this.

[Bug target/100333] New: arm: ICE (unrecognizable insn) with CMSE nonsecure call and -march=armv8.1-m.main

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

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

Bug ID: 100333
   Summary: arm: ICE (unrecognizable insn) with CMSE nonsecure
call and -march=armv8.1-m.main
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: acoplan at gcc dot gnu.org
  Target Milestone: ---

The following fails:

$ cat test.c
typedef void __attribute__((cmse_nonsecure_call)) t(void);
t g;
void f() {
  g();
}
$ ./arm-eabi-gcc -c test.c -mcmse -march=armv8.1-m.main -mfloat-abi=soft
test.c: In function 'f':
test.c:5:1: error: unrecognizable insn:
5 | }
  | ^
(call_insn 5 2 0 2 (parallel [
(call (unspec:SI [
(mem:SI (symbol_ref:SI ("g") [flags 0x41]
) [0 g S4 A32])
] UNSPEC_NONSECURE_MEM)
(const_int 0 [0]))
(use (const_int 0 [0]))
(clobber (reg:SI 14 lr))
]) "test.c":4:3 -1
 (nil)
(nil))
during RTL pass: vregs
test.c:5:1: internal compiler error: in extract_insn, at recog.c:2770
0xcc2347 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/home/alecop01/toolchain/src/gcc/gcc/rtl-error.c:108
0xcc2366 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/home/alecop01/toolchain/src/gcc/gcc/rtl-error.c:116
0xc90fa6 extract_insn(rtx_insn*)
/home/alecop01/toolchain/src/gcc/gcc/recog.c:2770
0x9b74e4 instantiate_virtual_regs_in_insn
/home/alecop01/toolchain/src/gcc/gcc/function.c:1658
0x9b74e4 instantiate_virtual_regs
/home/alecop01/toolchain/src/gcc/gcc/function.c:1983
0x9b74e4 execute
/home/alecop01/toolchain/src/gcc/gcc/function.c:2032
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

The ICE does not occur if I instead specify -march=armv8-m.main.

[Bug libstdc++/100259] ODR violations in

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

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

--- Comment #5 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Jonathan Wakely
:

https://gcc.gnu.org/g:75d1d6841dd90649ea03cbe2ec43c3cfb27bebe8

commit r9-9475-g75d1d6841dd90649ea03cbe2ec43c3cfb27bebe8
Author: Jonathan Wakely 
Date:   Mon Apr 26 11:37:38 2021 +0100

libstdc++: Add missing 'inline' specifiers to net::ip functions [PR 100259]

libstdc++-v3/ChangeLog:

PR libstdc++/100259
* include/experimental/internet (net::ip::make_error_code)
(net::ip::make_error_condition, net::ip::make_network_v4)
(net::ip::operator==(const udp&, const udp&)): Add 'inline'.

(cherry picked from commit 3f4aa4579a6c03e0a0b0a6aec68aa5a301264d45)

[Bug libstdc++/100259] ODR violations in

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

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

--- Comment #4 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Jonathan Wakely
:

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

commit r10-9780-g9b6fecd9e594c7342141c334644d3938c8e5fcdb
Author: Jonathan Wakely 
Date:   Mon Apr 26 11:37:38 2021 +0100

libstdc++: Add missing 'inline' specifiers to net::ip functions [PR 100259]

libstdc++-v3/ChangeLog:

PR libstdc++/100259
* include/experimental/internet (net::ip::make_error_code)
(net::ip::make_error_condition, net::ip::make_network_v4)
(net::ip::operator==(const udp&, const udp&)): Add 'inline'.

(cherry picked from commit 3f4aa4579a6c03e0a0b0a6aec68aa5a301264d45)

[Bug libstdc++/100259] ODR violations in

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

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

--- Comment #3 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Jonathan Wakely
:

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

commit r11-8330-g4e54a34eed4f941cf09f27245bb3a5bfdb406a16
Author: Jonathan Wakely 
Date:   Mon Apr 26 11:37:38 2021 +0100

libstdc++: Add missing 'inline' specifiers to net::ip functions [PR 100259]

libstdc++-v3/ChangeLog:

PR libstdc++/100259
* include/experimental/internet (net::ip::make_error_code)
(net::ip::make_error_condition, net::ip::make_network_v4)
(net::ip::operator==(const udp&, const udp&)): Add 'inline'.

(cherry picked from commit 3f4aa4579a6c03e0a0b0a6aec68aa5a301264d45)

[Bug tree-optimization/94589] Optimize (i<=>0)>0 to i>0

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

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

--- Comment #12 from Marc Glisse  ---
(In reply to rguent...@suse.de from comment #11)

> For PR7
> I have prototyped a forwprop patch to try constant folding
> stmts with all-constant PHIs, thus in this case c$_M_value_2 > 0,
> when there's only a single use of it

Maybe we could handle any case where trying to fold the single use (counting
x*x as a single use of x) with each possible value satisfies is_gimple_val (or
whatever the condition is to be allowed in a PHI, and without introducing a use
of a ssa_name before it is defined), so that things like PHI & X would
simplify. But the constant case is indeed the most important, and should allow
the optimization in this PR before the vectorizer using reassoc1.

[Bug tree-optimization/100173] telecom/viterb00data_1 has 16.92% regression compared O2 -ftree-vectorize -fvect-cost-model=very-cheap to O2 on CLX/ICX, 9% regression on znver3

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Hongtao.liu  ---

> but yes, cselim will also sink the first store, moving it across the

Can we also sink loads? assign pointer to another temp pointer in both if and
else bb, and then load val from this temp pointer. those assignments that in if
and else branch would be finially transformed to conditional mov. 

performance can benifit 100% with below change.

 for (i = 0; i < (1<<5)/2; i++) {

esMetricIn = *pBranchMetric++;

esMetric1 = pIn1->m_esPathMetric - esMetricIn;
esMetric2 = pIn2->m_esPathMetric + esMetricIn;

e_s16 *t1p = (esMetric1 >= esMetric2) ? &(pIn1->m_esState) :
&(pIn2->m_esState);
e_s16 t1  = (esMetric1 >= esMetric2) ? esMetric1 : esMetric2;
pOut->m_esPathMetric = t1;
pOut->m_esState = *t1p << 1;
pOut++;

esMetric1 = pIn1->m_esPathMetric + esMetricIn;
esMetric2 = pIn2->m_esPathMetric - esMetricIn;

e_s16 *t2p = (esMetric1 >= esMetric2) ? &(pIn1->m_esState) :
&(pIn2->m_esState);
e_s16 t2  = (esMetric1 >= esMetric2) ? esMetric1 : esMetric2;
pOut->m_esPathMetric = t2;
pOut->m_esState = *t2p << 1;
pOut++;

pIn1++;
pIn2++;
  }

[Bug other/63426] [meta-bug] Issues found with -fsanitize=undefined

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

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

Bug 100311 Summary: UB in sel-sched.c:init_regs_for_mode with 
-march=armv8-m.base
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100311

   What|Removed |Added

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

[Bug rtl-optimization/100311] UB in sel-sched.c:init_regs_for_mode with -march=armv8-m.base

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

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

Richard Earnshaw  changed:

   What|Removed |Added

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

--- Comment #5 from Richard Earnshaw  ---
Fixed on all relevant branches.

[Bug d/100324] gcc-10.2.0 (and earlier) fails to build on x86_64, but has builds just fine aarch64

[ibuclaw at gdcproject dot org via Gcc-bugs]

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

--- Comment #7 from Iain Buclaw  ---
(In reply to Richard Biener from comment #3)
> /bin/sh: ../libtool: No such file or directory
> 
> that's odd.  What's your host operating system, in particular what shell
> is /bin/sh?
> 
> You'd need to see what (and why) libphobos picks up as @LIBTOOL@
LIBTOOL is unconditionally set as:

---
# Always use our own libtool.
LIBTOOL='$(SHELL) $(top_builddir)/libtool'
---

Which is the same everywhere as far as I understand.

[Bug rtl-optimization/100311] UB in sel-sched.c:init_regs_for_mode with -march=armv8-m.base

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

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

--- Comment #4 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Richard Earnshaw
:

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

commit r10-9778-gd0ae39ce2c3b4d635de6102ec3750cf6109cdc8d
Author: Richard Earnshaw 
Date:   Wed Apr 28 17:56:38 2021 +0100

arm: fix UB due to missing mode check [PR100311]

Some places in the compiler iterate over all the fixed registers to
check if that register can be used in a particular mode.  The idiom is
to iterate over the register and then for that register, if it
supports the current mode to check all that register and any
additional registers needed (HARD_REGNO_NREGS).  If these two checks
are not fully aligned then it is possible to generate a buffer overrun
when testing data objects that are sized by the number of hard regs in
the machine.

The VPR register is a case where these checks were not consistent and
because this is the last HARD register the result was that we ended up
overflowing the fixed_regs array.

gcc:
PR target/100311
* config/arm/arm.c (arm_hard_regno_mode_ok): Only allow VPR to be
used in HImode.
(cherry picked from commit 59f5d16f2c5db4d9592c8ce6453afe81334bb012)