[Bug fortran/106606] New: Internal compiler error with abstract derived type using recursive class() components.

[shepard at tcg dot anl.gov via Gcc-bugs]

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

Bug ID: 106606
   Summary: Internal compiler error with abstract derived type
using recursive class() components.
   Product: gcc
   Version: 11.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: shepard at tcg dot anl.gov
  Target Milestone: ---

Created attachment 53449
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53449=edit
This is a small file that demonstrates the error.

$ gfortran error.F90 
gfortran: internal compiler error: Segmentation fault: 11 signal terminated
program f951
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


$ gfortran --version
GNU Fortran (Homebrew GCC 11.3.0_2) 11.3.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.

[Bug tree-optimization/106605] New: [13 Regression] ICE in range_on_path_entry, at gimple-range-path.cc:164 with -march=skylake-avx512 -O3

[vsevolod.livinskiy at gmail dot com via Gcc-bugs]

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

Bug ID: 106605
   Summary: [13 Regression] ICE in range_on_path_entry, at
gimple-range-path.cc:164 with -march=skylake-avx512
-O3
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vsevolod.livinskiy at gmail dot com
  Target Milestone: ---

Link to the Compiler Explorer: https://godbolt.org/z/hWornT4aW

Reproducer:
unsigned e;
extern int f[];
extern long g[];
void h() {
  for (int a(e);;)
for (unsigned b = 0;;)
  for (short c = 0;;)
for (short d = 0; d < 66; d++)
  if (d) {
f[d] = 0;
g[a * b * c + d] = 0;
  }
}

Error:
>$ g++ -c -march=skylake-avx512 -O3 func.cpp
during GIMPLE pass: threadfull
func.cpp: In function 'void h()':
func.cpp:4:6: internal compiler error: in range_on_path_entry, at
gimple-range-path.cc:164
4 | void h() {
  |  ^
0x8c16b8 path_range_query::range_on_path_entry(vrange&, tree_node*)
/testing/gcc/gcc_src_master/gcc/gimple-range-path.cc:164
0x140788d path_range_query::ssa_range_in_phi(vrange&, gphi*)
/testing/gcc/gcc_src_master/gcc/gimple-range-path.cc:321
0x1406cc5 path_range_query::range_defined_in_block(vrange&, tree_node*,
basic_block_def*)
/testing/gcc/gcc_src_master/gcc/gimple-range-path.cc:348
0x1406f39 path_range_query::compute_ranges_in_phis(basic_block_def*)
/testing/gcc/gcc_src_master/gcc/gimple-range-path.cc:394
0x1407a2b path_range_query::compute_ranges_in_block(basic_block_def*)
/testing/gcc/gcc_src_master/gcc/gimple-range-path.cc:442
0x14083ca path_range_query::compute_ranges(vec const&, bitmap_head const*)
/testing/gcc/gcc_src_master/gcc/gimple-range-path.cc:673
0x148e99c back_threader::find_taken_edge_cond(vec const&, gcond*)
/testing/gcc/gcc_src_master/gcc/tree-ssa-threadbackward.cc:317
0x148f493 back_threader::maybe_register_path()
/testing/gcc/gcc_src_master/gcc/tree-ssa-threadbackward.cc:231
0x148fa66 back_threader::find_paths_to_names(basic_block_def*, bitmap_head*,
unsigned int)
/testing/gcc/gcc_src_master/gcc/tree-ssa-threadbackward.cc:355
0x148fe94 back_threader::find_paths_to_names(basic_block_def*, bitmap_head*,
unsigned int)
/testing/gcc/gcc_src_master/gcc/tree-ssa-threadbackward.cc:471
0x14909bc back_threader::find_paths(basic_block_def*, tree_node*)
/testing/gcc/gcc_src_master/gcc/tree-ssa-threadbackward.cc:529
0x1490c21 back_threader::thread_blocks()
/testing/gcc/gcc_src_master/gcc/tree-ssa-threadbackward.cc:943
0x1490d08 execute
/testing/gcc/gcc_src_master/gcc/tree-ssa-threadbackward.cc:1073

gcc version 13.0.0 20220812 (1595794f804ed3e925dcdf5f21b7fa762c74ca15)

[Bug c++/106434] [12/13 Regression] Spurious -Wnull-dereference when using std::unique_copy() since r12-5187-g1ae8edf5f73ca5c3

[joshua.r.marshall.1991 at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Josh Marshall  ---
How involved should I be on this?

[Bug rtl-optimization/82889] Unnecessary sign extension of int32 to int64

[hiraditya at msn dot com via Gcc-bugs]

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

--- Comment #5 from AK  ---
Link to compiler explorer: https://godbolt.org/z/dGYG4dG15

[Bug rtl-optimization/82889] Unnecessary sign extension of int32 to int64

[hiraditya at msn dot com via Gcc-bugs]

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

--- Comment #4 from AK  ---
Seems like clang doesn't sign extend.

$ clang -O3 -std=c++14 -g0

```
.text
.intel_syntax noprefix
.file   "example.cpp"
.globl  lol(int*, int*, unsigned int, unsigned int)   
# -- Begin function lol(int*, int*, unsigned int, unsigned int)
.p2align4, 0x90
.type   lol(int*, int*, unsigned int, unsigned int),@function
lol(int*, int*, unsigned int, unsigned int):   #
@lol(int*, int*, unsigned int, unsigned int)
.cfi_startproc
# %bb.0:
# kill: def $edx killed $edx def $rdx
and edx, ecx
mov r8d, ecx
mov ecx, 1
jmp .LBB0_1
.p2align4, 0x90
.LBB0_4:#   in Loop: Header=BB0_1 Depth=1
testal, 1
jne .LBB0_5
.LBB0_7:#   in Loop: Header=BB0_1 Depth=1
add edx, ecx
and edx, r8d
inc rcx
.LBB0_1:# =>This Inner Loop Header: Depth=1
mov eax, dword ptr [rsi + 4*rdx]
testeax, eax
js  .LBB0_4
# %bb.2:#   in Loop: Header=BB0_1 Depth=1
cmp dword ptr [rdi + 4*rax], 42
jne .LBB0_7
# %bb.3:
mov eax, 1
ret
.LBB0_5:
xor eax, eax
ret
.Lfunc_end0:
.size   lol(int*, int*, unsigned int, unsigned int),
.Lfunc_end0-lol(int*, int*, unsigned int, unsigned int)
.cfi_endproc
# -- End function
.ident  "clang version 16.0.0 (https://github.com/llvm/llvm-project.git
5e22ef3198d1686f7978dd150a3eefad4f737bfc)"
.section".note.GNU-stack","",@progbits
.addrsig
```


$ gcc -O3 -std=c++14 -g0

```
lol(int*, int*, unsigned int, unsigned int):
and edx, ecx
mov r8d, 1
mov ecx, ecx
jmp .L5
.L10:
cmp DWORD PTR [rdi+rax*4], 42
je  .L9
.L4:
add rdx, r8
add r8, 1
and rdx, rcx
.L5:
movsx   rax, DWORD PTR [rsi+rdx*4] <--- sign extend
testeax, eax
jns .L10
testal, 1
je  .L4
xor eax, eax
ret
.L9:
mov eax, 1
ret
```

[Bug c++/106604] New: Fully-specified deduction guide in anonymous namespace warns as-if a function? Unsuppressably?

[nabijaczleweli at nabijaczleweli dot xyz via Gcc-bugs]

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

Bug ID: 106604
   Summary: Fully-specified deduction guide in anonymous namespace
warns as-if a function? Unsuppressably?
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nabijaczleweli at nabijaczleweli dot xyz
  Target Milestone: ---

Reproduced this separately on 10.2.1-6 (bullseye), 12.1.0-7 (sid from 2 weeks
ago), trunk (according to godbolt).

TL;DR: https://gcc.godbolt.org/z/869TdbvEe


Given:
  namespace {
  template 
  struct test {
  test(T) noexcept {}
  };

  UNUSED test(bool) -> test;
  }

If UNUSED is blank, GCC produces:
  :7:12: warning: '{anonymous}::test(int) -> test' declared
'static' but never defined [-Wunused-function]
  7 | UNUSED test(int) -> test;
|^~~~
  Compiler returned: 0


If UNUSED is [[maybe_unused]] (which was my solution originally since it works
on Clang):
  :0:16: error: 'decl-specifier' in declaration of deduction guide
  0 | #define UNUSED [[maybe_unused]]
|^
  :7:5: note: in expansion of macro 'UNUSED'
  7 | UNUSED test(int) -> test;
| ^~
  :7:12: warning: '{anonymous}::test(int) -> test' declared
'static' but never defined [-Wunused-function]
  7 | UNUSED test(int) -> test;
|^~~~
  Compiler returned: 1


So:
  * the deduction guide is decidedly not "declared 'static'" (anon namespace
means it has static linkage, sure, but it's not 'static')
  * of course it's not defined?? can you even define a deduction guide?
  * how do you suppress this? (besides template)?

[Bug libstdc++/78717] no definition of string::find when lowered to gimple

[hiraditya at msn dot com via Gcc-bugs]

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

--- Comment #3 from AK  ---
Even with a high inline limit, string::find didn't inline.

g++-11.0.2 -O3  -finline-limit=10  -S -o a.s s.cpp

cat a.s

```
_Z3fooRKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEES6_i:
.LFB1240:
.cfi_startproc
endbr64
pushq   %rbx
.cfi_def_cfa_offset 16
.cfi_offset 3, -16
movq8(%rsi), %rcx
movslq  %edx, %rbx
xorl%edx, %edx
movq(%rsi), %rsi
call   
_ZNKSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE4findEPKcmm@PLT
cmpq%rax, %rbx
popq%rbx
.cfi_def_cfa_offset 8
sete%al
movzbl  %al, %eax
ret

```

[Bug other/92396] -ftime-trace support

[hiraditya at msn dot com via Gcc-bugs]

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

AK  changed:

   What|Removed |Added

 CC||hiraditya at msn dot com

--- Comment #12 from AK  ---
I was building a giant file that takes around 100 minutes. The -ftime-report
gave nothing useful to find out hotspots. It is also not clear what we are
reporting here as there is no documentation for it in man gcc. The %ages don't
add up to 100 and that makes it confusing.

I'm wondering if making this task a GSoC project will get more attention?

[Bug c/106569] enhancement: use STL algorithm instead of a raw loop

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

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

--- Comment #8 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #5)
> (In reply to David Binderman from comment #0)
> > Static analyser cppcheck can produce these style messages for gcc trunk
> > source code:
> > 
> > $ fgrep useStlAlgorithm cppcheck.20220809.out
> > trunk.git/gcc/analyzer/call-string.cc:169:9: style: Consider using
> > std::count_if algorithm instead of a raw loop. [useStlAlgorithm]
> 
> I don't think count_if would work here. I haven't looked at the others yet,
> but this first one seems like a useless suggestion.

The other suggestions for gcc/analyzer/*.cc look correct, or at least, not
incorrect, but not all of them would improve clarity. Similarly for the
gcc/cp/constexpr.cc suggestions. They would need a lambda expression that
captures local variables, and then compare the result of the algorithm to the
end iterator of the range. I don't think that would improve the code. It would
certainly be more lines of code.

[Bug libstdc++/106589] [12/13 Regression] visit rejects lambdas that do not return void

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

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

--- Comment #3 from Jonathan Wakely  ---
I haven't checked, but it's probably g:cfb582f62791dfadc243d97d37f0b83ef77cf480

[Bug c/106569] enhancement: use STL algorithm instead of a raw loop

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

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

--- Comment #7 from Jonathan Wakely  ---
std::find_if exists since c++98.

I'll go through these in a couple of weeks, it's probably not productive for
people who don't know the C++ std::lib well to bother analysing the
suggestions.

[Bug c/106569] enhancement: use STL algorithm instead of a raw loop

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

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

--- Comment #6 from Jonathan Wakely  ---
(In reply to David Binderman from comment #2)
> According to
> 
> https://cplusplus.com/reference/algorithm/any_of/

cplusplus.com is garbage, use cppreference.com

[Bug c/106569] enhancement: use STL algorithm instead of a raw loop

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

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

--- Comment #5 from Jonathan Wakely  ---
(In reply to David Binderman from comment #0)
> Static analyser cppcheck can produce these style messages for gcc trunk
> source code:
> 
> $ fgrep useStlAlgorithm cppcheck.20220809.out
> trunk.git/gcc/analyzer/call-string.cc:169:9: style: Consider using
> std::count_if algorithm instead of a raw loop. [useStlAlgorithm]

I don't think count_if would work here. I haven't looked at the others yet, but
this first one seems like a useless suggestion.

[Bug fortran/106603] New: Problem with character(:), allocatable, intent(out) :: err for functions which return fixed arrays

[wogan at uw dot edu via Gcc-bugs]

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

Bug ID: 106603
   Summary: Problem with character(:), allocatable, intent(out) ::
err for functions which return fixed arrays
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wogan at uw dot edu
  Target Milestone: ---

Consider the following code:

```fortran
program main
  use iso_fortran_env, only: dp => real64
  implicit none
  call test_fun1()

contains

  function fun1(a, err) result(b)
real(dp), intent(in) :: a
character(:), allocatable, intent(out) :: err
real(dp) :: b(2)

b = 1

if (a > 2) then
  err = "a bigger than 2"
  print*,'err in fun1: ',err
  return
endif

err = "OK"

  end function

  subroutine test_fun1()
real(dp) :: a, b(2)
character(:), allocatable :: err
a = 3

b = fun1(a, err)
if (allocated(err)) then
  print*,'err is allocated'
  print*,'next line tries to print err'
  print*,err
endif
  end subroutine

end program
```

I compile the code with `gfortran main.f90`, then run with `./a.out`. The
result is

```
(base) nicholas@Nicholass-MacBook-Air test_gfortran_err % ./a.out  
 err in fun1: a bigger than 2
 err is allocated
 next line tries to print err

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

Backtrace for this error:
#0  0x100df21c7
#1  0x100df11a3
#2  0x194092c43
#3  0x100ee865b
zsh: segmentation fault  ./a.out
```

When I compile with `-fno-strict-aliasing -fwrapv
-fno-aggressive-loop-optimizations` I get a slightly different result, which is
also not correct:

```
(base) nicholas@Nicholass-MacBook-Air test_gfortran_err % ./a.out   
 err in fun1: a bigger than 2
 err is allocated
 next line tries to print err


```

Instead of the results above, the program should print "a bigger than 2". Here
is a relevant form where I discussed the bug with others:
https://fortran-lang.discourse.group/t/what-is-wrong-with-this-code/4151 . 

Exact version of GCC:
```
(base) nicholas@Nicholass-MacBook-Air test_gfortran_err % gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/opt/homebrew/Cellar/gcc/12.1.0/bin/../libexec/gcc/aarch64-apple-darwin20/12/lto-wrapper
Target: aarch64-apple-darwin20
Configured with: ../configure --prefix=/opt/homebrew/opt/gcc
--libdir=/opt/homebrew/opt/gcc/lib/gcc/current --disable-nls
--enable-checking=release --with-gcc-major-version-only
--enable-languages=c,c++,objc,obj-c++,fortran --program-suffix=-12
--with-gmp=/opt/homebrew/opt/gmp --with-mpfr=/opt/homebrew/opt/mpfr
--with-mpc=/opt/homebrew/opt/libmpc --with-isl=/opt/homebrew/opt/isl
--with-zstd=/opt/homebrew/opt/zstd --with-pkgversion='Homebrew GCC 12.1.0'
--with-bugurl=https://github.com/Homebrew/homebrew-core/issues
--with-system-zlib --build=aarch64-apple-darwin20
--with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX11.sdk
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.1.0 (Homebrew GCC 12.1.0) 
```

[Bug target/106601] __builtin_bswap16 code gen could be improved with ZBB enabled

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Last reconfirmed||2022-08-12

--- Comment #2 from Andrew Pinski  ---
(In reply to Andrew Waterman from comment #1)

> (I don't know whether bswap32 has already been similarly optimized on RV64,
> but it needs to use srai so that the 32-bit result is canonicalized
> properly.)

It is:
t:
rev8a0,a0
sraia0,a0,32
ret
For:
unsigned int t(unsigned int a)
{
  return __builtin_bswap32(a);
}

[Bug target/106601] __builtin_bswap16 code gen could be improved with ZBB enabled

[andrew at sifive dot com via Gcc-bugs]

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

Andrew Waterman  changed:

   What|Removed |Added

 CC||andrew at sifive dot com

--- Comment #1 from Andrew Waterman  ---
Yep.

(I don't know whether bswap32 has already been similarly optimized on RV64, but
it needs to use srai so that the 32-bit result is canonicalized properly.)

[Bug target/106602] riscv: suboptimal codegen for shift left, right, left

[vineetg at rivosinc dot com via Gcc-bugs]

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

--- Comment #2 from Vineet Gupta  ---
Yes I noted that in the original report.

[Bug target/106602] riscv: suboptimal codegen for shift left, right, left

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

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

--- Comment #1 from Andrew Pinski  ---
With ZBA_ZBB_ZBC_ZBS:
It is just:
foo2:
slli.uw a0,a0,6
ret

Which is good code gen :).

[Bug target/106602] New: riscv: suboptimal codegen for shift left, right, left

[vineetg at rivosinc dot com via Gcc-bugs]

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

Bug ID: 106602
   Summary: riscv: suboptimal codegen for shift left, right, left
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vineetg at rivosinc dot com
CC: christophm30 at gmail dot com, kito at gcc dot gnu.org
  Target Milestone: ---

This came up when investigating
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106545. The test to supposedly
induce the peephole doesn't, but generates far inferior code.

unsigned long foo2(unsigned long a)
{
return (unsigned long)(unsigned int)a << 6;
}

-march=rv64gc -O2   # no bitmanip

foo2:
li  a5,1
sllia5,a5,38
addia5,a5,-64
sllia0,a0,6
and a0,a0,a5
ret

llvm generates expected

foo:
sllia0, a0, 32
srlia0, a0, 26
ret

[Bug target/106601] New: __builtin_bswap16 code gen could be improved with ZBB enabled

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

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

Bug ID: 106601
   Summary: __builtin_bswap16 code gen could be improved with ZBB
enabled
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: target
  Assignee: pinskia at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---
Target: riscv

unsigned short t(unsigned short a)
{
  return __builtin_bswap16(a);
}

This could just be rev8 followed by a srli (I think).

[Bug target/106600] __builtin_bswap32 is not hooked up for ZBB

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Last reconfirmed||2022-08-12

--- Comment #1 from Andrew Pinski  ---
Mine.

[Bug target/106600] New: __builtin_bswap32 is not hooked up for ZBB

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

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

Bug ID: 106600
   Summary: __builtin_bswap32 is not hooked up for ZBB
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: target
  Assignee: pinskia at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---
Target: riscv32

Testcase:
```
int f(int a)
{
  return __builtin_bswap32(a);
}
```
The reason is because the check for TARGET_64BIT is there even though it should
not be:
(define_insn "bswap2"
  [(set (match_operand:X 0 "register_operand" "=r")
(bswap:X (match_operand:X 1 "register_operand" "r")))]
  "TARGET_64BIT && TARGET_ZBB"
  "rev8\t%0,%1"
  [(set_attr "type" "bitmanip")])

[Bug c++/106599] Wrong copy elision in delegating to copy-constructor

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

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

--- Comment #1 from Andrew Pinski  ---
MSVC also rejects it.

[Bug c++/106599] New: Wrong copy elision in delegating to copy-constructor

[fchelnokov at gmail dot com via Gcc-bugs]

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

Bug ID: 106599
   Summary: Wrong copy elision in delegating to copy-constructor
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fchelnokov at gmail dot com
  Target Milestone: ---

The following program should be valid:
```
struct A {   
int v = 0;
constexpr A() = default;
constexpr A(const A&) : v(1) {}
constexpr A(int) : A(A()) {}
};

static_assert( A(2).v == 1 );
```
and is accepted by Clang but not GCC. Online demo:
https://gcc.godbolt.org/z/zKoqq3rKW

Clang is probably correct here, because
http://eel.is/c++draft/class.base.init#7 says:

The expression-list or braced-init-list in a mem-initializer is used to
initialize the designated subobject (or, in the case of a delegating
constructor, the complete class object) according to the initialization rules
of [dcl.init] for direct-initialization.

So we should use the rules for direct-initialization and
http://eel.is/c++draft/dcl.init#general-16.6.2 says:

Otherwise, if the initialization is direct-initialization, or if it is
copy-initialization where the cv-unqualified version of the source type is the
same class as, or a derived class of, the class of the destination,
constructors are considered.
The applicable constructors are enumerated ([over.match.ctor]), and the best
one is chosen through overload resolution ([over.match]).

So we need to consider the constructors, and select A(const A&) : v(1)

[Bug fortran/106579] ieee_signaling_nan problem in fortran on powerpc64

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

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

--- Comment #9 from Jakub Jelinek  ---
Created attachment 53448
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53448=edit
gcc13-pr106579.patch

On top of that, this implements ieee_class.  ieee_value still to be
implemented.

[Bug tree-optimization/106594] [13 Regression] sign-extensions no longer merged into addressing mode

[roger at nextmovesoftware dot com via Gcc-bugs]

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

--- Comment #5 from Roger Sayle  ---
Hi Tamar,
I think this is where I need to apologize.  Combine is now canonicalizing these
equivalent RTL expressions to the zero_extend form, on the assumption that zero
extension has no data dependency and is cheaper or at worst the same speed on
many targets.  Unfortunately, for aarch64 there are patterns (splitters or
peephole2s) for optimizing the sign_extend version that don't exist for the
zero_extend version [even though the instruction set is symmetric and should
handle both sxtw/uxtw].  Technically, these were just missed-optimizations
before,  but I'm guessing my changes (to both trees and RTL) lead to changes in
the form that the backend encounters, and leads to a code quality regression.

This should be easy to fix, I just need to get up to speed on the instructions
that aarch64 supports, and which zero extended forms are currently missing.
I'm sure if GCC instead canonicalized to the sign_extend form, that other
targets would show similar asymmetries (it's only when things change that
anyone notices the difference).  I'll see if I can come up with a fix over the
weekend.

[Bug target/106598] New: s390: Inefficient branchless conditionals for int

[jens.seifert at de dot ibm.com via Gcc-bugs]

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

Bug ID: 106598
   Summary: s390: Inefficient branchless conditionals for int
   Product: gcc
   Version: 11.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jens.seifert at de dot ibm.com
  Target Milestone: ---

int lt(int a, int b)
{
return a < b;
}

generates:
cr  %r2,%r3
lhi %r1,1
lhi %r2,0
locrnl  %r1,%r2
lgfr%r2,%r1
br  %r14

int ltOpt(int a, int b)
{
long long x = a;
long long y = b;
return ((unsigned long long)(x - y)) >> 63;
}

better:
sgr %r2,%r3
srlg%r2,%r2,63
br  %r14

int ltMask(int a, int b)
{
return -(a < b);
}

generates:
cr  %r2,%r3
lhi %r1,1
lhi %r2,0
locrnl  %r1,%r2
sllg%r1,%r1,63
srag%r2,%r1,63


int ltMaskOpt(int a, int b)
{
long long x = a;
long long y = b;
return (x - y) >> 63;
}

better:
sgr %r2,%r3
srag%r2,%r2,63
br  %r14

int leMask(int a, int b)
{
return -(a <= b);
}

generates:
cr  %r2,%r3
lhi %r1,1
lhi %r2,0
locrnle %r1,%r2
sllg%r1,%r1,63
srag%r2,%r1,63
br  %r14

int leMaskOpt(int a, int b)
{
   int c;
   __asm__("cr %1,%2\n\tslbgr %0,%0":"=r"(c):"r"(a),"r"(b):"cc");
   // slbgr create a 64-bit mask => lgfr would not be required
   return c;
}

better:
cr %r2,%r3
slbgr %r2,%r2
lgfr%r2,%r2 <= not necessary
br  %r14


int le(int a, int b)
{
return a <= b;
}

generates:
cr  %r2,%r3
lhi %r1,1
lhi %r2,0
locrnle %r1,%r2
lgfr%r2,%r1
br  %r14

int leOpt(int a, int b)
{
   unsigned long long c;
   __asm__("cr %1,%2\n\tslbgr %0,%0":"=r"(c):"r"(a),"r"(b):"cc");
   return (c >> 63);
}

better:
cr %r2,%r3
slbgr %r2,%r2
srlg%r2,%r2,63
br  %r14

[Bug tree-optimization/106594] [13 Regression] sign-extensions no longer merged into addressing mode

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

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

--- Comment #4 from Tamar Christina  ---
Hmm my concern here is though that we've now introduced two forms to represent
this and may cause an issue in other places where we sink extensions.

Perhaps there should be some canonization somewhere? maybe combine?

[Bug rtl-optimization/106590] [12/13 Regression] x86-64 miscompilation starting with r12-8233-g1ceddd7497e15d w/ mtune=skylake

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #7 from Jakub Jelinek  ---
Created attachment 53447
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53447=edit
gcc13-pr106590.patch

Untested fix.

[Bug ipa/101839] [10/11/12/13 Regression] Hang in C++ code with -fdevirtualize

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

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

--- Comment #11 from Jan Hubicka  ---
Fixed on mainline with r:0f2c7ccd14a29a8af8318f50b8296098fb0ab218

[Bug c++/106057] Missed stmt_can_throw_external check in stmt_kills_ref_p

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Jan Hubicka :

https://gcc.gnu.org/g:0f2c7ccd14a29a8af8318f50b8296098fb0ab218

commit r13-2034-g0f2c7ccd14a29a8af8318f50b8296098fb0ab218
Author: Jan Hubicka 
Date:   Fri Aug 12 16:25:28 2022 +0200

Fix invalid devirtualization when combining final keyword and anonymous
types

this patch fixes a wrong code issue where we incorrectly devirtualize to
__builtin_unreachable.  The problem occurs in combination of anonymous
namespaces and final keyword used on methods.  We do two optimizations here
 1) when reacing final method we cut the search for possible new targets
 2) if the type is anonymous we detect whether it is ever instatiated by
looking if its vtable is referred to.
Now this goes wrong when thre is an anonymous type with final method that
is not instantiated while its derived type is.  So if 1 triggers we need
to make 2 to look for vtables of all derived types as done by this patch.

Bootstrpaped/regtested x86_64-linux

Honza

gcc/ChangeLog:

2022-08-10  Jan Hubicka  

PR middle-end/106057
* ipa-devirt.cc (type_or_derived_type_possibly_instantiated_p): New
function.
(possible_polymorphic_call_targets): Use it.

gcc/testsuite/ChangeLog:

2022-08-10  Jan Hubicka  

PR middle-end/106057
* g++.dg/tree-ssa/pr101839.C: New test.

[Bug analyzer/106597] New: False positive Wanalyzer-out-of-bounds warnings in coreutils/gnulib

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

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

Bug ID: 106597
   Summary: False positive Wanalyzer-out-of-bounds warnings in
coreutils/gnulib
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: tlange at gcc dot gnu.org
  Target Milestone: ---

Created attachment 53446
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53446=edit
false positive Wanalyzer-out-of-bounds in coreutils

When compiling coreutils with -fanalyzer enabled, a false positive
Wanalyzer-out-of-bounds underread warning is emitted in a complex flow. The
analyzer does think 'idx' can be 0 and thus, creates an offset_region with
offset - 1 in multiple locations. Logs attached.

[Bug tree-optimization/106594] [13 Regression] sign-extensions no longer merged into addressing mode

[roger at nextmovesoftware dot com via Gcc-bugs]

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

Roger Sayle  changed:

   What|Removed |Added

   Last reconfirmed||2022-08-12
 Status|UNCONFIRMED |NEW
 CC||roger at nextmovesoftware dot 
com
 Ever confirmed|0   |1

--- Comment #3 from Roger Sayle  ---
Ah interesting.  Because index is a char, the tree-level optimizers realize
that the shift by 4 can be an 8-bit shift instead of an int-sized shift. 
What's interesting is that because of (x & 3) << 4, is used, the optimizers
realize that because index can never be negative, that in the array memory
reference expression constellation_64qam[index], when the 8-bit index is being
sign extended, it is effectively being zero-extended.

I think that the aarch64 backend needs to be taught that in this case (because
of the AND), the zero extension is the same as (can be implemented using) a
sign-extension, i.e. restoring the original code generation.  Practically, the
sxtw;ldr[..lsl 2] above can legitimately be optimized to ldr[..sxtw 2] (or
ldr[..uxtw 2] like LLVM) in this case [cases like this].

(sign_extend:DI (and:SI x (const_int 3))) and
(zero_extend:DI (and:SI x (const_int 3))) should (ideally) produce the exact
same code [the more efficient if two implementations are possible].

[Bug rtl-optimization/106590] [12/13 Regression] x86-64 miscompilation starting with r12-8233-g1ceddd7497e15d w/ mtune=skylake

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

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

--- Comment #6 from Jakub Jelinek  ---
Cleaned up testcase:

/* { dg-additional-options "-mtune=skylake" { target { i?86-*-* x86_64-*-* } }
} */

typedef struct A { short a; } A;
typedef A *B;
typedef struct C { int c, d; } C;
typedef C *D;

B
foo (void)
{
  static A r = { .a = 1 };
  return 
}

D
bar (void)
{
  static C r = { .c = 1, .d = 23 };
  return 
}

static inline int __attribute__((always_inline))
baz (short a)
{
  int e = 1, f;
  short g;
  D h;

  switch (a)
{
case 1:
  f = 23;
  g = 1;
  break;
case 2:
  f = 20;
  g = 2;
  break;
}

  h = bar ();

  if (h->d != f || h->c != g)
__builtin_abort ();
  return e;
}

int
qux (void)
{
  B i = foo ();
  int e = 1;

  switch (i->a)
{
case 1:
case 2:
  e = baz (i->a);
  break;
case 3:
  e = 0;
  break;
}

  return e;
}

int
main ()
{
  qux ();
  return 0;
}

I think this is a latent bug in noce_convert_multiple_sets_1.
For cond
(eq (reg/v:HI 82 [ g ])
(const_int 1 [0x1]))
and cc_cmp
(eq (reg:CCZ 17 flags)
(const_int 0 [0]))
when we try_emit_cmove_seq for
(insn 3 35 4 7 (set (reg/v:HI 82 [ g ])
(const_int 2 [0x2])) "pr106590.c":37:9 84 {*movhi_internal}
 (nil))
insn, we get seq1
(insn 65 0 66 (set (reg:CCZ 17 flags)
(compare:CCZ (reg/v:HI 82 [ g ])
(const_int 1 [0x1]))) -1
 (nil))

(insn 66 65 67 (set (reg:QI 96)
(ne:QI (reg:CCZ 17 flags)
(const_int 0 [0]))) -1
 (nil))

(insn 67 66 68 (set (reg:HI 95)
(zero_extend:HI (reg:QI 96))) -1
 (nil))

(insn 68 67 0 (parallel [
(set (reg:HI 95)
(plus:HI (reg:HI 95)
(const_int 1 [0x1])))
(clobber (reg:CC 17 flags))
]) -1
 (nil))
and seq2
(insn 69 0 70 (set (reg:HI 97)
(const_int 2 [0x2])) -1
 (nil))

(insn 70 69 0 (set (reg:HI 95)
(if_then_else:HI (eq (reg:CCZ 17 flags)
(const_int 0 [0]))
(reg/v:HI 82 [ g ])
(reg:HI 97))) -1
 (nil))
and later for
(insn 4 3 36 7 (set (reg/v:SI 84 [ f ])
(const_int 20 [0x14])) "pr106590.c":36:9 83 {*movsi_internal}
 (nil))
we get seq1
(insn 72 0 71 (set (reg:SI 98)
(const_int 20 [0x14])) -1
 (nil))

(insn 71 72 73 (set (reg:CCZ 17 flags)
(compare:CCZ (reg/v:HI 82 [ g ])
(const_int 1 [0x1]))) -1
 (nil))

(insn 73 71 0 (set (reg/v:SI 84 [ f ])
(if_then_else:SI (eq (reg:CCZ 17 flags)
(const_int 0 [0]))
(reg/v:SI 84 [ f ])
(reg:SI 98))) -1
 (nil))
and seq2
(insn 74 0 75 (set (reg:SI 99)
(const_int 20 [0x14])) -1
 (nil))

(insn 75 74 0 (set (reg/v:SI 84 [ f ])
(if_then_else:SI (eq (reg:CCZ 17 flags)
(const_int 0 [0]))
(reg/v:SI 84 [ f ])
(reg:SI 99))) -1
 (nil))
In the former case, cost1 == cost2, in the latter case cost1 > cost2.
So, we for the first insn choose seq1 and for the second seq2.
That is wrong, because the first seq1 clobbers the (reg 17 flags) register
which is used in cc_cmp/rev_cc_cmp.  So, if we pick that seq1, we may not use
any seq2 afterwards for the latter instructions, need to always select seq1
since then.

[Bug c++/106596] Not a helpful diagnostic when putting things out of order in a member function

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

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

Marek Polacek  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Keywords||diagnostic
 CC||mpolacek at gcc dot gnu.org
   Last reconfirmed||2022-08-12

--- Comment #1 from Marek Polacek  ---
Confirmed.

[Bug c++/106596] New: Not a helpful diagnostic when putting things out of order in a member function

[barry.revzin at gmail dot com via Gcc-bugs]

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

Bug ID: 106596
   Summary: Not a helpful diagnostic when putting things out of
order in a member function
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: barry.revzin at gmail dot com
  Target Milestone: ---

Consider this example:

template  concept C = true;

template 
struct Widget {
void foo() requires C noexcept;  
};

The issue here is that the noexcept needs to go before the requires clause, but
how many people really remember what the order of these things needs to be?

The gcc 12.1 error for this is:

:5:25: error: expected ';' at end of member declaration
5 | void foo() requires C noexcept;
  | ^~~~
  | ;
:5:30: error: expected unqualified-id before 'noexcept'
5 | void foo() requires C noexcept;
  |  ^~~~

I suspect this might be a difficult thing to provide a diagnostic for, but this
particular one is pretty unhelpful. The first one is suggesting I needed to
write void foo() requires; which isn't even valid.

Hypothetical ideal:

:5:30: error: the noexcept-specifier needs to precede the
requires-clause
5 | void foo() requires C noexcept;
  |^ ^~~~
  |noexcept requires C;

[Bug analyzer/105898] RFE: -fanalyzer should complain about overlapping args to memcpy and mempcpy

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

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

--- Comment #3 from Tim Lange  ---
This checker is nearly finished, but is blocked by:
  https://gcc.gnu.org/pipermail/gcc/2022-July/239213.html

tl;dr: the current draft of the C standard does include new examples of how the
restrict keyword should be handled and states that two restrict-qualified
parameters are allowed to alias if they are never written in the body. Neither
my checker nor Wrestrict does check that at the moment. We yet have to decide
how to proceed with this checker.

[Bug target/99888] Add powerpc ELFv2 support for -fpatchable-function-entry*

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

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

--- Comment #9 from Segher Boessenkool  ---
(In reply to Alan Modra from comment #8)
> (In reply to Segher Boessenkool from comment #7)
> > '-fpatchable-function-entry=N[,M]'
> >  Generate N NOPs right at the beginning of each function, with the
> >  function entry point before the Mth NOP.
> 
> Bad doco.  Should be "after the Mth NOP" I think.  Or better written to
> avoid the concept of a 0th nop.  Default for M is zero, placing all nops
> after the function entry and before normal function prologue code.

It is correct as written?

Also, "M" isn't used in the current compiler (and *cannot* be used: it is a
local variable that goes out of scope after being set, patch_area_start in
process_options).

[The text is carefully written so that "anywhere before the Mth nop" will be
a valid implementation as well, btw, that perhaps explains the tortured
language here.  But maybe there is another explanation for that).

> > The nops have to be consecutive.
> 
> I hope you are making this statement based on

Based on just what is written.  "N nops right at the beginning of the
function".
Not very formal, but not open to other interpretations either.

> an analysis of the purpose of
> having M nops before the entry point and N-M after the entry point, because
> the documentation you are quoting doesn't take into account the fact that
> ELFv2 functions have two entry points.  We don't have "the" entry point.

If ELFv2 wants to do something with the LEP here, it should make some extra
flag here.  Abusing generic facilities for a different purpose never works.

> I admit I didn't analyse -fpatchable-function-entry usage in any depth
> before writing the patches in PR98125.  All I did was look at the linux
> kernel to the point of deciding that we want a patchable area after the
> local entry point to catch all calls to the function.  That would be what
> -fpatchable-function-entry=n does for ELFv2, and I think we all agree on
> that.

The PowerPC Linux kernel uses -mprofile-kernel instead, which works a lot
better for them AFAIUI.  Are people planning on changing that?

[Bug analyzer/106595] New: False positive Wanalyzer-out-of-bounds warnings in yacc generated files

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

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

Bug ID: 106595
   Summary: False positive Wanalyzer-out-of-bounds warnings in
yacc generated files
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: tlange at gcc dot gnu.org
  Target Milestone: ---

Created attachment 53445
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53445=edit
reduced httpd log with Wanalyzer-out-of-bounds false positives

The out-of-bounds checker emits some false-positives related to negative
offsets on the 'yyvsa' variable, also called 'semantic value stack'. The
analyzer isn't able to infer that the stack always has enough elements. An
exemplary log from building httpd is attached to this report.

David & I decided to leave it as is for now and merge the checker. Dependent on
how often the false-positives occur, we might auto-disable the warning on code
that looks like yacc generated code.

[Bug tree-optimization/106594] [13 Regression] sign-extensions no longer merged into addressing mode

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

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

--- Comment #2 from Tamar Christina  ---
(In reply to Richard Biener from comment #1)
> I believe this was some match.pd simplification - why does this affect the
> addressing mode?  Is the IVOPTs result different or does it differ later?

The results in IVOpts don't change aside from the changes mentioned above.  It
looks like this was previously being matched in RTL through combine.

Before we had

(insn 25 24 26 4 (set (reg:DI 118)
(sign_extend:DI (reg:SI 117))) "/app/example.c":12:35 109
{*extendsidi2_aarch64}
 (expr_list:REG_DEAD (reg:SI 117)
(nil)))
(insn 26 25 27 4 (set (reg:SI 119 [ constellation_64qam[_6] ])
(mem/u:SI (plus:DI (mult:DI (reg:DI 118)
(const_int 4 [0x4]))
(reg/f:DI 120)) [1 constellation_64qam[_6]+0 S4 A32]))
"/app/example.c":12:14 52 {*movsi_aarch64}

Trying 25 -> 26:
   25: r118:DI=sign_extend(r117:SI)
  REG_DEAD r117:SI
   26: r119:SI=[r118:DI*0x4+r120:DI]
  REG_DEAD r118:DI
  REG_EQUAL [r118:DI*0x4+`constellation_64qam']
Successfully matched this instruction:
(set (reg:SI 119 [ constellation_64qamD.3590[_6] ])
(mem/u:SI (plus:DI (mult:DI (sign_extend:DI (reg:SI 117))
(const_int 4 [0x4]))
(reg/f:DI 120)) [1 constellation_64qamD.3590[_6]+0 S4 A32]))
allowing combination of insns 25 and 26
original costs 4 + 16 = 20
replacement cost 16
deferring deletion of insn with uid = 25.
modifying insn i326: r119:SI=[sign_extend(r117:SI)*0x4+r120:DI]
  REG_DEAD r117:SI
deferring rescan insn with uid = 26.

now, instead we have


(insn 24 23 25 4 (set (reg:DI 116)
(sign_extend:DI (reg:SI 115))) "/app/example.c":12:35 126
{*extendsidi2_aarch64}
 (expr_list:REG_DEAD (reg:SI 115)
(nil)))
(insn 25 24 26 4 (set (reg:SI 117 [ constellation_64qam[_5] ])
(mem/u:SI (plus:DI (mult:DI (reg:DI 116)
(const_int 4 [0x4]))
(reg/f:DI 118)) [1 constellation_64qam[_5]+0 S4 A32]))
"/app/example.c":12:14 52 {*movsi_aarch64}

Trying 24 -> 25:
   24: r116:DI=sign_extend(r115:SI)
  REG_DEAD r115:SI
   25: r117:SI=[r116:DI*0x4+r118:DI]
  REG_DEAD r116:DI
  REG_EQUAL [r116:DI*0x4+`constellation_64qam']
Failed to match this instruction:
(set (reg:SI 117 [ constellation_64qamD.3641[_5] ])
(mem/u:SI (plus:DI (and:DI (mult:DI (subreg:DI (reg:SI 115) 0)
(const_int 4 [0x4]))
(const_int 252 [0xfc]))
(reg/f:DI 118)) [1 constellation_64qamD.3641[_5]+0 S4 A32]))


where the sign extend has suddenly turned into an and.

I don't know why though, the two input RTLs look identical to me.

[Bug tree-optimization/106594] [13 Regression] sign-extensions no longer merged into addressing mode

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |13.0
 CC||sayle at gcc dot gnu.org

--- Comment #1 from Richard Biener  ---
I believe this was some match.pd simplification - why does this affect the
addressing mode?  Is the IVOPTs result different or does it differ later?

[Bug tree-optimization/106506] [13 Regression] g++.dg/opt/pr94589-2.C FAILS after enabling floats in VRP

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  ---
Fixed.

[Bug tree-optimization/106506] [13 Regression] g++.dg/opt/pr94589-2.C FAILS after enabling floats in VRP

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

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

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

https://gcc.gnu.org/g:83e9bc792ef10d08bb952a961e8c6f567521d28d

commit r13-2032-g83e9bc792ef10d08bb952a961e8c6f567521d28d
Author: Jakub Jelinek 
Date:   Fri Aug 12 13:40:43 2022 +0200

phiopt: Remove unnecessary checks from spaceship_replacement [PR106506]

Those 2 checks were just me trying to be extra careful, the
(phires & 1) == phires and variants it is folded to of course make only
sense
for the -1/0/1/2 result spaceship, for -1/0/1 one can just use comparisons
of
phires.  We only floating point spaceship if nans aren't honored, so the
2 case is ignored, and if it is, with Aldy's changes we can simplify the
2 case away from the phi but the (phires & 1) == phires stayed.  It is safe
to treat the phires comparison as phires >= 0 even then.

2022-08-12  Jakub Jelinek  

PR tree-optimization/106506
* tree-ssa-phiopt.cc (spaceship_replacement): Don't punt for
is_cast or orig_use_lhs cases if phi_bb has 3 predecessors.

* g++.dg/opt/pr94589-2.C: New test.

[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)

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

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

Bug 106593 Summary: [13 Regression] ICE in range_on_path_entry, at 
gimple-range-path.cc:164 since r13-2020-g16b013c9d9b4d950
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106593

   What|Removed |Added

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

[Bug tree-optimization/106593] [13 Regression] ICE in range_on_path_entry, at gimple-range-path.cc:164 since r13-2020-g16b013c9d9b4d950

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

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/106593] [13 Regression] ICE in range_on_path_entry, at gimple-range-path.cc:164 since r13-2020-g16b013c9d9b4d950

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

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

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

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

commit r13-2031-g4cc0d3ebaee4b54280ff0466d8e5b351a3b5bacc
Author: Richard Biener 
Date:   Fri Aug 12 12:20:13 2022 +0200

tree-optimization/106593 - fix ICE with backward threading

With the last re-org I failed to make sure to not add SSA names
nor supported by ranger into m_imports which then triggers an
ICE in range_on_path_entry because range_of_expr returns false.

PR tree-optimization/106593
* tree-ssa-threadbackward.cc (back_threader::find_paths):
If the imports from the conditional do not satisfy
gimple_range_ssa_p don't try to thread anything.

[Bug target/106524] [12 Regression] ICE in extract_insn, at recog.cc:2791 (error: unrecognizable insn) since r12-4349-ge36206c9940d22.

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

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

Tamar Christina  changed:

   What|Removed |Added

Summary|[12/13 Regression] ICE in   |[12 Regression] ICE in
   |extract_insn, at|extract_insn, at
   |recog.cc:2791 (error:   |recog.cc:2791 (error:
   |unrecognizable insn) since  |unrecognizable insn) since
   |r12-4349-ge36206c9940d22.   |r12-4349-ge36206c9940d22.
   Target Milestone|12.2|12.3

--- Comment #3 from Tamar Christina  ---
Fixed on trunk, will backport to 12 once branch unfrozen.

[Bug target/106524] [12/13 Regression] ICE in extract_insn, at recog.cc:2791 (error: unrecognizable insn) since r12-4349-ge36206c9940d22.

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Tamar Christina :

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

commit r13-2030-gf4ff20d464f90c85919ce2e7fa63e204dcda4e40
Author: Tamar Christina 
Date:   Fri Aug 12 12:28:41 2022 +0100

sve: Fix fcmuo combine patterns [PR106524]

There's no encoding for fcmuo with zero.  This restricts the combine
patterns
from accepting zero registers.

gcc/ChangeLog:

PR target/106524
* config/aarch64/aarch64-sve.md (*fcmuo_nor_combine,
*fcmuo_bic_combine): Don't accept comparisons against zero.

gcc/testsuite/ChangeLog:

PR target/106524
* gcc.target/aarch64/sve/pr106524.c: New test.

[Bug tree-optimization/106594] New: [13 Regression] sign-extensions no longer merged into addressing mode

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

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

Bug ID: 106594
   Summary: [13 Regression] sign-extensions no longer merged into
addressing mode
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tnfchris at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64*

Since around the 5th of August (need to bisect) we no longer generate
addressing modes on load merging the sign extends.

The following example:

extern const int constellation_64qam[64];

void foo(int nbits,
 const char *p_src,
 int *p_dst) {

  while (nbits > 0U) {
char first = *p_src++;

char index1 = ((first & 0x3) << 4) | (first >> 4);

*p_dst++ = constellation_64qam[index1];

nbits--;
  }
}

used to generate

orr w3, w4, w3, lsr 4
ldr w3, [x6, w3, sxtw 2]

and now generates:

orr w0, w4, w0, lsr 4
sxtwx0, w0
ldr w0, [x6, x0, lsl 2]

at -O2 (-O1 seems to still be fine).  This is causing a regression in perf in
some of our libraries.

Looks like there's a change in how the operation is expressed.  It used to be

  first_17 = *p_src_28;
  _1 = (int) first_17;
  _2 = _1 << 4;
  _3 = (signed char) _2;

where the shift is done as an int, whereas now it's

  first_16 = *p_src_27;
  first.1_1 = (signed char) first_16;
  _2 = first.1_1 << 4;

[Bug fortran/106579] ieee_signaling_nan problem in fortran on powerpc64

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

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

Jakub Jelinek  changed:

   What|Removed |Added

  Attachment #53440|0   |1
is obsolete||

--- Comment #8 from Jakub Jelinek  ---
Created attachment 53444
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53444=edit
gcc13-builtin-issignaling.patch

This one works on x86_64/i686, now to test ppc64le and ppc64.

[Bug bootstrap/106472] No rule to make target '../libbacktrace/libbacktrace.la', needed by 'libgo.la'.

[jeffrey.rahr at baesystems dot com via Gcc-bugs]

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

Jeff Rahr  changed:

   What|Removed |Added

 CC||jeffrey.rahr at baesystems dot 
com

--- Comment #15 from Jeff Rahr  ---
I am still seeing this issue after the patch as well.

[Bug tree-optimization/106593] [13 Regression] ICE in range_on_path_entry, at gimple-range-path.cc:164 since r13-2020-g16b013c9d9b4d950

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

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed||2022-08-12
 Ever confirmed|0   |1
   Target Milestone|--- |13.0
 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org

--- Comment #1 from Richard Biener  ---
I will investigate.

[Bug tree-optimization/106593] New: [13 Regression] ICE in range_on_path_entry, at gimple-range-path.cc:164 since r13-2020-g16b013c9d9b4d950

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

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

Bug ID: 106593
   Summary: [13 Regression] ICE in range_on_path_entry, at
gimple-range-path.cc:164 since
r13-2020-g16b013c9d9b4d950
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
Blocks: 26163
  Target Milestone: ---

The following crashes, reduced from 507.cactuBSSN_r:

$ cat cactu.i
int
*PUGHInterp_DriverInterpolatePrepareParameterTable_N_boundary_points_to_omit,
*PUGHInterp_DriverInterpolatePrepareParameterTable_bbox;

double *
   
PUGHInterp_DriverInterpolatePrepareParameterTable_boundary_extrapolation_tolerance;

void
PUGHInterp_DriverInterpolatePrepareParameterTable() {
  int i;
  for (; i; i++)
if (PUGHInterp_DriverInterpolatePrepareParameterTable_bbox[i]) {
 
PUGHInterp_DriverInterpolatePrepareParameterTable_N_boundary_points_to_omit
  [i] = 0;
 
PUGHInterp_DriverInterpolatePrepareParameterTable_boundary_extrapolation_tolerance
  [i] = 0.0;
}
}

$ gcc -Ofast cactu.i -march=znver2 -c
during GIMPLE pass: threadfull
cactu.i: In function 'PUGHInterp_DriverInterpolatePrepareParameterTable':
cactu.i:8:1: internal compiler error: in range_on_path_entry, at
gimple-range-path.cc:164
8 | PUGHInterp_DriverInterpolatePrepareParameterTable() {
  | ^
0x7d243c path_range_query::range_on_path_entry(vrange&, tree_node*)
/home/marxin/Programming/gcc/gcc/gimple-range-path.cc:164
0x111bd50 path_range_query::ssa_range_in_phi(vrange&, gphi*)
/home/marxin/Programming/gcc/gcc/gimple-range-path.cc:321
0x111b27d path_range_query::range_defined_in_block(vrange&, tree_node*,
basic_block_def*)
/home/marxin/Programming/gcc/gcc/gimple-range-path.cc:348
0x111b36a path_range_query::compute_ranges_in_phis(basic_block_def*)
/home/marxin/Programming/gcc/gcc/gimple-range-path.cc:394
0x111be9c path_range_query::compute_ranges_in_block(basic_block_def*)
/home/marxin/Programming/gcc/gcc/gimple-range-path.cc:442
0x111c882 path_range_query::compute_ranges(vec const&, bitmap_head const*)
/home/marxin/Programming/gcc/gcc/gimple-range-path.cc:673
0x11a53a2 back_threader::find_taken_edge_cond(vec const&, gcond*)
/home/marxin/Programming/gcc/gcc/tree-ssa-threadbackward.cc:317
0x11a5e93 back_threader::maybe_register_path()
/home/marxin/Programming/gcc/gcc/tree-ssa-threadbackward.cc:231
0x11a645e back_threader::find_paths_to_names(basic_block_def*, bitmap_head*,
unsigned int)
/home/marxin/Programming/gcc/gcc/tree-ssa-threadbackward.cc:355
0x11a6c9b back_threader::find_paths_to_names(basic_block_def*, bitmap_head*,
unsigned int)
/home/marxin/Programming/gcc/gcc/tree-ssa-threadbackward.cc:471
0x11a7455 back_threader::find_paths(basic_block_def*, tree_node*)
/home/marxin/Programming/gcc/gcc/tree-ssa-threadbackward.cc:529
0x11a7651 back_threader::thread_blocks()
/home/marxin/Programming/gcc/gcc/tree-ssa-threadbackward.cc:943
0x11a76f8 execute
/home/marxin/Programming/gcc/gcc/tree-ssa-threadbackward.cc:1073
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
[Bug 26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)

[Bug analyzer/106539] -fanalyzer doesn't consider that realloc could shrink the buffer

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

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Tim Lange :

https://gcc.gnu.org/g:2b75b3b6a4ddc0d65a84a0cc4b00c47ae70e52c0

commit r13-2028-g2b75b3b6a4ddc0d65a84a0cc4b00c47ae70e52c0
Author: Tim Lange 
Date:   Fri Aug 12 10:26:14 2022 +0200

analyzer: consider that realloc could shrink the buffer [PR106539]

This patch adds the "shrinks buffer" case to the success_with_move
modelling of realloc.

Regression-tested on Linux x86-64, further ran the analyzer tests with
the -m32 option.

2022-08-11  Tim Lange  

gcc/analyzer/ChangeLog:

PR analyzer/106539
* region-model-impl-calls.cc (region_model::impl_call_realloc):
Use the result of get_copied_size as the size for the
sized_regions in realloc.
(success_with_move::get_copied_size): New function.

gcc/testsuite/ChangeLog:

PR analyzer/106539
* gcc.dg/analyzer/pr106539.c: New test.
* gcc.dg/analyzer/realloc-5.c: New test.

[Bug analyzer/106000] RFE: -fanalyzer should complain about memory accesses that are definitely out-of-bounds

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

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Tim Lange :

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

commit r13-2029-g7e3b45befdbbf1a1f9ff728fa2bac31b4756907c
Author: Tim Lange 
Date:   Fri Aug 12 10:27:16 2022 +0200

analyzer: out-of-bounds checker [PR106000]

This patch adds an experimental out-of-bounds checker to the analyzer.

The checker was tested on coreutils, curl, httpd and openssh. It is mostly
accurate but does produce false-positives on yacc-generated files and
sometimes when the analyzer misses an invariant. These cases will be
documented in bugzilla.
Regression-tested on Linux x86-64, further ran the analyzer tests with
the -m32 option.

2022-08-11  Tim Lange  

gcc/analyzer/ChangeLog:

PR analyzer/106000
* analyzer.opt: Add Wanalyzer-out-of-bounds.
* region-model.cc (class out_of_bounds): Diagnostics base class
for all out-of-bounds diagnostics.
(class past_the_end): Base class derived from out_of_bounds for
the buffer_overflow and buffer_overread diagnostics.
(class buffer_overflow): Buffer overflow diagnostics.
(class buffer_overread): Buffer overread diagnostics.
(class buffer_underflow): Buffer underflow diagnostics.
(class buffer_underread): Buffer overread diagnostics.
(region_model::check_region_bounds): New function to check region
bounds for out-of-bounds accesses.
(region_model::check_region_access):
Add call to check_region_bounds.
(region_model::get_representative_tree): New function that accepts
a region instead of an svalue.
* region-model.h (class region_model):
Add region_model::check_region_bounds.
* region.cc (region::symbolic_p): New predicate.
(offset_region::get_byte_size_sval): Only return the remaining
byte size on offset_regions.
* region.h: Add region::symbolic_p.
* store.cc (byte_range::intersects_p):
Add new function equivalent to bit_range::intersects_p.
(byte_range::exceeds_p): New function.
(byte_range::falls_short_of_p): New function.
* store.h (struct byte_range): Add byte_range::intersects_p,
byte_range::exceeds_p and byte_range::falls_short_of_p.

gcc/ChangeLog:

PR analyzer/106000
* doc/invoke.texi: Add Wanalyzer-out-of-bounds.

gcc/testsuite/ChangeLog:

PR analyzer/106000
* g++.dg/analyzer/pr100244.C: Disable out-of-bounds warning.
* gcc.dg/analyzer/allocation-size-3.c:
Disable out-of-bounds warning.
* gcc.dg/analyzer/memcpy-2.c: Disable out-of-bounds warning.
* gcc.dg/analyzer/pr101962.c: Add dg-warning.
* gcc.dg/analyzer/pr96764.c: Disable out-of-bounds warning.
* gcc.dg/analyzer/pr97029.c:
Add dummy buffer to prevent an out-of-bounds warning.
* gcc.dg/analyzer/realloc-5.c: Add dg-warning.
* gcc.dg/analyzer/test-setjmp.h:
Add dummy buffer to prevent an out-of-bounds warning.
* gcc.dg/analyzer/zlib-3.c: Add dg-bogus.
* g++.dg/analyzer/out-of-bounds-placement-new.C: New test.
* gcc.dg/analyzer/out-of-bounds-1.c: New test.
* gcc.dg/analyzer/out-of-bounds-2.c: New test.
* gcc.dg/analyzer/out-of-bounds-3.c: New test.
* gcc.dg/analyzer/out-of-bounds-container_of.c: New test.
* gcc.dg/analyzer/out-of-bounds-coreutils.c: New test.
* gcc.dg/analyzer/out-of-bounds-curl.c: New test.

[Bug target/106592] New: s390: Inefficient branchless conditionals for long long

[jens.seifert at de dot ibm.com via Gcc-bugs]

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

Bug ID: 106592
   Summary: s390: Inefficient branchless conditionals for long
long
   Product: gcc
   Version: 11.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jens.seifert at de dot ibm.com
  Target Milestone: ---

Created attachment 53443
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53443=edit
source code

long long gtRef(long long a, long long b)
{
   return a > b;
}

Generates:

cgr %r2,%r3
lghi%r1,0
lghi%r2,1
locgrnh %r2,%r1

Better sequence:
cgr %r2,%r3
lghi %r2,0
alcgr %r2,%r2


long long leMaskRef(long long a, long long b)
{
   return -(a <= b);
}

Generates:

cgr %r2,%r3
lhi %r1,0
lhi %r2,1
locrnle %r2,%r1
sllg%r2,%r2,63
srag%r2,%r2,63

Better sequence:

cgr %r2,%r3
slbgr %r2,%r2

long long gtMaskRef(long long a, long long b)
{
   return -(a > b);
}

Generates:
cgr %r2,%r3
lhi %r1,0
lhi %r2,1
locrnh  %r2,%r1
sllg%r2,%r2,63
srag%r2,%r2,63

Better sequence:
cgr   %r2,%r3
lghi  %r2,0
alcgr %r2,%r2
lcgr  %r2,%r2

[Bug c++/106369] [12 Regression] ICE in output_constructor_regular_field, at varasm.cc:5515 since r12-2975-g32c3a75390623a

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

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug c++/106369] [12 Regression] ICE in output_constructor_regular_field, at varasm.cc:5515 since r12-2975-g32c3a75390623a

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

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

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

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

commit r12-8684-g6b7d570a5001bb79e34c0d1626a8c7f55386dac7
Author: Jason Merrill 
Date:   Tue Jul 26 11:02:21 2022 -0400

c++: constexpr, empty base after non-empty [PR106369]

Here the CONSTRUCTOR we were providing for D{} had an entry for the B base
subobject at offset 0 following the entry for the C base, causing
output_constructor_regular_field to ICE due to going backwards.  It might
be
nice for that function to be more tolerant of empty fields, but it also
seems reasonable for the front end to prune the useless entry.

PR c++/106369

gcc/cp/ChangeLog:

* constexpr.cc (reduced_constant_expression_p): Return false
if a CONSTRUCTOR initializes an empty field.

gcc/testsuite/ChangeLog:

* g++.dg/cpp1z/constexpr-lambda27.C: New test.

(cherry picked from commit 9efe4e153d994974afcbba09c3c683f5f4a19c63)

[Bug c++/67048] [10/11/12 Regression] GCC rejects well-formed program using empty anonymous enum specifier in a variable declaration

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

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

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

https://gcc.gnu.org/g:60fed79c1e9a968eaedf292b298d19c9475ad37a

commit r12-8683-g60fed79c1e9a968eaedf292b298d19c9475ad37a
Author: Marek Polacek 
Date:   Thu Apr 28 16:50:06 2022 -0400

c++: pedwarn for empty unnamed enum in decl [PR67048]

[dcl.dcl]/5 says that

  enum { };

is ill-formed, and since r197742 we issue a pedwarn.  However, the
pedwarn also fires for

   enum { } x;

which is well-formed.  So only warn when {} is followed by a ;.  This
should be correct since you can't have "enum {}, " -- that
produces "expected unqualified-id before ',' token".

PR c++/67048

gcc/cp/ChangeLog:

* parser.cc (cp_parser_enum_specifier): Warn about empty unnamed
enum
only when it's followed by a semicolon.

gcc/testsuite/ChangeLog:

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

(cherry picked from commit fd0d3e9121c5aa65150d242676be6bbdc8d4a92a)

[Bug target/99889] Add powerpc ELFv1 support for -fpatchable-function-entry* with "o" sections

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

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

Kewen Lin  changed:

   What|Removed |Added

 CC||linkw at gcc dot gnu.org
 Ever confirmed|0   |1
   Last reconfirmed||2022-08-12
 Status|UNCONFIRMED |NEW

--- Comment #1 from Kewen Lin  ---
I think PR105169 already fixed the original issue in PR98125, although the
referenced symbol is still _Z3foov, like:

  __patchable_function_entries,"awGo",@progbits,_Z3foov,_Z3foov,comdat  //
reverted the workaround as well.

the linking works well without any errors.

[Bug target/106524] [12/13 Regression] ICE in extract_insn, at recog.cc:2791 (error: unrecognizable insn) since r12-4349-ge36206c9940d22.

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

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

Tamar Christina  changed:

   What|Removed |Added

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

[Bug c++/69410] [10/11/12/13 Regression] friend declarations in local classes

[creatorsmithmdt at gmail dot com via Gcc-bugs]

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

--- Comment #7 from Zopolis0  ---
With this change, GCC gets most of the way through bootstrapping until failing
on a issue on stage 3 specific to my machine so it seems like this doesn't
break anything.

[Bug ipa/91771] Optimization fails to inline final override.

[yinyuefengyi at gmail dot com via Gcc-bugs]

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

Xionghu Luo (luoxhu at gcc dot gnu.org)  changed:

   What|Removed |Added

 CC||yinyuefengyi at gmail dot com

--- Comment #4 from Xionghu Luo (luoxhu at gcc dot gnu.org)  ---
Just curious about the 021t.ssa dump...


int f (struct Derived & d)
{
  struct Base * _1;  
  int _5;
  int _6;

   :
  _1 = _2(D)->D.2395;
  _5 = Base::foo (_1, 40);
  _6 = _5;
  return _6;

}


d_2 is a reference to "struct Derived" type instance, so is it an unnecessary
type promotion of promoting type "_1" to "struct Base *"?  Another thing to be
noted is early inline pass inlined Base::foo into f, but it failed to
devirtualize the virtual call in it, is it possible to devirt the call if
"struct Derived * _1" is produced in ssa pass?

[Bug c++/106434] [12/13 Regression] Spurious -Wnull-dereference when using std::unique_copy() since r12-5187-g1ae8edf5f73ca5c3

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

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed||2022-08-12
 Status|UNCONFIRMED |NEW
   Priority|P3  |P2
 Ever confirmed|0   |1
   Target Milestone|--- |12.2

[Bug c++/106584] g++ not showing correct line number in "use of deleted function" error

[accelerator0099 at gmail dot com via Gcc-bugs]

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

--- Comment #5 from Devourer Station  ---
(In reply to Andrew Pinski from comment #4)
> Actually clang references the call:
> f(cl);
> 
> When it comes to the copy constructor.

At least it tells you about where the error is, otherwise you may fall into
thousands of lines of source code without knowing where to edit

[Bug sanitizer/106591] New: ASan at -O1 fails to detect a global buffer overflow

[shaohua.li at inf dot ethz.ch via Gcc-bugs]

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

Bug ID: 106591
   Summary: ASan at -O1 fails to detect a global buffer overflow
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: shaohua.li at inf dot ethz.ch
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

For the following code, `gcc-trunk -O1 -fsanitize=address` failed to detect the
global-buffer-overflow, while other opt flags (-O0, -O2, and -O3) can.

$cat a.c
a;
*b = , *d = 
volatile static **c = 

int foo(int p1, int p2) {
return p1 % p2;
}
static int* e() {
  **c;
  int *f = 
  return f + 1;
}
int main() {
  *c = e();
  *d = 1;
  foo(**c, *d);
}
$
$gcc-trunk -O1 -fsanitize=address -w -g && ./a.out
$
$gcc-trunk -O2 -fsanitize=address -w -g && ./a.out
=
==1==ERROR: AddressSanitizer: global-buffer-overflow on address 0x00404224
at pc 0x0040113b bp 0x73ecdca0 sp 0x73ecdc98
READ of size 4 at 0x00404224 thread T0
#0 0x40113a in main /app/a.c:16
#1 0x7f68868750b2 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x240b2) (BuildId:
9fdb74e7b217d06c93172a8243f8547f947ee6d1)
#2 0x4011ad in _start (/app/output.s+0x4011ad) (BuildId:
db3aa359dc97f1881309f971535063412033e172)

0x00404224 is located 0 bytes to the right of global variable 'a' defined
in '/app/a.c:1:1' (0x404220) of size 4
SUMMARY: AddressSanitizer: global-buffer-overflow /app/a.c:16 in main
Shadow bytes around the buggy address:
  0x800787f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x80078800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x80078810: 00 f9 f9 f9 f9 f9 f9 f9 00 f9 f9 f9 f9 f9 f9 f9
  0x80078820: 00 00 00 00 00 00 00 00 f9 f9 f9 f9 f9 f9 f9 f9
  0x80078830: f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9
=>0x80078840: 00 00 00 00[04]f9 f9 f9 f9 f9 f9 f9 00 00 00 00
  0x80078850: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x80078860: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x80078870: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x80078880: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x80078890: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:   00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:   fa
  Freed heap region:   fd
  Stack left redzone:  f1
  Stack mid redzone:   f2
  Stack right redzone: f3
  Stack after return:  f5
  Stack use after scope:   f8
  Global redzone:  f9
  Global init order:   f6
  Poisoned by user:f7
  Container overflow:  fc
  Array cookie:ac
  Intra object redzone:bb
  ASan internal:   fe
  Left alloca redzone: ca
  Right alloca redzone:cb
==1==ABORTING

[Bug rtl-optimization/106590] [12/13 Regression] x86-64 miscompilation starting with r12-8233-g1ceddd7497e15d w/ mtune=skylake

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
  Known to fail||12.1.0
 CC||jakub at gcc dot gnu.org

[Bug middle-end/106582] Wrong code generation resulting in HardFault

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

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

--- Comment #8 from Richard Biener  ---
(In reply to Piotr from comment #3)
> (In reply to Richard Biener from comment #1)
> > Can you provide preprocessed source of the file where the crash occurs and
> > the compiler commandline?  Can you also try GCC 10.4 (or a compiler built
> > from
> > the GCC 10 branch head) or possibly even GCC 12.1 to see if the issue still
> > reproduces there?
> 
> Attached preprocessed file. 
> 
> The compiler comes with STMCubeIDE and I would not manually change it. Full
> command line is in the original post (excluding include and library files
> and paths)

Just to note besides the conversation with Andrew - if you got the compiler
from some vendor and are not willing to try a plain version from upstream it
might be useful to report it to the vendor - those often apply changes to GCC
we do not know about and of course those might also introduce bugs (and I hope
they are interested in such bugreports).

[Bug libstdc++/106589] [12/13 Regression] visit rejects lambdas that do not return void

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||needs-bisection
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-08-12
 Ever confirmed|0   |1

--- Comment #2 from Andrew Pinski  ---
Confirmed. A regression from GCC 11.3.0.

[Bug libstdc++/106589] [12/13 Regression] visit rejects lambdas that do not return void

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|visit rejects lambdas |[12/13 Regression]
   |that do not return void |visit rejects lambdas
   ||that do not return void
  Known to work||11.3.0
   Target Milestone|--- |12.2
  Known to fail||12.1.0