[Bug c++/109205] New: vector.resize( v.size() + 100 ) does unnecessary comparison

[joerg.richter--- via Gcc-bugs]

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

Bug ID: 109205
   Summary: vector.resize( v.size() + 100 ) does unnecessary
comparison
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: joerg.rich...@pdv-fs.de
  Target Milestone: ---

This function:

#include 

void testResize( std::vector & v )
{
  v.resize( v.size() + 100 );
}


Will compile (-O2) to something like this:

mov rcx, QWORD PTR [rdi+8]
mov rax, QWORD PTR [rdi]
mov rdx, rcx
sub rdx, rax
lea rsi, [rdx+100]
cmp rdx, rsi
jb  .L39
add rax, rsi
cmp rcx, rax
je  .L36
mov QWORD PTR [rdi+8], rax
.L36:
ret
.L39:
mov esi, 100
jmp std::vector
>::_M_default_append(unsigned long)

The call to _M_default_append is guarded by a cmp.  This seems unnecessary, as
the argument passed to resize is always bigger than size.  

Doing the addition with a signed type does not change the result.

See: https://godbolt.org/z/xY77fsz4z

[Bug fortran/109206] New: [13 Regression] gcc/fortran/class.cc:2768:14: runtime error: load of value 4139789424, which is not a valid value for type 'bt' since r13-6747-gd7caf313525a46

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

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

Bug ID: 109206
   Summary: [13 Regression] gcc/fortran/class.cc:2768:14: runtime
error: load of value 4139789424, which is not a valid
value for type 'bt' since r13-6747-gd7caf313525a46
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: pault at gcc dot gnu.org
  Target Milestone: ---

The following test-case fails with UBSAN enabled:

$ cat finalize_38a.f90
module testmode
  type simple
integer ind
  end type 
  type, extends(simple) :: complicated
real rind
  contains
final destructor4
  end type 
contains
  subroutine destructor4(self)
type(complicated)  self
  end  
  function constructor2(rind)
 optional  rind
type(complicated), allocatable :: src(:)
integer sz
if (present (rind)) then
  src  = [(complicated (ind0, rind0), i = 1, sz)]   
end if
  end  
  end

$ /dev/shm/objdir2/gcc/xgcc -B/dev/shm/objdir2/gcc/ finalize_38a.f90 -c
-std=f2008
finalize_38a.f90:19:56:

   19 |   src  = [(complicated (ind0, rind0), i = 1, sz)]
  |1
Warning: The structure constructor at (1) has been finalized. This feature was
removed by f08/0011. Use -std=f2018 or -std=gnu to eliminate the finalization.
/home/marxin/Programming/gcc/gcc/fortran/class.cc:2768:14: runtime error: load
of value 4139789424, which is not a valid value for type 'bt'
#0 0xab7ec1 in gfc_may_be_finalized(gfc_typespec)
/home/marxin/Programming/gcc/gcc/fortran/class.cc:2768
#1 0xed949d in gfc_trans_array_constructor_value
/home/marxin/Programming/gcc/gcc/fortran/trans-array.cc:2309
#2 0xede7b7 in trans_array_constructor
/home/marxin/Programming/gcc/gcc/fortran/trans-array.cc:2936
#3 0xee0956 in gfc_add_loop_ss_code
/home/marxin/Programming/gcc/gcc/fortran/trans-array.cc:3229
#4 0xef7ce6 in gfc_conv_loop_setup(gfc_loopinfo*, locus*)
/home/marxin/Programming/gcc/gcc/fortran/trans-array.cc:5526
#5 0x10270a6 in gfc_trans_assignment_1
/home/marxin/Programming/gcc/gcc/fortran/trans-expr.cc:11789
#6 0x102a9e2 in gfc_trans_assignment(gfc_expr*, gfc_expr*, bool, bool,
bool, bool) /home/marxin/Programming/gcc/gcc/fortran/trans-expr.cc:12251
#7 0x102ab73 in gfc_trans_assign(gfc_code*)
/home/marxin/Programming/gcc/gcc/fortran/trans-expr.cc:12264
#8 0xec3f1b in trans_code
/home/marxin/Programming/gcc/gcc/fortran/trans.cc:2229
#9 0xec497c in gfc_trans_code(gfc_code*)
/home/marxin/Programming/gcc/gcc/fortran/trans.cc:2582
#10 0x110ae45 in gfc_trans_if_1
/home/marxin/Programming/gcc/gcc/fortran/trans-stmt.cc:1487
#11 0x110b1bf in gfc_trans_if(gfc_code*)
/home/marxin/Programming/gcc/gcc/fortran/trans-stmt.cc:1519
#12 0xec42e3 in trans_code
/home/marxin/Programming/gcc/gcc/fortran/trans.cc:2317
#13 0xec497c in gfc_trans_code(gfc_code*)
/home/marxin/Programming/gcc/gcc/fortran/trans.cc:2582
#14 0xfa0df6 in gfc_generate_function_code(gfc_namespace*)
/home/marxin/Programming/gcc/gcc/fortran/trans-decl.cc:7714
#15 0xec55d8 in gfc_generate_module_code(gfc_namespace*)
/home/marxin/Programming/gcc/gcc/fortran/trans.cc:2649
#16 0xcff92f in translate_all_program_units
/home/marxin/Programming/gcc/gcc/fortran/parse.cc:6707
#17 0xd00f09 in gfc_parse_file()
/home/marxin/Programming/gcc/gcc/fortran/parse.cc:7026
#18 0xe822bb in gfc_be_parse_file
/home/marxin/Programming/gcc/gcc/fortran/f95-lang.cc:229
#19 0x278e9f1 in compile_file
/home/marxin/Programming/gcc/gcc/toplev.cc:444
#20 0x2796c4b in do_compile /home/marxin/Programming/gcc/gcc/toplev.cc:2125
#21 0x27974c1 in toplev::main(int, char**)
/home/marxin/Programming/gcc/gcc/toplev.cc:2277
#22 0x69f084d in main /home/marxin/Programming/gcc/gcc/main.cc:39
#23 0x7722caef in __libc_start_call_main
../sysdeps/nptl/libc_start_call_main.h:58
#24 0x7722cbb8 in __libc_start_main_impl ../csu/libc-start.c:360
#25 0xa3c164 in _start ../sysdeps/x86_64/start.S:115

[Bug fortran/109206] [13 Regression] gcc/fortran/class.cc:2768:14: runtime error: load of value 4139789424, which is not a valid value for type 'bt' since r13-6747-gd7caf313525a46

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

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

Martin Liška  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2023-03-20
   Target Milestone|--- |13.0
 Status|UNCONFIRMED |NEW

[Bug target/109189] Format string warnings in gcc/config/h8300/h8300.cc under MigW-W64/MSYS2

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Given that all values printed that way are 0..0xff or 0..0x, I think better
would be to cast those to unsigned int and use %u, or cast to long and keep
using %ld.
C/C++ guarantee int is at least 16-bit and long is at least 32-bit, which is
enough to hold all those values.
So say instead of
fprintf (file, "#%ld", (INTVAL (x) >> 8) & 0xff);
use
fprintf (file, "#%ld", (long) ((INTVAL (x) >> 8) & 0xff));
or
fprintf (file, "#%u", (unsigned) ((INTVAL (x) >> 8) & 0xff));
(the & 0xff cases can be even (int) and %d) rather than the even longer
fprintf (file, "#" HOST_WIDE_INT_PRINT_DEC, (INTVAL (x) >> 8) & 0xff);

[Bug target/104713] gcc does not reject -march=i686 -fcf-protection

[jay+ggcc--- via Gcc-bugs]

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

James Addison  changed:

   What|Removed |Added

 CC||jay+g...@jp-hosting.net

--- Comment #5 from James Addison  ---
Adrian wrote:
> To support the Geode in OLPC, the toolchain definition of i686 does include 
> CMOV but it does not include multi-byte NOPs.
...
> Sorry for being unclear, this is the historical reason why the binutils/gcc 
> definition of i686 does not include multi-byte NOPs.

Jakub wrote:
> Just build for those as -march=i586. preventing -fcf-protection with 
> -march=i686 would be a really bad idea, that would basically prevent all of 
> CET protection for 32-bit code, i686 is what is used as the supported lowest 
> common denominator of 32-bit code.

Could the findings indicate that there are two bugs here?

  - The Geode LX target capable of supporting fcf-protection but GCC-11
currently rejects that architecture and flag combination (in the
potentially-buggy code[1] that Adrian refers to)

  - Multi-byte NOPs are emitted for architecture i686 by GCC-11, despite some
CPUs within that architecture lacking[2] support


Also potentially relevant is bug 41989.

[1] -
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/i386/i386-options.cc;h=805539364108eee07f5bda527acd6f39f3f7bf95;hb=HEAD#l2929

[2] - https://bugzilla.redhat.com/show_bug.cgi?id=579838#c32

[Bug target/104713] gcc does not reject -march=i686 -fcf-protection

[bunk at stusta dot de via Gcc-bugs]

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

--- Comment #6 from Adrian Bunk  ---
(In reply to James Addison from comment #5)
> Could the findings indicate that there are two bugs here?
> 
>   - The Geode LX target capable of supporting fcf-protection but GCC-11
> currently rejects that architecture and flag combination

The problem is the opposite.

[Bug libfortran/109207] New: Uninitialised static variables in unit.c

[carsten.dehning at scai dot fraunhofer.de via Gcc-bugs]

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

Bug ID: 109207
   Summary: Uninitialised static variables in unit.c
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libfortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: carsten.dehning at scai dot fraunhofer.de
  Target Milestone: ---

libfortran  unit.c,  valgrind complaints, possible segfault due to missing
proper initialization with NULL.

Line 336ff:   
 if (unit_cache[c] != NULL && unit_cache[c]->unit_number == n)

Initially unit_cache[0..2] is not NULL.

Fixes:

line 98:   static gfc_unit *unit_cache[CACHE_SIZE] = {NULL};
line 103:  gfc_unit *unit_root = NULL;

[Bug c/109208] New: gcc doesn't detect when sizes are booleans

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 109208
   Summary: gcc doesn't detect when sizes are booleans
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Some standard C functions accept sizes as arguments. memcmp, strcmp etc.

gcc doesn't detect when programmers get the ( and ) wrong and provide a
boolean.

An example would be:

# include 

extern void g( const char *);

void f( const char * response)
{
if (!response || strncmp(response, "GDM ", strlen("GDM ") != 0)) 
{
g( response);
}
}

$ ~/gcc/results/bin/gcc -c -g -O2 -Wall -Wextra mar20b.cc
$ 

Here is clang:

$ clang++ -c  mar20b.cc
mar20b.cc:7:60: warning: size argument in 'strncmp' call is a comparison
[-Wmemsize-comparison]
if (!response || strncmp(response, "GDM ", strlen("GDM ") != 0)) 
   ~~~^~~~
mar20b.cc:7:19: note: did you mean to compare the result of 'strncmp' instead?
if (!response || strncmp(response, "GDM ", strlen("GDM ") != 0)) 
 ^~
 )
mar20b.cc:7:45: note: explicitly cast the argument to size_t to silence this
warning
if (!response || strncmp(response, "GDM ", strlen("GDM ") != 0)) 
   ^
   (size_t)(  )
1 warning generated.

and here is cppcheck:

$ ~/cppcheck/trunk/cppcheck mar20b.cc
mar20b.cc:7:60: error: Invalid strncmp() argument nr 3. A non-boolean value is
required. [invalidFunctionArgBool]
 if (!response || strncmp(response, "GDM ", strlen("GDM ") != 0))
   ^
$

[Bug tree-optimization/109176] [13 Regression] internal compiler error: in to_constant, at poly-int.h:504

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
   Keywords||needs-bisection
Summary|internal compiler error: in |[13 Regression] internal
   |to_constant, at |compiler error: in
   |poly-int.h:504  |to_constant, at
   ||poly-int.h:504

[Bug target/109178] ICE using __builtin_vec_xst_trunc built-in

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|13.0|---

[Bug preprocessor/109183] [regression?] since GCC 11.1, -MM -MMD generates "a-" prefixed dependency files

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||aoliva at gcc dot gnu.org

--- Comment #1 from Richard Biener  ---
It's expected, there might be a way to get back the old behavior.  Alex can
probably explain.

[Bug tree-optimization/109184] [10/11/12/13 Regression] csmith: 2017 bug with -floop-interchange

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #5 from Richard Biener  ---
I will try to have a look.

[Bug fortran/109209] New: [13.0 regression] erroneous error on assignment of alloctables

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

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

Bug ID: 109209
   Summary: [13.0 regression] erroneous error on assignment of
alloctables
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: juergen.reuter at desy dot de
  Target Milestone: ---

Some commit between last week and now, so between March 12 and March 19, has
created a regression, so gfortran throws a (presumably wrong) error message:
resonances_sub.f90:816:4:
  816 | history_new(1:s) = res_set%history(1:s)
  |1
Error: Component to the right of a part reference with nonzero rank must not
have the ALLOCATABLE attribute at (1)
resonances_sub.f90:816:23:
  816 | history_new(1:s) = res_set%history(1:s)
  |   1
Error: Component to the right of a part reference with nonzero rank must not
have the ALLOCATABLE attribute at (1)

This is a first part of the code below, I will hopefully provide a full
reproducer later one.


   810module subroutine resonance_history_set_expand (res_set)
   811  class(resonance_history_set_t), intent(inout) :: res_set
   812  type(resonance_history_t), dimension(:), allocatable :: history_new
   813  integer :: s
   814  s = size (res_set%history)
   815  allocate (history_new (2 * s))
   816  history_new(1:s) = res_set%history(1:s)
   817  call move_alloc (history_new, res_set%history)
   818end subroutine resonance_history_set_expand

   58type :: resonance_info_t
59   type(flavor_t) :: flavor
60   type(resonance_contributors_t) :: contributors
61contains
62   procedure :: copy => resonance_info_copy
63   procedure :: write => resonance_info_write
64   procedure, private :: resonance_info_init_pdg
65   procedure, private :: resonance_info_init_flv
66   generic :: init => resonance_info_init_pdg,
resonance_info_init_flv
67   procedure, private :: resonance_info_equal
68   generic :: operator(==) => resonance_info_equal
69   procedure :: mapping => resonance_info_mapping
70   procedure, private :: get_n_contributors =>
resonance_info_get_n_contributors
71   procedure, private :: contains => resonance_info_contains
72   procedure :: evaluate_distance => resonance_info_evaluate_distance
73   procedure :: evaluate_gaussian => resonance_info_evaluate_gaussian
74   procedure :: is_on_shell => resonance_info_is_on_shell
75   procedure :: as_omega_string => resonance_info_as_omega_string
76end type resonance_info_t
77  
78type :: resonance_history_t
79   type(resonance_info_t), dimension(:), allocatable :: resonances
80   integer :: n_resonances = 0
81contains
82   procedure :: clear => resonance_history_clear
83   procedure :: copy => resonance_history_copy
84   procedure :: write => resonance_history_write
85   procedure, private :: resonance_history_assign
86   generic :: assignment(=) => resonance_history_assign
87   procedure, private :: resonance_history_equal
88   generic :: operator(==) => resonance_history_equal
89   procedure, private :: resonance_history_contains
90   generic :: operator(.contains.) => resonance_history_contains
91   procedure :: add_resonance => resonance_history_add_resonance
92   procedure :: remove_resonance =>
resonance_history_remove_resonance
93   procedure :: add_offset => resonance_history_add_offset
94   procedure :: contains_leg => resonance_history_contains_leg
95   procedure :: mapping => resonance_history_mapping
96   procedure :: only_has_n_contributors => &
97resonance_history_only_has_n_contributors
98   procedure :: has_flavor => resonance_history_has_flavor
99   procedure :: evaluate_distances =>
resonance_history_evaluate_distances
   100   procedure :: evaluate_gaussian =>
resonance_history_evaluate_gaussian
   101   procedure :: is_on_shell => resonance_history_is_on_shell
   102   procedure :: as_omega_string => resonance_history_as_omega_string
   103   procedure :: to_tree => resonance_history_to_tree
   104end type resonance_history_t

  129type :: resonance_history_set_t
   130   private
   131   logical :: complete = .false.
   132   integer :: n_filter = 0
   133   type(resonance_history_t), dimension(:), allocatable :: history
   134   type(index_array_t), dimension(:), allocatable :: contains_this
   135   type(resonance_tree_t), dimension(:), allocatable :: tree
   136   integer :: last = 0
   137 contains
   138   procedure :: write => resonance_history_set_write
   139   procedure :: i

[Bug fortran/109206] [13 Regression] gcc/fortran/class.cc:2768:14: runtime error: load of value 4139789424, which is not a valid value for type 'bt' since r13-6747-gd7caf313525a46

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P4

[Bug fortran/109209] [13 regression] erroneous error on assignment of alloctables

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P4
Summary|[13.0 regression] erroneous |[13 regression] erroneous
   |error on assignment of  |error on assignment of
   |alloctables |alloctables
   Target Milestone|--- |13.0

[Bug libstdc++/109182] unused parameter pack is in expected(in_place_t)

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

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

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

https://gcc.gnu.org/g:5194ad1958cbfe800357571fad68be8bc8b7d915

commit r13-6759-g5194ad1958cbfe800357571fad68be8bc8b7d915
Author: Jonathan Wakely 
Date:   Mon Mar 20 09:30:58 2023 +

libstdc++: Remove template-head from std::expected ctor [PR109182]

The presence of a template-head on this constructor is a copy & paste
error from the primary template.

libstdc++-v3/ChangeLog:

PR libstdc++/109182
* include/std/expected (expected::expected(in_place_t)):
Remove template-head.

[Bug tree-optimization/109176] [13 Regression] internal compiler error: in to_constant, at poly-int.h:504

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

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

--- Comment #3 from ktkachov at gcc dot gnu.org ---
Created attachment 54708
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54708&action=edit
Reduced testcase

Reduced testcase ICEs at -O2

[Bug libstdc++/109182] unused parameter pack is in expected(in_place_t)

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
   Last reconfirmed||2023-03-20
   Target Milestone|--- |12.3

--- Comment #2 from Jonathan Wakely  ---
Thanks, it's just a typo.

[Bug c++/99934] bad_array_new_length thrown when non-throwing allocation function would have been used

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||barry.revzin at gmail dot com

--- Comment #2 from Jonathan Wakely  ---
*** Bug 93016 has been marked as a duplicate of this bug. ***

[Bug c++/93016] erroneous new (nothrow_t) still throws an exception

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #3 from Jonathan Wakely  ---
PR 99934 is a dup of this, with more info, so let's close this one.

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

[Bug libstdc++/109203] sort(zip(v1, v2)) fails to compile

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

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

--- Comment #4 from Jonathan Wakely  ---
Technically, that's needed for libstdc++ too, it just happens to work "by
accident" without it.

[Bug gcov-profile/109210] New: Bogus use of __builtin_expect defined by PHI arguments

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

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

Bug ID: 109210
   Summary: Bogus use of __builtin_expect defined by PHI arguments
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

gcc.dg/predict-20.c shows how we bogously apply a __builtin_expect value from
a PHI def without considering the guarding condition.  We have from the
loop exit block

   _2 = b.0_1 < 0;
   _3 = (long int) _2;
   _4 = __builtin_expect (_3, 0);
   if (_4 != 0)
 goto ; [10.00%]

and the __builtin_expect guarding the asm() is CSEd to the above and the
block looks like

[local count: 977105059]:
   # _9 = PHI <_4(3), 0(4)>
   if (_9 != 0)
 goto ; [10.00%]
   else
 goto ; [90.00%]

we are blindly handling _4 as having a value zero with probability 90%
for the first PHI argument, then merging with zero on the other edge
and using that as predictor for _9.  But we fail to account for the
__builtin_expect inversion implied by the condition on the 3->5 edge.

We're somehow lucky in the end and the profile looks good.  With a proposed
patch that propagates the equivalence using value-range info we'd get

[local count: 977105059]:
   # _9 = PHI <1(3), 0(4)>

(also showing the prediction is bad) and we no longer predict anything.

If we'd simply resort to look for recorded predictions on the edges we'd
discover a __builtin_expect unlikely on 3->5 and likely on the other.
If we then just take the likely constant (zero) as prediction the testcase
would work again (but probability of the incoming edge is not a good measure
for the count we'd end up here?)

[Bug c++/93016] erroneous new (nothrow_t) still throws an exception

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

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

--- Comment #4 from Jonathan Wakely  ---
(In reply to Nikita Kniazev from comment #2)
> This is a regression since GCC 6 https://godbolt.org/z/7WbYb9a7j

Not really. The difference is that GCC 6 defaults to -std=gnu++14 but if you
use that (or -std=c++11) with GCC 5 you get the same behaviour.

[Bug c++/102514] The allocation function shall not be called when existing an erroneous expression in noptr-new-declarator

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=99934
 Resolution|--- |DUPLICATE
 Status|UNCONFIRMED |RESOLVED

--- Comment #3 from Jonathan Wakely  ---
This is Bug 99934

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

[Bug c++/99934] bad_array_new_length thrown when non-throwing allocation function would have been used

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=102514
 CC||xmh970252187 at gmail dot com

--- Comment #3 from Jonathan Wakely  ---
*** Bug 102514 has been marked as a duplicate of this bug. ***

[Bug fortran/109211] New: f951: internal compiler error: in gfc_current_interface_head

[volker.weissmann at gmx dot de via Gcc-bugs]

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

Bug ID: 109211
   Summary: f951: internal compiler error: in
gfc_current_interface_head
   Product: gcc
   Version: 12.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: volker.weissmann at gmx dot de
  Target Milestone: ---

My compiler told me to submit a bug report, so here I go:

$ cat bug.f90
module child
contains
module procedure childprod
print *,123
end procedure childprod
end submodule child
$ gfortran -freport-bug -c bug.f90
f951: internal compiler error: in gfc_current_interface_head, at
fortran/interface.cc:4890
0x193c404 internal_error(char const*, ...)
???:0
0x644496 fancy_abort(char const*, int, char const*)
???:0
0x68894d gfc_match_modproc()
???:0
0x734ef4 gfc_parse_file()
???:0
Please submit a full bug report, with preprocessed source.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c++/99934] bad_array_new_length thrown when non-throwing allocation function would have been used

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed|2022-03-28 00:00:00 |2023-3-20

--- Comment #4 from Jonathan Wakely  ---
Another case from Bug 102514:

namespace std {
  using size_t = decltype(sizeof(0));
}

extern "C" void abort();
extern "C" int puts(const char*);

int main()
{
  int n = -1;
  struct C {
void* operator new[](std::size_t n) noexcept(false) {
  puts("C::operator new[] called");
  abort();
}
  };
  C* ptr = new C[n];
}

C::operator new[] called
Aborted (core dumped)


I guess we don't throw bad_array_new_length here because sizeof(C) * size_t(-1)
fits in size_t. But it's still larger than the maximum possible object size,
and in any case, the expression n is less than zero so is erroneous so operator
new should never be called. The compiler should throw bad_array_new_length.

Similarly for this one with a non-throwing operator new[]:

namespace std {
  using size_t = decltype(sizeof(0));
}

extern "C" void abort();
extern "C" int puts(const char*);

int main()
{
  int n = -1;
  struct C2 {
void* operator new[](std::size_t n) noexcept(true) {
  puts("C2::operator new[] called");
  abort();
}
  };
  C2* ptr = new C2[n];
}

The sizeof(C2) * size_t(-1) result fits in size_t, so G++ calls the operator
new[]. But the expression is still erroneous, and so the compiler should just
produce a null pointer without calling C2::operator new[].

[Bug libstdc++/106477] With -fno-exception operator new(nothrow) aborts instead of returning null

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

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

--- Comment #9 from Jonathan Wakely  ---
(In reply to Nikita Kniazev from comment #8)
> bug 93016 might be related?

Not really. This is about the behaviour of the library's operator new. In 93016
the compiler should never even call the library function, because the
new-expression is erroneous.

[Bug tree-optimization/109192] [13 Regression] timeout with -O3 since r13-5579

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2023-03-20
Summary|[13 Regression] timeout |[13 Regression] timeout
   |with -O3 -fno-var-tracking  |with -O3 since r13-5579
   |since r13-5579  |
   Priority|P3  |P1

--- Comment #5 from Richard Biener  ---
Confirmed - this has nothing to do with -fno-var-tracking btw but reproduces
with just -O3 vs -O2.  An interrupted (after a minute) perf profile shows

+   55.46% 0.66%  1769  cc1  cc1 [.]
operator_cast::op1_range  #
+   48.68% 0.05%   141  cc1  cc1 [.]
operator_cast::fold_range #
+   48.63% 3.06%  8238  cc1  cc1 [.]
operator_cast::fold_range #
+   27.27% 1.18%  3160  cc1  cc1 [.]
irange::set_nonzero_bits  #
+   25.39% 1.68%  4512  cc1  cc1 [.]
irange::set_range_from_nonzero_bits   #
+   21.08% 0.74%  1998  cc1  cc1 [.]
irange::get_nonzero_bits  #
+   20.34%14.24% 38289  cc1  cc1 [.]
irange::get_nonzero_bits_from_range   

and we're in the 'thread'(200) pass

  NEXT_PASS (pass_fre, false /* may_iterate */);
  /* After late FRE we rewrite no longer addressed locals into SSA
 form if possible.  */
  NEXT_PASS (pass_thread_jumps, /*first=*/false);
  NEXT_PASS (pass_dominator, false /* may_peel_loop_headers_p */);
  NEXT_PASS (pass_strlen);

interrupting gives a backtrace like

#2  0x0196ec95 in gori_compute::compute_operand_range (
this=this@entry=0x47bd5e0, r=..., stmt=, 
lhs=..., name=name@entry=, src=..., 
rel=)
at /space/rguenther/src/gcc/gcc/gimple-range-gori.cc:700
...
#211 0x0196f37b in gori_compute::compute_operand_range (
this=this@entry=0x47bd5e0, r=..., 
stmt=stmt@entry=, lhs=..., 
name=name@entry=, src=..., 
rel=)
at /space/rguenther/src/gcc/gcc/gimple-range-gori.cc:702
#212 0x01970ec9 in gori_compute::outgoing_edge_range_p (
this=this@entry=0x47bd5e0, r=..., 
e=e@entry= 126)>, 

name=name@entry=, q=...)
at /space/rguenther/src/gcc/gcc/gimple-range-gori.cc:1358
#213 0x00e4aa79 in path_range_query::compute_ranges_in_block (
this=this@entry=0x7fff9c936a40, 
bb=bb@entry=)
at /space/rguenther/src/gcc/gcc/gimple-range-path.cc:454

so 200 frames worth of recursion (just luck from some random gdb attach).
There are just 201 BBs in the function (func_36.constprop) and 1525
SSA names, so this seems to be quadraticness / missed caching.

[Bug tree-optimization/108819] [12 Regression] ICE on valid code at -O1 with "-fno-tree-ccp -fno-tree-forwprop" on x86_64-linux-gnu: tree check: expected ssa_name, have integer_cst in number_of_iterat

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #9 from Jakub Jelinek  ---
Fixed also for GCC 12.3.

[Bug target/108881] "__builtin_ia32_cvtne2ps2bf16_v16hi" compiled only with option -mavx512bf16 report ICE.

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

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

--- Comment #8 from Jakub Jelinek  ---
Fixed for 12.3 too.

[Bug middle-end/108854] [10/11 Regression] tbb-2021.8.0 fails on i686-linux (32-bit), internal compiler error: in expand_expr_real_1, at expr.c:10281 since r10-4511-g6cf67b62c8cda035dccac

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

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[10/11/12 Regression]   |[10/11 Regression]
   |tbb-2021.8.0 fails on   |tbb-2021.8.0 fails on
   |i686-linux (32-bit),|i686-linux (32-bit),
   |internal compiler error: in |internal compiler error: in
   |expand_expr_real_1, at  |expand_expr_real_1, at
   |expr.c:10281 since  |expr.c:10281 since
   |r10-4511-g6cf67b62c8cda035d |r10-4511-g6cf67b62c8cda035d
   |ccac|ccac

--- Comment #16 from Jakub Jelinek  ---
Fixed for 12.3 too.

[Bug debug/108967] [11 Regression] internal compiler error: in expand_debug_expr, at cfgexpand.cc:5450

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

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[11/12 Regression] internal |[11 Regression] internal
   |compiler error: in  |compiler error: in
   |expand_debug_expr, at   |expand_debug_expr, at
   |cfgexpand.cc:5450   |cfgexpand.cc:5450

--- Comment #9 from Jakub Jelinek  ---
Fixed for 12.3 too.

[Bug libquadmath/87204] strtoflt128 produces different results for subnormals with -m32 and -m64

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

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

--- Comment #6 from Jakub Jelinek  ---
Fixed for 12.3 too.

[Bug debug/108716] [10/11 Regression] Incorrect DW_AT_decl_{line,column} in DW_TAG_imported_decl

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

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[10/11/12 Regression]   |[10/11 Regression]
   |Incorrect   |Incorrect
   |DW_AT_decl_{line,column} in |DW_AT_decl_{line,column} in
   |DW_TAG_imported_decl|DW_TAG_imported_decl

--- Comment #5 from Jakub Jelinek  ---
Fixed for 12.3 too.

[Bug c++/108934] [12 Regression] bit_cast'ing to long double errors out with "the argument cannot be interpreted" since gcc-12

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #10 from Jakub Jelinek  ---
Fixed for 12.3 too.

[Bug libquadmath/94756] strtoflt128 assigns some subnormals incorrectly on MS Windows

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

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

--- Comment #20 from Jakub Jelinek  ---
Fixed for 12.3 too.

[Bug c/107465] [10/11 Regression] Bogus warning: promoted bitwise complement of an unsigned value is always nonzero

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

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[10/11/12 Regression] Bogus |[10/11 Regression] Bogus
   |warning: promoted bitwise   |warning: promoted bitwise
   |complement of an unsigned   |complement of an unsigned
   |value is always nonzero |value is always nonzero

--- Comment #14 from Jakub Jelinek  ---
Fixed for 12.3 too.

[Bug c/108986] [11 Regression] Incorrect warning for [static] array parameter

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

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[11/12 Regression]  |[11 Regression] Incorrect
   |Incorrect warning for   |warning for [static] array
   |[static] array parameter|parameter

--- Comment #8 from Jakub Jelinek  ---
Fixed for 12.3 too.

[Bug c/109151] UBsan misses a divide-by-zero

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

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

--- Comment #6 from Jakub Jelinek  ---
Fixed for 12.3 too.

[Bug c++/109039] [12 Regression] Miscompilation with no_unique_address and bitfields

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #8 from Jakub Jelinek  ---
Fixed for 12.3 too.

[Bug testsuite/108973] [10/11 Regression] Sufficiently narrow terminal window causes selftest failure

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

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[10/11/12 Regression]   |[10/11 Regression]
   |Sufficiently narrow |Sufficiently narrow
   |terminal window causes  |terminal window causes
   |selftest failure|selftest failure

--- Comment #9 from Jakub Jelinek  ---
Fixed for 12.3 too.

[Bug target/105554] [10/11 Regression] ICE: in emit_block_move_hints, at expr.cc:1829 since r9-5509-g5928bc2ec06dd4e7

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

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[10/11/12 Regression] ICE:  |[10/11 Regression] ICE: in
   |in emit_block_move_hints,   |emit_block_move_hints, at
   |at expr.cc:1829 since   |expr.cc:1829 since
   |r9-5509-g5928bc2ec06dd4e7   |r9-5509-g5928bc2ec06dd4e7

--- Comment #24 from Jakub Jelinek  ---
Fixed for 12.3 too.

[Bug c/108079] [10/11 Regression] -Wunused-variable gives misleading duplicate warning for unused static local variable

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

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[10/11/12 Regression]   |[10/11 Regression]
   |-Wunused-variable gives |-Wunused-variable gives
   |misleading duplicate|misleading duplicate
   |warning for unused static   |warning for unused static
   |local variable  |local variable

--- Comment #7 from Jakub Jelinek  ---
Fixed for 12.3 too.

[Bug c++/107558] [10/11 Regression] ICE in fld_incomplete_type_of with -fmerge-all-constants and openmp and LTO since r11-16-ga2f32550a085984f

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

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[10/11/12 Regression] ICE   |[10/11 Regression] ICE in
   |in fld_incomplete_type_of   |fld_incomplete_type_of with
   |with -fmerge-all-constants  |-fmerge-all-constants and
   |and openmp and LTO since|openmp and LTO since
   |r11-16-ga2f32550a085984f|r11-16-ga2f32550a085984f

--- Comment #6 from Jakub Jelinek  ---
Fixed for 12.3 too.

[Bug middle-end/108685] [10/11 Regression] ICE in verify_loop_structure, at cfgloop.cc:1748 since r13-2388-ga651e6d59188da

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

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[10/11/12 Regression] ICE   |[10/11 Regression] ICE in
   |in verify_loop_structure,   |verify_loop_structure, at
   |at cfgloop.cc:1748 since|cfgloop.cc:1748 since
   |r13-2388-ga651e6d59188da|r13-2388-ga651e6d59188da

--- Comment #10 from Jakub Jelinek  ---
Fixed for 12.3 too.

[Bug c++/109096] __has_unique_object_representations does not account for unnamed bitfield

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

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

--- Comment #7 from Jakub Jelinek  ---
Fixed for 12.3 too.

[Bug tree-optimization/109184] [10/11/12/13 Regression] csmith: 2017 bug with -floop-interchange

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

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

--- Comment #6 from Richard Biener  ---
Confirmed with -O2 -floop-interchange.  There's just a single interchange done:

runData/keep/in.713.c:648:32: optimized: loops interchanged in loop nest

that's in func_2 for the nest

for (g_149 = 0; (g_149 > (-15)); g_149--)
{
for (l_1719 = 4; (l_1719 >= 1); l_1719 -= 1)
{
for (l_1721 = 0; (l_1721 >= 0); l_1721 -= 1)
{
struct S1 l_1935 = {0x13186D76L,0xC9L,36,24,1L,0x87L};
for (g_1179 = 0; (g_1179 <= 4); g_1179 += 1)
{
int32_t l_1942 = (-3L);
int32_t *l_1947 = &l_1946[0][6];
int i, j;
l_1942 ^= ((safe_add_func_uint64_t_u_u((l_1935 ,
(((l_1936[1] != (void*)0) < (*g_511)) & (g_1731[(l_1719 + 1)][l_1721] &=
(((0x943C8AB0L | 0xE398A931L) != g_20) , (0x26L &
(safe_add_func_uint64_t_u_u((--l_1930[g_1179]), 0xFC07342370A5FE25LL))),
4L)) <= p_5.f0);
l_1943[0][1][1]++;
l_1949 = (((*l_1947) = l_1946[0][6]) == g_1948);
}
}
}
}

[Bug tree-optimization/109192] [13 Regression] timeout with -O3 since r13-5579

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

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

--- Comment #6 from Richard Biener  ---
On a fast machine compile eventually finishes and a time-report looks like

 dominator optimization : 156.84 ( 52%)   0.00 (  0%) 156.86 ( 52%)
  112k (  1%)
 backwards jump threading   : 145.15 ( 48%)   0.00 (  0%) 145.15 ( 48%)
   70k (  0%)
 TOTAL  : 302.15  0.02302.19   
   16M

[Bug tree-optimization/105867] [12/13 Regression] incorrect dangling-pointer warning

[wielkiegie at gmail dot com via Gcc-bugs]

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

Gustaw Smolarczyk  changed:

   What|Removed |Added

 CC||wielkiegie at gmail dot com

--- Comment #5 from Gustaw Smolarczyk  ---
This warning is triggered just by std::set::swap(std::set&) when optimizing.

https://godbolt.org/z/e84xPMdf6



#include 

void foo()
{
  std::set x, y;
  x.swap(y);
}

[Bug ada/109212] New: Ada "for" expression generates gcc error

[vawasthi at acm dot org via Gcc-bugs]

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

Bug ID: 109212
   Summary: Ada "for" expression generates gcc error
   Product: gcc
   Version: 10.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vawasthi at acm dot org
CC: dkm at gcc dot gnu.org
  Target Milestone: ---

Created attachment 54709
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54709&action=edit
Error generating code and compiler output

An Ada "for" expression that uses the Range attribute of a doubly indexed array
fails to compile in my version of gnatmake. Doesn't happen for a single indexed
array.

I am on a Debian 11.6 Gnu/Linux box.

The attached file (err.adb) contains all code needed to generate the error. It
also contains the command line and error output.

[Bug tree-optimization/109184] [10/11/12/13 Regression] csmith: 2017 bug with -floop-interchange

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

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

--- Comment #7 from Richard Biener  ---
(In reply to Richard Biener from comment #6)
> Confirmed with -O2 -floop-interchange.  There's just a single interchange
> done:
> 
> runData/keep/in.713.c:648:32: optimized: loops interchanged in loop nest
> 
> that's in func_2 for the nest
> 
> for (g_149 = 0; (g_149 > (-15)); g_149--)
> {
> for (l_1719 = 4; (l_1719 >= 1); l_1719 -= 1)
> {
> for (l_1721 = 0; (l_1721 >= 0); l_1721 -= 1)
> {
> struct S1 l_1935 = {0x13186D76L,0xC9L,36,24,1L,0x87L};
> for (g_1179 = 0; (g_1179 <= 4); g_1179 += 1)
> {
> int32_t l_1942 = (-3L);
> int32_t *l_1947 = &l_1946[0][6];
> int i, j;
> l_1942 ^= ((safe_add_func_uint64_t_u_u((l_1935 ,
> (((l_1936[1] != (void*)0) < (*g_511)) & (g_1731[(l_1719 + 1)][l_1721] &=
> (((0x943C8AB0L | 0xE398A931L) != g_20) , (0x26L &
> (safe_add_func_uint64_t_u_u((--l_1930[g_1179]), 0xFC07342370A5FE25LL))),
> 4L)) <= p_5.f0);
> l_1943[0][1][1]++;
> l_1949 = (((*l_1947) = l_1946[0][6]) == g_1948);
> }
> }
> }
> }

And we are interchanging the outer two loops.  Since the outer loop IV isn't
used in the body it doesn't change anything data dep wise?

Interchanging the loops in the source reproduces the issue, so somehow
for the only use of l_1719

(g_1731[(l_1719 + 1)][l_1721] &= (((0x943C8AB0L | 0xE398A931L) != g_20) ,
(0x26L & (safe_add_func_uint64_t_u_u((--l_1930[g_1179]),
0xFC07342370A5FE25LL)

it makes a difference.  It's

  g_1731[(l_1719 + 1)][l_1721] &= val;

the order we & values into it shouldn't matter.  But it's so much obfuscated
code ...

[Bug c++/109177] Call to C++ function marked unavailable gets diagnosed twice

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

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

--- Comment #2 from Alex Coplan  ---
Part of the problem here seems to be that dg-error doesn't care how many times
the same diagnostic is emitted, so it doesn't seem able to detect this failure
mode. Otherwise, I expect this would have shown up in failures of the existing
g++.dg/ext/attr-unavailable*.C tests.

[Bug target/104713] gcc does not reject -march=i686 -fcf-protection

[jay+ggcc--- via Gcc-bugs]

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

--- Comment #7 from James Addison  ---
(In reply to Adrian Bunk from comment #6)
> (In reply to James Addison from comment #5)
> > Could the findings indicate that there are two bugs here?
> > 
> >   - The Geode LX target capable of supporting fcf-protection but GCC-11
> > currently rejects that architecture and flag combination
> 
> The problem is the opposite.

Ok, thank you.

Something that's unclear to me is whether fcf-protection requires NOPL
(multi-byte NOP).  I understand that it requires endbr32.

Was my second statement (re: GCC-11 emitting NOPL for i686) correct?

[Bug fortran/109209] [13 regression] erroneous error on assignment of alloctables

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

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

--- Comment #1 from Jürgen Reuter  ---
Created attachment 54710
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54710&action=edit
First still pretty large reproducer

I will provide a smaller reproducer soon.

[Bug ada/109212] Ada "for" expression generates gcc error

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

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

--- Comment #1 from Marc Poulhiès  ---
Yes, but this has been fixed in later 11.x and above versions of the compiler,
see for example:

https://ada.godbolt.org/z/6KraGY965

I don't think we'll try to backport the Ada 202x features/bugfixes in old
compilers.

[Bug tree-optimization/109213] New: [13 Regression] -Os generates significantly more code

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

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

Bug ID: 109213
   Summary: [13 Regression] -Os generates significantly more code
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: theodort at inf dot ethz.ch
  Target Milestone: ---

Input C-code:

static char g, d[5] = {0};
static int f = 0, *e;
static void b(int) {};

static int i() {
for (int j =0; j < 1; j +=1)
f = 0;
return 0;
}

static void m() {
int n[10];
int o[56] = {};
for (int h = 0; h < 3; h++)
if (d[h])
for (; f; f++)
if (n[0])
break;

int *r[] = {&o[0]};
}


int main() {
int p[10] = {};
m();
if (!i()) {
int *q = &p[0];
for (; g;)
b(e == q);
}
}

-
12.2 -Os:

main:
xorl%eax, %eax
movl%eax, f(%rip)
xorl%eax, %eax
ret

-
trunk -Os: 

m:
movlf(%rip), %eax
xorl%edx, %edx
xorl%ecx, %ecx
.L5:
cmpb$0, d(%rdx)
je  .L2
movl-40(%rsp), %esi
.L3:
testl   %eax, %eax
je  .L2
testl   %esi, %esi
jne .L2
incl%eax
movb$1, %cl
jmp .L3
.L2:
incq%rdx
cmpq$3, %rdx
jne .L5
testb   %cl, %cl
je  .L1
movl%eax, f(%rip)
.L1:
ret
main:
xorl%eax, %eax
callm
xorl%eax, %eax
movl%eax, f(%rip)
xorl%eax, %eax
ret
d:
.zero   5

[Bug libstdc++/109165] std::hash>::operator() should be const

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

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

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

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

commit r12-9296-g2a9e6f58c4d9d63dde6c4d53d10f686bf71fb435
Author: Jonathan Wakely 
Date:   Fri Mar 17 11:39:55 2023 +

libstdc++: Add const to hash>::operator() [PR109165]

libstdc++-v3/ChangeLog:

PR libstdc++/109165
* include/std/coroutine (hash<>::operator()): Add const.
* testsuite/18_support/coroutines/hash.cc: New test.

[Bug target/108443] arm: MVE wrongly re-interprets predicate constants

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

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

Stam Markianos-Wright  changed:

   What|Removed |Added

 CC||stammark at gcc dot gnu.org

--- Comment #2 from Stam Markianos-Wright  ---
What are people's thoughts on getting this (and the rest of the patch series
the fix was part of) backported to GCC12?

One of the changes in the series is arguably a mid-end optimisation (the change
to simplify-rtx), but it is a pre-requisite to getting this wrong-code bug
resolved.

[Bug libstdc++/109064] Maximum recursion depth exceeded in std::shared_ptr xmethod

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

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

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

https://gcc.gnu.org/g:07246eee2393312c187dcb4fa70d0e0785d75ae6

commit r12-9298-g07246eee2393312c187dcb4fa70d0e0785d75ae6
Author: Jonathan Wakely 
Date:   Fri Mar 10 11:06:25 2023 +

libstdc++: Fix GDB Xmethod for std::shared_ptr::use_count() [PR109064]

libstdc++-v3/ChangeLog:

PR libstdc++/109064
* python/libstdcxx/v6/xmethods.py (SharedPtrUseCountWorker):
Remove self-recursion in __init__. Add missing _supports.
* testsuite/libstdc++-xmethods/shared_ptr.cc: Check use_count()
and unique().

(cherry picked from commit 37c8a083d44f8123ad81a3cd411389b0b7b42ae6)

[Bug libstdc++/109182] unused parameter pack is in expected(in_place_t)

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

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

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

https://gcc.gnu.org/g:03f745992715872982d86bf2085f956bf0173b50

commit r12-9297-g03f745992715872982d86bf2085f956bf0173b50
Author: Jonathan Wakely 
Date:   Mon Mar 20 09:30:58 2023 +

libstdc++: Remove template-head from std::expected ctor [PR109182]

The presence of a template-head on this constructor is a copy & paste
error from the primary template.

libstdc++-v3/ChangeLog:

PR libstdc++/109182
* include/std/expected (expected::expected(in_place_t)):
Remove template-head.

[Bug libstdc++/109182] unused parameter pack is in expected(in_place_t)

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #4 from Jonathan Wakely  ---
Fixed

[Bug libstdc++/109165] std::hash>::operator() should be const

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #5 from Jonathan Wakely  ---
Fixed - thanks for spotting it.

[Bug ada/109212] Ada "for" expression generates gcc error

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

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

Eric Botcazou  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 CC||ebotcazou at gcc dot gnu.org
  Known to work||11.0, 12.0
 Status|UNCONFIRMED |RESOLVED

--- Comment #2 from Eric Botcazou  ---
No, indeed, upgrading to GCC 11 or later is the way to go instead.

[Bug tree-optimization/109184] [10/11/12/13 Regression] csmith: 2017 bug with -floop-interchange

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

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

--- Comment #8 from Richard Biener  ---
Reduced testcase:

typedef __UINT64_TYPE__ uint64_t;

static uint64_t g_1731[7][1] = {{0xF75EE82FC4736923LL},{0UL},
  {0xF75EE82FC4736923LL},{0UL},
  {0xF75EE82FC4736923LL},{0UL},
  {0xF75EE82FC4736923LL}};

static int g_149;
static unsigned short g_1179;

void __attribute__((noipa)) foo ()
{
  uint64_t l_1930[5];
  int l_1719, l_1721;

  int i;
  for (i = 0; i < 5; i++)
l_1930[i] = 0x623D9EDB6316A7CDLL;

  for (g_149 = 0; (g_149 > (-15)); g_149--)
for (l_1719 = 4; (l_1719 >= 1); l_1719 -= 1)
  for (l_1721 = 0; (l_1721 >= 0); l_1721 -= 1)
for (g_1179 = 0; (g_1179 <= 4); g_1179 += 1)
  g_1731[(l_1719 + 1)][l_1721]
&= ((0x26L & (((--l_1930[g_1179]) + 0xFC07342370A5FE25LL;
}

int main()
{
  foo ();
  /* f75ee82fc4736923 0 2 0 0 0 f75ee82fc4736923 */
  if (g_1731[0][0] != 0xF75EE82FC4736923LL
  || g_1731[2][0] != 2
  || g_1731[4][0] != 0
  || g_1731[6][0] != 0xF75EE82FC4736923LL)
__builtin_abort ();
  return 0;
}

[Bug tree-optimization/109184] [10/11/12/13 Regression] csmith: 2017 bug with -floop-interchange

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

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

--- Comment #9 from Jakub Jelinek  ---
I've tried to deobfuscate the innermost loop's body:
int32_t l_1942 = (-3L);
int32_t *l_1947 = &l_1946[0][6];
int i, j;
uint64_t t1 = --l_1930[g_1179];
t1 += 0xFC07342370A5FE25ULL;
t1 &= 38;
uint64_t t2 = (g_1731[l_1719 + 1][l_1721] &= t1);
l_1942 ^= (t2 + 4ULL <= p_5.f0);
l_1943[0][1][1]++;
int32_t t3 = l_1946[0][6];
*l_1947 = t3;
l_1949 = t3 == g_1948;

[Bug tree-optimization/109184] [10/11/12/13 Regression] csmith: 2017 bug with -floop-interchange

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

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

--- Comment #10 from Richard Biener  ---
Somewhat more reduced:

typedef __UINT64_TYPE__ uint64_t;

static uint64_t g_1731[7] = {0xF75EE82FC4736923LL, 0, 0xF75EE82FC4736923LL, 0,
0xF75EE82FC4736923LL, 0, 0xF75EE82FC4736923LL};

void __attribute__((noipa)) foo ()
{
  uint64_t l_1930[5] = { 0x5e44d2fed3bca5f2, 0x5e44d2fed3bca5f2, 
  0x5e44d2fed3bca5f2, 0x5e44d2fed3bca5f2, 0x5e44d2fed3bca5f2 };

  for (int i = 0; i < 15; ++i)
for (int j = 4; (j >= 1); j -= 1)
#pragma GCC unroll 0
  for (int k = 0; (k <= 4); k += 1)
g_1731[(j + 1)] &= (0x26L & (--l_1930[k]));
}

int main()
{
  foo ();
  /* f75ee82fc4736923 0 2 0 0 0 f75ee82fc4736923 */
  if (g_1731[0] != 0xF75EE82FC4736923LL
  || g_1731[2] != 2
  || g_1731[4] != 0
  || g_1731[6] != 0xF75EE82FC4736923LL)
__builtin_abort ();
  return 0;
}

[Bug c++/101361] Bogus -Wstringop-overread warning with -O3

[mail+gnu at tzik dot jp via Gcc-bugs]

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

Taiju Tsuiki  changed:

   What|Removed |Added

 CC||mail+gnu at tzik dot jp

--- Comment #12 from Taiju Tsuiki  ---
Created attachment 54711
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54711&action=edit
A reproducer of an inaccurate -Wstringop-overread

[Bug tree-optimization/109184] [10/11/12/13 Regression] csmith: 2017 bug with -floop-interchange

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

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

--- Comment #11 from Richard Biener  ---
Fails even with -O2 -floop-interchange -fno-move-loop-stores (otherwise we
complicate the IL by applying store-motion to g_1731).

(compute_affine_dependence
  ref_a: l_1930[k_33], stmt_a: _1 = l_1930[k_33];
  ref_b: g_1731[_51], stmt_b: g_1731[_51] = _5;
) -> no dependence
(compute_affine_dependence
  ref_a: l_1930[k_33], stmt_a: l_1930[k_33] = _2;
  ref_b: g_1731[_51], stmt_b: _4 = g_1731[_51];
) -> no dependence
(compute_affine_dependence
  ref_a: l_1930[k_33], stmt_a: l_1930[k_33] = _2;
  ref_b: g_1731[_51], stmt_b: g_1731[_51] = _5;
) -> no dependence

maybe I'm missing something but we seem to fail to honor dependences from
SSA edges?

   [local count: 894749066]:
  # k_33 = PHI 
  # ivtmp_41 = PHI 
  _1 = l_1930[k_33];
  _2 = _1 + 18446744073709551615;
  l_1930[k_33] = _2;
  _4 = g_1731[_51];
  _38 = _2 & _4;
  _5 = _38 & 38;
  g_1731[_51] = _5;
  k_24 = k_33 + 1;
  ivtmp_40 = ivtmp_41 - 1;
  if (ivtmp_40 != 0)

Of course DDR_ARE_DEPENDENT (ddr) == chrec_known just tells us there's no
memory dependece.

As said, maybe I'm missing something ...

[Bug tree-optimization/109213] [13 Regression] -Os generates significantly more code

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |13.0
   Keywords||missed-optimization,
   ||needs-bisection

[Bug c++/101361] Bogus -Wstringop-overread warning with -O3

[mail+gnu at tzik dot jp via Gcc-bugs]

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

--- Comment #13 from Taiju Tsuiki  ---
I saw a similar inaccurate -Wstringop-overread warning with a smaller
reproducer (attached).
https://wandbox.org/permlink/EPjH0ZPoA4EWky0e

Reproducing gcc was tip of trunk (
https://github.com/gcc-mirror/gcc/commits/33fb1625992ba8180b42988e714460bcab08ca0f
),
and compile options and the error were:
$ g++ -Werror -O3 -std=c++20 -c foo.cc
In function ‘auto operator<=>(const V&, const V&)’,
inlined from ‘Node* foo(Node*, const V&)’ at minify2/foo.cc:33:17:
minify2/foo.cc:20:36: error: ‘int __builtin_memcmp(const void*, const void*,
long unsigned int)’ specified bound [9223372036854775808, 18446744073709551615]
exceeds maximum object size 9223372036854775807 (9) 
[-Werror=stringop-overread]
   20 | const auto c = __builtin_memcmp(x.beg, y.beg, len) <=> 0;
  |^~~
minify2/foo.cc:17:15: note: source object allocated here
   17 |   }(x.end - x.beg, y.end - y.beg);
  | ~~^~~

$ cat foo.cc
#include 

struct Res {
  long min;
  std::strong_ordering cmp;
};

struct V {
  const unsigned char* beg = nullptr;
  const unsigned char* end = nullptr;
};

auto operator<=>(const V& x, const V& y) {
  const auto [len, lencmp] = [&](long len_x, long len_y) {
auto c = len_x <=> len_y;
return Res{c > 0 ? len_y : len_x, c};
  }(x.end - x.beg, y.end - y.beg);

  if (len) {
const auto c = __builtin_memcmp(x.beg, y.beg, len) <=> 0;
if (c != 0)
  return c;
  }
  return lencmp;
}

struct Node {
  Node* next = nullptr;
  V v;
};

Node* foo(Node* x, const V& k) {
  while (x && k < x->v)
x = x->next;
  return x;
}

[Bug tree-optimization/109184] [10/11/12/13 Regression] csmith: 2017 bug with -floop-interchange

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

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

Alex Coplan  changed:

   What|Removed |Added

 CC||acoplan at gcc dot gnu.org

--- Comment #12 from Alex Coplan  ---
The original testcase with -fsanitize=undefined shows some "load of misaligned
address" errors at runtime, which suggests it is invalid.

[Bug c/109214] New: extension to C language allowing void * to be cast to function pointer should be documented

[rouca at debian dot org via Gcc-bugs]

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

Bug ID: 109214
   Summary: extension to C  language allowing void  * to be cast
to function pointer should be documented
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rouca at debian dot org
  Target Milestone: ---

Hi,

according to POSIX
https://pubs.opengroup.org/onlinepubs/009696899/functions/dlsym.html

"The ISO C standard does not require that pointers to functions can be cast
back and forth to pointers to data. Indeed, the ISO C standard does not require
that an object of type void * can hold a pointer to a function. Implementations
supporting the XSI extension, however, do require that an object of type void *
can hold a pointer to a function. The result of converting a pointer to a
function into a pointer to another data type (except void *) is still
undefined, however. Note that compilers conforming to the ISO C standard are
required to generate a warning if a conversion from a void * pointer to a
function pointer is attempted as in:

fptr = (int (*)(int))dlsym(handle, "my_function");"

This extension should be documented in the C, C++ extension documentation.

Moreover maybe adding a type attribute in order to clear the warning for this
kind of function may also help [1]

Bastien

[1] https://stackoverflow.com/questions/31526876/casting-when-using-dlsym

[Bug rtl-optimization/109187] [13 Regression] ICE: qsort checking failed: qsort comparator non-negative on sorted output: 1736258160 at -O2 since r13-5154-g733a1b777f16cd

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

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2023-03-20
 Ever confirmed|0   |1
Summary|[13 Regression] ICE: qsort  |[13 Regression] ICE: qsort
   |checking failed: qsort  |checking failed: qsort
   |comparator non-negative on  |comparator non-negative on
   |sorted output: 1736258160   |sorted output: 1736258160
   |at -O2  |at -O2 since
   ||r13-5154-g733a1b777f16cd
 CC||amonakov at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
   Keywords|needs-bisection |
 Status|UNCONFIRMED |NEW

--- Comment #1 from Martin Liška  ---
Started with r13-5154-g733a1b777f16cd.

[Bug tree-optimization/109176] [13 Regression] internal compiler error: in to_constant, at poly-int.h:504

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
   Keywords|needs-bisection |

--- Comment #4 from Jakub Jelinek  ---
At least on the reduced testcase, this started to ICE with
r11-1445-g502d63b6d6141597bb one way and with
r11-1470-gd11c9841d54ed74978f8d0e0f352631f90504dd5 changed to the ICE in
to_constant.  So not really sure this should be P1.

[Bug target/109178] ICE using __builtin_vec_xst_trunc built-in

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Peter Bergner :

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

commit r13-6761-gfbd50e867e6a782c7b56c9727bf7e1e74dae4b94
Author: Peter Bergner 
Date:   Mon Mar 20 09:12:47 2023 -0500

rs6000: Don't ICE when compiling the __builtin_vec_xst_trunc built-in
[PR109178]

When we expand the __builtin_vec_xst_trunc built-in, we use the wrong mode
for the MEM operand which causes an unrecognizable insn ICE.  The solution
is to use the correct TMODE mode.

2023-03-20  Peter Bergner  

gcc/
PR target/109178
* config/rs6000/rs6000-builtin.cc (stv_expand_builtin): Use tmode.

gcc/testsuite/
PR target/109178
* gcc.target/powerpc/pr109178.c: New test.

[Bug c/109215] New: warning: array subscript 0 is outside the bounds of an interior zero-length array ‘struct lock_class_key[3]’

[ubizjak at gmail dot com via Gcc-bugs]

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

Bug ID: 109215
   Summary: warning: array subscript 0 is outside the bounds of an
interior zero-length array ‘struct lock_class_key[3]’
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ubizjak at gmail dot com
  Target Milestone: ---

The linux kernel compile fails with gcc-13 in super.c with:

fs/super.c: In function ‘alloc_super.isra’:
fs/super.c:234:21: error: array subscript 2 is outside the bounds of an
interior zero-length array ‘struct lock_class_key[3]’
[-Werror=zero-length-bounds]
  234 | if (__percpu_init_rwsem(&s->s_writers.rw_sem[i],
  | ^~~~
  235 | sb_writers_name[i],
  | ~~~
  236 | &type->s_writers_key[i]))
  | 
In file included from ./include/linux/highmem.h:5,
 from ./include/linux/bvec.h:10,
 from ./include/linux/blk_types.h:10,
 from ./include/linux/blkdev.h:9,
 from fs/super.c:26:
./include/linux/fs.h:2211:31: note: while referencing ‘s_writers_key’
 2211 | struct lock_class_key s_writers_key[SB_FREEZE_LEVELS];
  |   ^
cc1: all warnings being treated as errors

[Bug c/109215] warning: array subscript 0 is outside the bounds of an interior zero-length array ‘struct lock_class_key[3]’

[ubizjak at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Uroš Bizjak  ---
The minimized testcase:

--cut here--
#define SB_FREEZE_COMPLETE 4

struct lock_class_key { };

struct file_system_type {
 struct lock_class_key s_writers_key[(SB_FREEZE_COMPLETE - 1)];
 struct lock_class_key i_lock_key;
};

void foo (struct file_system_type *type)
{
  for (int i = 0; i < (SB_FREEZE_COMPLETE - 1); i++)
__builtin_printf ("%p\n", &type->s_writers_key[i]);
}
--cut here--

gcc -O2 -Wall:

super-i.c: In function ‘foo’:
super-i.c:13:5: warning: array subscript 0 is outside the bounds of an interior
zero-length array ‘struct lock_class_key[3]’ [-Wzero-length-bounds]
   13 | __builtin_printf ("%p\n", &type->s_writers_key[i]);
  | ^~
super-i.c:6:24: note: while referencing ‘s_writers_key’
6 |  struct lock_class_key s_writers_key[(SB_FREEZE_COMPLETE - 1)];
  |^

[Bug fortran/109209] [13 regression] erroneous error on assignment of alloctables

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

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

--- Comment #2 from Jürgen Reuter  ---
Created attachment 54712
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54712&action=edit
Second, single-file reproducer, still 6295 lines

Still further reducing, stay tuned.

[Bug fortran/82943] [F03] Error with type-bound procedure of parametrized derived type

[vegard.g.j at icloud dot com via Gcc-bugs]

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

vegard  changed:

   What|Removed |Added

 CC||vegard.g.j at icloud dot com

--- Comment #10 from vegard  ---
(In reply to kargl from comment #9)
> (In reply to alig from comment #8)
> > The problem still persists with GNU Fortran (GCC) 11.1.0.
> 
> The problem is likely to persist for the foreseeable future
> as there is no one left to work on gfortran bugs.  Lacking 
> a sudden influx of new volunteer contributors, it seems
> the only way forward is to NOT use parameterized derived 
> types with gfortran.

Any news here? I seem to be having this issue with gfortran (Homebrew GCC)
12.2.0

As a side note: I'm somewhat new to the fortran community, but could see myself
contributing to gfortran in the future. Do you think you could point me to
where I should read up on contributing?

[Bug tree-optimization/109215] [13 Regression] wrong warning: array subscript 0 is outside the bounds of an interior zero-length array ‘struct lock_class_key[3]’

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |13.0
Summary|warning: array subscript 0  |[13 Regression] wrong
   |is outside the bounds of an |warning: array subscript 0
   |interior zero-length array  |is outside the bounds of an
   |‘struct lock_class_key[3]’  |interior zero-length array
   ||‘struct lock_class_key[3]’

[Bug tree-optimization/109215] [13 Regression] wrong warning: array subscript 0 is outside the bounds of an interior zero-length array ‘struct lock_class_key[3]’

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-03-20
 Ever confirmed|0   |1

--- Comment #2 from Andrew Pinski  ---
Confirmed.

[Bug target/109178] ICE using __builtin_vec_xst_trunc built-in

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

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

--- Comment #4 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Peter Bergner
:

https://gcc.gnu.org/g:19ad58ef1f09373b0f75eded8f0b12da381a1190

commit r12-9302-g19ad58ef1f09373b0f75eded8f0b12da381a1190
Author: Peter Bergner 
Date:   Mon Mar 20 09:12:47 2023 -0500

rs6000: Don't ICE when compiling the __builtin_vec_xst_trunc built-in
[PR109178]

When we expand the __builtin_vec_xst_trunc built-in, we use the wrong mode
for the MEM operand which causes an unrecognizable insn ICE.  The solution
is to use the correct TMODE mode.

2023-03-20  Peter Bergner  

gcc/
PR target/109178
* config/rs6000/rs6000-builtin.cc (stv_expand_builtin): Use tmode.

gcc/testsuite/
PR target/109178
* gcc.target/powerpc/pr109178.c: New test.

(cherry picked from commit fbd50e867e6a782c7b56c9727bf7e1e74dae4b94)

[Bug target/109178] ICE using __builtin_vec_xst_trunc built-in

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

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

Peter Bergner  changed:

   What|Removed |Added

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

--- Comment #5 from Peter Bergner  ---
Fixed everywhere.

[Bug tree-optimization/109176] [13 Regression] internal compiler error: in to_constant, at poly-int.h:504

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||rsandifo at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  ---
Before veclower2 we had/have
  _7 = ba_5(D) < a_6(D);
  _8 = svnand_b_z (_7, _7, _7);
  _9 = VEC_COND_EXPR <_7, _8, _7>;
where _7/_8/_9 are all __SVBool_t.
Before the r11-1445 changes, the VEC_COND_EXPR would be left untouched, because
expand_vec_cond_expr_p (__SVBool_t, __SVBool_t, SSA_NAME) is true on aarch64.
Now it doesn't, because _7 def_stmt is a comparison, and so
expand_vec_cond_expr_p (__SVBool_t, VNx16QI, LT_EXPR).
--- gcc/tree-vect-generic.cc.jj 2023-03-12 22:36:06.356178068 +0100
+++ gcc/tree-vect-generic.cc2023-03-20 16:31:03.321831866 +0100
@@ -1063,6 +1063,12 @@ expand_vector_condition (gimple_stmt_ite
   return true;
 }

+  if (!TYPE_VECTOR_SUBPARTS (type).is_constant ()
+  && VECTOR_BOOLEAN_TYPE_P (type)
+  && VECTOR_BOOLEAN_TYPE_P (TREE_TYPE (a))
+  && expand_vec_cond_expr_p (type, TREE_TYPE (a), TREE_CODE (a)))
+return true;
+
   /* Handle vector boolean types with bitmasks.  If there is a comparison
  and we can expand the comparison into the vector boolean bitmask,
  or otherwise if it is compatible with type, we can transform
basically restores the behaviour here for the SVE boolean types and makes it
compile.
Because otherwise, unless this would be solvable by the AVX512 "Handle vector
boolean types with bitmasks." code the non-constant vector elts cases will
always ICE in the following code,   int nunits = nunits_for_known_piecewise_op
(type);
requires constant TYPE_VECTOR_SUBPARTS and the code really isn't prepared to
handle anything non-constant.

[Bug fortran/109216] New: Wrong behaviour explained in -fno-underscoring documentation

[rhidalgochar at bloomberg dot net via Gcc-bugs]

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

Bug ID: 109216
   Summary: Wrong behaviour explained in -fno-underscoring
documentation
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rhidalgochar at bloomberg dot net
  Target Milestone: ---

In the documentation section for codegen options it has two parts explaining
the behaviour of -fno-underscoring (and implictly -funderscoring) and
-fsecond-underscore:
https://gcc.gnu.org/onlinedocs/gfortran/Code-Gen-Options.html

However under -fno-underscoring it has an example for -funderscoring that seems
to describe the -fsecond-underscore behaviour.

Indeed if I compile the following example into an object and look at the
symbols I see that j_ and max_count_ are found as undefined symbols, not j_ and
max_count__ as suggested, though I do get that if I compile it with
-fsecond-underscore.

code: 
  program main
  integer i, j, max_count
  i = j() + max_count(i, j())
  end program main

[Bug fortran/109209] [13 regression] erroneous error on assignment of alloctables

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

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

--- Comment #3 from Jürgen Reuter  ---
Created attachment 54713
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54713&action=edit
Promised short reproducer, 73 lines

[Bug fortran/109209] [13 regression] erroneous error on assignment of alloctables

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

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

--- Comment #4 from Jürgen Reuter  ---
Here is the promised reproducer, which fails even when not using submodules:
$ gfortran -c reproducer.f90 
reproducer.f90:69:4:

   69 | history_new(1:s) = res_set%history(1:s)
  |1
Error: Component to the right of a part reference with nonzero rank must not
have the ALLOCATABLE attribute at (1)
reproducer.f90:69:23:

   69 | history_new(1:s) = res_set%history(1:s)
  |   1
Error: Component to the right of a part reference with nonzero rank must not
have the ALLOCATABLE attribute at (1)



module resonances
  implicit none
  private

  type :: t1_t
 integer, dimension(:), allocatable :: c
   contains
 procedure, private :: t1_assign
 generic :: assignment(=) => t1_assign
  end type t1_t

  type :: t3_t
 type(t1_t), dimension(:), allocatable :: resonances
 integer :: n_resonances = 0
  contains
 procedure, private :: t3_assign
 generic :: assignment(=) => t3_assign
  end type t3_t

  type :: resonance_branch_t
 integer :: i = 0
 integer, dimension(:), allocatable :: r_child
 integer, dimension(:), allocatable :: o_child
  end type resonance_branch_t

  type :: resonance_tree_t
 private
 integer :: n = 0
 type(resonance_branch_t), dimension(:), allocatable :: branch
  end type resonance_tree_t

  type :: t3_set_t
 private
 type(t3_t), dimension(:), allocatable :: history
 type(resonance_tree_t), dimension(:), allocatable :: tree
 integer :: last = 0
   contains
 procedure, private :: expand => t3_set_expand
  end type t3_set_t

contains

  pure subroutine t1_assign &
   (t1_out, t1_in)
class(t1_t), intent(inout) :: t1_out
class(t1_t), intent(in) :: t1_in
if (allocated (t1_out%c))  deallocate (t1_out%c)
if (allocated (t1_in%c)) then
   allocate (t1_out%c (size (t1_in%c)))
   t1_out%c = t1_in%c
end if
  end subroutine t1_assign

  subroutine t3_assign (res_hist_out, res_hist_in)
class(t3_t), intent(out) :: res_hist_out
class(t3_t), intent(in) :: res_hist_in
if (allocated (res_hist_in%resonances)) then
   res_hist_out%resonances = res_hist_in%resonances
   res_hist_out%n_resonances = res_hist_in%n_resonances
end if
  end subroutine t3_assign

  module subroutine t3_set_expand (res_set)
class(t3_set_t), intent(inout) :: res_set
type(t3_t), dimension(:), allocatable :: history_new
integer :: s
s = size (res_set%history)
allocate (history_new (2 * s))
history_new(1:s) = res_set%history(1:s)
call move_alloc (history_new, res_set%history)
  end subroutine t3_set_expand

end module resonances

[Bug fortran/109209] [13 regression] erroneous error on assignment of alloctables

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

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

--- Comment #5 from Jürgen Reuter  ---
This could be either this commit
commit d7caf313525a46f200d7f5db1ba893f853774aee
Author: Paul Thomas 
Date:   Sat Mar 18 07:56:23 2023 +
/Fortran

I think, it is NOT this one: 
commit 5889c7bd46a45dc07ffb77ec0d698e18e0b99840
Author: Paul Thomas 
Date:   Mon Mar 20 06:13:54 2023 +
Fortran: Allow external function from in an associate block [PR87127]

NOR this one:
commit 5426ab34643d9e6502f3ee572891a03471fa33ed
Author: Harald Anlauf 
Date:   Fri Mar 17 22:24:49 2023 +0100
Fortran: procedures with BIND(C) attribute require explicit interface
[PR85877]

[Bug fortran/109209] [13 regression] erroneous error on assignment of alloctables

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

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

--- Comment #6 from Jürgen Reuter  ---
Actually could be also this commit here:
commit 901edd99b44976b3c2b13a7d525d9e315540186a
Author: Harald Anlauf 
Date:   Tue Mar 14 20:23:06 2023 +0100

Fortran: rank checking with explicit-/assumed-size arrays and CLASS
[PR58331]

gcc/fortran/ChangeLog:

PR fortran/58331
* interface.cc (compare_parameter): Adjust check of array dummy
arguments to handle the case of CLASS variables.

gcc/testsuite/ChangeLog:

PR fortran/58331
* gfortran.dg/class_dummy_10.f90: New test.

Co-authored-by: Tobias Burnus 

[Bug rtl-optimization/109187] [13 Regression] ICE: qsort checking failed: qsort comparator non-negative on sorted output: 1736258160 at -O2 since r13-5154-g733a1b777f16cd

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

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

--- Comment #2 from Alexander Monakov  ---
This is caused by overflowing subtraction in autopref_rank_for_schedule:

  if (!irrel1 && !irrel2)
/* Sort memory references from lowest offset to the largest.  */
r = data1->offset - data2->offset;

When offsets are arbitrary this pattern (anti-pattern?) is inappropriate for
producing a less/equal/greater comparison result. The following (or variants)
is safe:

diff --git a/gcc/haifa-sched.cc b/gcc/haifa-sched.cc
index 4efaa9445..11bf10645 100644
--- a/gcc/haifa-sched.cc
+++ b/gcc/haifa-sched.cc
@@ -5686,7 +5686,7 @@ autopref_rank_for_schedule (const rtx_insn *insn1, const
rtx_insn *insn2)

   if (!irrel1 && !irrel2)
/* Sort memory references from lowest offset to the largest.  */
-   r = data1->offset - data2->offset;
+   r = (data1->offset > data2->offset) - (data1->offset < data2->offset);
   else if (write)
/* Schedule "irrelevant" insns before memory stores to resolve
   as many producer dependencies of stores as possible.  */

[Bug libstdc++/109203] sort(zip(v1, v2)) fails to compile

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

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

Patrick Palka  changed:

   What|Removed |Added

   Last reconfirmed||2023-03-20
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
 CC||ppalka at gcc dot gnu.org

--- Comment #5 from Patrick Palka  ---
This is https://wg21.link/lwg3865 which we don't yet implement (or P2165R4)

[Bug c/109214] extension to C language allowing void * to be cast to function pointer should be documented

[rouca at debian dot org via Gcc-bugs]

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

--- Comment #1 from rouca  ---
According to my C standard:


  6.3.2.3 Pointers
1 A pointer to void may be converted to or from a pointer to any incomplete
or object
type. A pointer to any incomplete or object type may be converted to a
pointer to void
and back again; the result shall compare equal to the original pointer.
[...]
8. A pointer to a function of one type may be converted to a pointer to a
function ofanother
  type and back again; the result shall compare equal to the original
pointer. If a converted
  pointer is used to call a function whose type is not compatible with the
pointed-to type,
  the behavior is undefined


Note that I work due to implementation of J - Portability issues, §J.5.7
Function pointer cast (informative)

J.5.7 Function pointer casts
1 A pointer to an object or to void may be cast to a pointer to a function,
allowing data to
be invoked as a function (6.5.4).
2 A pointer to a function may be cast to a pointer to an object or to void,
allowing a
function to be inspected or modified (for example, by a debugger) (6.5.4).

[Bug fortran/109209] [13 regression] erroneous error on assignment of alloctables

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

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

--- Comment #7 from Jürgen Reuter  ---
It looks like it is NOT Harald's and Tobias' commit,
https://github.com/gcc-mirror/gcc/commit/901edd99b44976b3c2b13a7d525d9e315540186a
I reverted that one, and still get the error.

[Bug fortran/109206] [13 Regression] gcc/fortran/class.cc:2768:14: runtime error: load of value 4139789424, which is not a valid value for type 'bt' since r13-6747-gd7caf313525a46

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

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

Paul Thomas  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |pault at gcc dot gnu.org

--- Comment #1 from Paul Thomas  ---
Created attachment 54714
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54714&action=edit
Fix for this PR

Hi Martin,

Thanks for the rapid reporting!

This was plain carelessness on my part. I will commit as obvious a bit later
on.

Regards

Paul

[Bug tree-optimization/109215] [13 Regression] wrong warning: array subscript 0 is outside the bounds of an interior zero-length array ‘struct lock_class_key[3]’

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Started with r13-4521-g710c9676520dfd38b4bfdcc937ce026ed89921d6

[Bug fortran/109209] [13 regression] erroneous error on assignment of alloctables

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

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

--- Comment #8 from Tobias Burnus  ---
The debugger shows for the example in comment 4 for the line

   69 | history_new(1:s) = res_set%history(1:s)

the following expression:

(gdb) p gfc_debug_expr(expr)
t3_set_expand:history_new(1:__convert_i4_i8[[((t3_set_expand:s))]]) %
resonances(FULL)

That's F03:C614 - or in F2018:

C919 (R911) There shall not be more than one part-ref with nonzero rank. A
part-name to the right of a part-ref with nonzero rank shall not have the
ALLOCATABLE or POINTER attribute.

For the 'expr' shown in the debugger, that's violated as 'resonances' is
allocatable.


The 'expr' shown above is generated via
   generate_component_assignments -> gfc_resolve_expr
 -> resolve_variable -> gfc_resolve_ref
where generate_component_assignments's gfc_debug_code(*code) is
  ASSIGN
t3_set_expand:history_new(1:__convert_i4_i8[[((t3_set_expand:s))]])
t3_set_expand:res_set % history(1:__convert_i4_i8[[((t3_set_expand:s))]])
which matches the user code and looks fine.

(BTW: We should also check whether there is now an issue with generating
redundant (re)allocate on assignment code in trans*.cc.)

[Bug tree-optimization/109119] missing loading fre with branch comparing two pointers

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug target/109130] [13 Regression] 464.h264ref regressed by 6.5% on a Neoverse-N1 CPU with PGO, LTO, -Ofast and -march=native

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|464.h264ref regressed by|[13 Regression] 464.h264ref
   |6.5% on a Neoverse-N1 CPU   |regressed by 6.5% on a
   |with PGO, LTO, -Ofast and   |Neoverse-N1 CPU with PGO,
   |-march=native   |LTO, -Ofast and
   ||-march=native
   Target Milestone|--- |13.0

[Bug libfortran/109207] Uninitialised static variables in unit.c

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2023-03-20
 Ever confirmed|0   |1
 Status|UNCONFIRMED |WAITING

--- Comment #1 from Andrew Pinski  ---
>Initially unit_cache[0..2] is not NULL.


Yes they are by definition.
That is:
```
#define CACHE_SIZE 3
static gfc_unit *unit_cache[CACHE_SIZE];

...

gfc_unit *unit_root;
```
Since they are not in the auto scope, they are static scope and initialized to
0 by default.

Your fix does not change anything really.