[Bug target/111255] New: RISC-V: Miss combine two vsetvl insns

[lehua.ding at rivai dot ai via Gcc-bugs]

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

Bug ID: 111255
   Summary: RISC-V: Miss combine two vsetvl insns
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lehua.ding at rivai dot ai
  Target Milestone: ---

Missed combine two bellow vsetvl insns:

vsetvli a5,a4,e8,m1,tu,mu  => this two vsetvl insns 
vsetvli zero,a5,e16,m2,ta,ma  should be combined.


C Code:

#include 

#define DEF_LOOP(OLD_TYPE, NEW_TYPE)  
\
  void __attribute__ ((noipa))
\
  test_##OLD_TYPE##_2_##NEW_TYPE (NEW_TYPE *__restrict r, 
\
  OLD_TYPE *__restrict a, NEW_TYPE b, 
\
  OLD_TYPE *__restrict pred, int n)   
\
  {   
\
for (int i = 0; i < n; ++i)   
\
  {   
\
r[i] = pred[i] ? (NEW_TYPE) a[i] : b; 
\
  }   
\
  }

/* INT -> narrower-INT */
#define TEST_ALL_X2X_NARROWER(T)  
\
  T (int16_t, int8_t)

TEST_ALL_X2X_NARROWER (DEF_LOOP)

Assembly:

test_int16_t_2_int8_t:
ble a4,zero,.L5
vsetvli t1,zero,e8,m1,ta,ma
vmv.v.x v4,a2
.L3:
vsetvli a5,a4,e8,m1,tu,mu  => this two vsetvl insns 
vsetvli zero,a5,e16,m2,ta,ma  should be combined.
vle16.v v0,0(a3)
vsetvli t1,zero,e16,m2,ta,ma
vmsne.viv0,v0,0
vsetvli zero,a5,e16,m2,ta,ma
vle16.v v2,0(a1),v0.t
vsetvli a6,zero,e8,m1,ta,ma
sllia7,a5,1
vncvt.x.x.w v2,v2
sub a4,a4,a5
vmerge.vvm  v2,v4,v2,v0
vsetvli zero,a5,e8,m1,ta,ma
vse8.v  v2,0(a0)
add a3,a3,a7
add a0,a0,a5
add a1,a1,a7
bne a4,zero,.L3
.L5:
ret

compiler explorer: https://godbolt.org/z/KPP8G1E3W

[Bug middle-end/111253] Dodgy pointer name (*_42 = PHI ...) in -Wfree-nonheap-object diagnostic

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

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

--- Comment #1 from Sam James  ---
Created attachment 55825
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55825&action=edit
reduced.i

[Bug tree-optimization/52252] An opportunity for x86 gcc vectorizer (gain up to 3 times)

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #9 from Richard Biener  ---
We are not optimally vectorizing this yet, we are using SLP to cover
out[0], out[1], out[2] and single element interleaving for out[3].  The
stores end up strided (aka scalar), that's not what the reporter intended.
We also unroll the loop four times.

The SLP discovery code splits the store group (in the end we should avoid
throwing away such information).  This makes it have a gap and stores with
a gap are only supported "strided" (we could at least store two and one
element, but ...).  We don't support "merging" back the group from SLP
and non-SLP.  With SLP only we might recover here, possibly we shouldn't
allow half SLP / non-SLP for a store group but it might fail even after
discovery so it might be difficult to force this.  Maybe a good case to
"prime" single-lane SLP.

[Bug target/103784] suboptimal code for returning bool value on target ppc

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

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

--- Comment #16 from Ajit Kumar Agarwal  ---
This patch https://gcc.gnu.org/pipermail/gcc-patches/2023-July/624751.html

removes the zero extension from the below testcase that has different cfg, My
patch is not based on any CFG shape but it is general valid for all the CFG.

Testcase from Surya.
#include 

bool glob1;
bool glob2;

bool foo (int a, bool d)
{
  bool c;
  if (a > 2)
c = glob1 & glob2;
  else
c = glob1 | glob2;
  return c^d;
}

[Bug middle-end/111254] Dodgy variable name (*_11 = PHI <_1(25), _25(23)>.CargoPacket::Pool...) in -Wmaybe-uninitialized

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

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

--- Comment #2 from Sam James  ---
sorry, wrong output:
```
[...]
In static member function ‘static void Pool::PoolItem::operator delete(void*)
[with Pool*
Tpool = (& _cargopacket_pool); Titem = CargoPacket; Tindex = unsigned int; long
unsigned int Tgrowth_step = 1024; long unsigned int Tmax_size = 16773120;
PoolType Tpool_type = PT_NORMAL; bool Tcache = true; bool Tzero = false]’,
inlined from ‘static void Pool::PoolItem::operator delete(void*) [with
Pool* Tpool
= (& _cargopacket_pool); Titem = CargoPacket; Tindex = unsigned int; long
unsigned int Tgrowth_step = 1024; long unsigned int Tmax_size = 16773120;
PoolType Tpool_type = PT_NORMAL; bool Tcache = true; bool Tzero = false]’ at
/var/tmp/portage/games-simulation/openttd-13.4/work/openttd-13.4/src/core/pool_type.hpp:256:15,
inlined from ‘CargoList::~CargoList() [with Tinst =
StationCargoList; Tcont = MultiMap]’ at
/var/tmp/portage/games-simulation/openttd-13.4/work/openttd-13.4/src/cargopacket.cpp:158:3:
/var/tmp/portage/games-simulation/openttd-13.4/work/openttd-13.4/src/core/pool_type.hpp:261:45:
warning: ‘*_56 = PHI <_27(25), _7(23)>.CargoPacket::Pool::PoolItem<(&
_cargopacket_pool)>.Pool::PoolItem<(& _cargopacket_pool)>::index’ may be used uninitialized
[-Wmaybe-uninitialized]
  261 | Tpool->FreeItem(pn->index);
  | ^
[...]
```

[Bug c/111256] New: Wrong code at -O2/3/s since r10-1615-g75efe9cb1f8

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

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

Bug ID: 111256
   Summary: Wrong code at -O2/3/s since r10-1615-g75efe9cb1f8
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: shaohua.li at inf dot ethz.ch
CC: rguenth at gcc dot gnu.org
  Target Milestone: ---

gcc at -O2/3/s produces the wrong code.

Bisected to r10-1615-g75efe9cb1f8

Compiler explorer: https://godbolt.org/z/WPzEMoW6e

$ cat a.c
int printf(const char *, ...);
int a, d, e, g;
long b, h;
long i() {
  b++;
  return b;
}
int l(int m[], int p[]) {
  if (d)
for (; e; e++) {
  m[4] = m[0] = m[1] ^ m[2] ^ m[5];
  m[7] = m[3] ^ m[6];
  m += 4;
}
  m[6] = m[0] ^ 1;
  m[7] = m[1] ^ m[2] ^ m[7];
  m[9] = m[3] ^ m[8];
  return 1;
}
int fn3() {
  int j[] = {0, 7, 0, 0, 5, 0, 0, 8, 0, 0};
  int k[17];
  int c = l(j, k);
  return c;
}
int main() {
  for (; h <= 3; h = fn3() + h) {
long n[2];
for (; i() < 2;)
  n[g] = 508;
for (; (int)n[0] < 2;) {
  char o[] = {3, 4, 6, 3, 0, 0, 5, 6, 6, 1, 7, 0, 0, 0, 0, 0};
  char *f = o;
  for (; *f; ++f)
;
}
  }
  printf("%X\n", a);
}
$
$ gcc -O0 a.c && ./a.out
0
$ gcc -O2 a.c
% ./a.out
(Timeout)

[Bug c/111256] Wrong code at -O2/3/s since r10-1615-g75efe9cb1f8

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

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

Xi Ruoyao  changed:

   What|Removed |Added

 CC||xry111 at gcc dot gnu.org
 Resolution|--- |INVALID
 Status|UNCONFIRMED |RESOLVED

--- Comment #1 from Xi Ruoyao  ---
In the 2nd iteration of "for (; h <= 3; h = fn3() + h)" the code uses
uninitialized value:

$ clang t.c -O0 -fsanitize=memory -g
$ ./a.out 
==76055==WARNING: MemorySanitizer: use-of-uninitialized-value
#0 0x56392dea5370 in main /home/xry111/t.c:31:5
#1 0x7f9671e27f59 in __libc_start_call_main
/home/xry111/sources/lfs/glibc-2.38/csu/../sysdeps/nptl/libc_start_call_main.h:58:16
#2 0x7f9671e28024 in __libc_start_main@GLIBC_2.2.5
/home/xry111/sources/lfs/glibc-2.38/csu/../csu/libc-start.c:360:3
#3 0x56392de0f2d0 in _start
/home/xry111/sources/lfs/glibc-2.38/csu/../sysdeps/x86_64/start.S:115

SUMMARY: MemorySanitizer: use-of-uninitialized-value /home/xry111/t.c:31:5 in
main
Exiting

Thus invalid.

[Bug c/111256] Wrong code at -O2/3/s since r10-1615-g75efe9cb1f8

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

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

--- Comment #2 from Xi Ruoyao  ---
If you don't have Clang, you can also reproduce the timeout with
-ftrivial-auto-var-init=zero or -ftrivial-auto-var-init=pattern (in GCC 12 or
later).

[Bug libstdc++/111129] std::regex incorrectly matches quantifiers with plus appended

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

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

--- Comment #3 from Jonathan Wakely  ---
I have a patch to reject "a++" and "a**" but it doesn't work for "a+?" which is
invalid for POSIX REs, but valid for ECMAScript.

[Bug c++/102609] [C++23] P0847R7 - Deducing this

[gasper.azman at gmail dot com via Gcc-bugs]

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

--- Comment #17 from Gašper Ažman  ---
Read through the patch quickly, want to suggest a few tests.

When a lambda has captures, the explicit object parameter is used to get at
them *silently*, if they are related, otherwise the program is ill-formed:

int x = 42;
auto f1 = [x](this auto&&) {
   return x;
};
auto f2 = [](this auto&&) { return 42; }

static_cast(decltype(f1)::operator()); // OK
static_cast(decltype(f1)::operator()); // ERROR
static_cast(decltype(f2)::operator()); // OK

[Bug tree-optimization/111240] [12/13/14 Regression] Incorrect warning from -Wmaybe-uninitialized

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

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||11.4.0
 Status|UNCONFIRMED |NEW
Summary|Incorrect warning from  |[12/13/14 Regression]
   |-Wmaybe-uninitialized   |Incorrect warning from
   ||-Wmaybe-uninitialized
   Last reconfirmed|2023-08-30 00:00:00 |2023-08-31
   Target Milestone|--- |12.4
  Known to fail||12.1.0, 12.2.0, 13.2.0,
   ||14.0
   Keywords||needs-reduction
 Ever confirmed|0   |1

--- Comment #5 from Richard Biener  ---
Confirmed.

rettype_58 = enforce_generic_type_consistency (&actual_arg_types,
&declared_arg_types, 0, _56, 0);

and we reach this on the args == 0 path where indeed actual_arg_types
is uninitialized and our heuristic says that a const qualified pointer
is an input and thus might be read.  So you get a maybe-uninitialized
diagnostic at the call.

GCC doesn't know that the 'nargs' argument relates to the array and
that at most 'nargs' (zero here) arguments are inspected.

So I think it works as designed, we have some duplicate bugreports
complaining about this "heuristic".

We are exposing this to ourselves by optimizing the args == 0 case
(skipping the initialization loop and constant propagating the
nargs argument).  Aka jump-threading.

[Bug middle-end/111241] Extraordinary amount of time spent in "callgraph functions expansion"

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

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

Richard Biener  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
  Known to fail||11.4.0, 13.2.0
   Last reconfirmed||2023-08-31
Version|unknown |13.2.0

--- Comment #2 from Richard Biener  ---
Confirmed.  -ftime-report -ftime-report-details reveals most of the alias stmt
walking time is from FRE (and then PRE).  Lowering --param
sccvn-max-alias-queries-per-access doesn't help much (but we're not running
into the existing limit anyway).

At -O1 FRE doesn't iterate and PRE doesn't run so that helps compile-time.

We possibly run into the VN iteration complexity which scales non-linearily
with loop depth.  Lowering --param=rpo-vn-max-loop-depth to it's minimum
of two doesn't help either though.

Not a recent regression, the testcase doesn't build with GCC 10, GCC 11.4 is
20% slower than 13.2 for me.

[Bug fortran/111218] Conflict in BIND(C) INTERFACEs in two Modules leads to ICE.

[rimvydas.jas at gmail dot com via Gcc-bugs]

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

Rimvydas (RJ)  changed:

   What|Removed |Added

 CC||rimvydas.jas at gmail dot com

--- Comment #4 from Rimvydas (RJ)  ---
Another testcase resulting in identical ICE.

$ cat test.f90
module foo1
  interface !bail ! generic works ok
subroutine bail() bind(c,name="bail_")
end subroutine
  end interface
end

module foo2
  interface !bail
subroutine sfx_bail(k)
  integer :: k
end subroutine
  end interface
end

module foo
  use foo1
  use foo2 , bail => sfx_bail
end

subroutine unice_dummy ! avoid ice
end

$ ./gcc/f951 test.f90
test.f90:21:22:

   21 | subroutine unice_dummy
  |  1
Error: Name 'bail' at (1) is an ambiguous reference to 'bail' from module
'foo1'

Using extra dummy unit at the end of file helps to avoid the ICE (avoids ICE on
original case too), but notice the wrong locus.  Issue here happens because
ambiguous_symbol() is called after parsing was already done, resulting in
nullification of gfc_current_locus global in gfc_advance_line () at
gcc/fortran/scanner.cc:651
651   gfc_current_locus.nextc = NULL;
So the "%C" cannot be used in gcc/fortran/symbol.cc:3167
  gfc_error ("Name %qs at %C is an ambiguous reference to %qs "
Note: there is an assertion in gcc/fortran/error.cc:1078
  gcc_assert (loc->nextc - loc->lb->line >= 0);


Question is weather bind(c) rename attribute should somehow affect interface
generic status in any way?
Testcase does pass with bind(c) commented out or with explicitly marked
interface as generic in foo1.

[Bug middle-end/111243] The -Og option inlines functions, making for a poor debugging experience.

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

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

Richard Biener  changed:

   What|Removed |Added

Version|unknown |13.2.1
 Status|UNCONFIRMED |NEW
 CC||hubicka at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
   Last reconfirmed||2023-08-31
   Keywords||documentation
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
One of the points of -Og is to make debugging of C++ programs easier and that
absolutely requires some inlining as otherwise you step into a lot of
abstraction stuff.  So no, -finline is enabled on purpose for -Og, but it
should only inline where doing that improves code size.

For your example we probably either have wrong estimates or the C++ frontends
indicates we should ignore limits when inlining.

/tmp/t.cpp:14:13: optimized:  Inlining Foo::Foo(int)/1 into int Test(int)/3.
   Estimating body: Foo::Foo(int)/1
   Known to be false: not inlined
   size:4
Accounting size:2.00, time:2.00 on predicate exec:(true)
Accounting size:1.00, time:0.41 on predicate exec:(true)
Accounting size:0.50, time:0.20 on predicate exec:(true)
Accounting size:0.50, time:0.30 on predicate exec:(true)
/tmp/t.cpp:14:13: note: Inlining Foo::Foo(int)/1 to int Test(int)/3 with
frequency 1.00

We estimate a growth of one which is visible by setting --param
early-inlining-insn=0:

/tmp/t.cpp:14:13: note: Considering inline candidate Foo::Foo(int)/1.
   Estimating body: Foo::Foo(int)/1
   Known to be false: not inlined
   size:4
   Estimating body: Foo::Foo(int)/1
   Known to be false: not inlined
   size:4
/tmp/t.cpp:14:13: missed:   will not early inline: int
Test(int)/3->Foo::Foo(int)/1, growth 1 exceeds --param early-inlining-insns

with --param early-inlining-insns=1 we still inline.  I guess it makes sense
to adjust this param by default for -Og (and to zero).  The intent is
to inline things like get() and set(x) in

struct X { int get() { return val; } void set(int v) { val = v; } int val; };

or other simple forwarders.

Would you agree with inlining these?  -Og is also documented to shift the
balance a bit towards performance compared to -O0 which for C++ code
necessarily means at least some inlining.  Possibly we should also amend
the documentation highlighting this.

[Bug ipa/111245] [12/13/14 Regression] miscompilation: missing assignment when exception thrown since r12-5244-g64f3e71c302b4a13e61656ee509e7050b9bce978

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

--- Comment #4 from Richard Biener  ---
Sounds like call LHS analysis mistake in modref.

[Bug target/110411] ICE on simple memcpy test case when allowing generation of vector pair load/store insns

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

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

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

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

commit r14-3592-g9ea1248604d7b65009af32103814332f35bd33e2
Author: Jeevitha 
Date:   Thu Aug 31 05:40:18 2023 -0500

rs6000: Don't allow AltiVec address in movoo & movxo pattern [PR110411]

There are no instructions that do traditional AltiVec addresses (i.e.
with the low four bits of the address masked off) for OOmode and XOmode
objects. The solution is to modify the constraints used in the movoo and
movxo pattern to disallow these types of addresses, which assists LRA in
resolving this issue. Furthermore, the mode size 16 check has been
removed in vsx_quad_dform_memory_operand to allow OOmode and XOmode, and
quad_address_p already handles less than size 16.

2023-08-31  Jeevitha Palanisamy  

gcc/
PR target/110411
* config/rs6000/mma.md (define_insn_and_split movoo): Disallow
AltiVec address operands.
(define_insn_and_split movxo): Likewise.
* config/rs6000/predicates.md (vsx_quad_dform_memory_operand):
Remove
redundant mode size check.

gcc/testsuite/
PR target/110411
* gcc.target/powerpc/pr110411-1.c: New testcase.
* gcc.target/powerpc/pr110411-2.c: New testcase.

[Bug tree-optimization/111249] [12/13 Regression] Aggressive loop optimization reports "iteration 2147483645 invokes undefined behavior"

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

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

Richard Biener  changed:

   What|Removed |Added

  Known to fail||13.2.1
   Target Milestone|--- |12.4
 Status|UNCONFIRMED |NEW
 CC||hubicka at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=111233
 Ever confirmed|0   |1
   Keywords||wrong-code
   Last reconfirmed||2023-08-31

--- Comment #1 from Richard Biener  ---
-fno-split-loops avoids this, so possibly related to PR111233.  It's also a hit
at a wrong-code issue.

[Bug middle-end/111253] Dodgy pointer name (*_42 = PHI ...) in -Wfree-nonheap-object diagnostic

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-08-31
   Keywords||diagnostic
 CC||msebor at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Richard Biener  ---
We use

2034  if (!warning_at (loc, OPT_Wfree_nonheap_object,
2035   "%qD called on pointer %qE with nonzero offset%s",
2036   dealloc_decl, aref.ref, offstr))

so this is %qE handling where in c_pretty_printer::primary_expression for
an SSA name we do

  if (SSA_NAME_VAR (e))
...
  else
{
  /* Print only the right side of the GIMPLE assignment.  */
  gimple *def_stmt = SSA_NAME_DEF_STMT (e);
  pp_gimple_stmt_1 (this, def_stmt, 0, TDF_RHS_ONLY);
}

this regressed with r11-6508-gabb1b6058c09a7 which of course was supposed
to be an improvement.  But I'm not sure in which cases it actually is?
Possibly when the definition is a memory read (but then this can also
appear to falsely re-order loads across stores).

Fixing this gets us again

t.i:21:5: warning: 'realloc' called on pointer '*.t_mem_caches' with
nonzero offset 40 [-Wfree-nonheap-object]
   21 | realloc(__trans_tmp_1.t_mem_caches, sizeof(int));
  | ^~~~

the idea of expanding GIMPLE stmts until we hit a named one might be
appealing but then we need to do so recursively and for example
expand PHIs as  ? A : B (or even more complex for PHIs with
more than one argument).

The following still passes the three testcases adjusted/added with the
original change.

diff --git a/gcc/c-family/c-pretty-print.cc b/gcc/c-family/c-pretty-print.cc
index 7536a7c471f..679aa766fe0 100644
--- a/gcc/c-family/c-pretty-print.cc
+++ b/gcc/c-family/c-pretty-print.cc
@@ -33,6 +33,9 @@ along with GCC; see the file COPYING3.  If not see
 #include "langhooks.h"
 #include "options.h"
 #include "internal-fn.h"
+#include "function.h"
+#include "basic-block.h"
+#include "gimple.h"

 /* The pretty-printer code is primarily designed to closely follow
(GNU) C and C++ grammars.  That is to be contrasted with spaghetti
@@ -1380,12 +1383,14 @@ c_pretty_printer::primary_expression (tree e)
  else
primary_expression (var);
}
-  else
+  else if (gimple_assign_single_p (SSA_NAME_DEF_STMT (e)))
{
  /* Print only the right side of the GIMPLE assignment.  */
  gimple *def_stmt = SSA_NAME_DEF_STMT (e);
  pp_gimple_stmt_1 (this, def_stmt, 0, TDF_RHS_ONLY);
}
+  else
+   expression (e);
   break;

 default:

[Bug middle-end/111253] [11/12/13/14 Regression] Dodgy pointer name (*_42 = PHI ...) in -Wfree-nonheap-object diagnostic

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

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

Richard Biener  changed:

   What|Removed |Added

Summary|Dodgy pointer name (*_42 =  |[11/12/13/14 Regression]
   |PHI ...) in |Dodgy pointer name (*_42 =
   |-Wfree-nonheap-object   |PHI ...) in
   |diagnostic  |-Wfree-nonheap-object
   ||diagnostic
   Target Milestone|--- |11.5

[Bug middle-end/111253] [11/12/13/14 Regression] Dodgy pointer name (*_42 = PHI ...) in -Wfree-nonheap-object diagnostic

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

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

--- Comment #3 from Richard Biener  ---
*** Bug 111254 has been marked as a duplicate of this bug. ***

[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues

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

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

Bug 111254 Summary: Dodgy variable name (*_11 = PHI <_1(25), 
_25(23)>.CargoPacket::Pool...) in -Wmaybe-uninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111254

   What|Removed |Added

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

[Bug middle-end/111254] Dodgy variable name (*_11 = PHI <_1(25), _25(23)>.CargoPacket::Pool...) in -Wmaybe-uninitialized

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

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

Richard Biener  changed:

   What|Removed |Added

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

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

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

[Bug c++/102610] [C++23] P2036R3 - Change scope of lambda trailing-return-type

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Related question for the last paper:
https://github.com/cplusplus/draft/issues/6536
Other than that, I guess opening a new sk_lambda scope in
cp_parser_lambda_declarator_opt at the start and leaving it at the end should
be easy,
but we only build_capture_proxy later on.  Shall we pushdecl into the sk_lambda
scope
instead the LAMBDA_CAPTURE_EXPLICIT_P && !DECL_NORMAL_CAPTURE_P captures and
somehow special-case them in name lookup or just finish_decltype_type where we
currently handle
the
  if (outer_automatic_var_p (expr)
  && current_function_decl
  && LAMBDA_FUNCTION_P (current_function_decl))
type = capture_decltype (expr);
case?  Though, in the lambda declarator, current_function_decl is still the
containing function and outer_automatic_var_p also will not work.  I guess we
need some way to know whether we are in the lambda declarator (and also whether
it is before the end of
parameter declarations or after and whether in the latter case the lambda is
mutable or not) and special case in that case both the init-captures and
automatic? vars from the current function (which will be outer vars in lambda
body).

[Bug tree-optimization/111257] New: new signed overflow after vectorizer

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

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

Bug ID: 111257
   Summary: new signed overflow after vectorizer
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kristerw at gcc dot gnu.org
  Target Milestone: ---

The vectorizer is not removing the original scalar calculations, and they may
overflow after vectorization.

This can be seen with

  int a[8];

  void foo(void)
  {
for (int i = 0; i < 8; i++)
  a[i] = a[i] + 5;
  }

The IR for the loop before vectorization looks like

   [local count: 954449104]:
  # i_10 = PHI 
  # ivtmp_4 = PHI 
  _1 = a[i_10];
  _2 = _1 + 5;
  a[i_10] = _2;
  i_7 = i_10 + 1;
  ivtmp_3 = ivtmp_4 - 1;
  if (ivtmp_3 != 0)
goto ; [87.50%]
  else
goto ; [12.50%]

   [local count: 835156385]:
  goto ; [100.00%]

and it is vectorized to

   [local count: 238585440]:
  # i_10 = PHI 
  # ivtmp_4 = PHI 
  # vectp_a.4_9 = PHI 
  # vectp_a.8_16 = PHI 
  # ivtmp_19 = PHI 
  vect__1.6_13 = MEM  [(int *)vectp_a.4_9];
  _1 = a[i_10];
  vect__2.7_15 = vect__1.6_13 + { 5, 5, 5, 5 };
  _2 = _1 + 5;
  MEM  [(int *)vectp_a.8_16] = vect__2.7_15;
  i_7 = i_10 + 1;
  ivtmp_3 = ivtmp_4 - 1;
  vectp_a.4_8 = vectp_a.4_9 + 16;
  vectp_a.8_17 = vectp_a.8_16 + 16;
  ivtmp_20 = ivtmp_19 + 1;
  if (ivtmp_20 < 2)
goto ; [50.00%]
  else
goto ; [50.00%]

   [local count: 119292723]:
  goto ; [100.00%]

This vectorized loop still read _1 from a[i_10] and adds 5 to it, so the second
loop iteration will add 5 to the value of a[1]. But the first iteration has
already added 5 to a[1], so we are now doing a different calculation compared
to the original loop, and this can overflow even if the original did not.

[Bug c/67729] -Wformat should warn for %Ns where the buffer size is known to be less than N in size

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #5 from David Binderman  ---
I just noticed that clang-16.0.6 now implements this check:

$ clang++ -c -g -O2 -Wall -Wextra -Wformat=2 -D_FORTIFY_SOURCE=2 sep9a.cc
sep9a.cc:13:29: warning: 'fscanf' may overflow; destination buffer in argument
3 has size 10, but the corresponding specifier may require size 11
[-Wfortify-source]
while (fscanf( fp, "%10s", buf))
   ^
sep9a.cc:17:29: warning: 'fscanf' may overflow; destination buffer in argument
3 has size 10, but the corresponding specifier may require size 21
[-Wfortify-source]
while (fscanf( fp, "%20s", buf))
   ^
2 warnings generated.
$

Still nothing from gcc:

$ ~/gcc/results/bin/g++ -c -g -O2 -Wall -Wextra -Wformat=2 -D_FORTIFY_SOURCE=2
sep9a.cc
$

[Bug middle-end/111253] [11/12/13/14 Regression] Dodgy pointer name (*_42 = PHI ...) in -Wfree-nonheap-object diagnostic

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #4 from Richard Biener  ---
Successfully tested.

[Bug fortran/99711] Crash when reading an allocated character array in namelist

[philippe.wautelet at aero dot obs-mip.fr via Gcc-bugs]

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

--- Comment #18 from philippe.wautelet at aero dot obs-mip.fr ---
Hello,

What is the status of this bug?

It seems that it is not present any more in the 12.x and 13.x GCC versions.

11.4 does not crash but gives incorrect results.

[Bug middle-end/111241] Extraordinary amount of time spent in "callgraph functions expansion"

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

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

--- Comment #3 from Richard Biener  ---
Samples: 121K of event 'cycles:u', Event count (approx.): 159788164341  
Overhead   Samples  Command  Shared Object   Symbol 
  21.24% 25791  cc1  cc1 [.]
get_ref_base_and_exten#
   7.75%  9154  cc1  libc-2.31.so[.] __memset_avx512_erms 
#
   5.61%  7072  cc1  cc1 [.] dominated_by_p   
#
   2.43%  2936  cc1  cc1 [.] bitmap_set_bit   
#
   2.38%  3000  cc1  cc1 [.] dominated_by_p_w_unex
#
   1.76%  2154  cc1  cc1 [.] find_base_term   
#
   1.75%  2148  cc1  cc1 [.] ix86_find_base_term  
#
   1.41%  1656  cc1  cc1 [.]
df_reorganize_refs_by_#

all usual suspects are present ... :/

The memset and df_reorganize_refs_by_defs are the known bug that RTL invariant
motion does work O(function-size) * O(number-of-loops) through df_analyze_loop
because reorganize-refs processes all function refs, not only loop refs
(difficult to fix).

For get_ref_base_and_extent we have ~2 array-refs per call and array-ref
processing is expensive (array_ref_element_size, but also
wi::lshift_large).  The most expensive calls are from vn_reference_lookup done
during elimination looking for redundant stores (that's odd), possibly
because it enables VN_WALKREWRITE unconditionally, for -O2 that's also
the default though.

[Bug middle-end/111253] [11/12/13/14 Regression] Dodgy pointer name (*_42 = PHI ...) in -Wfree-nonheap-object diagnostic

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

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

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

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

commit r14-3595-ge3ece7684b02c47d2b259899cf8009d6bdcccaf3
Author: Richard Biener 
Date:   Thu Aug 31 13:53:21 2023 +0200

middle-end/111253 - partly revert r11-6508-gabb1b6058c09a7

The following keeps dumping SSA def stmt RHS during diagnostic
reporting only for gimple_assign_single_p defs which means
memory loads.  This avoids diagnostics containing PHI nodes
like

  warning: 'realloc' called on pointer '*_42 = PHI .t_mem_caches' with nonzero offset 40

instead getting back the previous behavior:

  warning: 'realloc' called on pointer '*.t_mem_caches' with
nonzero offset 40

PR middle-end/111253
gcc/c-family/
* c-pretty-print.cc (c_pretty_printer::primary_expression):
Only dump gimple_assign_single_p SSA def RHS.

gcc/testsuite/
* gcc.dg/Wfree-nonheap-object-7.c: New testcase.

[Bug fortran/106065] Crash when reading extended derived type array in namelist

[philippe.wautelet at aero dot obs-mip.fr via Gcc-bugs]

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

philippe.wautelet at aero dot obs-mip.fr changed:

   What|Removed |Added

Version|12.1.0  |13.2.0

--- Comment #3 from philippe.wautelet at aero dot obs-mip.fr ---
Hello,

The problem is still there in the 13.2.0 version. Any update?

Thanks,

[Bug middle-end/111253] [11/12/13 Regression] Dodgy pointer name (*_42 = PHI ...) in -Wfree-nonheap-object diagnostic

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
Summary|[11/12/13/14 Regression]|[11/12/13 Regression] Dodgy
   |Dodgy pointer name (*_42 =  |pointer name (*_42 = PHI
   |PHI ...) in |...) in
   |-Wfree-nonheap-object   |-Wfree-nonheap-object
   |diagnostic  |diagnostic
  Known to work||14.0

--- Comment #6 from Richard Biener  ---
Fixed on trunk sofar.

[Bug tree-optimization/111257] new signed overflow after vectorizer

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

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

Richard Biener  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2023-08-31
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Keywords||missed-optimization,
   ||wrong-code

--- Comment #1 from Richard Biener  ---
Yeah, we modify a copy of the scalar loop in-place, only removing original
stmts that have side-effects, leaving dead code elimination to the followup DCE
pass.  Note we run that immediately after loop vectorization but for SLP
vectorization
there are quite some intermediate passes until we perform DCE, for example
there's IVOPTS which might re-compute number of iterations and at least
max_iteration estimate also looks at undefined behavior.  OTOH with SLP
vectorization we don't change any loop iteration which means the original
stmts only compute the very original values (should, at least).

That means there might be an actual issue for those cases but for loop
vectorization the issue should be moot unless those stmts survive the
DCE pass after it.

I would suggest to "blacklist" analyzing the "vect" dump, the followup "dce"
dump should be fine.

For SLP I'm not sure, I guess no actual problems should show up but we
should maybe try to use simple_dce_from_worklist with the root stmts
original SSA uses (and defs in some cases), possibly the root stmt
vectorization code generation code could gather relevant defs.

So I think, correctness wise it should be a non-issue but it's a bit
ugly also since some fuzzers like to disable DCE which then indeed
would create wrong-code issues.

[Bug libstdc++/111163] signed integer overflow in std::format("{:%S}",std::chrono::duration....)

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

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

--- Comment #4 from Jonathan Wakely  ---
With this patch:

--- a/libstdc++-v3/include/bits/chrono_io.h
+++ b/libstdc++-v3/include/bits/chrono_io.h
@@ -507,6 +507,16 @@ namespace __format
  if constexpr (__is_specialization_of<_Tp, chrono::hh_mm_ss>)
__is_neg = __t.is_negative();

+ if constexpr (chrono::__is_duration_v<_Tp>)
+   if constexpr (_Tp::period::num != 1)
+ {
+   // Check conversion to seconds will not overflow.
+   chrono::seconds::rep __s{};
+   if (__builtin_mul_overflow(__t.count(), _Tp::period::num,
&__s))
+ __throw_format_error("chrono format error: integer overflow "
+  "converting duration to seconds");
+ }
+
  auto __print_sign = [&__is_neg, &__out] {
if constexpr (chrono::__is_duration_v<_Tp>
|| __is_specialization_of<_Tp, chrono::hh_mm_ss>)

The testcase throws:

terminate called after throwing an instance of 'std::format_error'
  what():  chrono format error: integer overflow converting duration to seconds
Aborted (core dumped)


This isn't ideal as there are some uses that wouldn't overflow, e.g.
std::format("{:%j}", std::chrono::days::max())
This doesn't require any conversion and so could be formatted. But I'm not sure
I care about this case, it's pretty unlikely to ever be needed.

If we did the overflow checks at the point of conversion then we'd be doing
them multiple times for a format string like "%H:%M:%S". But then I suppose
we're already converting the duration to hh_mm_ss three times there anyway. The
patch in PR 110739 comment 2 would help with that, as the _S_hms call might be
subject to common subexpression elimination, and the checks would only be done
once. We could also just call _S_hms once up-front when we have a type that can
make use of it, and then reuse the result as needed.


And the patch above doesn't handle all cases anyway, because this will still
overflow:
std::format("{:%S}", std::chrono::sys_days{std::chrono::days::max()});

So maybe we just need a checked duration_cast, floor, floor,
and the check for conversion to seconds for use with hh_mm_ss.

[Bug c++/111247] Very confusing diagnostic when attempting to initialize an incomplete type: "too many initializers"

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

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #2 from Marek Polacek  ---
Changed in r247630 probably.

[Bug target/111246] PPC64 Sequentially Consistent Load allows Reordering of Stores

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

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

David Edelsohn  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-08-31

--- Comment #5 from David Edelsohn  ---
There is no lwfence instruction in PowerPC.  We will need to examine what code
generation change is necessary.  Did you intend to suggest lwsync?

[Bug target/111246] PPC64 Sequentially Consistent Load allows Reordering of Stores

[luke.geeson at cs dot ucl.ac.uk via Gcc-bugs]

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

--- Comment #6 from Luke Geeson  ---
Apologies - I've been thinking in syncs and fences too much!

Yes I mean `lwsync`, for clarity I repeat the above so you know it is the
correct fix:
```
lukegeeson@machine:~/Dev/tv-dev/herdtools7$  cat test.litmus
PPC test-fixed

{ [P1_r0]=0;[x]=0;[y]=0;
  uint64_t %P0_x=x; uint64_t %P0_y=y;
  uint64_t %P1_P1_r0=P1_r0;uint64_t %P1_x=x;
  uint64_t %P1_y=y }
(*)
(* the Telechat toolsuite*)
(*   *)
(* Luke Geeson, University College London, UK.   *)
(*   *)
(*)
  P0 |  P1;
   li r10,2  |   sync ;
   stw r10,0(%P0_x)  |   lwz r9,0(%P1_y)  ;
   lwsync|   cmpw r9,r9   ;
   sync  |   b   L0x50;
   li r10,1  |  L0x50: lwsync ;
   stw r10,0(%P0_y)  |   li r8,1  ;
 |   stw r8,0(%P1_x)  ;
 |   stw r9,0(%P1_P1_r0)  ;


exists ([x]=2 /\ P1_r0=1)
lukegeeson@machine:~/Dev/tv-dev/herdtools7$  ./_build/install/default/bin/herd7
-model ppc.cat -I herd/libdir test.litmus
Test test-fixed Allowed
States 3
[P1_r0]=0; [x]=1;
[P1_r0]=0; [x]=2;
[P1_r0]=1; [x]=1;
No
Witnesses
Positive: 0 Negative: 3
Condition exists ([x]=2 /\ [P1_r0]=1)
Observation test-fixed Never 0 3
Time test-fixed 0.01
Hash=b215018fe694934d3b5fd1dc5eef48e9
```

[Bug libstdc++/111258] New: std::string cannot to be moved in constant evaluated expression

[kisses07_rupee at icloud dot com via Gcc-bugs]

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

Bug ID: 111258
   Summary: std::string cannot to be moved in constant evaluated
expression
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kisses07_rupee at icloud dot com
  Target Milestone: ---

c++20 std::string's destructor fails after move:

#include 

using namespace std::literals;

constexpr auto foo(auto a) {
auto b = std::move(a);
return b[1];
}

int main(int,char**) {
static_assert( foo("hello"s) == 'e' );
return 0;
}

fails with:
: In function 'int main(int, char**)':
:11:34: error: non-constant condition for static assertion
   11 | static_assert( foo("hello"s) == 'e' );
  |~~^~
:11:23:   in 'constexpr' expansion of
'foo
>(std::literals::string_literals::operator""s(const char*, std::size_t)(5))'
:11:42:   in 'constexpr' expansion of
'std::__cxx11::basic_string((* &
std::move<__cxx11::basic_string&>(a)))'
:11:34: error: accessing 'std::__cxx11::basic_string_M_allocated_capacity' member instead of initialized
'std::__cxx11::basic_string_M_local_buf' member in
constant expression
Compiler returned: 1

online demo: https://godbolt.org/z/Tz7MK58f1

it seems it's affecting on bug 103924

[Bug testsuite/111228] [14 regression] gcc.target/powerpc/vsx-extract-6.c fails after r14-3381-g27de9aa152141e

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

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

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

https://gcc.gnu.org/g:80277e18e1a77b68f938b605c3ecd2750194ed75

commit r14-3598-g80277e18e1a77b68f938b605c3ecd2750194ed75
Author: Peter Bergner 
Date:   Thu Aug 31 08:56:47 2023 -0500

rs6000: Update instruction counts to match vec_* calls [PR111228]

Commit  r14-3258-ge7a36e4715c716 increased the amount of folding we
perform,
leading to better code.  Update the expected instruction counts to match
the
changes.

2023-08-31  Peter Bergner  

gcc/testsuite/
PR testsuite/111228
* gcc.target/powerpc/fold-vec-logical-ors-char.c: Update
instruction
counts to match the number of associated vec_* built-in calls.
* gcc.target/powerpc/fold-vec-logical-ors-int.c: Likewise.
* gcc.target/powerpc/fold-vec-logical-ors-longlong.c: Likewise.
* gcc.target/powerpc/fold-vec-logical-ors-short.c: Likewise.
* gcc.target/powerpc/fold-vec-logical-other-char.c: Likewise.
* gcc.target/powerpc/fold-vec-logical-other-int.c: Likewise.
* gcc.target/powerpc/fold-vec-logical-other-longlong.c: Likewise.
* gcc.target/powerpc/fold-vec-logical-other-short.c: Likewise.

[Bug testsuite/111228] [14 regression] gcc.target/powerpc/vsx-extract-6.c fails after r14-3381-g27de9aa152141e

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

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

--- Comment #8 from Peter Bergner  ---
(In reply to CVS Commits from comment #7)
> The master branch has been updated by Peter Bergner :

Bah, wrong PR#, Sorry! :-(

[Bug testsuite/111216] [14 regression] instructions counts for vector tests change after r14-3258-ge7a36e4715c716

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

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

Peter Bergner  changed:

   What|Removed |Added

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

--- Comment #4 from Peter Bergner  ---
Fixed on trunk.

[Bug target/111246] PPC64 Sequentially Consistent Load allows Reordering of Stores

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

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

--- Comment #7 from David Edelsohn  ---
Have you reached out to Paul McKenney (now at Meta) who suggested the
instruction sequences to implement the C/C++ memory for PowerPC?
https://open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2745.html

[Bug gcov-profile/110827] C++20 coroutines aren't being measured by gcov

[mwd at md5i dot com via Gcc-bugs]

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

--- Comment #9 from Michael Duggan  ---
More data:
The coroutine actor is marked as artificial in
coro_build_actor_or_destroy_function.  As a result, it is completely ignored by
gcov.  In gcov's process_all_functions function, artificial functions are
removed from the set of functions to consider.  This may not be the only
problem, but this will definitely prevent things from working.

The marking is not incorrect.  The actor function is artificial.  But, unlike
most artificial functions, it is built using the body of an actual function. 
I'm not certain how that should be dealt with.

[Bug fortran/99711] Crash when reading an allocated character array in namelist

[sgk at troutmask dot apl.washington.edu via Gcc-bugs]

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

--- Comment #19 from Steve Kargl  ---
On Thu, Aug 31, 2023 at 12:58:15PM +, philippe.wautelet at aero dot
obs-mip.fr wrote:
> 
> What is the status of this bug?
> 
> It seems that it is not present any more in the 12.x and 13.x GCC versions.
> 

Looks like it is fixed by the patch for some other bug report.
A scan of gcc/fortran/ChangeLog shows a number patches that
tinker with the character length for deferred length strings.
I don't which one is the responsiblei, and since I don't use 
git (other than for trivial 'git diff' and 'git pull') doing a
bisection is beyond my skillset.

Someone should likely convert your testcase into something
that the testsuite can digest, and commit it.

[Bug fortran/99711] Crash when reading an allocated character array in namelist

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

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

  Known to work||12.2.0, 14.0
   Priority|P3  |P4

[Bug middle-end/111156] [14 Regression] aarch64 aarch64/sve/mask_struct_store_4.c failures

[adhemerval.zanella at linaro dot org via Gcc-bugs]

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

Adhemerval Zanella  changed:

   What|Removed |Added

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

--- Comment #5 from Adhemerval Zanella  
---
Reopening since this is not a duplicate of bug 36.  The issue is
mask_struct_store_4.c generates the very instructions that the test is
checking:

$ ./gcc/xgcc -Bgcc -march=armv8.2-a+sve -O2 -ftree-vectorize -ffast-math
[..]/gcc/testsuite/gcc.target/aarch64/sve/mask_struct_store_4.c -S -o - | grep
st2b
st2b{z30.b - z31.b}, p7, [x0, x5]
st2b{z28.b - z29.b}, p6, [x0, x5]
st2b{z28.b - z29.b}, p6, [x0, x5]
st2b{z28.b - z29.b}, p7, [x0, x5]
st2b{z26.b - z27.b}, p6, [x0, x5]
st2b{z26.b - z27.b}, p6, [x0, x5]
st2b{z28.b - z29.b}, p7, [x0, x5]
st2b{z26.b - z27.b}, p6, [x0, x5]
st2b{z26.b - z27.b}, p6, [x0, x5]
st2b{z28.b - z29.b}, p7, [x0, x5]
st2b{z26.b - z27.b}, p6, [x0, x5]
st2b{z26.b - z27.b}, p6, [x0, x5]

[Bug tree-optimization/110915] vector version of `x == MIN & x > y` is not optimized

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

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

--- Comment #4 from CVS Commits  ---
The trunk branch has been updated by Andrew Pinski :

https://gcc.gnu.org/g:16a268785f646b3d641acd8634ab487b24f51c33

commit r14-3603-g16a268785f646b3d641acd8634ab487b24f51c33
Author: Andrew Pinski 
Date:   Wed Aug 30 12:27:06 2023 -0700

MATCH: extend min_value/max_value match to vectors

This simple patch extends the min_value/max_value match to vector integer
types.
Using uniform_integer_cst_p makes this easy.

OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions.

The testcases pr110915-*.c are the same as pr88784-*.c except using vector
types instead.

PR tree-optimization/110915

gcc/ChangeLog:

* match.pd (min_value, max_value): Extend to vector constants.

gcc/testsuite/ChangeLog:

* gcc.dg/pr110915-1.c: New test.
* gcc.dg/pr110915-10.c: New test.
* gcc.dg/pr110915-11.c: New test.
* gcc.dg/pr110915-12.c: New test.
* gcc.dg/pr110915-2.c: New test.
* gcc.dg/pr110915-3.c: New test.
* gcc.dg/pr110915-4.c: New test.
* gcc.dg/pr110915-5.c: New test.
* gcc.dg/pr110915-6.c: New test.
* gcc.dg/pr110915-7.c: New test.
* gcc.dg/pr110915-8.c: New test.
* gcc.dg/pr110915-9.c: New test.

[Bug tree-optimization/110915] vector version of `x == MIN & x > y` is not optimized

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #5 from Andrew Pinski  ---
Fixed.

[Bug middle-end/111243] The -Og option inlines functions, making for a poor debugging experience.

[amohr at amohr dot org via Gcc-bugs]

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

--- Comment #2 from Alex Mohr  ---
Thanks much for looking at this, Richard.

I definitely understand what you're driving at with regard to stepping into
lots of C++ abstraction stuff.  But I think it gets blurry trying to
distinguish what's interesting to a human or not based on code size.

I think I could probably be convinced about inlining trivial getters, setters,
and forwarders like in your struct X. But I think code size doesn't work as the
deciding factor here. Just to illustrate, here's a modified example with '-Og
--param early-inlining-insns=0'.  The entire thing gets inlined, even though
every small function contains a conditional, and one even calls another:

struct Foo {
explicit Foo(int in) { m = in > 0 ? in : 0; }
int CalcFoo() const { int r = CalcBar(); return r < 0 ? -r : r; }
int CalcBar() const { return m > 20 ? 20 : m; }
int m;
};

int Test(int in) {
Foo f(in);
return f.CalcFoo() + f.CalcBar();
}

--

Test(int):
testedi, edi
mov eax, 0
cmovs   edi, eax
mov eax, 20
cmp edi, eax
cmovg   edi, eax
lea eax, [rdi+rdi]
ret

https://godbolt.org/z/hcsnzMrP9

On one hand it's awesome that the optimizer is so good... but this could be
pretty frustrating to debug.

Just FWIW when I compile with '-O0', I see a ~5x slowdown vs '-O2', but with
'-Og -fno-inline', I see just ~4x, so it's still a nice win over '-O0'.

[Bug tree-optimization/19832] don't remove an if when we know the value is the same as with the if (subtraction)

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

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

--- Comment #10 from Andrew Pinski  ---
Patch posted here:
https://gcc.gnu.org/pipermail/gcc-patches/2023-August/628995.html

[Bug target/111246] PPC64 Sequentially Consistent Load allows Reordering of Stores

[luke.geeson at cs dot ucl.ac.uk via Gcc-bugs]

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

--- Comment #8 from Luke Geeson  ---
I have not, but I will contact him and link this discussion. In the meantime, I
read that page and provide some more testing. Consider the passage:
```
bc;isync: this is a very low-overhead and very weak form of memory fence. A
specific set of preceding loads on which the bc (branch conditional)
instruction depends are guaranteed to have completed before any subsequent
instruction begins execution
```
Note how the set of loads depend on a conditional load - in the test above GCC
emits an unconditional branch - and so this passage does not apply. We can see
this if we compare the output of the test with and without a conditional
branch:
```
$ cat test.litmus
PPC test

{ [P1_r0]=0;[x]=0;[y]=0;
  uint64_t %P0_x=x; uint64_t %P0_y=y;
  uint64_t %P1_P1_r0=P1_r0;uint64_t %P1_x=x;
  uint64_t %P1_y=y }
(*)
(* the Telechat toolsuite*)
(*   *)
(* Luke Geeson, University College London, UK.   *)
(*   *)
(*)
  P0 |  P1;
   li r10,2  |   sync ;
   stw r10,0(%P0_x)  |   lwz r9,0(%P1_y)  ;
   lwsync|   cmpw r9,r9   ;
   sync  |   b   L0x50;
   li r10,1  |  L0x50: isync  ;
   stw r10,0(%P0_y)  |   li r8,1  ;
 |   stw r8,0(%P1_x)  ;
 |   stw r9,0(%P1_P1_r0)  ;


exists ([x]=2 /\ P1_r0=1)

$ herd7 -model ppc.cat -I herd/libdir test.litmus
Test test Allowed
States 4
[P1_r0]=0; [x]=1;
[P1_r0]=0; [x]=2;
[P1_r0]=1; [x]=1;
[P1_r0]=1; [x]=2;
Ok
Witnesses
Positive: 1 Negative: 3
Condition exists ([x]=2 /\ [P1_r0]=1)
Observation test Sometimes 1 3
Time test 0.00
Hash=490e848f65aae63641db024a0fc82aa2
```
Then we make the branch a conditional branch:
```
PPC test

{ [P1_r0]=0;[x]=0;[y]=0;
  uint64_t %P0_x=x; uint64_t %P0_y=y;
  uint64_t %P1_P1_r0=P1_r0;uint64_t %P1_x=x;
  uint64_t %P1_y=y }
(*)
(* the Telechat toolsuite*)
(*   *)
(* Luke Geeson, University College London, UK.   *)
(*   *)
(*)
  P0 |  P1;
   li r10,2  |   sync ;
   stw r10,0(%P0_x)  |   lwz r9,0(%P1_y)  ;
   lwsync|   cmpw r9,r9   ;
   sync  |   beq   L0x50  ;
   li r10,1  |  L0x50: isync  ;
   stw r10,0(%P0_y)  |   li r8,1  ;
 |   stw r8,0(%P1_x)  ;
 |   stw r9,0(%P1_P1_r0)  ;


exists ([x]=2 /\ P1_r0=1)%
lukegeeson@LA:~/Dev/tv-dev/herdtools7|825f7fd5 ⇒ 
./_build/install/default/bin/herd7 -model ppc.cat -I herd/libdir test.litmus
Test test Allowed
States 3
[P1_r0]=0; [x]=1;
[P1_r0]=0; [x]=2;
[P1_r0]=1; [x]=1;
No
Witnesses
Positive: 0 Negative: 3
Condition exists ([x]=2 /\ [P1_r0]=1)
Observation test Never 0 3
Time test 0.00
Hash=52d2f37ed1564ba98544ff790020b69a
```

As you can see the buggy behaviour disappears when b is changed to bc. So there
are two solutions:

- Make isync a lwsync (better maps to the intent of sequential consistency,
perf costs)
- Make b a conditional branch bee (restores the intent of Paul's work, but adds
a control dependency where there was none in the source program - I am not a
fan of a mismatch of such dependencies).

I hope this helps.

[Bug target/111246] PPC64 Sequentially Consistent Load allows Reordering of Stores

[luke.geeson at cs dot ucl.ac.uk via Gcc-bugs]

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

--- Comment #9 from Luke Geeson  ---
apologies typos:
bc -> bee
bee -> beq

[Bug target/111259] New: [14 Regression] ICE: RTL check: expected code 'reg', have 'subreg' in rhs_regno, at rtl.h:1934 during riscv64 build

[zsojka at seznam dot cz via Gcc-bugs]

gcc-trunk/gcc/config/riscv/iterators.md:60
0x2249d2b recog(rtx_def*, rtx_insn*, int*)
/repo/gcc-trunk/gcc/config/riscv/iterators.md:58
0x227e442 recog_for_combine_1
/repo/gcc-trunk/gcc/combine.cc:11382
0x22819de recog_for_combine
/repo/gcc-trunk/gcc/combine.cc:11652
0x229c022 try_combine
/repo/gcc-trunk/gcc/combine.cc:3546
0x22a1544 combine_instructions
/repo/gcc-trunk/gcc/combine.cc:1264
0x22a1544 rest_of_handle_combine
/repo/gcc-trunk/gcc/combine.cc:15063
0x22a1544 execute
/repo/gcc-trunk/gcc/combine.cc:15107
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.



$ /repo/build-gcc-trunk-riscv64/./gcc/xgcc -v
Using built-in specs.
COLLECT_GCC=/repo/build-gcc-trunk-riscv64/./gcc/xgcc
Target: riscv64-unknown-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--with-cloog --with-ppl --with-isl --with-isa-spec=2.2
--with-sysroot=/usr/riscv64-unknown-linux-gnu --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=riscv64-unknown-linux-gnu
--with-ld=/usr/bin/riscv64-unknown-linux-gnu-ld
--with-as=/usr/bin/riscv64-unknown-linux-gnu-as --disable-multilib
--disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r14-3602-20230831181644-ga335cf241b9-checking-yes-rtl-df-extra-riscv64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.0 20230831 (experimental) (GCC)

[Bug target/111259] [14 Regression] ICE: RTL check: expected code 'reg', have 'subreg' in rhs_regno, at rtl.h:1934 during riscv64 build

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |14.0

[Bug target/111246] PPC64 Sequentially Consistent Load allows Reordering of Stores

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

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

--- Comment #10 from David Edelsohn  ---
If I compile your testcase with either GCC 11.3 or GCC trunk, GCC produces

P1:
.LFB1:
.cfi_startproc
.localentry P1,1
pld 9,.LANCHOR0+8@pcrel
sync
lwz 9,0(9)
cmpw 0,9,9<*** compare
bne- 0,$+4<*** branch conditional
isync <*** isync
pld 10,.LANCHOR0@pcrel
li 8,1
stw 8,0(10)
pld 10,.LANCHOR0+16@pcrel
stw 9,0(10)
blr

which contains the branch conditional that should satisfy the processor memory
model.  I'm not seeing the unconditional branch that you see in your example.

Your link to Compiler Explorer code generated by Clang also shows a branch
conditional

P1: # @P1
.quad   .Lfunc_begin1
.quad   .TOC.@tocbase
.quad   0
.Lfunc_begin1:
addis 3, 2, y@toc@ha
ld 3, y@toc@l(3)
sync
li 5, 1
lwz 3, 0(3)
cmpd 7, 3, 3  <*** compare
bne- 7, .+4   <*** branch conditional
isync <*** isync

What is generating or parsing or interpreting the unconditional branch shown in
your pasted code?

[Bug tree-optimization/107137] (unsigned)-(int)(bool_var) should be optimized to -(unsigned)bool_var

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

[Bug tree-optimization/107765] missing (int)-(unsigned)int_val to just -int_val if int_val is known not to contain INT_MIN

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

[Bug target/111260] New: arm: ice in maybe_legitimize_operand, at optabs.cc:8054

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 111260
   Summary: arm: ice in maybe_legitimize_operand, at
optabs.cc:8054
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Created attachment 55827
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55827&action=edit
C source code

For the attached C code, on a raspberry Pi 3, with
compiler flag -O2 and recent gcc, does this:

bug952.c:809:17: internal compiler error: in maybe_legitimize_operand, at
optabs.cc:8054
  809 | static uint32_t  func_16(int8_t * p_17, int64_t  p_18)
  | ^~~
0x8811b3 maybe_legitimize_operand
../../trunk/gcc/optabs.cc:8054
0x8811b3 maybe_legitimize_operands(insn_code, unsigned int, unsigned int,
expand_operand*)
../../trunk/gcc/optabs.cc:8191
0x87dfa7 maybe_gen_insn(insn_code, unsigned int, expand_operand*)
../../trunk/gcc/optabs.cc:8210
0x87ecff maybe_expand_insn(insn_code, unsigned int, expand_operand*)
../../trunk/gcc/optabs.cc:8265

The bug first seems to appear sometime between g:bb0da4542df887a5
and g:7c04da768c1fc22e

[Bug fortran/110987] Segmentation fault after finalization of a temporary variable

[chilikin.k at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Kirill Chilikin  ---
Some additional information:

$ gfortran -g -o test test.f90 -fdump-tree-original
$ cat test.f90.005t.original | head -n 747 | tail -n 26
  {
struct t3 zero.25;
struct array00_t3 desc.26;
struct t3 D.4638;

desc.26.dtype = {.elem_len=80, .rank=0, .type=5};
desc.26.data = (void * restrict) &zero.25;
desc.26.span = (integer(kind=8)) desc.26.dtype.elem_len;
{
  struct array00_t3 desc.27;

  desc.27.dtype = {.elem_len=80, .rank=0, .type=5};
  desc.27.data = (void * restrict) &x3;
  desc.27.span = (integer(kind=8)) desc.27.dtype.elem_len;
  __final_test_module_T1 (&desc.27, 80, 0);
} 
D.4638 = x3;
x3 = (struct t3) t3_constructor ();
if ((struct t1_pointer[0:] * restrict) D.4638.t1.next._data.data != 0B)
  {
__builtin_free ((void *) D.4638.t1.next._data.data);
(struct t1_pointer[0:] * restrict) D.4638.t1.next._data.data = 0B;
  }
D.4638.t1.next._vptr = (struct __vtype_test_module_T1_pointer * {ref-all})
&__vtab_test_module_T1_pointer;
__vtab_test_module_T3._final (&desc.26, __vtab_test_module_T3._size, 0);
  }

The call of __vtab_test_module_T3._final is on desc.26 pointing to otherwise
unused zero.25.

$ gdb ./test
(gdb) b 102
Breakpoint 1 at 0x4033ca: file test.f90, line 102.
(gdb) r
Breakpoint 1, test_program () at test.f90:102
102   X3 = T3()
(gdb) p x2
$1 = ( t1 = ( n_next = 1, next = ( _data = (( t1 = ( _data = 0x4062a0 ,
_vptr = 0x406140 <__test_module_MOD___vtab_test_module_T1> ) )), _vptr =
0x4061a0 <__test_module_MOD___vtab_test_module_T1_pointer> ) ), x =
1.40129846e-45 )
(gdb) b t1_destructor
Breakpoint 2 at 0x4027f0: file test.f90, line 49.
(gdb) ignore 2 3
Will ignore next 3 crossings of breakpoint 2.
(gdb) c
Breakpoint 2, test_module::t1_destructor (self=...) at test.f90:49
49  IF (ALLOCATED(SELF%NEXT)) THEN
(gdb) backtrace
#0  test_module::t1_destructor (self=...) at test.f90:49
#1  0x00401813 in test_module::__final_test_module_T1 (array=...,
byte_stride=80, fini_coarray=.FALSE.) at test.f90:90
#2  0x004035d0 in test_program () at test.f90:102
(gdb) p self
$2 = ( n_next = 1, next = ( _data = (( t1 = ( _data = 0x4062a0 , _vptr =
0x406140 <__test_module_MOD___vtab_test_module_T1> ) )), _vptr = 0x4061a0
<__test_module_MOD___vtab_test_module_T1_pointer> ) )

But in the compiled program, it seems to finalize X2%T1.

[Bug target/111246] PPC64 Sequentially Consistent Load allows Reordering of Stores

[luke.geeson at cs dot ucl.ac.uk via Gcc-bugs]

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

--- Comment #11 from Luke Geeson  ---
I'm using

`powerpc64le-linux-gnu-objdump -Dr --disassemble --section=.text
--no-show-raw-insn`. 

installed using `binutils-powerpc64le-linux-gnu` under Ubuntu 20:04 (in a
docker container running on an Arm AArch64 machine). I realise I should be
testing using trunk binutils, but I provide the objdump info regardless:
```
$ powerpc64le-linux-gnu-objdump --version
GNU objdump (GNU Binutils for Ubuntu) 2.34
Copyright (C) 2020 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) any later version.
This program has absolutely no warranty.
```
Do you have a trunk build of binutils to hand to test? Godbolt doesn't support
objdump. I will try to install binutils from source to reproduce.

I have a custom tool that parses that and turns the disassembly into the below
(The custom tool is correct as far as I can see.

[Bug target/111246] PPC64 Sequentially Consistent Load allows Reordering of Stores

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

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

--- Comment #12 from Andrew Pinski  ---
(In reply to Luke Geeson from comment #11)
> Do you have a trunk build of binutils to hand to test? Godbolt doesn't
> support objdump. I will try to install binutils from source to reproduce.

Yes it does.
Use the option "Compile to binary object" under the output option.

This is what I see with that option:
 lwz r9,0(r9)
 cmpwr9,r9
 bne 44 
 isync
 lis r10,0

[Bug target/111246] PPC64 Sequentially Consistent Load allows Reordering of Stores

[luke.geeson at cs dot ucl.ac.uk via Gcc-bugs]

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

--- Comment #13 from Luke Geeson  ---
Please bear with me whilst I figure out what has happened here.

[Bug tree-optimization/108397] Missed optimization with [0, 0][-1U,-1U] range arithmetics

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

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

--- Comment #7 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #6)
> Forwprop will not change _4 to _1 though. because t1_11 is used twice.

But combined with PR 107137, we are able to optimize it just fine.

[Bug target/111246] PPC64 Sequentially Consistent Load allows Reordering of Stores

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

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

--- Comment #14 from David Edelsohn  ---
The conditional branch always will proceed to the next instruction, so the code
that you showed in the PR is a correct "optimization" of the original code, but
the processor does execute the conditional branch in the original code.  Is the
simulator performing an optimization?  Something seems to have transformed the
code.

[Bug fortran/31059] bounds-check does not detect nonconforming assignment arrays

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

  Attachment #55821|0   |1
is obsolete||

--- Comment #10 from anlauf at gcc dot gnu.org ---
Created attachment 55828
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55828&action=edit
Improved patch

This one also handles arbitrary order of array section and constructor.

[Bug c++/111261] New: No warning for out of order class initialisation when using class initialisers

[matt at godbolt dot org via Gcc-bugs]

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

Bug ID: 111261
   Summary: No warning for out of order class initialisation when
using class initialisers
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: matt at godbolt dot org
  Target Milestone: ---

The code:

```
struct S {
  std::size_t len{s.size()};
  std::string s{"A rather long string"};
};

```

warns on clang, but not on GCC. https://compiler-explorer.com/z/5qf3WbdY7

The equivalent code using a constructor _does_ warn on both compilers:

```
struct S {
  std::size_t len;
  std::string s;

  S() : s{"A rather long string"}, len{s.size()} {}
};
```

( https://compiler-explorer.com/z/Wov4Tx93v )

[Bug c++/110997] [13/14 Regression] internal compiler error: in cxx_eval_constant_expression, at cp/constexpr.cc:8005

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

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

Marek Polacek  changed:

   What|Removed |Added

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

[Bug fortran/31059] bounds-check does not detect nonconforming assignment arrays

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #11 from anlauf at gcc dot gnu.org ---
Submitted: https://gcc.gnu.org/pipermail/fortran/2023-August/059722.html

[Bug c++/111262] New: error: count of bb not initialized with -O3

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 111262
   Summary: error: count of bb not initialized with -O3
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Created attachment 55829
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55829&action=edit
gzipped C++ source code

For the attached C++ code, with recent gcc trunk and compiler
flag -O3, does this:

foundBugs $ /home/dcb38/gcc/results.20230824.asan.ubsan/bin/gcc -c -w -O3
bug953.cc
foundBugs $ /home/dcb38/gcc/results.20230825.asan.ubsan/bin/gcc -c -w -O3
bug953.cc
In file included from testing/regtest.cc:31:
testing/cmp.h: In static member function ‘static xoff_t
Regtest::CmpDifferentBytes(const FileSpec&, const FileSpec&) [with
Constants = SmallBlock]’:
testing/cmp.h:19:15: error: count of bb 188 not initialized
testing/cmp.h:19:15: error: count of bb 189 not initialized
testing/cmp.h:19:15: error: count of bb 190 not initialized
testing/cmp.h:19:15: error: count of bb 191 not initialized
testing/cmp.h:19:15: error: count of bb 193 not initialized
during GIMPLE pass: vect
testing/cmp.h:19:15: internal compiler error: verify_flow_info failed
0xbb35fa verify_flow_info()
../../trunk.year/gcc/cfghooks.cc:287
0x11a6aaf checking_verify_flow_info()
../../trunk.year/gcc/cfghooks.h:214
0x11a6aaf cleanup_tree_cfg_noloop(unsigned int)
../../trunk.year/gcc/tree-cfgcleanup.cc:1154

The bug first seems to start sometime between g:7e05cd632fab4587
and g:449ab115dece8ac8

[Bug target/111246] PPC64 Sequentially Consistent Load allows Reordering of Stores

[luke.geeson at cs dot ucl.ac.uk via Gcc-bugs]

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

--- Comment #15 from Luke Geeson  ---
I am sorry to you all - I have wasted your time. It was a bug in the
translation tool. 

In the future I will make absolutely sure that I check everything before
submitting a bug - this is an embarrassing mistake.

[Bug target/111246] PPC64 Sequentially Consistent Load allows Reordering of Stores

[luke.geeson at cs dot ucl.ac.uk via Gcc-bugs]

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

Luke Geeson  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|NEW |RESOLVED

--- Comment #16 from Luke Geeson  ---
closing as invalid

[Bug target/111246] PPC64 Sequentially Consistent Load allows Reordering of Stores

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

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

--- Comment #17 from David Edelsohn  ---
I'm glad that we have confirmed that the GCC and LLVM code generation for
PowerPC are correct for the memory model. And now your translation tool is more
accurate.

[Bug target/111246] PPC64 Sequentially Consistent Load allows Reordering of Stores

[luke.geeson at cs dot ucl.ac.uk via Gcc-bugs]

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

--- Comment #18 from Luke Geeson  ---
Indeed that is a plus - I have 167k concurrency tests that I feed through
LLVM/GCC -O1/2/3/fast and for GCC -Og that test compilation from the C/C++ to
PPC memory models. If you are interested I can provide them publicly (although
I understand given the above that you may like to wait until I have ensured
there are no more issues).

[Bug tree-optimization/111262] error: count of bb not initialized with -O3

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #1 from David Binderman  ---
Reduced C++ code is

struct _Rb_tree_header {
  int _M_node_count;
};
struct _Rb_tree {
  _Rb_tree_header _M_impl;
  bool empty() { return _M_impl._M_node_count; }
};
struct Trans_NS_std_map {
  _Rb_tree _M_t;
  int empty() { return _M_t.empty(); }
};
struct SmallBlock {
  static long BLOCK_SIZE;
};
long BytesOnBlock_blocks, CmpDifferentBytes_total;
int TestFirstByte_rand;
struct Regtest {
  struct FileSpec {
FileSpec(int *);
int Blocks_blksize;
long Blocks() {
  if (table_.empty())
return 0;
  return Blocks_blksize;
}
Trans_NS_std_map table_;
  };
  struct BlockIterator {
BlockIterator(FileSpec spec)
: spec_(spec), blksize_(SmallBlock::BLOCK_SIZE) {}
bool Done() { return blkno_ >= spec_.Blocks(); }
void Next() { blkno_++; }
int BytesOnBlock() {
  if (blkno_ == BytesOnBlock_blocks)
return 1;
  return blksize_;
}
FileSpec spec_;
unsigned long blkno_;
int blksize_;
  };
  void CmpDifferentBlockBytes();
  void CmpDifferentBytes(FileSpec a) {
BlockIterator a_i(a);
CmpDifferentBlockBytes();
for (; !a_i.Done(); a_i.Next())
  CmpDifferentBytes_total += a_i.BytesOnBlock();
  }
  void TestFirstByte() {
FileSpec spec0(&TestFirstByte_rand);
CmpDifferentBytes(spec0);
  }
};
main() {
  Regtest regtest;
  regtest.TestFirstByte();
}

[Bug other/111263] New: test case gfortran.dg/ieee/comparisons_3.F90 fails

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

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

Bug ID: 111263
   Summary: test case gfortran.dg/ieee/comparisons_3.F90 fails
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

make  -k check-fortran RUNTESTFLAGS="--target_board=unix'{-m32,m64}'
ieee.exp=gfortran.dg/ieee/comparisons_3.F90"
FAIL: gfortran.dg/ieee/comparisons_3.F90   -O0  execution test
FAIL: gfortran.dg/ieee/comparisons_3.F90   -O1  execution test
FAIL: gfortran.dg/ieee/comparisons_3.F90   -O2  execution test
FAIL: gfortran.dg/ieee/comparisons_3.F90   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  execution test
FAIL: gfortran.dg/ieee/comparisons_3.F90   -O3 -g  execution test
FAIL: gfortran.dg/ieee/comparisons_3.F90   -Os  execution test

I can't definitely trace it to a specific commit because of build errors but I
believe it has failed since its introduction here:

commit dca2874897ec58ea1c22a9c2161f112fff07cfb2 (HEAD)
Author: Francois-Xavier Coudert 
Date:   Fri Sep 2 13:27:38 2022 +0200

Fortran: add IEEE_QUIET_* and IEEE_SIGNALING_* comparisons

* gfortran.dg/ieee/comparisons_3.F90: New test.

The failure is at line 46:

spawn [open ...]
 Check failed at   46
STOP 1
FAIL: gfortran.dg/ieee/comparisons_3.F90   -Os  execution test


  if (ieee_signaling_eq (0., rnan)) stop 13
  CHECK_INVALID(.true.)

[Bug target/111263] test case gfortran.dg/ieee/comparisons_3.F90 fails

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||wrong-code
  Component|other   |target

--- Comment #1 from Andrew Pinski  ---
This is a target specific issue, making sure ieee_signaling_eq gives the
correct result.

Is gcc.dg/torture/builtin-iseqsig-* also failing?

[Bug c++/92407] Destruction of objects returned from functions skipped by goto

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

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

--- Comment #10 from CVS Commits  ---
The releases/gcc-13 branch has been updated by Jason Merrill
:

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

commit r13-7770-ga645347c19b07cc7abd7bf276c6769fc41afc932
Author: Jason Merrill 
Date:   Sun Jun 4 12:00:55 2023 -0400

c++: NRV and goto [PR92407]

Here our named return value optimization was breaking the required
destructor when the goto takes 'a' out of scope.  A simple fix for the
release branches is to disable the optimization in the presence of backward
goto.

We could do better by disabling the optimization only if there is a
backward
goto across the variable declaration, but we don't track that, and in GCC
14
we instead make the goto work with NRV.

PR c++/92407

gcc/cp/ChangeLog:

* cp-tree.h (struct language_function): Add backward_goto.
* decl.cc (check_goto): Set it.
* typeck.cc (check_return_expr): Prevent NRV if set.

gcc/testsuite/ChangeLog:

* g++.dg/opt/nrv22.C: New test.

[Bug c++/109751] [13/14 Regression] boost iterator_interface fails concept check starting in gcc-13

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

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

--- Comment #25 from CVS Commits  ---
The releases/gcc-13 branch has been updated by Jason Merrill
:

https://gcc.gnu.org/g:6396e37d451b2ef6d3cb9c11edbc06deeaccd808

commit r13-7771-g6396e37d451b2ef6d3cb9c11edbc06deeaccd808
Author: Jason Merrill 
Date:   Thu Aug 17 11:36:23 2023 -0400

Revert "c++: only declare satisfied friends" [PR109751]

The earlier patch was only an incremental step toward making this sort of
code work, and broke code that had been working.  So let's revert it.

This reverts commit r13-4035-gc41bbfcaf9d6ef.

PR c++/109751

gcc/cp/ChangeLog:

* pt.cc (tsubst_friend_function): Don't check constraints.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/concepts-friend11.C: Xfail.
* g++.dg/cpp2a/concepts-friend15.C: New test.

[Bug c++/109751] [13/14 Regression] boost iterator_interface fails concept check starting in gcc-13

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

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #26 from Jason Merrill  ---
Fixed for 13.3/14.

[Bug c++/66487] sanitizer/warnings for lifetime DSE

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

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

Eric Gallager  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=66163
 CC||egallager at gcc dot gnu.org

--- Comment #25 from Eric Gallager  ---
this came up on the gcc-help mailing list here:
https://gcc.gnu.org/pipermail/gcc-help/2023-August/142848.html

[Bug other/111264] New: [14 regression] gcc.dg/plugin/analyzer_cpython_plugin.c breaks after r14-3580-g597b9ec69bca8a

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

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

Bug ID: 111264
   Summary: [14 regression]
gcc.dg/plugin/analyzer_cpython_plugin.c breaks after
r14-3580-g597b9ec69bca8a
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:597b9ec69bca8acb7a3d65641c0a730de8b27ed4, r14-3580-g597b9ec69bca8a
make  -k check-gcc
RUNTESTFLAGS="plugin.exp=gcc.dg/plugin/analyzer_cpython_plugin.c"
FAIL: gcc.dg/plugin/analyzer_cpython_plugin.c compilation
# of unexpected failures1

commit 597b9ec69bca8acb7a3d65641c0a730de8b27ed4 (HEAD)
Author: Eric Feng 
Date:   Wed Aug 30 17:52:24 2023 -0400

analyzer: implement reference count checking for CPython plugin [PR107646]



Executing on build: g++ -g
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/plugin/analyzer_cpython_plugin.c
-I. -I/home/seurer/gcc/git/gcc-test/gcc/testsuite
-I/home/seurer/gcc/git/gcc-test/gcc/testsuite/../../gcc
-I/home/seurer/gcc/git/build/gcc-test/gcc/testsuite/gcc/../../../gcc 
-I/home/seurer/gcc/git/gcc-test/gcc/testsuite/../../include
-I/home/seurer/gcc/git/gcc-test/gcc/testsuite/../../libcpp/include 
-I/home/seurer/gcc/git/build/gcc-test/./gmp -I/home/seurer/gcc/git/gcc-test/gmp
-I/home/seurer/gcc/git/build/gcc-test/./mpfr/src
-I/home/seurer/gcc/git/gcc-test/mpfr/src
-I/home/seurer/gcc/git/gcc-test/mpc/src 
-I/home/seurer/gcc/git/build/gcc-test/gcc/testsuite/gcc/../../../intl -g
-DIN_GCC -fPIC -shared -fno-rtti -o analyzer_cpython_plugin.so(timeout =
300)
spawn -ignore SIGHUP g++ -g
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/plugin/analyzer_cpython_plugin.c
-I. -I/home/seurer/gcc/git/gcc-test/gcc/testsuite
-I/home/seurer/gcc/git/gcc-test/gcc/testsuite/../../gcc
-I/home/seurer/gcc/git/build/gcc-test/gcc/testsuite/gcc/../../../gcc
-I/home/seurer/gcc/git/gcc-test/gcc/testsuite/../../include
-I/home/seurer/gcc/git/gcc-test/gcc/testsuite/../../libcpp/include
-I/home/seurer/gcc/git/build/gcc-test/./gmp -I/home/seurer/gcc/git/gcc-test/gmp
-I/home/seurer/gcc/git/build/gcc-test/./mpfr/src
-I/home/seurer/gcc/git/gcc-test/mpfr/src
-I/home/seurer/gcc/git/gcc-test/mpc/src
-I/home/seurer/gcc/git/build/gcc-test/gcc/testsuite/gcc/../../../intl -g
-DIN_GCC -fPIC -shared -fno-rtti -o analyzer_cpython_plugin.so
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/plugin/analyzer_cpython_plugin.c:
In function 'void ana::pyobj_refcnt_checker(const ana::region_model*, const
ana::region_model*, const ana::svalue*, ana::region_model_context*)':
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/plugin/analyzer_cpython_plugin.c:480:58:
error: no matching function for call to 'hash_map::hash_map(hash_map)'
   auto region_to_refcnt = hash_map ();
  ^
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/plugin/analyzer_cpython_plugin.c:
In member function 'virtual void
ana::kf_analyzer_cpython_dump_refcounts::impl_call_pre(const
ana::call_details&) const':
/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/plugin/analyzer_cpython_plugin.c:564:60:
error: no matching function for call to 'hash_map::hash_map(hash_map)'
 auto region_to_refcnt = hash_map ();
^

[Bug c++/110936] if constexpr: member function pointers cannot be checked with ubsan

[johelegp at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Johel Ernesto Guerrero Peña  ---
This should block BUG101603.

[Bug target/110484] Spec2017 541 after adding the '-flto-fomit-frame-pointer' optimization, after optimizing the rnreg, directly replaced other registers with the $r22 register, so that the value of t

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

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

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

https://gcc.gnu.org/g:1967f21d000e09d3d3190317af7923b578ce02b1

commit r14-3605-g1967f21d000e09d3d3190317af7923b578ce02b1
Author: Lulu Cheng 
Date:   Thu Jun 29 19:30:59 2023 +0800

LoongArch: Fix bug in loongarch_emit_stack_tie [PR110484].

Which may result in implicit references to $fp when frame_pointer_needed is
false,
causing regs_ever_live[$fp] to be true when $fp is not explicitly used,
resulting in $fp being used as the target replacement register in the rnreg
pass.

The bug originates from SPEC2017 541.leela_r(-flto).

gcc/ChangeLog:

PR target/110484
* config/loongarch/loongarch.cc (loongarch_emit_stack_tie): Use the
frame_pointer_needed to determine whether to use the $fp register.

Co-authored-by: Guo Jie 

[Bug other/111264] [14 regression] gcc.dg/plugin/analyzer_cpython_plugin.c breaks after r14-3580-g597b9ec69bca8a

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

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

Hans-Peter Nilsson  changed:

   What|Removed |Added

 CC||hp at gcc dot gnu.org

--- Comment #1 from Hans-Peter Nilsson  ---
Also seen for cris-elf and m68k-linux
(https://gcc.gnu.org/pipermail/gcc-testresults/2023-August/794806.html).

Some experimentation says that this is a mismatch between the default C++
version for the host/installed gcc (for me, C++11, I think) and the target
(C++17, right?).  If you add "-std=c++17" to the invocation line in gcc.log,
compilation succeeds.  Or, change the form of the newly introduced declarations
from
 auto foobar = foo();
to
 foo foobar;
Not sure why the former is used, it seems negate the benefits of auto and just
be more typing.  Beware: since I know Very Little C++ of the last decades, I
could be completely wrong.

[Bug target/110484] Spec2017 541 after adding the '-flto-fomit-frame-pointer' optimization, after optimizing the rnreg, directly replaced other registers with the $r22 register, so that the value of t

[chenglulu at loongson dot cn via Gcc-bugs]

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

chenglulu  changed:

   What|Removed |Added

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

--- Comment #4 from chenglulu  ---
resolved

[Bug c++/110936] if constexpr: member function pointers cannot be checked with ubsan

[johelegp at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Johel Ernesto Guerrero Peña  ---
FWIW, it seems that you can use

to test the validity during constant evaluation.
It seems that an invalid constant expression implies a `false` result.
So I guard the check with a validity check:
.

```C++
#include 
template concept is_constant = requires { typename
std::integral_constant; };
template
constexpr bool implements() {
  using R = decltype(r);
  if constexpr (requires { static_cast(l); })
#if !defined(__GNUC__) || defined(__clang__)
return static_cast(l) != r;
#else // Workaround .
return !is_constant<[]() { return static_cast(l) != r; }> ||
static_cast(l) != r;
#endif
  return false;
}
struct B { void f(); };
struct D0 : B { };
struct D1 : B { void f(); };
struct D2 : B { void f() const; };
// struct D3 : B { int f(); void f() const; };
static_assert(!implements<&D0::f, &B::f>());
static_assert(implements<&D1::f, &B::f>());
static_assert(!implements<&D2::f, &B::f>());
// static_assert(!implements<&D3::f, &B::f>());
```

[Bug tree-optimization/107765] missing (int)-(unsigned)int_val to just -int_val if int_val is known not to contain INT_MIN

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

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

Andrew Pinski  changed:

   What|Removed |Added

URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2023-Septemb
   ||er/629018.html
   Keywords||patch

--- Comment #2 from Andrew Pinski  ---
Patch posted:
https://gcc.gnu.org/pipermail/gcc-patches/2023-September/629018.html

[Bug tree-optimization/107137] (unsigned)-(int)(bool_var) should be optimized to -(unsigned)bool_var

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||patch
URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2023-Septemb
   ||er/629018.html

--- Comment #3 from Andrew Pinski  ---
Patch posted:
https://gcc.gnu.org/pipermail/gcc-patches/2023-September/629018.html

[Bug target/110484] Spec2017 541 after adding the '-flto-fomit-frame-pointer' optimization, after optimizing the rnreg, directly replaced other registers with the $r22 register, so that the value of t

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

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

--- Comment #5 from CVS Commits  ---
The releases/gcc-13 branch has been updated by LuluCheng
:

https://gcc.gnu.org/g:3f23fa7e74fa01828d649e8ee7230701b6fb1e19

commit r13-7773-g3f23fa7e74fa01828d649e8ee7230701b6fb1e19
Author: Lulu Cheng 
Date:   Thu Jun 29 19:30:59 2023 +0800

LoongArch: Fix bug in loongarch_emit_stack_tie [PR110484].

Which may result in implicit references to $fp when frame_pointer_needed is
false,
causing regs_ever_live[$fp] to be true when $fp is not explicitly used,
resulting in $fp being used as the target replacement register in the rnreg
pass.

The bug originates from SPEC2017 541.leela_r(-flto).

gcc/ChangeLog:

PR target/110484
* config/loongarch/loongarch.cc (loongarch_emit_stack_tie): Use the
frame_pointer_needed to determine whether to use the $fp register.

Co-authored-by: Guo Jie 

(cherry picked from commit 1967f21d000e09d3d3190317af7923b578ce02b1)

[Bug other/111264] [14 regression] gcc.dg/plugin/analyzer_cpython_plugin.c breaks after r14-3580-g597b9ec69bca8a

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

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

Hans-Peter Nilsson  changed:

   What|Removed |Added

URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2023-Septemb
   ||er/629019.html

--- Comment #2 from Hans-Peter Nilsson  ---
Patch posted:
https://gcc.gnu.org/pipermail/gcc-patches/2023-September/629019.html

[Bug other/111264] [14 regression] gcc.dg/plugin/analyzer_cpython_plugin.c breaks after r14-3580-g597b9ec69bca8a

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-09-01

--- Comment #3 from Andrew Pinski  ---
(In reply to Hans-Peter Nilsson from comment #1)
> Also seen for cris-elf and m68k-linux
> (https://gcc.gnu.org/pipermail/gcc-testresults/2023-August/794806.html).
> 
> Some experimentation says that this is a mismatch between the default C++
> version for the host/installed gcc (for me, C++11, I think) and the target
> (C++17, right?).  If you add "-std=c++17" to the invocation line in gcc.log,
> compilation succeeds.  Or, change the form of the newly introduced
> declarations from
>  auto foobar = foo();
> to
>  foo foobar;
> Not sure why the former is used, it seems negate the benefits of auto and
> just be more typing.  Beware: since I know Very Little C++ of the last
> decades, I could be completely wrong.

You are mostly correct.
In C++17, Copy elision is guaranteed to be done here while in earlier versions
it is not and earlier versions of C++ require a copy/move constructor even if
copy elision is to be done. See
https://en.cppreference.com/w/cpp/language/copy_elision for more information.

[Bug tree-optimization/111262] [14 Regression] error: count of bb not initialized with -O3

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |14.0
Version|unknown |14.0
Summary|error: count of bb not  |[14 Regression] error:
   |initialized with -O3|count of bb not initialized
   ||with -O3

[Bug tree-optimization/111262] [14 Regression] error: count of bb not initialized with -O3

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2023-09-01

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

;; Scaling loop 3 with scale uninitialized

is new though ...

[Bug target/110484] Spec2017 541 after adding the '-flto-fomit-frame-pointer' optimization, after optimizing the rnreg, directly replaced other registers with the $r22 register, so that the value of t

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

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

--- Comment #6 from CVS Commits  ---
The releases/gcc-12 branch has been updated by LuluCheng
:

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

commit r12-9840-gd60c00492eb5818493560f299f06d1e3d9efcc69
Author: Lulu Cheng 
Date:   Thu Jun 29 19:30:59 2023 +0800

LoongArch: Fix bug in loongarch_emit_stack_tie [PR110484].

Which may result in implicit references to $fp when frame_pointer_needed is
false,
causing regs_ever_live[$fp] to be true when $fp is not explicitly used,
resulting in $fp being used as the target replacement register in the rnreg
pass.

The bug originates from SPEC2017 541.leela_r(-flto).

gcc/ChangeLog:

PR target/110484
* config/loongarch/loongarch.cc (loongarch_emit_stack_tie): Use the
frame_pointer_needed to determine whether to use the $fp register.

Co-authored-by: Guo Jie 

(cherry picked from commit 1967f21d000e09d3d3190317af7923b578ce02b1)

[Bug target/111232] RISC-V: Failed to combine vwmul + vadd into vwmacc

[lehua.ding at rivai dot ai via Gcc-bugs]

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

--- Comment #1 from Lehua Ding  ---
reproduce on compiler explorer: https://godbolt.org/z/Mq3bzajn6

[Bug libstdc++/111258] std::string cannot to be moved in constant evaluated expression

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||rejects-valid

--- Comment #1 from Andrew Pinski  ---
Note clang rejects (libstdc++ version) for a different reason:
```
:12:20: error: static assertion expression is not an integral constant
expression
   12 | static_assert( foo("hello"s) == 'e' );
  |^~~~
/opt/compiler-explorer/gcc-snapshot/lib/gcc/x86_64-linux-gnu/14.0.0/../../../../include/c++/14.0.0/bits/basic_string.h:626:2:
note: undefined function '_M_construct' cannot be used in a
constant expression
  626 | _M_construct(__s, __s + __n, std::forward_iterator_tag());
  | ^
/opt/compiler-explorer/gcc-snapshot/lib/gcc/x86_64-linux-gnu/14.0.0/../../../../include/c++/14.0.0/bits/basic_string.h:4686:14:
note: in call to 'basic_string(&"hello"[0], 5, std::allocator())'
 4686 | { return basic_string{__str, __len}; }
  |  ^~~~
:12:24: note: in call to 'operator""s(&"hello"[0], 5)'
   12 | static_assert( foo("hello"s) == 'e' );
  |^~~~
/opt/compiler-explorer/gcc-snapshot/lib/gcc/x86_64-linux-gnu/14.0.0/../../../../include/c++/14.0.0/bits/basic_string.h:336:9:
note: declared here
  336 | _M_construct(_FwdIterator __beg, _FwdIterator __end,
  | ^
```

clang accepts LLVM's libc++ version though.

[Bug tree-optimization/19832] don't remove an if when we know the value is the same as with the if (subtraction)

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

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

--- Comment #11 from CVS Commits  ---
The trunk branch has been updated by Andrew Pinski :

https://gcc.gnu.org/g:3d86e7f4a8aef1b864a51660825597eafe9059b1

commit r14-3606-g3d86e7f4a8aef1b864a51660825597eafe9059b1
Author: Andrew Pinski 
Date:   Wed Aug 30 21:21:01 2023 -0700

MATCH [PR19832]: Optimize some `(a != b) ? a OP b : c`

This patch adds the following match patterns to optimize these:
 /* (a != b) ? (a - b) : 0 -> (a - b) */
 /* (a != b) ? (a ^ b) : 0 -> (a ^ b) */
 /* (a != b) ? (a & b) : a -> (a & b) */
 /* (a != b) ? (a | b) : a -> (a | b) */
 /* (a != b) ? min(a,b) : a -> min(a,b) */
 /* (a != b) ? max(a,b) : a -> max(a,b) */
 /* (a != b) ? (a * b) : (a * a) -> (a * b) */
 /* (a != b) ? (a + b) : (a + a) -> (a + b) */
 /* (a != b) ? (a + b) : (2 * a) -> (a + b) */
Note currently only integer types (include vector types)
are handled. Floating point types can be added later on.

OK? Bootstrapped and tested on x86_64-linux-gnu.

The first pattern had still shows up in GCC in cse.c's preferable
function which was the original motivation for this patch.

PR tree-optimization/19832

gcc/ChangeLog:

* match.pd: Add pattern to optimize
`(a != b) ? a OP b : c`.

gcc/testsuite/ChangeLog:

* g++.dg/opt/vectcond-1.C: New test.
* gcc.dg/tree-ssa/phi-opt-same-1.c: New test.

[Bug tree-optimization/19832] don't remove an if when we know the value is the same as with the if (subtraction)

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #12 from Andrew Pinski  ---
Fixed.