[Bug target/112773] New: [14 Regression] RISC-V ICE: in force_align_down_and_div, at poly-int.h:1828 on rv32gcv_zvl256b

[patrick at rivosinc dot com via Gcc-bugs]

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

Bug ID: 112773
   Summary: [14 Regression] RISC-V ICE: in
force_align_down_and_div, at poly-int.h:1828 on
rv32gcv_zvl256b
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: patrick at rivosinc dot com
  Target Milestone: ---

Created attachment 56724
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56724=edit
-freport-bug output

during RTL pass: expand
red.c: In function 'e':
red.c:4:6: internal compiler error: in force_align_down_and_div, at
poly-int.h:1828
4 | void e(unsigned f) {
  |  ^
0x9b006c poly_int<2u, unsigned long> force_align_down_and_div<2u, unsigned
long, int>(poly_int<2u, unsigned long> const&, int)
../../../gcc/gcc/poly-int.h:1828
0x9b006c poly_int<2u, unsigned long> force_align_down_and_div<2u, unsigned
long, int>(poly_int<2u, unsigned long> const&, int)
../../../gcc/gcc/poly-int.h:1826
0x9b006c extract_bit_field_1
../../../gcc/gcc/expmed.cc:1861
0xe42532 extract_bit_field(rtx_def*, poly_int<2u, unsigned long>, poly_int<2u,
unsigned long>, int, rtx_def*, machine_mode, machine_mode, bool, rtx_def**)
../../../gcc/gcc/expmed.cc:2149
0xe607a9 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../../gcc/gcc/expr.cc:11804
0xe6dddf expand_expr_real(tree_node*, rtx_def*, machine_mode, expand_modifier,
rtx_def**, bool)
../../../gcc/gcc/expr.cc:9046
0xe6dddf expand_expr(tree_node*, rtx_def*, machine_mode, expand_modifier)
../../../gcc/gcc/expr.h:310
0xe6dddf store_expr(tree_node*, rtx_def*, int, bool, bool)
../../../gcc/gcc/expr.cc:6232
0xe6e679 expand_assignment(tree_node*, tree_node*, bool)
../../../gcc/gcc/expr.cc:6070
0xd29577 expand_gimple_stmt_1
../../../gcc/gcc/cfgexpand.cc:3947
0xd29577 expand_gimple_stmt
../../../gcc/gcc/cfgexpand.cc:4045
0xd2e6c0 expand_gimple_basic_block
../../../gcc/gcc/cfgexpand.cc:6101
0xd30656 execute
../../../gcc/gcc/cfgexpand.cc:6836
Please submit a full bug report, with preprocessed source.
Please include the complete backtrace with any bug report.
See  for instructions.
Preprocessed source stored into /scratch/tmp/ccSDQZzq.out file, please attach
this to your bugreport.


Reduced testcase:
long long a;
int b, c;
int *d;
void e(unsigned f) {
  for (;; ++c)
if (f) {
  a = 0;
  for (; a <= 3; a++) {
f = 0;
for (; f <= 0; f++)
  if ((long)a)
break;
  }
  if (b)
*d = f;
}
}

[Bug target/112431] RISC-V GCC-15 feature: Support register overlap on widen RVV instructions

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

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

--- Comment #6 from GCC Commits  ---
The trunk branch has been updated by Lehua Ding :

https://gcc.gnu.org/g:8614cbb253484e28c3eb20cde4d1067aad56de58

commit r14-5984-g8614cbb253484e28c3eb20cde4d1067aad56de58
Author: Juzhe-Zhong 
Date:   Thu Nov 30 10:36:30 2023 +0800

RISC-V: Support highpart overlap for floating-point widen instructions

This patch leverages the approach of vwcvt/vext.vf2 which has been
approved.
Their approaches are totally the same.

Tested no regression and committed.

PR target/112431

gcc/ChangeLog:

* config/riscv/vector.md: Add widenning overlap.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/base/pr112431-10.c: New test.
* gcc.target/riscv/rvv/base/pr112431-11.c: New test.
* gcc.target/riscv/rvv/base/pr112431-12.c: New test.
* gcc.target/riscv/rvv/base/pr112431-13.c: New test.
* gcc.target/riscv/rvv/base/pr112431-14.c: New test.
* gcc.target/riscv/rvv/base/pr112431-15.c: New test.
* gcc.target/riscv/rvv/base/pr112431-7.c: New test.
* gcc.target/riscv/rvv/base/pr112431-8.c: New test.
* gcc.target/riscv/rvv/base/pr112431-9.c: New test.

[Bug target/112411] ICE: SIGSEGV with --param=min-nondebug-insn-uid=2147483647 on powerpc64le-unknown-linux-gnu

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

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

--- Comment #4 from Alexandre Oliva  ---
yeah, its intended use case is for debugging -fcompare-debug fails, reducing
superfluous differences between rtl dumps.

In theory GCC may overflow insn uids regardless of this param, and if guarding
against that is important, there should be code to check for it when
incrementing insn uids, but I suppose we can live without that.

Such limit values are definitely not useful for fuzz testing, but I'd be
curious whether values that do not cause overflows would cause any codegen
differences.  I think not, and it really shouldn't, but this thought makes me
hesitant to recommend against using this option for fuzz testing.

[Bug target/109253] libbpf: failed to find BTF info for global/extern symbol '__divdi3'

[shung-hsi.yu at suse dot com via Gcc-bugs]

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

--- Comment #7 from Shung-Hsi Yu  ---
(In reply to Jose E. Marchesi from comment #6)
> Yes.  We plan to backport this and many other BPF related fixes and
> improvements to GCC 10, 11, 12 and 13, once the port is capable of building
> all the kernel BPF selftests.  We are almost there.

That's awesome! Thank you and others so much for this.

[Bug target/112431] RISC-V GCC-15 feature: Support register overlap on widen RVV instructions

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

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

--- Comment #5 from GCC Commits  ---
The master branch has been updated by Pan Li :

https://gcc.gnu.org/g:62685890d8861b72f812bfe171a20332df08bd49

commit r14-5982-g62685890d8861b72f812bfe171a20332df08bd49
Author: Juzhe-Zhong 
Date:   Wed Nov 29 18:53:06 2023 +0800

RISC-V: Support highpart overlap for vext.vf

PR target/112431

gcc/ChangeLog:

* config/riscv/vector.md: Support highpart overlap for vext.vf2

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/base/unop_v_constraint-2.c: Adapt test.
* gcc.target/riscv/rvv/base/pr112431-4.c: New test.
* gcc.target/riscv/rvv/base/pr112431-5.c: New test.
* gcc.target/riscv/rvv/base/pr112431-6.c: New test.

[Bug target/112740] [14 Regression] wrong code with vector compare on riscv64 at -O0

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

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

--- Comment #2 from Andrew Pinski  ---
Does this work post:
https://gcc.gnu.org/pipermail/gcc-cvs/2023-November/394162.html

?

If so I will commit a testcase.

[Bug tree-optimization/112734] [14 regression] ICE verify_gimple failed since r14-3751-g8c984a1c3693df - BitInt

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

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

Sam James  changed:

   What|Removed |Added

 CC||sjames at gcc dot gnu.org
   Target Milestone|--- |14.0
Summary|ICE verify_gimple failed|[14 regression] ICE
   |since   |verify_gimple failed since
   |r14-3751-g8c984a1c3693df -  |r14-3751-g8c984a1c3693df -
   |BitInt  |BitInt

[Bug ipa/111922] [11/12/13/14 Regression] ICE in cp with -O2 -fno-tree-fre

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

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

Sam James  changed:

   What|Removed |Added

 CC||sjames at gcc dot gnu.org

--- Comment #12 from Sam James  ---
Is the plan to backport to 11/12/13 or to leave it?

[Bug c++/98940] Implement C++23 language features

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

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

Bug 106650 Summary: [C++23] P2280 - Using unknown references in constant 
expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106650

   What|Removed |Added

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

[Bug c++/106650] [C++23] P2280 - Using unknown references in constant expressions

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #5 from Marek Polacek  ---
Implemented in GCC 14.

[Bug driver/112759] [13/14 regression] mips -march=native detection broken with gcc 13+

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|[13 regression] mips|[13/14 regression] mips
   |-march=native detection |-march=native detection
   |broken with gcc 13+ |broken with gcc 13+

--- Comment #2 from Andrew Pinski  ---
Hmm, looks like it is this part of the change:
+  if (cpu)
+ret = reconcat (ret, ret, "-m", argv[0], "=", cpu, NULL);

-  return concat ("-m", argv[0], "=", cpu, NULL);


Maybe it should have been:
```
if (cpu)
  {
if (!ret)
  ret = concat ("-m", argv[0], "=", cpu, NULL);
else
  ret = reconcat (ret, ret, "-m", argv[0], "=", cpu, NULL);
  }
```

Can you try that?

[Bug c++/106650] [C++23] P2280 - Using unknown references in constant expressions

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

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

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

https://gcc.gnu.org/g:99d114c15523e0bfe7a89ef1947f82eb5ff0260b

commit r14-5979-g99d114c15523e0bfe7a89ef1947f82eb5ff0260b
Author: Marek Polacek 
Date:   Fri Nov 17 14:48:44 2023 -0500

c++: P2280R4, Using unknown refs in constant expr [PR106650]

This patch is an attempt to implement (part of?) P2280, Using unknown
pointers and references in constant expressions.  (Note that R4 seems to
only allow References to unknown/Accesses via this, but not Pointers to
unknown.)

This patch works to the extent that the test case added in [expr.const]
works as expected, as well as the test in
   


Most importantly, the proposal makes this compile:

  template 
  constexpr auto array_size(T (&)[N]) -> size_t {
  return N;
  }

  void check(int const ()[3]) {
  constexpr auto s = array_size(param);
  static_assert (s == 3);
  }

and I think it would be a pity not to have it in GCC 14.

What still doesn't work is the test in $3.2:

  struct A2 { constexpr int f() { return 0; } };
  struct B2 : virtual A2 {};
  void f2(B2 ) { constexpr int k = b.f(); }

where we say
error: '* & b' is not a constant expression

This will be fixed in the future.

PR c++/106650

gcc/cp/ChangeLog:

* constexpr.cc (cxx_eval_constant_expression) :
Allow
reference to unknown/this as per P2280.
: Allow reference to unknown as per P2280.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/constexpr-array-ptr6.C: Remove dg-error.
* g++.dg/cpp0x/constexpr-ref12.C: Likewise.
* g++.dg/cpp0x/constexpr-ref2.C: Adjust dg-error.
* g++.dg/cpp0x/noexcept34.C: Remove dg-error.
* g++.dg/cpp1y/lambda-generic-const10.C: Likewise.
* g++.dg/cpp0x/constexpr-ref13.C: New test.
* g++.dg/cpp1z/constexpr-ref1.C: New test.
* g++.dg/cpp1z/constexpr-ref2.C: New test.
* g++.dg/cpp2a/constexpr-ref1.C: New test.

[Bug tree-optimization/112767] [14 regression] spurious -Waggressive-loop-optimizations

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

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

Patrick Palka  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org

--- Comment #2 from Patrick Palka  ---
Started with r14-2944-g3d48c11ad082de

[Bug c++/112765] [14 regression] -Wparentheses warning even when extra parens are present

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

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #4 from Patrick Palka  ---
Should be fixed, thanks for the bug report.

[Bug c++/112765] [14 regression] -Wparentheses warning even when extra parens are present

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

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

--- Comment #3 from GCC Commits  ---
The master branch has been updated by Patrick Palka :

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

commit r14-5977-g0b242afffdddc251eca96b37c59802aa66197be7
Author: Patrick Palka 
Date:   Wed Nov 29 16:47:12 2023 -0500

c++: fix testcase [PR112765]

PR c++/112765

gcc/testsuite/ChangeLog:

* g++.dg/warn/Wparentheses-33.C: Compile with -Wparentheses.

[Bug target/96341] Support mixed element widths for AArch64 "omp declare simd" functions

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

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

--- Comment #2 from Andrew Pinski  ---
Does
https://inbox.sourceware.org/gcc-patches/mpta5qwk1dq@arm.com/T/#md361994bae652d68136f3075a557cad834798611
fix this?

[Bug c++/112765] [14 regression] -Wparentheses warning even when extra parens are present

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

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

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

https://gcc.gnu.org/g:220fe41fd4085e91a49e62dd815628ec4883a4ea

commit r14-5976-g220fe41fd4085e91a49e62dd815628ec4883a4ea
Author: Patrick Palka 
Date:   Wed Nov 29 16:42:39 2023 -0500

c++: bogus -Wparentheses warning [PR112765]

We need to consistently look through implicit INDIRECT_REF when
setting/checking for -Wparentheses warning suppression.  In passing
use the recently introduced STRIP_REFERENCE_REF helper some more.

PR c++/112765

gcc/cp/ChangeLog:

* pt.cc (tsubst_expr) : Look through implicit
INDIRECT_REF when propagating -Wparentheses warning suppression.
* semantics.cc (maybe_warn_unparenthesized_assignment): Replace
REFERENCE_REF_P handling with STRIP_REFERENCE_REF.
(finish_parenthesized_expr): Likewise.

gcc/testsuite/ChangeLog:

* g++.dg/warn/Wparentheses-33.C: New test.

[Bug fortran/112772] New: Some issues with OPTIONAL, ALLOCATABLE dummy arguments

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

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

Bug ID: 112772
   Summary: Some issues with OPTIONAL, ALLOCATABLE dummy arguments
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anlauf at gcc dot gnu.org
  Target Milestone: ---

While working on pr100651, the following issues surfaced (not discussed there):

program main
  call test_rank1 ()
contains
  subroutine test_rank1 (msg1)
class(*), optional, allocatable :: msg1(:)
if (present (msg1)) stop 77
call assert_rank1 ()! <- no problem here
call assert_rank1 (msg1)! <- problematic code path
  end

  subroutine assert_rank1 (msg2)
class(*), optional, allocatable :: msg2(:)
  end
end

This crashes at runtime.  The dump for the problematic code path is:

  {
struct __class__STAR_1_0a class.0;

if (msg1 != 0B)
  {
class.0._len = msg1->_len;
class.0._data = msg1->_data;
class.0._vptr = msg1->_vptr;
  }
assert_rank1 (msg1 != 0B ?  : 0B);
msg1->_data = class.0._data;
msg1->_vptr = class.0._vptr;
msg1->_len = class.0._len;
  }

We need to protect the copy-out for an absent optional argument.

Also, the testcase provided in

https://gcc.gnu.org/pipermail/fortran/2023-November/059969.html

which is similar to the above but uses deferred-length character
shows a questionable tree dump (excerpt):

void test_rank1 (struct array01_character(kind=1) * msg1, integer(kind=8) *
_msg1)
{
  integer(kind=8) D.4350;
  bitsizetype D.4351;
  sizetype D.4352;

  D.4350 = *_msg1;
  D.4351 = (bitsizetype) (sizetype) *_msg1 * 8;
  D.4352 = (sizetype) *_msg1;
  if (msg1 != 0B)
{
  _gfortran_stop_numeric (77, 0);
}
  L.2:;
  assert_rank1 (0B, &0);
  {
struct array01_character(kind=1) * D.4348;
integer(kind=8) * D.4349;

D.4348 = msg1 != 0B ? msg1 : 0B;
D.4349 = msg1 != 0B ? _msg1 : 0B;
assert_rank1 (D.4348, D.4349);
  }
}

This emits warning messages with -fsanitize=undefined, likely due to the
unconditional dereferencing of _msg1 at function entry.

[Bug fortran/112764] Associating entity does not have target attribute if selector has pointer attribute in associate block

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

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

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 #6 from anlauf at gcc dot gnu.org ---
Submitted: https://gcc.gnu.org/pipermail/fortran/2023-November/059974.html

[Bug fortran/112764] Associating entity does not have target attribute if selector has pointer attribute in associate block

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

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

--- Comment #5 from anlauf at gcc dot gnu.org ---
(In reply to martin from comment #4)
> (In reply to anlauf from comment #1)
> > Confirmed.
> > 
> > F2018:11.1.3.3 has:
> > 
> > "The associating entity does not have the ALLOCATABLE or POINTER attributes;
> > it has the TARGET attribute if and only if the selector is a variable and 
> > has
> > either the TARGET or POINTER attribute."
> 
> I was not sure, whether this formulation also covers array sections.

The following example has apparently always been legal, is accepted and works:

  integer, pointer :: x, y(:)
  integer, allocatable, target :: z(:)
  allocate (y(2), z(3))
  y = 42
  x => y(2)
  print *,x
  z = 23
  x => z(2)
  print *,x
end

I think this is covered by F2018:8.5.17 TARGET attribute, although I find
the text somewhat hard to understand.  Like:

"If an object has the TARGET attribute, then all of its nonpointer subobjects
also have the TARGET attribute."

IIUC that would cover array sections.

[Bug fortran/112764] Associating entity does not have target attribute if selector has pointer attribute in associate block

[mscfd at gmx dot net via Gcc-bugs]

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

--- Comment #4 from martin  ---
(In reply to anlauf from comment #1)
> Confirmed.
> 
> F2018:11.1.3.3 has:
> 
> "The associating entity does not have the ALLOCATABLE or POINTER attributes;
> it has the TARGET attribute if and only if the selector is a variable and has
> either the TARGET or POINTER attribute."

I was not sure, whether this formulation also covers array sections.
Anyway, thanks for the fast reply!

[Bug fortran/112764] Associating entity does not have target attribute if selector has pointer attribute in associate block

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||rejects-valid
 CC||pault at gcc dot gnu.org

--- Comment #3 from anlauf at gcc dot gnu.org ---
CC'ing Paul.  He's the expert on ASSOCIATE issues.

[Bug fortran/112764] Associating entity does not have target attribute if selector has pointer attribute in associate block

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org

--- Comment #2 from anlauf at gcc dot gnu.org ---
Created attachment 56723
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56723=edit
Untested patch

The attached patch fixes the issue.  Needs regtesting.

[Bug middle-end/112771] New: during GIMPLE pass: bitintlower0 ICE: in build_bitint_type, at tree.cc:7178 with _BitInt(65535) and division by zero

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 112771
   Summary: during GIMPLE pass: bitintlower0 ICE: in
build_bitint_type, at tree.cc:7178 with _BitInt(65535)
and division by zero
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

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

$ x86_64-pc-linux-gnu-gcc testcase.c 
testcase.c: In function 'foo':
testcase.c:5:5: warning: division by zero [-Wdiv-by-zero]
5 |   a /= 0;
  | ^~
during GIMPLE pass: bitintlower0
testcase.c:2:1: internal compiler error: in build_bitint_type, at tree.cc:7178
2 | foo (void)
  | ^~~
0x891bea build_bitint_type(unsigned long, int)
/repo/gcc-trunk/gcc/tree.cc:7178
0x2538b8e handle_operand_addr
/repo/gcc-trunk/gcc/gimple-lower-bitint.cc:2185
0x2539407 lower_muldiv_stmt
/repo/gcc-trunk/gcc/gimple-lower-bitint.cc:3339
0x254ca76 gimple_lower_bitint
/repo/gcc-trunk/gcc/gimple-lower-bitint.cc:6349
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

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

[Bug middle-end/112770] New: during GIMPLE pass: bitintlower0 ICE: verify_gimple failed: statement marked for throw in middle of block with -fnon-call-exceptions and _BitInt(128)

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 112770
   Summary: during GIMPLE pass: bitintlower0 ICE: verify_gimple
failed: statement marked for throw in middle of block
with -fnon-call-exceptions and _BitInt(128)
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

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

Compiler output:
$ x86_64-pc-linux-gnu-gcc -fnon-call-exceptions testcase.c 
testcase.c: In function 'foo':
testcase.c:5:5: warning: division by zero [-Wdiv-by-zero]
5 |   a /= 0;
  | ^~
testcase.c:2:1: error: statement marked for throw in middle of block
2 | foo (void)
  | ^~~
_7 = _8 / 0;
during GIMPLE pass: bitintlower0
testcase.c:2:1: internal compiler error: verify_gimple failed
0x1539ca5 verify_gimple_in_cfg(function*, bool, bool)
/repo/gcc-trunk/gcc/tree-cfg.cc:5662
0x13a32e4 execute_function_todo
/repo/gcc-trunk/gcc/passes.cc:2088
0x13a383e execute_todo
/repo/gcc-trunk/gcc/passes.cc:2142
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

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

[Bug c++/112769] New: ICE on valid code related to requires-expression

[janpmoeller at gmx dot de via Gcc-bugs]

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

Bug ID: 112769
   Summary: ICE on valid code related to requires-expression
   Product: gcc
   Version: 13.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: janpmoeller at gmx dot de
  Target Milestone: ---

All gcc versions since (and including) 11.2 reject the following valid C++20
code:

//
template
struct type
{
constexpr explicit type(T value)
{
}

template
constexpr explicit type(type value)
requires requires { T{value}; }
{
}
};

template 
using alias = type<0, T>;

constexpr alias foo{123};
//


The reported error is:

##
:11:18: internal compiler error: in add_outermost_template_args, at
cp/pt.cc:617
   11 | requires requires { T{value}; }
  |  ^~
0x1ce7bde internal_error(char const*, ...)
???:0
0x7290fc fancy_abort(char const*, int, char const*)
???:0
0x7879b6 tsubst_requires_expr(tree_node*, tree_node*, int, tree_node*)
???:0
0x783c90 tsubst_constraint(tree_node*, tree_node*, int, tree_node*)
???:0
0x783df1 tsubst_constraint_info(tree_node*, tree_node*, int, tree_node*)
???:0
0x8b1e90 do_auto_deduction(tree_node*, tree_node*, tree_node*, int,
auto_deduction_context, tree_node*, int, tree_node*)
???:0
0x7ccd01 cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
???:0
0x89fd5b c_parse_file()
???:0
0x98c5d9 c_common_parse_file()
???:0
Please submit a full bug report, with preprocessed source.
Please include the complete backtrace with any bug report.
See  for instructions.
Preprocessed source stored into /tmp/cclpGAjI.out file, please attach this to
your bugreport.
Compiler returned: 1
##

gcc-11.1 accepts the code.Here is a link to compiler explorer with the same
example: https://godbolt.org/z/aq1d53anv

Note that the first (non-template) constructor is required to make the code
valid, but it is not required to reproduce the issue. Removing it still leads
to the same ICE on gcc > 11.1, whereas gcc-11.1 (correctly) rejects it due to
failed argument deduction.

[Bug debug/112768] btf: fix asm comment output for BTF_KIND_FUNC* kinds

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

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

Indu Bhagat  changed:

   What|Removed |Added

   Priority|P3  |P4

[Bug debug/112768] New: btf: fix asm comment output for BTF_KIND_FUNC* kinds

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

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

Bug ID: 112768
   Summary: btf: fix asm comment output for BTF_KIND_FUNC* kinds
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ibhagat at gcc dot gnu.org
  Target Milestone: ---

The BTF type of kind BTF_KIND_FUNC_PROTO is always anonymous.  The
machinery, via btf_collect_datasec (), resets the ctti_name to 0 to
reflect that.  The name string in the (ctf) type contained in the CTF
container is, however, not updated.  The latter is used to emit the type
name in the asm comment output.

E.g., for gcc/testsuite/gcc.dg/debug/btf/btf-function-6.c:

extern int extfunc(int a, int b);

int foo (int x) {

  int y = extfunc (x, x+1);

  return y;
}

a user may see the following in the comments in the -dA output:

.long   0   # TYPE 2 BTF_KIND_FUNC_PROTO 'extfunc'
.long   0xd02   # btt_info: kind=13, kflag=0, vlen=2
.long   0x1 # btt_type: (BTF_KIND_INT 'int')
.long   0   # farg_name
.long   0x1 # farg_type: (BTF_KIND_INT 'int')
.long   0   # farg_name
.long   0x1 # farg_type: (BTF_KIND_INT 'int')
.long   0   # TYPE 3 BTF_KIND_FUNC_PROTO 'foo'
.long   0xd01   # btt_info: kind=13, kflag=0, vlen=1
.long   0x1 # btt_type: (BTF_KIND_INT 'int')
.long   0x68# farg_name
.long   0x1 # farg_type: (BTF_KIND_INT 'int')
.long   0x5 # TYPE 4 BTF_KIND_FUNC '(null)'
.long   0xc02   # btt_info: kind=12, kflag=0, linkage=2
.long   0x2 # btt_type: (BTF_KIND_FUNC_PROTO 'extfunc')
.long   0xd # TYPE 5 BTF_KIND_FUNC '(null)'
.long   0xc01   # btt_info: kind=12, kflag=0, linkage=1
.long   0x3 # btt_type: (BTF_KIND_FUNC_PROTO 'foo')

The above may cause confusion to the reader:
- Types of kind BTF_KIND_FUNC_PROTO are displayed with a name.
- BTF_KIND_FUNC appears with 'null'

It will be ideal to display:
- BTF_KIND_FUNC_PROTO as anonymous
- BTF_KIND_FUNC with the name of the function

[Bug debug/112656] btf: function prototypes generated with name

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

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

--- Comment #7 from Indu Bhagat  ---
Currently generating everything at finish () when -mco-re is in effect is
sufficient for BPF needs.  BTF is generated late for -mco-re because of CO-RE
relocations: these are strings which record indexes into the source-level data
structures, e.g. "0:4:2:3", and are stored int the .BTF string table.  CO-RE is
handled in the BPF backend during expand, which is after debug_early_finish ().

'Whether we should split BTF generation into two parts' is a larger question
not affecting the current PR at hand, I think. We should evaluate the overall
benefit of that approach (apart from the one we are seeing here - reproducible
BTF across targets), vs the implementation cost and complexity. If there is
interest.

[Bug target/111107] i686-w64-mingw32 does not realign stack when __attribute__((aligned)) or __attribute__((vector_size)) are used

[zfigura at codeweavers dot com via Gcc-bugs]

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

--- Comment #17 from Zeb Figura  ---
Actually, for that matter, what is the intended purpose of -mstackrealign? How
is it supposed to differ from -mincoming-stack-boundary and
-mpreferred-stack-boundary? The documentation is kind of unclear; it "realigns
the stack at entry [...] if necessary", which sounds like it could be
synonymous with -mincoming-stack-boundary or -mpreferred-stack-boundary.

But the mechanism in the code seems to be entirely separate, and it's also
broken with -mavx512f (bug 110273). From some quick testing it also seems to be
broken with aligned(8), though not aligned(16). That seems to be due to the
logic at [1]; not sure if that was intentional but I'll admit it doesn't make
much sense to me. But I also don't see why this mechanism is used instead of
whatever mechanism is used for -mincoming-stack-boundary.

[1]
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/i386/i386.cc;h=9390f525b99f0c078c912876aee8498bc3e7701b;hb=HEAD#l7768

[Bug target/112762] [14 Regression] Cannot build crosscompilers for some uclinux targets since r14-5791-g24592abd68e6ef

[joseph at codesourcery dot com via Gcc-bugs]

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

--- Comment #5 from joseph at codesourcery dot com  ---
The *-uclinux* targets are generally for systems without an MMU and a 
corresponding ABI (FLAT, FDPIC, etc.), whereas *-linux-uclibc* targets are 
for systems with an MMU and an associated conventional ELF ABI.

[Bug middle-end/100604] GCC generates invalid LO_SYM for unaligned global

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-11-29
 Ever confirmed|0   |1

--- Comment #6 from Andrew Pinski  ---
.

[Bug target/106818] riscv produces bad low_sum while doing expansion of strict aligned stores/load

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #13 from Andrew Pinski  ---
Dup of bug 100604.

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

[Bug middle-end/100604] GCC generates invalid LO_SYM for unaligned global

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||pangbw at gmail dot com

--- Comment #5 from Andrew Pinski  ---
*** Bug 106818 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/112767] [14 regression] spurious -Waggressive-loop-optimizations

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2023-11-29
 Ever confirmed|0   |1
   Target Milestone|--- |14.0
 Status|UNCONFIRMED |NEW

--- Comment #1 from Andrew Pinski  ---
Confirmed. Looks like loop split is messing up ...

[Bug c++/112767] New: [14 regression] spurious -Waggressive-loop-optimizations

[sss--- via Gcc-bugs]

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

Bug ID: 112767
   Summary: [14 regression] spurious
-Waggressive-loop-optimizations
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: s...@li-snyder.org
  Target Milestone: ---

With a recent checkout of gcc14 (20231129), on a x86_64-pc-linux-gnu host,
the following source gives a seemingly bogus -Waggressive-loop-optimizations
warning with -O3:

--
double reg_dict[32];

void foo(int);

void initialize()
{
  int i=8;
  for (int phi=0; phi<8; ++phi) {
reg_dict[i]=0;
int sn = 0;
if (i < 16) sn = 20;
foo(sn);
++i;
  }
}
--

$ g++ -c -O3 x.cc
x.cc: In function ‘void initialize()’:
x.cc:9:16: warning: iteration 16 invokes undefined behavior
[-Waggressive-loop-optimizations]
9 | reg_dict[i]=0;
  | ~~~^~
x.cc:8:22: note: within this loop
8 |   for (int phi=0; phi<8; ++phi) {
  |   ~~~^~


This is a confusing warning, as the containing loop is executed only 8 times.
Exactly which undefined behavior is meant is also not spelled out.
>From the context, i'd guess it to be an out-of-bounds array write,
but that's a false positive.

The warning happens with -O3 but not with lower optimization levels.
It also does not occur with gcc 13.2.1 20230728.

[Bug target/112725] [14 Regression] powerpc64le-linux-gnu: 'c-c++-common/builtin-classify-type-1.c:113:3: error: AltiVec argument passed to unprototyped function'

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

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

--- Comment #5 from GCC Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:259bb7a45a26b76cbde2131a62926d4419c1cc1b

commit r14-5974-g259bb7a45a26b76cbde2131a62926d4419c1cc1b
Author: Jakub Jelinek 
Date:   Wed Nov 29 19:19:07 2023 +0100

rs6000: Fix up c-c++-common/builtin-classify-type-1.c failure [PR112725]

The rs6000 backend (and s390 one as well) diagnoses passing vector types
to unprototyped functions, which breaks the builtin-classify-type-1.c test.
The builtin isn't really unprototyped, it is just type-generic and
accepting
vector types is just fine there, all it does is categorize the vector type.
The following patch makes sure we don't diagnose it for this builtin.

2023-11-29  Jakub Jelinek  

PR target/112725
* config/rs6000/rs6000.cc (invalid_arg_for_unprototyped_fn): Return
NULL for __builtin_classify_type calls with vector arguments.

[Bug rtl-optimization/112758] [13/14 Regression] Inconsistent Bitwise AND Operation Result between int and long long int

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|target  |rtl-optimization
   Last reconfirmed||2023-11-29
Summary|Inconsistent Bitwise AND|[13/14 Regression]
   |Operation Result between|Inconsistent Bitwise AND
   |int and long long int on|Operation Result between
   |Different Optimization  |int and long long int
   |Levels in GCC Trunk |
   Keywords||needs-bisection
 Ever confirmed|0   |1
   Target Milestone|--- |13.3
 Status|UNCONFIRMED |NEW

--- Comment #1 from Andrew Pinski  ---
Trying 21, 18 -> 22:
   21: r149:DI=0x00ff
   18: r147:DI=sign_extend([r143:DI+low(`globalVar')])
  REG_DEAD r143:DI
   22: r148:DI=r147:DI:DI
  REG_DEAD r149:DI
  REG_DEAD r147:DI
  REG_EQUAL r147:DI&0x00ff
Successfully matched this instruction:
(set (reg:DI 148)
(zero_extend:DI (mem/c:SI (lo_sum:DI (reg/f:DI 143)
(symbol_ref:DI ("globalVar") [flags 0x86]  )) [1 globalVarD.2927+0 S4 A32])))
allowing combination of insns 18, 21 and 22
original costs 32 + 4 + 4 = 40
replacement cost 32


That is almost definitely wrong.

Was working in GCC 12 but started to go wrong in GCC 13.

[Bug target/112762] [14 Regression] Cannot build crosscompilers for some uclinux targets since r14-5791-g24592abd68e6ef

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

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

--- Comment #4 from Andrew Pinski  ---
Part of the problem is *-uclinux is not matched in config.gcc where
linux-protos.h/linux.o gets added:
```
*-*-linux* | frv-*-*linux* | *-*-kfreebsd*-gnu | *-*-gnu* |
*-*-kopensolaris*-gnu | *-*-uclinuxfdpiceabi)
...
  # Linux C libraries selection switch: glibc / uclibc / bionic.
  # uclibc and bionic aren't usable for GNU/Hurd and neither for GNU/k*BSD.
  case $target in
*linux*)
  tm_p_file="${tm_p_file} linux-protos.h"
  tmake_file="${tmake_file} t-linux"
  extra_objs="${extra_objs} linux.o"
  extra_options="${extra_options} linux.opt"
  ;;
  esac

```

As I mentioned there seems to be some misunderstanding what is the canonical
form for the triplet, or is both canonical (and different?) and just need fix
the usage for when uclinux is used and have them set tm_p_file/extra_objs
correctly, if they use linux.h .

[Bug fortran/112764] Associating entity does not have target attribute if selector has pointer attribute in associate block

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2023-11-29
 Status|UNCONFIRMED |NEW

--- Comment #1 from anlauf at gcc dot gnu.org ---
Confirmed.

F2018:11.1.3.3 has:

"The associating entity does not have the ALLOCATABLE or POINTER attributes;
it has the TARGET attribute if and only if the selector is a variable and has
either the TARGET or POINTER attribute."

[Bug target/112762] [14 Regression] Cannot build crosscompilers for some uclinux targets since r14-5791-g24592abd68e6ef

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

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

--- Comment #3 from Marek Polacek  ---
I'm not really sure what the problem is but I wonder if this would help:

--- a/gcc/config/linux.h
+++ b/gcc/config/linux.h
@@ -215,7 +215,7 @@ see the files COPYING3 and COPYING.RUNTIME respectively. 
If not, see
 # undef TARGET_LIBM_FUNCTION_MAX_ERROR
 # define TARGET_LIBM_FUNCTION_MAX_ERROR linux_libm_function_max_error

-#endif
-
 #undef TARGET_FORTIFY_SOURCE_DEFAULT_LEVEL
 #define TARGET_FORTIFY_SOURCE_DEFAULT_LEVEL linux_fortify_source_default_level
+
+#endif

[Bug target/112762] [14 Regression] Cannot build crosscompilers for some uclinux targets since r14-5791-g24592abd68e6ef

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2023-11-29

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

It looks like config.gcc is partly a mess when it comes to *-uclinux targets
too.

Is bfin*-uclinux* or bfin*-linux-uclibc* canonical form here? The later will
work while the former is now broken ...

[Bug target/112762] [14 Regression] Cannot build crosscompilers for some uclinux targets since r14-5791-g24592abd68e6ef

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org
Summary|Cannot build crosscompilers |[14 Regression] Cannot
   |for some uclinux targets|build crosscompilers for
   ||some uclinux targets since
   ||r14-5791-g24592abd68e6ef
   Target Milestone|--- |14.0

--- Comment #1 from Andrew Pinski  ---
Almost definitely caused by r14-5791-g24592abd68e6ef .

[Bug tree-optimization/112766] [14 regression] spurious -Wmaybe-uninitialized with array new

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

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

Marek Polacek  changed:

   What|Removed |Added

   Target Milestone|--- |14.0
 Status|UNCONFIRMED |NEW
   Keywords||diagnostic
 CC||mpolacek at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
 Ever confirmed|0   |1
  Component|c++ |tree-optimization
   Last reconfirmed||2023-11-29

--- Comment #1 from Marek Polacek  ---
Started with r14-4089:

commit d45ddc2c04e471d0dcee016b6edacc00b8341b16
Author: Richard Biener 
Date:   Thu Sep 14 13:06:51 2023 +0200

tree-optimization/111294 - backwards threader PHI costing

[Bug c++/112766] New: [14 regression] spurious -Wmaybe-uninitialized with array new

[sss--- via Gcc-bugs]

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

Bug ID: 112766
   Summary: [14 regression] spurious -Wmaybe-uninitialized with
array new
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: s...@li-snyder.org
  Target Milestone: ---

hi -

With a recent checkout of gcc14 (20231129), on a x86_64-pc-linux-gnu host,
the following source gives a bogus -Wmaybe-uninitialized warning
with -Wall:

--
void* operator new[](unsigned long, void* __p) ;

class Result
{
public:
  Result();
  ~Result();
};

void *foo(long nElements, void *p) {
  return p ? new((int*)p) Result[nElements] : new Result[nElements];
}
--


$ g++ -c -O1 -Wall x.cc
x.cc: In function ‘void* foo(long int, void*)’:
x.cc:11:67: warning: ‘nElements.6’ may be used uninitialized
[-Wmaybe-uninitialized]
   11 |   return p ? new((int*)p) Result[nElements] : new Result[nElements];
  |   ^
x.cc:11:58: note: ‘nElements.6’ was declared here
   11 |   return p ? new((int*)p) Result[nElements] : new Result[nElements];
  |  ^

We get the same warning with -O2 and -O3, but not -O0.

This warning does not occur with gcc 13.2.1 20230728.

[Bug ipa/111922] [11/12/13/14 Regression] ICE in cp with -O2 -fno-tree-fre

[amacleod at redhat dot com via Gcc-bugs]

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

Andrew Macleod  changed:

   What|Removed |Added

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

--- Comment #11 from Andrew Macleod  ---
fixed.

[Bug ipa/111922] [11/12/13/14 Regression] ICE in cp with -O2 -fno-tree-fre

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

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

--- Comment #10 from GCC Commits  ---
The master branch has been updated by Andrew Macleod :

https://gcc.gnu.org/g:634cf26c94de620e66aa124b8ec4d6c2be4b74b2

commit r14-5973-g634cf26c94de620e66aa124b8ec4d6c2be4b74b2
Author: Andrew MacLeod 
Date:   Tue Nov 28 13:02:35 2023 -0500

Check operands before invoking fold_range.

Call check_operands_p before fold_range to make sure it is a valid
operation.

PR tree-optimization/111922
gcc/
* ipa-cp.cc (ipa_vr_operation_and_type_effects): Check the
operands are valid before calling fold_range.

gcc/testsuite/
* gcc.dg/pr111922.c: New.

[Bug c++/112765] [14 regression] -Wparentheses warning even when extra parens are present

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

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

Patrick Palka  changed:

   What|Removed |Added

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

[Bug tree-optimization/112711] [14 Regression] SRA seems to ignore writes when using __builtin_assume_aligned since r14-5831-gaae723d360ca26

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

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

--- Comment #9 from Sergei Trofimovich  ---
The change also fixes llvm-16.0.6 testsuite for me. Thank you!

[Bug c++/112765] [14 regression] -Wparentheses warning even when extra parens are present

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

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org,
   ||ppalka at gcc dot gnu.org
   Keywords||diagnostic
   Target Milestone|--- |14.0
   Last reconfirmed||2023-11-29
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #1 from Marek Polacek  ---
Confirmed, started with r14-4111:

commit 6e92a6a2a72d3b7a5e1b29042d8a6a43fe1085aa
Author: Patrick Palka 
Date:   Mon Sep 18 14:47:52 2023 -0400

c++: non-dependent assignment checking [PR63198, PR18474]

[Bug c++/112765] New: [14 regression] -Wparentheses warning even when extra parens are present

[sss--- via Gcc-bugs]

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

Bug ID: 112765
   Summary: [14 regression] -Wparentheses warning even when extra
parens are present
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: s...@li-snyder.org
  Target Milestone: ---

hi -

With a recent checkout of gcc14 (20231129), on a x86_64-pc-linux-gnu host,
the following source gives a bogus -Wparentheses warning
with -Wall:

--
struct ptr
{
  ptr& operator= (ptr&& __u);
  explicit operator bool() const;
};

ptr getShare ();

template
class AnaToolHandle final
{
public:
  int getMode (ptr& sharedTool) const;
};

template
int AnaToolHandle::getMode (ptr& sharedTool) const
{
  if ((sharedTool = getShare ()))
return 0;

  return 1;
}

void initialize(AnaToolHandle& jetCleaningTool)
{
  ptr sharedTool;
  jetCleaningTool.getMode (sharedTool);
}
--


$ g++ -c -Wall x.cc
x.cc: In instantiation of ‘int AnaToolHandle::getMode(ptr&) const [with T =
int]’:
x.cc:28:27:   required from here
   28 |   jetCleaningTool.getMode (sharedTool);
  |   ^~~~
x.cc:19:31: warning: suggest parentheses around assignment used as truth value
[-Wparentheses]
   19 |   if ((sharedTool = getShare ()))
  |   ^


It is true that there is an assignment used as a truth value, and in the
original code this was intentional, which the author signalled by adding
an extra pair of parentheses.  However, gcc emits the warning even though
the extra parentheses are there.  (Adding yet another pair of parentheses
around the condition does not silence the warning.)

This warning does not occcur with gcc 13.2.1 20230728.

[Bug tree-optimization/112711] [14 Regression] SRA seems to ignore writes when using __builtin_assume_aligned since r14-5831-gaae723d360ca26

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

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

Martin Jambor  changed:

   What|Removed |Added

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

--- Comment #8 from Martin Jambor  ---
Fixed.

[Bug tree-optimization/112721] [14 Regression] Wrong code at -O1/s on x86_64-linux-gnu since r14-5831-gaae723d360c

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

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

Martin Jambor  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Jambor  ---
Fixed

[Bug tree-optimization/112711] [14 Regression] SRA seems to ignore writes when using __builtin_assume_aligned since r14-5831-gaae723d360ca26

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

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

--- Comment #7 from GCC Commits  ---
The master branch has been updated by Martin Jambor :

https://gcc.gnu.org/g:302461ad9a04d82fee904bddac69811d13d5bb6a

commit r14-5971-g302461ad9a04d82fee904bddac69811d13d5bb6a
Author: Martin Jambor 
Date:   Wed Nov 29 16:24:33 2023 +0100

tree-sra: Avoid returns of references to SRA candidates

The enhancement to address PR 109849 contained an importsnt thinko,
and that any reference that is passed to a function and does not
escape, must also not happen to be aliased by the return value of the
function.  This has quickly transpired as bugs PR 112711 and PR
112721.

Just as IPA-modref does a good enough job to allow us to rely on the
escaped set of variables, it sems to be doing well also on updating
EAF_NOT_RETURNED_DIRECTLY call argument flag which happens to address
exactly the situation we need to avoid.  Of course, if a call
statement ignores any returned value, we also do not need to check the
flag.

Hopefully this does not pessimize things too much, I have verified
that the PR 109849 testcae remains quick and so should also the
benchmark it is derived from.

gcc/ChangeLog:

2023-11-27  Martin Jambor  

PR tree-optimization/112711
PR tree-optimization/112721
* tree-sra.cc (build_access_from_call_arg): New parameter
CAN_BE_RETURNED, disqualify any candidate passed by reference if it
is
true.  Adjust leading comment.
(scan_function): Pass appropriate value to CAN_BE_RETURNED of
build_access_from_call_arg.

gcc/testsuite/ChangeLog:

2023-11-29  Martin Jambor  

PR tree-optimization/112711
PR tree-optimization/112721
* g++.dg/tree-ssa/pr112711.C: New test.
* gcc.dg/tree-ssa/pr112721.c: Likewise.

[Bug tree-optimization/112721] [14 Regression] Wrong code at -O1/s on x86_64-linux-gnu since r14-5831-gaae723d360c

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

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

--- Comment #3 from GCC Commits  ---
The master branch has been updated by Martin Jambor :

https://gcc.gnu.org/g:302461ad9a04d82fee904bddac69811d13d5bb6a

commit r14-5971-g302461ad9a04d82fee904bddac69811d13d5bb6a
Author: Martin Jambor 
Date:   Wed Nov 29 16:24:33 2023 +0100

tree-sra: Avoid returns of references to SRA candidates

The enhancement to address PR 109849 contained an importsnt thinko,
and that any reference that is passed to a function and does not
escape, must also not happen to be aliased by the return value of the
function.  This has quickly transpired as bugs PR 112711 and PR
112721.

Just as IPA-modref does a good enough job to allow us to rely on the
escaped set of variables, it sems to be doing well also on updating
EAF_NOT_RETURNED_DIRECTLY call argument flag which happens to address
exactly the situation we need to avoid.  Of course, if a call
statement ignores any returned value, we also do not need to check the
flag.

Hopefully this does not pessimize things too much, I have verified
that the PR 109849 testcae remains quick and so should also the
benchmark it is derived from.

gcc/ChangeLog:

2023-11-27  Martin Jambor  

PR tree-optimization/112711
PR tree-optimization/112721
* tree-sra.cc (build_access_from_call_arg): New parameter
CAN_BE_RETURNED, disqualify any candidate passed by reference if it
is
true.  Adjust leading comment.
(scan_function): Pass appropriate value to CAN_BE_RETURNED of
build_access_from_call_arg.

gcc/testsuite/ChangeLog:

2023-11-29  Martin Jambor  

PR tree-optimization/112711
PR tree-optimization/112721
* g++.dg/tree-ssa/pr112711.C: New test.
* gcc.dg/tree-ssa/pr112721.c: Likewise.

[Bug middle-end/109849] suboptimal code for vector walking loop

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

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

--- Comment #33 from GCC Commits  ---
The master branch has been updated by Martin Jambor :

https://gcc.gnu.org/g:302461ad9a04d82fee904bddac69811d13d5bb6a

commit r14-5971-g302461ad9a04d82fee904bddac69811d13d5bb6a
Author: Martin Jambor 
Date:   Wed Nov 29 16:24:33 2023 +0100

tree-sra: Avoid returns of references to SRA candidates

The enhancement to address PR 109849 contained an importsnt thinko,
and that any reference that is passed to a function and does not
escape, must also not happen to be aliased by the return value of the
function.  This has quickly transpired as bugs PR 112711 and PR
112721.

Just as IPA-modref does a good enough job to allow us to rely on the
escaped set of variables, it sems to be doing well also on updating
EAF_NOT_RETURNED_DIRECTLY call argument flag which happens to address
exactly the situation we need to avoid.  Of course, if a call
statement ignores any returned value, we also do not need to check the
flag.

Hopefully this does not pessimize things too much, I have verified
that the PR 109849 testcae remains quick and so should also the
benchmark it is derived from.

gcc/ChangeLog:

2023-11-27  Martin Jambor  

PR tree-optimization/112711
PR tree-optimization/112721
* tree-sra.cc (build_access_from_call_arg): New parameter
CAN_BE_RETURNED, disqualify any candidate passed by reference if it
is
true.  Adjust leading comment.
(scan_function): Pass appropriate value to CAN_BE_RETURNED of
build_access_from_call_arg.

gcc/testsuite/ChangeLog:

2023-11-29  Martin Jambor  

PR tree-optimization/112711
PR tree-optimization/112721
* g++.dg/tree-ssa/pr112711.C: New test.
* gcc.dg/tree-ssa/pr112721.c: Likewise.

[Bug fortran/112764] New: Associating entity does not have target attribute if selector has pointer attribute in associate block

[mscfd at gmx dot net via Gcc-bugs]

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

Bug ID: 112764
   Summary: Associating entity does not have target attribute if
selector has pointer attribute in associate block
   Product: gcc
   Version: 13.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mscfd at gmx dot net
  Target Milestone: ---

The selector has the pointer attribute but association is with an array
section. The associating entity should have the target attribute even in this
case, right? gfortran complains with "Pointer assignment target is neither
TARGET nor POINTER", ifort and ifx accept it. Looks like a bug in gfortran, or
has i1 indeed no target attribute?



program assoc_target

implicit none

integer, dimension(:,:), pointer :: x
integer, pointer :: j

allocate(x(1:100,1:2), source=0)
associate(i1 => x(:,1))
   j => i1(1)
   print *, j
end associate
deallocate(x)

end program assoc_target

[Bug testsuite/112729] gcc.target/i386/apx-interrupt-1.c etc. FAIL

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

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

Rainer Orth  changed:

   What|Removed |Added

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

--- Comment #10 from Rainer Orth  ---
AFAICS, all aspects of this PR have been dealt with now.

[Bug middle-end/112697] [14 Regression] 30-40% exec time regression of 433.milc on zen2 since r14-4972-g8aa47713701b1f

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

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

--- Comment #7 from Martin Jambor  ---
Created attachment 56720
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56720=edit
Perf annotate of milc built with r14-4972-g8aa47713701b1f

commit r14-4972-g8aa47713701b1f:

$ perf stat taskset -c 0 specinvoke

 Performance counter stats for 'taskset -c 0 specinvoke':

 272931.43 msec task-clock:u #1.000 CPUs
utilized 
 0  context-switches:u   #0.000 /sec
 0  cpu-migrations:u #0.000 /sec
472353  page-faults:u#1.731 K/sec   
  886165387570  cycles:u #3.247 GHz
(83.33%)
   31546898034  stalled-cycles-frontend:u#3.56% frontend
cycles idle(83.33%)
  729878095777  stalled-cycles-backend:u #   82.36% backend
cycles idle (83.33%)
 1061779557370  instructions:u   #1.20  insn per
cycle
  #0.69  stalled cycles per
insn (83.33%)
   58797121078  branches:u   #  215.428 M/sec  
(83.33%)
   6960852  branch-misses:u  #0.01% of all
branches (83.33%)

 272.967381843 seconds time elapsed

 268.718335000 seconds user
   4.212584000 seconds sys

$ perf record taskset -c 0 specinvoke
[ perf record: Woken up 167 times to write data ]
[ perf record: Captured and wrote 41.549 MB perf.data (1088982 samples) ]

$ perf report -n --percent-limit=1 --stdio
# To display the perf.data header info, please use --header/--header-only
options.
#
#
# Total Lost Samples: 0
#
# Samples: 1M of event 'cycles:Pu'
# Event count (approx.): 883903400858
#
# Overhead   Samples  Command  Shared Object   Symbol   
#     ...  .. 
..
#
24.34%260907  milc_base.mine-  milc_base.mine-lto-gen  [.]
add_force_to_mom
18.01%198287  milc_base.mine-  milc_base.mine-lto-gen  [.]
mult_su3_na
17.45%187529  milc_base.mine-  milc_base.mine-lto-gen  [.]
u_shift_fermion
14.22%155596  milc_base.mine-  milc_base.mine-lto-gen  [.]
mult_su3_nn
 5.61% 60601  milc_base.mine-  milc_base.mine-lto-gen  [.]
scalar_mult_add_su3_matrix
 4.35% 51034  milc_base.mine-  milc_base.mine-lto-gen  [.]
path_product
 4.24% 46032  milc_base.mine-  milc_base.mine-lto-gen  [.]
mult_su3_an
 2.99% 32624  milc_base.mine-  milc_base.mine-lto-gen  [.]
imp_gauge_force.constprop.0
 1.50% 16242  milc_base.mine-  milc_base.mine-lto-gen  [.]
compute_gen_staple
 1.35% 14580  milc_base.mine-  milc_base.mine-lto-gen  [.]
mult_su3_mat_vec_sum_4dir
 1.21% 12922  milc_base.mine-  milc_base.mine-lto-gen  [.]
make_anti_hermitian
 1.06% 11469  milc_base.mine-  milc_base.mine-lto-gen  [.]
mult_adj_su3_mat_4vec
 1.03% 1  milc_base.mine-  libc.so.6   [.]
__memset_avx2_unaligned_erms


$ perf annotate -n --percent-limit=1 > ~/tmp/milc-perf-annotate-8aa47713701 
(gzipeped and attached)

[Bug testsuite/112729] gcc.target/i386/apx-interrupt-1.c etc. FAIL

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

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

--- Comment #9 from GCC Commits  ---
The master branch has been updated by Rainer Orth :

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

commit r14-5968-g8ee480441eaec87ca6e0b0963fe9aade7edd1e8a
Author: Rainer Orth 
Date:   Wed Nov 29 14:52:04 2023 +0100

testsuite, i386: Only check for cfi directives if supported [PR112729]

gcc.target/i386/apx-interrupt-1.c and two more tests FAIL on Solaris/x86
with the native assembler.  Like Darwin as, it doesn't support cfi
directives.  Instead of adding more and more targets in every affected
test, this patch introduces a cfi effective-target keyword to check for
the prerequisite.

Tested on i386-pc-solaris2.11 (as and gas), x86_64-pc-linux-gnu, and
x86_64-apple-darwin23.1.0.

2023-11-24  Rainer Orth  

gcc/testsuite:
PR testsuite/112729
* lib/target-supports.exp (check_effective_target_cfi): New proc.
* gcc.target/i386/apx-interrupt-1.c: Require cfi instead of
skipping on *-*-darwin*.
* gcc.target/i386/apx-push2pop2_force_drap-1.c: Likewise.
* gcc.target/i386/apx-push2pop2-1.c: Likewise.

gcc:
PR testsuite/112729
* doc/sourcebuild.texi (Effective-Target Keywords, Environment
attributes): Document cfi.

[Bug middle-end/112697] [14 Regression] 30-40% exec time regression of 433.milc on zen2 since r14-4972-g8aa47713701b1f

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

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

--- Comment #6 from Martin Jambor  ---
Created attachment 56719
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56719=edit
Perf annotate of milc built with r14-4971-g0beb1611754742

commit r14-4971-g0beb1611754742:

$ perf stat taskset -c 0 specinvoke

 Performance counter stats for 'taskset -c 0 specinvoke':

 216908.59 msec task-clock:u #1.000 CPUs
utilized 
 0  context-switches:u   #0.000 /sec
 0  cpu-migrations:u #0.000 /sec
889694  page-faults:u#4.102 K/sec   
  697007650237  cycles:u #3.213 GHz
(83.33%)
   31999772966  stalled-cycles-frontend:u#4.59% frontend
cycles idle(83.33%)
  540485725923  stalled-cycles-backend:u #   77.54% backend
cycles idle (83.33%)
 1061256162815  instructions:u   #1.52  insn per
cycle
  #0.51  stalled cycles per
insn (83.33%)
   58760648879  branches:u   #  270.901 M/sec  
(83.34%)
  11890202  branch-misses:u  #0.02% of all
branches (83.33%)

 216.935387643 seconds time elapsed

 211.436079000 seconds user
   5.472459000 seconds sys

$ perf record taskset -c 0 specinvoke
[ perf record: Woken up 132 times to write data ]
[ perf record: Captured and wrote 32.901 MB perf.data (862286 samples) ]


$ perf report -n --percent-limit=1 --stdio
# To display the perf.data header info, please use --header/--header-only
options.
#
#
# Total Lost Samples: 0
#
# Samples: 862K of event 'cycles:Pu'
# Event count (approx.): 695776598661
#
# Overhead   Samples  Command  Shared Object   Symbol   
#     ...  .. 
..
#
22.68%197003  milc_base.mine-  milc_base.mine-lto-gen  [.]
mult_su3_na
20.99%177912  milc_base.mine-  milc_base.mine-lto-gen  [.]
u_shift_fermion
19.04%163787  milc_base.mine-  milc_base.mine-lto-gen  [.]
mult_su3_nn
 6.85% 58509  milc_base.mine-  milc_base.mine-lto-gen  [.]
scalar_mult_add_su3_matrix
 5.51% 50953  milc_base.mine-  milc_base.mine-lto-gen  [.]
path_product
 5.40% 46083  milc_base.mine-  milc_base.mine-lto-gen  [.]
mult_su3_an
 4.22% 35853  milc_base.mine-  milc_base.mine-lto-gen  [.]
add_force_to_mom
 3.77% 32446  milc_base.mine-  milc_base.mine-lto-gen  [.]
imp_gauge_force.constprop.0
 1.98% 16848  milc_base.mine-  milc_base.mine-lto-gen  [.]
compute_gen_staple
 1.94% 16462  milc_base.mine-  milc_base.mine-lto-gen  [.]
make_anti_hermitian
 1.73% 14655  milc_base.mine-  milc_base.mine-lto-gen  [.]
mult_su3_mat_vec_sum_4dir
 1.35% 11472  milc_base.mine-  milc_base.mine-lto-gen  [.]
mult_adj_su3_mat_4vec
 1.27% 10801  milc_base.mine-  libc.so.6   [.]
__memset_avx2_unaligned_erms


$ perf annotate -n --percent-limit=1 > ~/tmp/milc-perf-annotate-0beb1611754 
(gzipeped and attached)

[Bug middle-end/112763] New: [OpenMP] ICE in gimplify_adjust_omp_clauses, at gimplify.cc:13238 – with defaultmap(firstprivate) for C++ member variables

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

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

Bug ID: 112763
   Summary: [OpenMP] ICE in gimplify_adjust_omp_clauses, at
gimplify.cc:13238 – with defaultmap(firstprivate) for
C++ member variables
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: openmp
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
  Target Milestone: ---

Created attachment 56718
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56718=edit
Testcase; compile with 'g++ -fopenmp -DDEFAULT_FIRSTPRIVATE' for this PR or
without -D for PR110347

The following code uses a C++ member variable and 'defaultmap(firstprivate)'
causes an ICE.

I am not quite sure what the result should be but an ICE is surely wrong.

Vaguely related to OpenMP spec issue #3343, strongly related is my email today
to the omp-lang@ spec email list.

* * *

In member function ‘void myClass::tgt()’:
28:14: internal compiler error: in gimplify_adjust_omp_clauses, at
gimplify.cc:13238
   28 |  #pragma omp target defaultmap(firstprivate) private(d) if (0)
  |  ^~~


0x880609 gimplify_adjust_omp_clauses
../../repos/gcc-trunk-commit/gcc/gimplify.cc:13238
0x10094b4 gimplify_omp_workshare
../../repos/gcc-trunk-commit/gcc/gimplify.cc:15783


Compile the attached testcase with:
 g++ -fopenmp -DDEFAULT_FIRSTPRIVATE
Note: it compiles with  -DNON_MEMBER (and fails at runtime, which might be
correct).

See also PR 110347 for the case of unset DEFAULT_FIRSTPRIVATE, i.e. using
  firstprivate(member_var)  instead of   default{,map}(firstprivate)

[Bug target/109253] libbpf: failed to find BTF info for global/extern symbol '__divdi3'

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

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

--- Comment #6 from Jose E. Marchesi  ---
(In reply to Shung-Hsi Yu from comment #5)
> any chance we will also have this fix in GCC 13?

Yes.  We plan to backport this and many other BPF related fixes and
improvements to GCC 10, 11, 12 and 13, once the port is capable of building all
the kernel BPF selftests.  We are almost there.

[Bug target/112762] New: Cannot build crosscompilers for some uclinux targets

[fkastl at suse dot cz via Gcc-bugs]

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

Bug ID: 112762
   Summary: Cannot build crosscompilers for some uclinux targets
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: build
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fkastl at suse dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: *-uclinux

While building the current upstream GCC configured with --target=bfin-uclinux,
--target=c6x-uclinux, --target=lm32-uclinux or --target=moxie-uclinux, the
build fails. The respective errors look almost the same. I list them at the end
of this report.


Configuration of the GCC I'm building:
../src/configure --prefix=/home/fkastl/gcc/inst --enable-languages=c,c++
--enable-checking --disable-bootstrap --disable-multilib --enable-obsolete
--target= OR bfin-uclinux OR c6x-uclinux OR lm32-uclinux OR moxie-uclinux}

Configuration of system GCC:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-suse-linux/7/lto-wrapper
OFFLOAD_TARGET_NAMES=hsa:nvptx-none
Target: x86_64-suse-linux
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64
--enable-languages=c,c++,objc,fortran,obj-c++,ada,go
--enable-offload-targets=hsa,nvptx-none, --without-cuda-driver
--enable-checking=release --disable-werror
--with-gxx-include-dir=/usr/include/c++/7 --enable-ssp --disable-libssp
--disable-libvtv --disable-libcc1 --disable-plugin
--with-bugurl=https://bugs.opensuse.org/ --with-pkgversion='SUSE Linux'
--with-slibdir=/lib64 --with-system-zlib --enable-libstdcxx-allocator=new
--disable-libstdcxx-pch --enable-version-specific-runtime-libs
--with-gcc-major-version-only --enable-linker-build-id --enable-linux-futex
--enable-gnu-indirect-function --program-suffix=-7 --without-system-libunwind
--enable-multilib --with-arch-32=x86-64 --with-tune=generic
--build=x86_64-suse-linux --host=x86_64-suse-linux
Thread model: posix
gcc version 7.5.0 (SUSE Linux)


List of the respective error messages:

bfin-uclinux

g++  -fno-PIE -c   -g -O2   -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE  
-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing
-Wwrite-strings -Wcast-qual -Wmissing-format-attribute
-Wconditionally-supported -Woverloaded-virtual -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H
-fno-PIE -I. -I. -I../../src/gcc -I../../src/gcc/. -I../../src/gcc/../include 
-I../../src/gcc/../libcpp/include -I../../src/gcc/../libcody 
-I../../src/gcc/../libdecnumber -I../../src/gcc/../libdecnumber/dpd
-I../libdecnumber -I../../src/gcc/../libbacktrace   -o bfin.o -MT bfin.o -MMD
-MP -MF ./.deps/bfin.TPo ../../src/gcc/config/bfin/bfin.cc
In file included from ../../src/gcc/config/bfin/bfin.cc:28:0:
../../src/gcc/rtl.h:66:26: warning: ‘rtx_def::code’ is too small to hold all
values of ‘enum rtx_code’
 #define RTX_CODE_BITSIZE 8
  ^
../../src/gcc/rtl.h:318:33: note: in expansion of macro ‘RTX_CODE_BITSIZE’
   ENUM_BITFIELD(rtx_code) code: RTX_CODE_BITSIZE;
 ^~~~
In file included from ./tm.h:31:0,
 from ../../src/gcc/backend.h:28,
 from ../../src/gcc/config/bfin/bfin.cc:26:
../../src/gcc/config/linux.h:221:45: error:
‘linux_fortify_source_default_level’ was not declared in this scope
 #define TARGET_FORTIFY_SOURCE_DEFAULT_LEVEL linux_fortify_source_default_level
 ^
../../src/gcc/config/linux.h:221:45: note: in definition of macro
‘TARGET_FORTIFY_SOURCE_DEFAULT_LEVEL’
 #define TARGET_FORTIFY_SOURCE_DEFAULT_LEVEL linux_fortify_source_default_level
 ^~
../../src/gcc/config/bfin/bfin.cc:5885:29: note: in expansion of macro
‘TARGET_INITIALIZER’
 struct gcc_target targetm = TARGET_INITIALIZER;
 ^~
../../src/gcc/config/linux.h:221:45: note: suggested alternative:
‘default_fortify_source_default_level’
 #define TARGET_FORTIFY_SOURCE_DEFAULT_LEVEL linux_fortify_source_default_level
 ^
../../src/gcc/config/linux.h:221:45: note: in definition of macro
‘TARGET_FORTIFY_SOURCE_DEFAULT_LEVEL’
 #define TARGET_FORTIFY_SOURCE_DEFAULT_LEVEL linux_fortify_source_default_level
 ^~
../../src/gcc/config/bfin/bfin.cc:5885:29: note: in expansion of macro
‘TARGET_INITIALIZER’
 struct gcc_target targetm = TARGET_INITIALIZER;
 ^~
make[1]: *** [Makefile:2531: bfin.o] Error 1
make[1]: Leaving directory '/home/fkastl/gcc/build/gcc'
make: *** [Makefile:4650: all-gcc] Error 2

[Bug rtl-optimization/110237] gcc.dg/torture/pr58955-2.c is miscompiled by RTL scheduling after reload

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

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug middle-end/109849] suboptimal code for vector walking loop

[hubicka at ucw dot cz via Gcc-bugs]

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

--- Comment #32 from Jan Hubicka  ---
> /tmp/build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/stl_algobase.h:437:
> warning: 'void* __builtin_memcpy(void*, const void*, long unsigned int)'
> writing between 2 and 9223372036854775806 bytes into a region of size 0
> overflows the destination [-Wstringop-overflow=]

It warns on:

  template
struct __copy_move<_IsMove, true, random_access_iterator_tag>
{
  template
_GLIBCXX20_CONSTEXPR
static _Up*
__copy_m(_Tp* __first, _Tp* __last, _Up* __result)
{
  const ptrdiff_t _Num = __last - __first;
  if (__builtin_expect(_Num > 1, true))
__builtin_memmove(__result, __first, sizeof(_Tp) * _Num);
  else if (_Num == 1)
std::__copy_move<_IsMove, false, random_access_iterator_tag>::
  __assign_one(__result, __first);
  return __result + _Num;
}
};

It is likely false positive on a code path that never happens in real
code, but we now optimize it better.

Does it show an inline path?

[Bug rtl-optimization/110237] gcc.dg/torture/pr58955-2.c is miscompiled by RTL scheduling after reload

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

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

--- Comment #27 from GCC Commits  ---
The master branch has been updated by Richard Biener :

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

commit r14-5964-gb09b879e4e9cc24a5d2b0344c1930020c218a104
Author: Richard Biener 
Date:   Wed Jun 21 09:31:30 2023 +0200

middle-end/110237 - wrong MEM_ATTRs for partial loads/stores

The following addresses a miscompilation by RTL scheduling related
to the representation of masked stores.  For that we have

(insn 38 35 39 3 (set (mem:V16SI (plus:DI (reg:DI 40 r12 [orig:90 _22 ]
[90])
(const:DI (plus:DI (symbol_ref:DI ("b") [flags 0x2] 
)
(const_int -4 [0xfffc] [1 MEM
 [(int *)vectp_b.12_28]+0 S64 A32])
(vec_merge:V16SI (reg:V16SI 20 xmm0 [118])
(mem:V16SI (plus:DI (reg:DI 40 r12 [orig:90 _22 ] [90])
(const:DI (plus:DI (symbol_ref:DI ("b") [flags 0x2] 
)
(const_int -4 [0xfffc] [1 MEM
 [(int *)vectp_b.12_28]+0 S64 A32])

and specifically the memory attributes

  [1 MEM  [(int *)vectp_b.12_28]+0 S64 A32]

are problematic.  They tell us the instruction stores and reads a full
vector which it if course does not.  There isn't any good MEM_EXPR
we can use here (we lack a way to just specify a pointer and restrict
info for example), and since the MEMs have a vector mode it's
difficult in general as passes do not need to look at the memory
attributes at all.

The easiest way to avoid running into the alias analysis problem is
to scrap the MEM_EXPR when we expand the internal functions for
partial loads/stores.  That avoids the disambiguation we run into
which is realizing that we store to an object of less size as
the size of the mode we appear to store.

After the patch we see just

  [1  S64 A32]

so we preserve the alias set, the alignment and the size (the size
is redundant if the MEM insn't BLKmode).  That's still not good
in case the RTL alias oracle would implement the same
disambiguation but it fends off the gimple one.

This fixes gcc.dg/torture/pr58955-2.c when built with AVX512
and --param=vect-partial-vector-usage=1.

PR middle-end/110237
* internal-fn.cc (expand_partial_load_optab_fn): Clear
MEM_EXPR and MEM_OFFSET.
(expand_partial_store_optab_fn): Likewise.

[Bug target/109253] libbpf: failed to find BTF info for global/extern symbol '__divdi3'

[shung-hsi.yu at suse dot com via Gcc-bugs]

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

--- Comment #5 from Shung-Hsi Yu  ---
any chance we will also have this fix in GCC 13?

[Bug middle-end/112733] [14 Regression] ICE: Segmentation fault in wide-int.cc during GIMPLE pass: sccp

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

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

--- Comment #13 from GCC Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:5c95bf945c632925efba86dd5dceccdb9da8884c

commit r14-5963-g5c95bf945c632925efba86dd5dceccdb9da8884c
Author: Jakub Jelinek 
Date:   Wed Nov 29 12:26:50 2023 +0100

fold-const: Fix up multiple_of_p [PR112733]

We ICE on the following testcase when wi::multiple_of_p is called on
widest_int 1 and -128 with UNSIGNED.  I still need to work on the
actual wide-int.cc issue, the latest patch attached to the PR regressed
bitint-{38,39}.c, so will need to debug that, but there is a clear bug
on the fold-const.cc side as well - widest_int is a signed representation
by definition, using UNSIGNED with it certainly doesn't match what was
intended, because -128 as the second operand effectively means unsigned
131072 bit 0xf80 integer, not the signed char -128
that appeared in the source.

In the INTEGER_CST case a few lines above this we already use
case INTEGER_CST:
  if (TREE_CODE (bottom) != INTEGER_CST || integer_zerop (bottom))
return false;
  return wi::multiple_of_p (wi::to_widest (top), wi::to_widest
(bottom),
SIGNED);
so I think using SIGNED with widest_int is best there (compared to the
other choices in the PR).

2023-11-29  Jakub Jelinek  

PR middle-end/112733
* fold-const.cc (multiple_of_p): Pass SIGNED rather than
UNSIGNED for wi::multiple_of_p on widest_int arguments.

* gcc.dg/pr112733.c: New test.

[Bug c/112761] Using incomplete array types in function prototypes doesn't work

[schwab--- via Gcc-bugs]

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

Andreas Schwab  changed:

   What|Removed |Added

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

--- Comment #1 from Andreas Schwab  ---
6.7.6.2#1 ... The element type shall not be an incomplete or function type.

[Bug driver/108865] gcc on Windows fails with Unicode path to source file

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

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

--- Comment #47 from GCC Commits  ---
The releases/gcc-13 branch has been updated by Jonathan Yong
:

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

commit r13-8107-g19da6d2d0048eb6a260a5cf8af707cb455848bfb
Author: Costas Argyris 
Date:   Mon Nov 20 17:58:16 2023 +

mingw: Exclude utf8 manifest [PR70, PR108865]

Make the utf8 manifest optional (on by default and
explicitly off with --disable-win32-utf8-manifest)
in the mingw hosts.

Also eliminate duplication between the 32-bit and
64-bit mingw hosts by putting them both in the
same branch and special-case only the 64-bit long
long setting.

PR mingw/70
PR mingw/108865

Signed-off-by: Costas Argyris 
Signed-off-by: Jonathan Yong <10wa...@gmail.com>

gcc/Changelog:

* configure.ac: Handle new --enable-win32-utf8-manifest
option.
* config.host: allow win32 utf8 manifest to be disabled
by user.
* configure: Regenerate.

(cherry picked from commit 4f1ebd54380e16927cd0085be939165870354eac)

[Bug target/111170] [13/14 regression] Malformed manifest does not allow to run gcc on Windows XP (Accessing a corrupted shared library) since r13-6552-gd11e088210a551

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

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

--- Comment #15 from GCC Commits  ---
The releases/gcc-13 branch has been updated by Jonathan Yong
:

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

commit r13-8107-g19da6d2d0048eb6a260a5cf8af707cb455848bfb
Author: Costas Argyris 
Date:   Mon Nov 20 17:58:16 2023 +

mingw: Exclude utf8 manifest [PR70, PR108865]

Make the utf8 manifest optional (on by default and
explicitly off with --disable-win32-utf8-manifest)
in the mingw hosts.

Also eliminate duplication between the 32-bit and
64-bit mingw hosts by putting them both in the
same branch and special-case only the 64-bit long
long setting.

PR mingw/70
PR mingw/108865

Signed-off-by: Costas Argyris 
Signed-off-by: Jonathan Yong <10wa...@gmail.com>

gcc/Changelog:

* configure.ac: Handle new --enable-win32-utf8-manifest
option.
* config.host: allow win32 utf8 manifest to be disabled
by user.
* configure: Regenerate.

(cherry picked from commit 4f1ebd54380e16927cd0085be939165870354eac)

[Bug c/112761] New: Using incomplete array types in function prototypes doesn't work

[ville.syrjala at linux dot intel.com via Gcc-bugs]

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

Bug ID: 112761
   Summary: Using incomplete array types in function prototypes
doesn't work
   Product: gcc
   Version: 13.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ville.syrjala at linux dot intel.com
  Target Milestone: ---

struct foo;

void func(struct foo bar[]);

int main(void)
{
}

error: array type has incomplete element type ‘struct foo’
3 | void func(struct foo bar[]);
  |  ^~~

This prevents using the array syntax in function prototypes with opaque types.
So I have to give up either:
- the array syntax, which means there is no longer any hint to the reader
whether the function takes an array or a pointer to a single object
- or the opaque type which is even worse since the clean abstraction is ruined
(not to mention the resulting stable ABI issues).

I couldn't immediately find anything in the spec that says this is illegal:
- "6.7.6.2 Array declarators ...
If the size is not present, the array type is an incomplete type."
- "6.7.6.3 Function declarators ...
If the function declarator is not part of a definition of that function,
parameters may have incomplete type and may use the [*] notation in their
sequences of declarator specifiers to specify variable length array types."

But maybe I just don't know how to read the spec correctly?

Side note:
This also affects the (arguably hideous) "ptr[static 1]" syntax which would be
beneficial to indicate that you can't pass in a null pointer. But I suppose
that one is explicitly forbidden by the spec since we do specify a size for the
"array" and thus it is not allowed to be an incomplete type.

[Bug c++/110734] Attributes cannot be applied to asm statements

[tanksherman27 at gmail dot com via Gcc-bugs]

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

--- Comment #7 from Julian Waters  ---
I have a new attribute proposed for asm declarations that fixes this issue, but
I need help from reviews to proceed with fixing up the patch properly

[Bug fortran/55824] [OOP] ICE with ALLOCATE and SOURCE= TRANSPOSE/RESHAPE

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

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

--- Comment #8 from Paul Thomas  ---
(In reply to Andrew Pinski from comment #7)
> Seems to be working in GCC 7+.

Hmmm! It seems to me to be broken from 7-branch through the current mainline.

Cheers

Paul

[Bug rtl-optimization/112760] [14 Regression] wrong code with -O2 -fno-dce -fno-guess-branch-probability -m8bit-idiv -mavx --param=max-cse-insns=0 and __builtin_add_overflow_p()

[ubizjak at gmail dot com via Gcc-bugs]

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

Uroš Bizjak  changed:

   What|Removed |Added

  Component|target  |rtl-optimization
   Last reconfirmed||2023-11-29
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Target Milestone|--- |14.0

--- Comment #2 from Uroš Bizjak  ---
With the original testcase, ce1 pass is if-converting:

   20: flags:CCZ=cmp(r110:SI,r111:SI)
  REG_DEAD r111:SI
  REG_DEAD r110:SI
   21: pc={(flags:CCZ==0)?L23:pc}
  REG_DEAD flags:CCZ
   39: NOTE_INSN_BASIC_BLOCK 5
   22: r103:HI=0x1
   23: L23:

with:

IF-THEN-JOIN block found, pass 2, test 2, then 5, join 6
scanning new insn with uid = 45.
scanning new insn with uid = 44.
scanning new insn with uid = 46.
if-conversion succeeded through noce_try_cmove
Removing jump 21.
deleting insn with uid = 21.
deleting insn with uid = 22.

to:

   20: flags:CCZ=cmp(r110:SI,r111:SI)
  REG_DEAD r111:SI
  REG_DEAD r110:SI
   45: r118:HI=0x1
   44: flags:CCZ=cmp(r110:SI,r111:SI)
   46: r103:HI={(flags:CCZ==0)?r103:HI:r118:HI}

And things go downhill from here. Before postreload we have:

   20: flags:CCZ=cmp(ax:SI,dx:SI)
  REG_UNUSED flags:CCZ
   44: flags:CCZ=cmp(ax:SI,dx:SI)
  REG_DEAD dx:SI
  REG_DEAD ax:SI
   62: ax:HI=0x1
  REG_EQUIV 0x1
   46: bx:HI={(flags:CCZ==0)?bx:HI:ax:HI}
  REG_DEAD flags:CCZ
  REG_DEAD ax:HI

and in posteload pass (insn 44) is removed:

   20: flags:CCZ=cmp(ax:SI,dx:SI)
  REG_UNUSED flags:CCZ
   62: ax:HI=0x1
  REG_EQUIV 0x1
   46: bx:HI={(flags:CCZ==0)?bx:HI:ax:HI}
  REG_DEAD flags:CCZ
  REG_DEAD ax:HI

here comes pro_and_epilogue pass that detects "unused" (insn 20) and removes
it:

df_analyze called
deleting insn with uid = 20.

Confirmed as RTL optimization problem.

[Bug c++/110734] Attributes cannot be applied to asm statements

[tanksherman27 at gmail dot com via Gcc-bugs]

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

Julian Waters  changed:

   What|Removed |Added

 CC||tanksherman27 at gmail dot com

--- Comment #6 from Julian Waters  ---
Created attachment 56717
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56717=edit
Attribute for asm declarations

[Bug fortran/102689] Segfault with RESHAPE of CLASS as actual argument

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

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

Paul Thomas  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-11-29
 CC||pault at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Paul Thomas  ---
Confirmed!

implicit none (type, external)
type t
  integer :: i
end type t
integer :: j
integer :: src(100) = [(j, j=1,100)]
class(t), allocatable :: B(:,:,:), D(:)
allocate(t :: B(10,10,1))
B(:,:,:)%i = RESHAPE(src, shape(B))
D = reshape(B, [100])
call class_bar(D)

contains

subroutine class_bar(x)
  class(t), intent(in) :: x(:)
  integer :: k
  if (any (x(:)%i /= [(k, k=1,100)])) error stop 1
end
end

Works as intended. Inspection of the original code reveals:
  atmp.19.dtype = {.elem_len=4, .rank=1, .type=5};
  atmp.19.dim[0].stride = 1;
  atmp.19.dim[0].lbound = 0;
  atmp.19.dim[0].ubound = 99;
  atmp.19.span = 4;
  atmp.19.data = (void * restrict) 
  atmp.19.offset = 0;
  _gfortran_reshape (, D.4442, D.4451, 0B, 0B);
  class_bar (atmp.19);

ie. The class formal argument is being fed an array descriptor. This is a
problem with gfc_conv_procedure_call.

The discussion about inlining or not is for another day :-)

Thanks for the report, Tobias.

Paul

[Bug target/111170] [13/14 regression] Malformed manifest does not allow to run gcc on Windows XP (Accessing a corrupted shared library) since r13-6552-gd11e088210a551

[costas.argyris at gmail dot com via Gcc-bugs]

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

--- Comment #14 from Costas Argyris  ---
(In reply to Eric Botcazou from comment #13)
> Thanks for the fix.  Now it needs to be backported onto the 13 branch.

Just sent email about it.

[Bug middle-end/112560] [14 Regression] ICE in try_combine on pr112494.c

[ubizjak at gmail dot com via Gcc-bugs]

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

Uroš Bizjak  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #4 from Uroš Bizjak  ---
Patch at [1].

[1] https://gcc.gnu.org/pipermail/gcc-patches/2023-November/638589.html

[Bug target/112431] RISC-V GCC-15 feature: Support register overlap on widen RVV instructions

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

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

--- Comment #4 from GCC Commits  ---
The master branch has been updated by Pan Li :

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

commit r14-5960-gbdad036da32f72b84a96070518e7d75c21706dc2
Author: Juzhe-Zhong 
Date:   Wed Nov 29 16:34:10 2023 +0800

RISC-V: Support highpart register overlap for vwcvt

Since Richard supports register filters recently, we are able to support
highpart register
overlap for widening RVV instructions.

This patch support it for vwcvt intrinsics.

I leverage real application user codes for vwcvt:
https://github.com/riscv/riscv-v-spec/issues/929
https://godbolt.org/z/xoeGnzd8q

This is the real application codes that using LMUL = 8 with unrolling to
gain optimal
performance for specific libraury.

You can see in the codegen, GCC has optimal codegen for such since we
supported register
lowpart overlap for narrowing instructions (dest EEW < source EEW).

Now, we start to support highpart register overlap from this patch for
widening instructions (dest EEW > source EEW).

Leverage this intrinsic codes above but for vwcvt:

https://godbolt.org/z/1TMPE5Wfr

size_t
foo (char const *buf, size_t len)
{
  size_t sum = 0;
  size_t vl = __riscv_vsetvlmax_e8m8 ();
  size_t step = vl * 4;
  const char *it = buf, *end = buf + len;
  for (; it + step <= end;)
{
  vint8m4_t v0 = __riscv_vle8_v_i8m4 ((void *) it, vl);
  it += vl;
  vint8m4_t v1 = __riscv_vle8_v_i8m4 ((void *) it, vl);
  it += vl;
  vint8m4_t v2 = __riscv_vle8_v_i8m4 ((void *) it, vl);
  it += vl;
  vint8m4_t v3 = __riscv_vle8_v_i8m4 ((void *) it, vl);
  it += vl;

  asm volatile("nop" ::: "memory");
  vint16m8_t vw0 = __riscv_vwcvt_x_x_v_i16m8 (v0, vl);
  vint16m8_t vw1 = __riscv_vwcvt_x_x_v_i16m8 (v1, vl);
  vint16m8_t vw2 = __riscv_vwcvt_x_x_v_i16m8 (v2, vl);
  vint16m8_t vw3 = __riscv_vwcvt_x_x_v_i16m8 (v3, vl);

  asm volatile("nop" ::: "memory");
  size_t sum0 = __riscv_vmv_x_s_i16m8_i16 (vw0);
  size_t sum1 = __riscv_vmv_x_s_i16m8_i16 (vw1);
  size_t sum2 = __riscv_vmv_x_s_i16m8_i16 (vw2);
  size_t sum3 = __riscv_vmv_x_s_i16m8_i16 (vw3);

  sum += sumation (sum0, sum1, sum2, sum3);
}
  return sum;
}

Before this patch:

...
csrrt0,vlenb
...
vwcvt.x.x.v v16,v8
vwcvt.x.x.v v8,v28
vs8r.v  v16,0(sp)   ---> spill
vwcvt.x.x.v v16,v24
vwcvt.x.x.v v24,v4
nop
vsetvli zero,zero,e16,m8,ta,ma
vmv.x.s a2,v16
vl8re16.v   v16,0(sp)  --->  reload
...
csrrt0,vlenb
...

You can see heavy spill && reload inside the loop body.

After this patch:

...
vwcvt.x.x.v v8,v12
vwcvt.x.x.v v16,v20
vwcvt.x.x.v v24,v28
vwcvt.x.x.v v0,v4
...

Optimal codegen after this patch.

Tested on zvl128b no regression.

I am gonna to test zve64d/zvl256b/zvl512b/zvl1024b.

Ok for trunk if no regression on the testing above ?

Co-authored-by: kito-cheng 
Co-authored-by: kito-cheng 

PR target/112431

gcc/ChangeLog:

* config/riscv/constraints.md (TARGET_VECTOR ? V_REGS : NO_REGS):
New register filters.
* config/riscv/riscv.md (no,W21,W42,W84,W41,W81,W82): Ditto.
(no,yes): Ditto.
* config/riscv/vector.md: Support highpart register overlap for
vwcvt.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/base/pr112431-1.c: New test.
* gcc.target/riscv/rvv/base/pr112431-2.c: New test.
* gcc.target/riscv/rvv/base/pr112431-3.c: New test.

[Bug testsuite/112728] gcc.dg/scantest-lto.c FAILs

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

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

--- Comment #2 from GCC Commits  ---
The master branch has been updated by Rainer Orth :

https://gcc.gnu.org/g:77f713a64aead2bcc68567de8431bdb67cb6b196

commit r14-5959-g77f713a64aead2bcc68567de8431bdb67cb6b196
Author: Rainer Orth 
Date:   Wed Nov 29 10:29:50 2023 +0100

testsuite: Handle double-quoted LTO section names [PR112728]

The gcc.dg/scantest-lto.c test FAILs on Solaris/SPARC with the native as:

FAIL: gcc.dg/scantest-lto.c scan-assembler-not ascii
FAIL: gcc.dg/scantest-lto.c scan-assembler-times ascii 0

It requires double-quoting the section name which scanasm.exp doesn't
allow for.

This patch fixes that.

Tested on sparc-sun-solaris2.11 (as and gas) and i386-pc-solaris2.11 (as
and gas).

2023-11-23  Rainer Orth  

gcc/testsuite:
PR testsuite/112728
* lib/scanasm.exp (dg-scan): Allow for double-quoted LTO section
names.
(scan-assembler-times): Likewise.
(scan-assembler-dem-not): Likewise.

[Bug middle-end/112733] [14 Regression] ICE: Segmentation fault in wide-int.cc during GIMPLE pass: sccp

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

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

--- Comment #12 from Jakub Jelinek  ---
The #c11 patch regresses gcc.dg/bitint-3{8,9}.c tests (and apparently it is
just the 1st and/or 6th hunk where I've tried to make the XALLOCAVEC
allocations smaller; the rest of the changes seem to work ok.

[Bug target/112725] [14 Regression] powerpc64le-linux-gnu: 'c-c++-common/builtin-classify-type-1.c:113:3: error: AltiVec argument passed to unprototyped function'

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

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

--- Comment #4 from Kewen Lin  ---
(In reply to Jakub Jelinek from comment #3)
> Agreed, so like this?

Yes, thanks for the prompt fix!  The rs6000 part is OK for trunk!

> 2023-11-29  Jakub Jelinek  
> 
>   PR target/112725
>   * config/rs6000/rs6000.cc (invalid_arg_for_unprototyped_fn): Return
>   NULL for __builtin_classify_type calls with vector arguments.
>   * config/s390/s390.cc (s390_invalid_arg_for_unprototyped_fn):
>   Likewise.
> 
> --- gcc/config/rs6000/rs6000.cc.jj2023-11-17 15:08:20.816961466 +0100
> +++ gcc/config/rs6000/rs6000.cc   2023-11-29 09:40:35.782955603 +0100
> @@ -24389,7 +24389,8 @@ invalid_arg_for_unprototyped_fn (const_t
> && VECTOR_TYPE_P (TREE_TYPE (val))
>&& (funcdecl == NULL_TREE
>|| (TREE_CODE (funcdecl) == FUNCTION_DECL
> -  && DECL_BUILT_IN_CLASS (funcdecl) != BUILT_IN_MD)))
> +  && DECL_BUILT_IN_CLASS (funcdecl) != BUILT_IN_MD
> +  && !fndecl_built_in_p (funcdecl,
> BUILT_IN_CLASSIFY_TYPE
> ? N_("AltiVec argument passed to unprototyped function")
> : NULL;
>  }
> --- gcc/config/s390/s390.cc.jj2023-11-27 17:34:25.684287136 +0100
> +++ gcc/config/s390/s390.cc   2023-11-29 09:41:08.569491077 +0100
> @@ -12650,7 +12650,8 @@ s390_invalid_arg_for_unprototyped_fn (co
>  && VECTOR_TYPE_P (TREE_TYPE (val))
>  && (funcdecl == NULL_TREE
>  || (TREE_CODE (funcdecl) == FUNCTION_DECL
> -&& DECL_BUILT_IN_CLASS (funcdecl) != BUILT_IN_MD)))
> +&& DECL_BUILT_IN_CLASS (funcdecl) != BUILT_IN_MD
> +&& !fndecl_built_in_p (funcdecl, BUILT_IN_CLASSIFY_TYPE
> ? N_("vector argument passed to unprototyped function")
> : NULL);
>  }

[Bug target/112725] [14 Regression] powerpc64le-linux-gnu: 'c-c++-common/builtin-classify-type-1.c:113:3: error: AltiVec argument passed to unprototyped function'

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  ---
Agreed, so like this?
2023-11-29  Jakub Jelinek  

PR target/112725
* config/rs6000/rs6000.cc (invalid_arg_for_unprototyped_fn): Return
NULL for __builtin_classify_type calls with vector arguments.
* config/s390/s390.cc (s390_invalid_arg_for_unprototyped_fn):
Likewise.

--- gcc/config/rs6000/rs6000.cc.jj  2023-11-17 15:08:20.816961466 +0100
+++ gcc/config/rs6000/rs6000.cc 2023-11-29 09:40:35.782955603 +0100
@@ -24389,7 +24389,8 @@ invalid_arg_for_unprototyped_fn (const_t
  && VECTOR_TYPE_P (TREE_TYPE (val))
   && (funcdecl == NULL_TREE
   || (TREE_CODE (funcdecl) == FUNCTION_DECL
-  && DECL_BUILT_IN_CLASS (funcdecl) != BUILT_IN_MD)))
+  && DECL_BUILT_IN_CLASS (funcdecl) != BUILT_IN_MD
+  && !fndecl_built_in_p (funcdecl, BUILT_IN_CLASSIFY_TYPE
  ? N_("AltiVec argument passed to unprototyped function")
  : NULL;
 }
--- gcc/config/s390/s390.cc.jj  2023-11-27 17:34:25.684287136 +0100
+++ gcc/config/s390/s390.cc 2023-11-29 09:41:08.569491077 +0100
@@ -12650,7 +12650,8 @@ s390_invalid_arg_for_unprototyped_fn (co
   && VECTOR_TYPE_P (TREE_TYPE (val))
   && (funcdecl == NULL_TREE
   || (TREE_CODE (funcdecl) == FUNCTION_DECL
-  && DECL_BUILT_IN_CLASS (funcdecl) != BUILT_IN_MD)))
+  && DECL_BUILT_IN_CLASS (funcdecl) != BUILT_IN_MD
+  && !fndecl_built_in_p (funcdecl, BUILT_IN_CLASSIFY_TYPE
  ? N_("vector argument passed to unprototyped function")
  : NULL);
 }

[Bug target/112725] [14 Regression] powerpc64le-linux-gnu: 'c-c++-common/builtin-classify-type-1.c:113:3: error: AltiVec argument passed to unprototyped function'

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

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

Kewen Lin  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 CC||bergner at gcc dot gnu.org,
   ||g...@the-meissners.org,
   ||linkw at gcc dot gnu.org,
   ||segher at gcc dot gnu.org
   Last reconfirmed||2023-11-29
 Ever confirmed|0   |1

--- Comment #2 from Kewen Lin  ---
Confirmed, thanks for reporting.

It looks we need to special-case __builtin_classify_type in the hook
invalid_arg_for_unprototyped_fn, the __builtin_classify_type invocation will
conclude to be a integer in the end, so no actual call.

[Bug bootstrap/111601] [14 Regression] profilebootstrap fails in stagestrain in libcody on x86_64-linux-gnu and powerpc64le-linux-gnu

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Priority|P3  |P1

--- Comment #26 from Jakub Jelinek  ---
Fixed now.

[Bug bootstrap/111601] [14 Regression] profilebootstrap fails in stagestrain in libcody on x86_64-linux-gnu and powerpc64le-linux-gnu

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

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

--- Comment #25 from GCC Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:9582538cf07d83d7e80553827de8b0f91e4705d8

commit r14-5955-g9582538cf07d83d7e80553827de8b0f91e4705d8
Author: Jakub Jelinek 
Date:   Wed Nov 29 09:14:03 2023 +0100

fold-mem-offsets: Fix powerpc64le-linux profiledbootstrap [PR111601]

The introduction of the fold-mem-offsets pass breaks profiledbootstrap
on powerpc64le-linux.
From what I can see, the pass works one basic block at a time and
will punt on any non-DEBUG_INSN uses outside of the current block
(I believe because of the
  /* This use affects instructions outside of CAN_FOLD_INSNS.  */
  if (!bitmap_bit_p (_fold_insns, INSN_UID (use)))
return 0;
test and can_fold_insns only set in do_analysis (when processing insns in
current bb, cleared at the end) or results of get_single_def_in_bb
(which are checked to be in the same bb).
But, while get_single_def_in_bb checks for
  if (DF_INSN_LUID (def) > DF_INSN_LUID (insn))
return NULL;
The basic block in the PR in question has:
...
(insn 212 210 215 25 (set (mem/f:DI (reg/v/f:DI 10 10 [orig:152 last_viable
] [152]) [2 *last_viable_336+0 S8 A64])
(reg/f:DI 9 9 [orig:155 _342 ] [155])) "pr111601.ii":50:17 683
{*movdi_internal64}
 (expr_list:REG_DEAD (reg/v/f:DI 10 10 [orig:152 last_viable ] [152])
(nil)))
(insn 215 212 484 25 (set (reg:DI 5 5 [226])
(const_int 0 [0])) "pr111601.ii":52:12 683 {*movdi_internal64}
 (expr_list:REG_EQUIV (const_int 0 [0])
(nil)))
(insn 484 215 218 25 (set (reg/v/f:DI 10 10 [orig:152 last_viable ] [152])
(reg/f:DI 9 9 [orig:155 _342 ] [155])) "pr111601.ii":52:12 683
{*movdi_internal64}
 (nil))
...
(insn 564 214 216 25 (set (reg/v/f:DI 10 10 [orig:152 last_viable ] [152])
(plus:DI (reg/v/f:DI 10 10 [orig:152 last_viable ] [152])
(const_int 96 [0x60]))) "pr111601.ii":52:12 66 {*adddi3}
 (nil))
(insn 216 564 219 25 (set (mem/f:DI (reg/v/f:DI 10 10 [orig:152 last_viable
] [152]) [2 _343->next+0 S8 A64])
(reg:DI 5 5 [226])) "pr111601.ii":52:12 683 {*movdi_internal64}
 (expr_list:REG_DEAD (reg:DI 5 5 [226])
(nil)))
...
and when asking for all uses of %r10 from def 564, it will see uses
in 216 and 212; the former is after the += 96 addition and gets changed
to load from %r10+96 with the addition being dropped, but there is
the other store which is a use across the backedge and when reached
from other edges certainly doesn't have the + 96 addition anywhere,
so the pass doesn't actually change that location.

This patch adds checks from get_single_def_in_bb to get_uses as well,
in particular check that the (regular non-debug) use only appears in the
same basic block as the definition and that it doesn't appear before it
(i.e.
use across backedge).

2023-11-29  Jakub Jelinek  

PR bootstrap/111601
* fold-mem-offsets.cc (get_uses): Ignore DEBUG_INSN uses. 
Otherwise,
punt if use is in a different basic block from INSN or appears
before
INSN in the same basic block.  Formatting fixes.
(get_single_def_in_bb): Formatting fixes.
(fold_offsets_1, pass_fold_mem_offsets::execute): Comment
formatting
fixes.

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

[Bug target/112760] [14 Regression] wrong code with -O2 -fno-dce -fno-guess-branch-probability -m8bit-idiv -mavx --param=max-cse-insns=0 and __builtin_add_overflow_p()

[zsojka at seznam dot cz via Gcc-bugs]

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

--- Comment #1 from Zdenek Sojka  ---
Created attachment 56716
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56716=edit
more complex testcase, with less compiler flags

Attached a testcase that needs only -O2 -mavx; might be a different issue,
though.

$ x86_64-pc-linux-gnu-gcc -m32 -O2 -mavx testcase.c
$ ./a.out 
Aborted


$ diff -u a-testcase.GOOD.s a-testcase.BAD.s 
--- a-testcase.GOOD.s   2023-11-29 08:53:43.058791568 +0100
+++ a-testcase.BAD.s2023-11-29 08:52:39.878792460 +0100
@@ -4,7 +4,7 @@
 #  compiled by GNU C version 14.0.0 20231128 (experimental), GMP version
6.3.0, MPFR version 4.2.1, MPC version 1.3.1, isl version isl-0.26-GMP

 # GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
-# options passed: -m32 -masm=intel -mtune=generic -march=x86-64 -O2
+# options passed: -m32 -mavx -masm=intel -mtune=generic -march=x86-64 -O2
.text
.p2align 4
.globl  foo0
@@ -37,19 +37,19 @@
rol ax, 8   # _5,
 # testcase.c:11:   u64 u64_1 = __builtin_bswap16 (SHL (u64_0, u8_0)) % u16_0;
div bx  # u16_0
-# testcase.c:12:   u8 u8_1 = __builtin_add_overflow_p (u8_0, u8_0, u8_0);
-   mov eax, ecx# u8_0, u8_0
 # testcase.c:13:   u32 u32_1 = foo0_u32_0 & u16_0;
movzx   ebx, bx # u16_0, u16_0
 # testcase.c:12:   u8 u8_1 = __builtin_add_overflow_p (u8_0, u8_0, u8_0);
-   add al, cl  # u8_0, u8_0
+   add al, al  # u8_0, u8_0
+# testcase.c:14:   u32 u32_2 = __builtin_sub_overflow_p (0, u64_1, (u8) 0);
+   movzx   edx, dx # _6, tmp127
+# testcase.c:12:   u8 u8_1 = __builtin_add_overflow_p (u8_0, u8_0, u8_0);
setcal  #, _15
 # testcase.c:14:   u32 u32_2 = __builtin_sub_overflow_p (0, u64_1, (u8) 0);
xor ecx, ecx# tmp133
 # testcase.c:13:   u32 u32_1 = foo0_u32_0 & u16_0;
and ebx, DWORD PTR foo0_u32_0   # u32_1, foo0_u32_0
 # testcase.c:14:   u32 u32_2 = __builtin_sub_overflow_p (0, u64_1, (u8) 0);
-   movzx   edx, dx # _6, tmp127
sub ecx, edx# tmp132, _6
setbdl  #, _18
and ecx, -256   # tmp132,

Here, the problem is with:
# testcase.c:12:   u8 u8_1 = __builtin_add_overflow_p (u8_0, u8_0, u8_0);
add al, al  # u8_0, u8_0

due to the:
-# testcase.c:12:   u8 u8_1 = __builtin_add_overflow_p (u8_0, u8_0, u8_0);
-   mov eax, ecx# u8_0, u8_0

there is no "u8_0" in eax

Maybe the compiler tries to use an AVX instruction, that is in the end not
generated?