[Bug tree-optimization/114476] [13/14 Regression] wrong code with -fwrapv -O3 -fno-vector-cost-mode (and -march=armv9-a+sve2 on aarch64 and -march=rv64gcv on riscv)

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

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #3)
> Here is a testcase where we don't need -fwrapv:
Ignore that, I was doing something wrong.

[Bug libstdc++/114477] New: The user-defined constructor of filter_view::iterator is not fully compliant with the standard

[hewillk at gmail dot com via Gcc-bugs]

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

Bug ID: 114477
   Summary: The user-defined constructor of filter_view::iterator
is not fully compliant with the standard
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hewillk at gmail dot com
  Target Milestone: ---

Since P3059R0 is closed (although I feel bad about this), this suggests that
libstdc++ may need to modify the user-defined constructor of
filter_view::iterator:

  #include 
  auto base = std::views::iota(0);
  auto filter = base | std::views::filter([](int) { return true; });
  auto begin = decltype(filter.begin())(filter, base.begin()); // should ok

https://godbolt.org/z/T7nY68rej

[Bug tree-optimization/114476] [13/14 Regression] wrong code with -fwrapv -O3 -fno-vector-cost-mode (and -march=armv9-a+sve2 on aarch64 and -march=rv64gcv on riscv)

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

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

--- Comment #3 from Andrew Pinski  ---
Here is a testcase where we don't need -fwrapv:
```
signed int b = 9;
int c[23][23];
signed int d[23];
int main() {
  for (int h = 0; h < 23; h += 2) {
c[h][h] = d[h];
b= -b;
  }
  __builtin_printf("%u\n", b);
}

```

[Bug tree-optimization/114476] [13/14 Regression] wrong code with -fwrapv -O3 -fno-vector-cost-mode (and -march=armv9-a+sve2 on aarch64 and -march=rv64gcv on riscv)

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

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

--- Comment #2 from Andrew Pinski  ---
Note -fwrapv is important here ...

[Bug tree-optimization/114476] [13/14 Regression] wrong code with -fwrapv -O3 -fno-vector-cost-mode (and -march=armv9-a+sve2 on aarch64 and -march=rv64gcv on riscv)

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2024-03-26
  Component|target  |tree-optimization
 Ever confirmed|0   |1
  Known to fail||13.2.0
 Target|riscv*-*-*  |riscv*-*-* aarch64
   Keywords||needs-bisection
Summary|[14] RISC-V rv64gcv vector: |[13/14 Regression] wrong
   |Runtime mismatch at -O3 |code with -fwrapv -O3
   ||-fno-vector-cost-mode (and
   ||-march=armv9-a+sve2 on
   ||aarch64 and -march=rv64gcv
   ||on riscv)
 Status|UNCONFIRMED |NEW
   Target Milestone|--- |14.0
  Known to work||12.3.0

--- Comment #1 from Andrew Pinski  ---
Happens on aarch64 with `-march=armv9-a+sve2 -fno-vect-cost-model` even in GCC
13.2.0.

[Bug target/114476] New: [14] RISC-V rv64gcv vector: Runtime mismatch at -O3

[patrick at rivosinc dot com via Gcc-bugs]

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

Bug ID: 114476
   Summary: [14] RISC-V rv64gcv vector: Runtime mismatch at -O3
   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: ---

Testcase:
signed char b = 9;
int c[23][23];
signed char d[23];
int main() {
  for (int h = 0; h < 23; h += 2) {
c[h][h] = d[h];
b *= 255;
  }
  __builtin_printf("%u\n", b);
}

Commands:
> /scratch/tc-testing/tc-mar-25/build-rv64gcv/bin/riscv64-unknown-linux-gnu-gcc 
> -march=rv64gcv -O3 -fwrapv red.c -o red.out
> /scratch/tc-testing/tc-mar-25/build-rv64gcv/bin/qemu-riscv64 red.out
4294967287
> /scratch/tc-testing/tc-mar-25/build-rv64gcv/bin/riscv64-unknown-linux-gnu-gcc 
> -march=rv64gcv -O2 -fwrapv red.c -o red.out
> /scratch/tc-testing/tc-mar-25/build-rv64gcv/bin/qemu-riscv64 red.out
9

Discovered/tested using r14-9654-g78b56a12dd0 (not bisected)

Found via fuzzer.

[Bug rtl-optimization/951] Documentation of compiler passes and sources very out of date

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

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

Eric Gallager  changed:

   What|Removed |Added

URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2024-March/6
   ||48306.html
   Keywords||patch

--- Comment #12 from Eric Gallager  ---
Patch posted that might help with this a little bit:
https://gcc.gnu.org/pipermail/gcc-patches/2024-March/648306.html

[Bug tree-optimization/13756] [tree-ssa] documentation missing

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

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||patch
URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2024-March/6
   ||48306.html

--- Comment #19 from Eric Gallager  ---
Patch posted: https://gcc.gnu.org/pipermail/gcc-patches/2024-March/648306.html

[Bug c++/102660] Valid template default parameter of a friend function is rejected

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2024-03-26
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=85604
 Ever confirmed|0   |1

--- Comment #2 from Andrew Pinski  ---
Confirmed, the opposite issue is recorded in PR 85604 in that default arguments
should not be valid in friend template.

[Bug tree-optimization/114471] [14 regression] ICE when building liblc3-1.0.4 with -fno-vect-cost-model -march=x86-64-v4

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

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

--- Comment #6 from Hongtao Liu  ---
(In reply to Hongtao Liu from comment #5)
> Maybe we should always use kmask under AVX512, currently only >= 128-bits
> vector of vector _Float16 use kmask, < 128 bits vector still use vector mask.
> 
and we need to support vec_cmp/vcond_mask for 64/32/16-bit vectors.
For the testcase, there's no kmask used at all, why x86-64-v3 doesn't issue an
error.

[Bug tree-optimization/114471] [14 regression] ICE when building liblc3-1.0.4 with -fno-vect-cost-model -march=x86-64-v4

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

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

Hongtao Liu  changed:

   What|Removed |Added

 CC||liuhongt at gcc dot gnu.org

--- Comment #5 from Hongtao Liu  ---
Maybe we should always use kmask under AVX512, currently only >= 128-bits
vector of vector _Float16 use kmask, < 128 bits vector still use vector mask.

24628  /* Scalar mask case.  */
24629  if ((TARGET_AVX512F && TARGET_EVEX512 && vector_size == 64)
24630  || (TARGET_AVX512VL && (vector_size == 32 || vector_size == 16))
24631  /* AVX512FP16 only supports vector comparison
24632 to kmask for _Float16.  */
24633  || (TARGET_AVX512VL && TARGET_AVX512FP16
24634  && GET_MODE_INNER (data_mode) == E_HFmode))
24635{
24636  if (elem_size == 4
24637  || elem_size == 8
24638  || (TARGET_AVX512BW && (elem_size == 1 || elem_size == 2)))
24639return smallest_int_mode_for_size (nunits);
24640}
24641
24642  scalar_int_mode elem_mode
24643= smallest_int_mode_for_size (elem_size * BITS_PER_UNIT);
24644
24645  gcc_assert (elem_size * nunits == vector_size);
24646
24647  return mode_for_vector (elem_mode, nunits);

[Bug target/112919] LoongArch: Alignments in tune parameters are not precise and they regress performance

[chenglulu at loongson dot cn via Gcc-bugs]

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

--- Comment #17 from chenglulu  ---
(In reply to Xi Ruoyao from comment #15)
> > Hi，Ruoyao:
> > 
> >  The results of spec2006 on 3A6000 were obtained, I removed the more 
> > volatile
> > test items, '-falign-loops=8 -falign-functions=8 -falign-jumps=32
> > -falign-lables=4' this set of parameters got the highest score. This is the
> > same combination of parameters as the coremark tested by Xu Chenghua.
> > 
> > The test of the 3A5000 will also be completed around the 15th of this month,
> > so I want to change the code after the test results of the 3a5000 are out.
> > What do you think?
> 
> Ok to me.
> 
> I'm getting some different results on LA664:
> 
> 22031.284424 Compiler flags : -O2 -falign-labels=4 -falign-functions=8
> -falign-loops=8 -falign-jumps=32 -DPERFORMANCE_RUN=1 -lrt
> 
> vs the "best" one:
> 
> 22075.055188 Compiler flags : -O2 -falign-labels=4 -falign-functions=32
> -falign-loops=16 -falign-jumps=8 -DPERFORMANCE_RUN=1 -lrt
> 
> maybe such a 0.1% difference is some random fluctuation, or hardware or
> kernel configuration difference anyway.

The results of spec2006 on LA464 are:
-falign-labels=4 -falign-functions=32 -falign-loops=16 -falign-jumps=16

[Bug libfortran/107031] endfile truncates file at wrong position

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

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

--- Comment #9 from Jerry DeLisle  ---
The following trivial patch changes gfortran behavior and regression tests Ok
on x86_64.

I will see if I can come up with a test case to catch this.

diff --git a/libgfortran/io/file_pos.c b/libgfortran/io/file_pos.c
index 2bc05b293f8..d169961f997 100644
--- a/libgfortran/io/file_pos.c
+++ b/libgfortran/io/file_pos.c
@@ -352,7 +352,6 @@ st_endfile (st_parameter_filepos *fpp)
  dtp.common = fpp->common;
  memset (, 0, sizeof (dtp.u.p));
  dtp.u.p.current_unit = u;
- next_record (, 1);
}

   unit_truncate (u, stell (u->s), >common);

[Bug libfortran/107031] endfile truncates file at wrong position

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

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

Jerry DeLisle  changed:

   What|Removed |Added

 Status|WAITING |NEW
   Assignee|unassigned at gcc dot gnu.org  |jvdelisle at gcc dot 
gnu.org
 CC||jvdelisle at gcc dot gnu.org

--- Comment #8 from Jerry DeLisle  ---
Thankyou for information, I will take a look.

[Bug c++/100557] [11/12/13/14 Regression] Internal compiler error: Error reporting routines re-entered.

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #6 from Marek Polacek  ---
Fixed by Patrick's r14-3809.  I'll add the test; the patch was fixing a
different problem.

[Bug libfortran/107031] endfile truncates file at wrong position

[urbanjost at comcast dot net via Gcc-bugs]

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

urbanjost at comcast dot net changed:

   What|Removed |Added

 CC||urbanjost at comcast dot net

--- Comment #7 from urbanjost at comcast dot net ---
FYI:  A parallel discussion of this issue came to the consensus that the file
should be truncating to five lines, not six. The conversation included members
of the Fortran Standards Committee. 



https://fortran-lang.discourse.group/t/clarification-on-expected-behavior-of-endfile/

[Bug c++/114457] [C++26] P2795R5 - Erroneous behavior for uninitialized reads

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

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #2)
Well RTL might be already done via init-regs (but there was some movement on
removing that), see PR 61810 .

[Bug lto/113208] [14 Regression] lto1: error: Alias and target's comdat groups differs since r14-5979-g99d114c15523e0

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2024-03-25
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #20 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #19)
> I will redo the reduction to make sure it is valid.

I have not had the time to do the re-reduction. so I will let someone else
handle that if needed. Note it might be the case where we have ICF doing the
alias which causes the difference but I am not 100% sure there.

Anyways confirmed with my reduction with the soruces in comment #16, #17 and
#18.

[Bug target/114468] unixbench compilation performance results vary with different gcc compilers (r10-6804-g3133bed5d0327e)

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

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

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=26944

--- Comment #2 from Andrew Pinski  ---
Also one should note that register allocation is NP complete problem. So
obvious tuning heurstics for one case will most likely cause issues for others.

Also dhrystone benchmark is very much not a decent benchmark for real code.

[Bug fortran/114475] [14.0 Regression] Regression with iso_c_binding and submodules

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

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

--- Comment #1 from Jürgen Reuter  ---
I suspect this commit here,
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=44c0398e65347def316700911a51ca8b4ec0a411
but not totally certain.

[Bug tree-optimization/114464] [14 regression] ICE when building tdscpp-20240212

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

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

--- Comment #6 from Andrew Pinski  ---
(In reply to Xi Ruoyao from comment #4)
> Interestingly, this only happens when N % 16 == 0.

That depends on the target, for aarch64 (and arm with neon enabled), GCC ICEs
for all multiplies of 8, while x86_64 is multiples of 16.

[Bug tree-optimization/114464] [14 regression] ICE when building tdscpp-20240212

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 CC||pinskia at gcc dot gnu.org
 Ever confirmed|0   |1
   Last reconfirmed||2024-03-25
   Keywords||needs-bisection

--- Comment #5 from Andrew Pinski  ---
Better reduced testcase (removes the template and unused arguments):
```
void h(unsigned char *scratch, bool carry) {
  for (int i = 0; i < 16; i++) {
bool b = scratch[i] <<= 1;
if (carry)
  scratch[i] |= 1;
carry = b;
  }
}
```

[Bug fortran/114475] New: [14.0 Regression] Regression with iso_c_binding and submodules

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

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

Bug ID: 114475
   Summary: [14.0 Regression] Regression with iso_c_binding and
submodules
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: juergen.reuter at desy dot de
  Target Milestone: ---

Between ca. March 18 and March 25, a regression has been introduced into the
gfortran 14.0.1 code, which makes the following valid code fail to compile, cf.
below:
gfortran  -c t1.f90
t1.f90:28:13:

   28 | submodule (t1) t1_s
  | 1
Error: Variable ‘n_external’ cannot appear in the expression at (1)

It would be cool if that could be fixed before the release of gcc 14.1 which I
believe is very soon. 



module t1
  use, intrinsic :: iso_c_binding !NODEP!   
  implicit none
  private
  public :: t1_t
  integer :: N_EXTERNAL = 0

  type :: t1_t
  contains
procedure :: set_n_external => t1_set_n_external
  end type t1_t

  abstract interface
 subroutine ol_eval (id, pp, emitter) bind(C)
   import
   real(kind = c_double), intent(in) :: pp(5 * N_EXTERNAL)
 end subroutine ol_eval
  end interface
  interface
module subroutine t1_set_n_external (object, n)
  class(t1_t), intent(inout) :: object
  integer, intent(in) :: n
end subroutine t1_set_n_external
  end interface

end module t1

submodule (t1) t1_s
  implicit none
contains
  module subroutine t1_set_n_external (object, n)
class(t1_t), intent(inout) :: object
integer, intent(in) :: n
N_EXTERNAL = n
  end subroutine t1_set_n_external

end submodule t1_s

[Bug c/112571] [13 Regression] ICE with nested redefinition of enum

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

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

Joseph S. Myers  changed:

   What|Removed |Added

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

--- Comment #7 from Joseph S. Myers  ---
Fix now backported to GCC 13 branch, so fixed in 13.3 as well.

[Bug c/112571] [13 Regression] ICE with nested redefinition of enum

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

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

--- Comment #6 from GCC Commits  ---
The releases/gcc-13 branch has been updated by Joseph Myers
:

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

commit r13-8495-gf2af129b68bc6b20f79a9a44b28c96650baa702c
Author: Joseph Myers 
Date:   Wed Jan 31 21:39:53 2024 +

c: Fix ICE for nested enum redefinitions with/without fixed underlying type
[PR112571]

Bug 112571 reports an ICE-on-invalid for cases where an enum is
defined, without a fixed underlying type, inside the enum type
specifier for a definition of that same enum with a fixed underlying
type.

The ultimate cause is attempting to access ENUM_UNDERLYING_TYPE in a
case where it is NULL.  Avoid this by clearing
ENUM_FIXED_UNDERLYING_TYPE_P in thie case of inconsistent definitions.

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

(Note: for this GCC 13 branch backport, the tests were changed to use
-std=c2x not -std=c23, and c23-enum-9.c was changed to expect
different diagnostics because GCC 13 branch doesn't have the C23 tag
compatibility support for redefinitions of tagged types and
enumerators.)

PR c/112571

gcc/c/
* c-decl.cc (start_enum): Clear ENUM_FIXED_UNDERLYING_TYPE_P when
defining without a fixed underlying type an enumeration previously
declared with a fixed underlying type.

gcc/testsuite/
* gcc.dg/c23-enum-9.c, gcc.dg/c23-enum-10.c: New tests.

(cherry picked from commit d22d1a9346f27db41459738c6eb404f8f0956e6f)

[Bug tree-optimization/114471] [14 regression] ICE when building liblc3-1.0.4 with -fno-vect-cost-model -march=x86-64-v4

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |14.0
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Keywords||ice-on-valid-code,
   ||needs-bisection
   Last reconfirmed||2024-03-25

--- Comment #4 from Andrew Pinski  ---
A little cleaned up testcase which might show what can and cannot be SLP'ed:
```
float f1, f0, fa[2];
short sa[2];
void quantize(short s0) {
  _Bool ta[2] = {(fa[0] < 0), (fa[1] < 0)};
  _Bool t = ((s0 > 0) & ta[0]);
  short x1 = s0 + t;
  _Bool t1 = ((x1 > 0) & ta[1]);
  sa[0] = x1;
  sa[1] = s0 + t1;
}
```

Confirmed.

[Bug c++/114349] [14 regression] ICE when building qtwebengine with -std=gnu++14 (cxx_eval_call_expression, at cp/constexpr.cc:3027)

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #7 from Marek Polacek  ---
Fixed.

[Bug c/92875] GCC ignores the floating-point 'f' suffix in C11 mode

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #11 from Andrew Pinski  ---
Invalid as explained

[Bug middle-end/114347] wrong constant folding when casting __bf16 to int

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #13 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #11)
> This is also true for similar case for 32bit x86 (without using SSE) and
> constants ending in f or other floating point constants. Just folks hit it
> there as much as that is not used as much either.

In fact that is recorded as PR 92875 :).

The constant handling is correct here (and there too).

So closing as invalid.

[Bug c++/114349] [14 regression] ICE when building qtwebengine with -std=gnu++14 (cxx_eval_call_expression, at cp/constexpr.cc:3027)

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

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

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

https://gcc.gnu.org/g:8651991fe2ea90a7276e91673b15b5c3865f14d7

commit r14-9659-g8651991fe2ea90a7276e91673b15b5c3865f14d7
Author: Marek Polacek 
Date:   Fri Mar 15 09:23:28 2024 -0400

c++: ICE with noexcept and local specialization, again [PR114349]

Patrick noticed that my r14-9339-gdc6c3bfb59baab patch is wrong;
we're dealing with a noexcept-spec there, not a noexcept-expr, so
setting cp_noexcept_operand et al is incorrect.  Back to the drawing
board then.

To fix noexcept84.C, we should probably avoid doing push_to_top_level
in certain cases.  maybe_push_to_top_level didn't work here as-is, so
I changed it to not push to top level if decl_function_context is
non-null, when we are not dealing with a lambda.

This also fixes c++/114349, introduced by r14-9339.

PR c++/114349

gcc/cp/ChangeLog:

* name-lookup.cc (maybe_push_to_top_level): For a non-lambda,
don't push to top level if decl_function_context is non-null.
* pt.cc (maybe_instantiate_noexcept): Use maybe_push_to_top_level.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/noexcept85.C: New test.
* g++.dg/cpp0x/noexcept86.C: New test.

[Bug c++/114439] [14 Regression] icu4c-73.2 build failure: invalid initializer for array member with initialization of array of struct containing arrays since r14-9622

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #5 from Marek Polacek  ---
Fixed.

[Bug c++/114439] [14 Regression] icu4c-73.2 build failure: invalid initializer for array member with initialization of array of struct containing arrays since r14-9622

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

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

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

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

commit r14-9658-gde0886d48032332d10e4acb5d15c8789b281b6fe
Author: Marek Polacek 
Date:   Mon Mar 25 15:32:20 2024 -0400

c++: broken direct-init with trailing array member [PR114439]

can_init_array_with_p is wrongly saying that the init for 's' here:

  struct S {
int *list = arr;
int arr[];
  };

  struct A {
A() {}
S s[2]{};
  };

is invalid.  But as process_init_constructor_array says, for "non-constant
initialization of trailing elements with no explicit initializers" we use
a VEC_INIT_EXPR wrapped in a TARGET_EXPR, built in
process_init_constructor.

Unfortunately we didn't have a test for this scenario so I didn't
realize can_init_array_with_p must handle it.

PR c++/114439

gcc/cp/ChangeLog:

* init.cc (can_init_array_with_p): Return true for a VEC_INIT_EXPR
wrapped in a TARGET_EXPR.

gcc/testsuite/ChangeLog:

* g++.dg/init/array65.C: New test.

[Bug c/93410] [9 only] can't use _Decimal64 in C99/C11/C17 mode

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #4 from Andrew Pinski  ---
Fixed in GCC 10+.

[Bug c++/77384] Assembler error - std::forward(decimal64) already defined

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords|needs-bisection |
  Known to fail||4.5.3

--- Comment #6 from Andrew Pinski  ---
Reduced testcase that where the issue happens for both C++98 and C++11+:
```
#include 
template int f(T1) {}
using std::decimal::decimal64;
int t = f(1.5dd);
int t1 = f(decimal64(1.5dd));
```

[Bug target/104817] mips: ICE in mips_output_move, at config/mips/mips.cc:5323 with -fzero-call-used-regs=all

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

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

Xi Ruoyao  changed:

   What|Removed |Added

 CC||qing.zhao at oracle dot com

--- Comment #3 from Xi Ruoyao  ---
Hi Qing,

Any progress on the
https://gcc.gnu.org/pipermail/gcc-patches/2022-March/592002.html stuff?

We just got another complain about -fzero-call-used-regs= on mips today...
(PR114466) and let's make another try to solve it (maybe for GCC 15).

[Bug analyzer/114473] [13/14 Regression] ICE: in deref_rvalue, at analyzer/region-model.cc:2780 with -fanalyzer -fanalyzer-call-summaries

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

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

David Malcolm  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Priority|P3  |P1
   Last reconfirmed||2024-03-25
 Ever confirmed|0   |1

--- Comment #1 from David Malcolm  ---
Thanks for filing this bug.

Confirmed: https://godbolt.org/z/cbvjrnYzE

[Bug c++/77384] Assembler error - std::forward(decimal64) already defined

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to fail||5.5.0
  Known to work|5.5.0   |
Summary|[11/12/13/14 Regression]|Assembler error -
   |Assembler error -   |std::forward(decimal64)
   |std::forward(decimal64) |already defined
   |already defined |

--- Comment #5 from Andrew Pinski  ---
(In reply to Jonathan Wakely from comment #2)
> This only happens for C++11 and later.
> 
> Modified testcase that's valid in C++98 too:

Oh I missed that. GCC 6 changed the default :).

[Bug c++/77384] [11/12/13/14 Regression] Assembler error - std::forward(decimal64) already defined

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to work||5.5.0
   Keywords||ABI, needs-bisection
Summary|Assembler error -   |[11/12/13/14 Regression]
   |std::forward(decimal64) |Assembler error -
   |already defined |std::forward(decimal64)
   ||already defined

--- Comment #4 from Andrew Pinski  ---
Hmm, the reduced testcase in comment #2 used to work in GCC 5.5.0.

[Bug tree-optimization/114464] [14 regression] ICE when building tdscpp-20240212

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

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

Xi Ruoyao  changed:

   What|Removed |Added

 CC||xry111 at gcc dot gnu.org

--- Comment #4 from Xi Ruoyao  ---
Interestingly, this only happens when N % 16 == 0.

[Bug tree-optimization/114464] [14 regression] ICE when building tdscpp-20240212

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

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

--- Comment #3 from Sam James  ---
Reduced:
```
template  void double_to_int(double, unsigned char *scratch, bool carry)
{
  for (int i = 0; i < N; i++) {
bool b = scratch[i] <<= 1;
if (carry)
  scratch[i] |= 1;
carry = b;
  }
}
double bcp_row_data_d;
unsigned char bcp_row_data_ptr;
bool carry;
void bcp_row_data() { double_to_int<16>(bcp_row_data_d, _row_data_ptr,
carry); }
```

[Bug c++/110714] constexpr lifetime error: base class this pointer

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

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

Patrick Palka  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||ppalka at gcc dot gnu.org

--- Comment #6 from Patrick Palka  ---
For the original testcase, evaluation of pf->get_this(); yields  [0]
instead of  the expected , which we don't recognize as a valid constexpr
heap pointer thus leading to the error.

This heap[0] term gets built from cxx_fold_indirect_ref which folds '*(struct
Derived *) ' into 'heap[0]' (where 'heap' has type Derived[1]), which
doesn't seem like a sound transformation?  I'd expect it to get folded to
simply 'heap'.

Then again this intermediate (Derived *) cast seems unsound in the first place
since we're casting something of type Derived[1]* to Derived*.  I don't know
what to make of that.

[Bug fortran/114474] [11/12/13/14 Regression] DATA statement with derived type, pointer component rejected

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

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

--- Comment #1 from anlauf at gcc dot gnu.org ---
Might have been caused by the fix for pr67804 (r10-10418).

[Bug fortran/114467] f951: internal compiler error: Segmentation fault

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2024-03-25
 Ever confirmed|0   |1

--- Comment #1 from anlauf at gcc dot gnu.org ---
Can you attached a self-contained reproducer?

The traceback looks familiar.  Are you by chance using an associate
construct?  There has been a fix backported from 14-mainline to 13-branch
after the release of 13.2, so it might have been fixed in the meantime.

(Likely a dup of pr109948).

[Bug fortran/114474] [11/12/13/14 Regression] DATA statement with derived type, pointer component rejected

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||rejects-valid
  Known to fail||10.5.0, 11.4.1, 12.3.1,
   ||13.2.1, 14.0
   Priority|P3  |P4
  Known to work||7.5.0, 8.5.0, 9.5.0
   Target Milestone|--- |11.5

[Bug fortran/114474] New: [11/12/13/14 Regression] DATA statement with derived type, pointer component rejected

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

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

Bug ID: 114474
   Summary: [11/12/13/14 Regression] DATA statement with derived
type, pointer component rejected
   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 pr50410, I noticed that the following code works with
gfortran <= 9.5.0, but fails with 10.5.0 and higher:

program p
  implicit none
  integer, target :: zz = 42  ! initial data target
  type t
 integer, pointer :: h
  end type t
  type(t) :: x, y
  data x / t(null()) / ! OK
  data y / t(zz) / ! fails starting with gcc-10
  if (associated (y% h)) print *, y% h
end

This works with NAG and older gfortran and prints "42".

Current mainline gives:

pr50410_ctor.f90:9:13:

9 |   data y / t(zz) / ! fails starting with gcc-10
  | 1
Error: The element in the structure constructor at (1), for pointer component
'h', is PROCEDURE but should be INTEGER

[Bug c++/114393] [14 regression] over eager "invalid use of void expression" ? since r14-2170-g4cf64d9cc2faf4

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

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

Patrick Palka  changed:

   What|Removed |Added

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

[Bug c++/93595] [c++20] function call, substitution failure of template parameter with a lambda default in template context

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

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

Patrick Palka  changed:

   What|Removed |Added

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

[Bug tree-optimization/114465] "x % const1 % const2" should be optimized if const1 % const2 == 0

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2024-03-25
 Ever confirmed|0   |1

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

[Bug analyzer/114472] [14 Regression] ICE: in falls_short_of_p, at analyzer/store.cc:365 (in exceeds_p, at analyzer/store.cc:342) with -fanalyzer

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

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

David Malcolm  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Last reconfirmed||2024-03-25
   Priority|P3  |P1

--- Comment #1 from David Malcolm  ---
Thanks for filing this bug.

Confirmed: https://godbolt.org/z/5rnoW9a3a

[Bug analyzer/114473] New: [13/14 Regression] ICE: in deref_rvalue, at analyzer/region-model.cc:2780 with -fanalyzer -fanalyzer-call-summaries

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 114473
   Summary: [13/14 Regression] ICE: in deref_rvalue, at
analyzer/region-model.cc:2780 with -fanalyzer
-fanalyzer-call-summaries
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm 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 57814
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57814=edit
reduced testcase

Compiler output:
$ x86_64-pc-linux-gnu-gcc -fanalyzer -fanalyzer-call-summaries testcase.c 
during IPA pass: analyzer
testcase.c: In function 'foo':
testcase.c:26:3: internal compiler error: in deref_rvalue, at
analyzer/region-model.cc:2780
   26 |   bar (q);
  |   ^~~
0x8c5153 ana::region_model::deref_rvalue(ana::svalue const*, tree_node*,
ana::region_model_context*, bool) const
/repo/gcc-trunk/gcc/analyzer/region-model.cc:2780
0x28c742a ana::call_summary_replay::convert_region_from_summary(ana::region
const*)
/repo/gcc-trunk/gcc/analyzer/call-summary.cc:553
0x19c44ca ana::store::replay_call_summary_cluster(ana::call_summary_replay&,
ana::store const&, ana::region const*)
/repo/gcc-trunk/gcc/analyzer/store.cc:3338
0x19c4734 ana::store::replay_call_summary(ana::call_summary_replay&, ana::store
const&)
/repo/gcc-trunk/gcc/analyzer/store.cc:3318
0x197463b ana::region_model::replay_call_summary(ana::call_summary_replay&,
ana::region_model const&)
/repo/gcc-trunk/gcc/analyzer/region-model.cc:5635
0x19552db ana::program_state::replay_call_summary(ana::call_summary_replay&,
ana::program_state const&)
/repo/gcc-trunk/gcc/analyzer/program-state.cc:1635
0x193b6f3 ana::call_summary_edge_info::update_state(ana::program_state*,
ana::exploded_edge const*, ana::region_model_context*) const
/repo/gcc-trunk/gcc/analyzer/engine.cc:1633
0x193397a ana::exploded_graph::process_node(ana::exploded_node*)
/repo/gcc-trunk/gcc/analyzer/engine.cc:4241
0x193442a ana::exploded_graph::process_worklist()
/repo/gcc-trunk/gcc/analyzer/engine.cc:3516
0x1936b9b ana::impl_run_checkers(ana::logger*)
/repo/gcc-trunk/gcc/analyzer/engine.cc:6210
0x1937b66 ana::run_checkers()
/repo/gcc-trunk/gcc/analyzer/engine.cc:6308
0x1926458 execute
/repo/gcc-trunk/gcc/analyzer/analyzer-pass.cc:87
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-9652-20240325121350-gcf3fc6f414f-checking-yes-rtl-df-extra-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.1/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
--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 --enable-libsanitizer
--disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r14-9652-20240325121350-gcf3fc6f414f-checking-yes-rtl-df-extra-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.1 20240325 (experimental) (GCC)

[Bug analyzer/113314] [14 Regression] -Wanalyzer-infinite-loop false positive seen on haproxy's fd.c

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

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

--- Comment #3 from Andrew Pinski  ---
Note a volatile memory location change even without this being multi-threaded;
an async signal (USR1..USR4, or ALRM, etc.) could come in and change the value.

Or the memory could be shared memory between 2 different processes; though I
suspect in that case you want to use atomics.

[Bug analyzer/114472] New: [14 Regression] ICE: in falls_short_of_p, at analyzer/store.cc:365 (in exceeds_p, at analyzer/store.cc:342) with -fanalyzer

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 114472
   Summary: [14 Regression] ICE: in falls_short_of_p, at
analyzer/store.cc:365 (in exceeds_p, at
analyzer/store.cc:342) with -fanalyzer
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm 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 57813
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57813=edit
reduced testcase

Compiler output:
$ x86_64-pc-linux-gnu-gcc -fanalyzer testcase.c 
during IPA pass: analyzer
testcase.c: In function 'bar':
testcase.c:13:3: internal compiler error: in falls_short_of_p, at
analyzer/store.cc:365
   13 |   __builtin_strncpy(,  - 3, -1);
  |   ^
0x8ca06b
ana::bit_range::falls_short_of_p(generic_wide_int
>, ana::bit_range*) const
/repo/gcc-trunk/gcc/analyzer/store.cc:365
0x28c0d6e ana::region_model::check_region_bounds(ana::region const*,
ana::access_direction, ana::svalue const*, ana::region_model_context*) const
/repo/gcc-trunk/gcc/analyzer/bounds-checking.cc:1438
0x19622b9 ana::region_model::check_region_access(ana::region const*,
ana::access_direction, ana::svalue const*, ana::region_model_context*) const
/repo/gcc-trunk/gcc/analyzer/region-model.cc:3095
0x19622b9 ana::region_model::check_region_access(ana::region const*,
ana::access_direction, ana::svalue const*, ana::region_model_context*) const
/repo/gcc-trunk/gcc/analyzer/region-model.cc:3084
0x19622b9 ana::region_model::check_region_for_read(ana::region const*,
ana::region_model_context*) const
/repo/gcc-trunk/gcc/analyzer/region-model.cc:3129
0x19622b9 ana::region_model::check_region_for_read(ana::region const*,
ana::region_model_context*) const
/repo/gcc-trunk/gcc/analyzer/region-model.cc:3126
0x19622b9 ana::region_model::get_store_value(ana::region const*,
ana::region_model_context*) const
/repo/gcc-trunk/gcc/analyzer/region-model.cc:2690
0x19688d2 ana::region_model::get_store_value(ana::region const*,
ana::region_model_context*) const
/repo/gcc-trunk/gcc/analyzer/region-model.cc:2686
0x19688d2 ana::region_model::read_bytes(ana::region const*, tree_node*,
ana::svalue const*, ana::region_model_context*) const
/repo/gcc-trunk/gcc/analyzer/region-model.cc:4462
0x19688d2 ana::region_model::read_bytes(ana::region const*, tree_node*,
ana::svalue const*, ana::region_model_context*) const
/repo/gcc-trunk/gcc/analyzer/region-model.cc:4453
0x1945a2a update_model
/repo/gcc-trunk/gcc/analyzer/kf.cc:1609
0x193397a ana::exploded_graph::process_node(ana::exploded_node*)
/repo/gcc-trunk/gcc/analyzer/engine.cc:4241
0x193442a ana::exploded_graph::process_worklist()
/repo/gcc-trunk/gcc/analyzer/engine.cc:3516
0x1936b9b ana::impl_run_checkers(ana::logger*)
/repo/gcc-trunk/gcc/analyzer/engine.cc:6210
0x1937b66 ana::run_checkers()
/repo/gcc-trunk/gcc/analyzer/engine.cc:6308
0x1926458 execute
/repo/gcc-trunk/gcc/analyzer/analyzer-pass.cc:87
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-9652-20240325121350-gcf3fc6f414f-checking-yes-rtl-df-extra-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.1/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
--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 --enable-libsanitizer
--disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r14-9652-20240325121350-gcf3fc6f414f-checking-yes-rtl-df-extra-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.1 20240325 (experimental) (GCC)

[Bug target/88309] ICE: Floating point exception (in is_miss_rate_acceptable), target assigning alignent of 4 bits(!) to vector

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

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

--- Comment #2 from Andrew Pinski  ---
Note I scanned the sources of the rs6000 backend and I don't see where `user
align:4` would be happening. I might try to debug this later this week.

[Bug tree-optimization/114469] gcc.dg/torture/bitint-64.c failure with -O2 -flto -std=c23 -fwrapv

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

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

--- Comment #1 from Joseph S. Myers  ---
I'd expect _Atomic _BitInt(5) to follow the same ABI (regarding upper bits
being defined or not) as plain _BitInt(5), and any simplification needs to deal
with that.

(In principle for atomics with _BitInt with padding bits there are the same
concerns as for any types with padding bits - any compare-and-exchange loop
needs to succeed eventually when the underlying memory isn't being modified,
rather than failing in comparison of padding bits that might not have been
consistently loaded / preserved. My guess is this is unlikely to be a concern
in practice for _BitInt the way it is e.g. for x86 long double where the
padding bits only exist in memory and not in registers.)

[Bug tree-optimization/114465] "x % const1 % const2" should be optimized if const1 % const2 == 0

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

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

--- Comment #1 from Joseph S. Myers  ---
Note that transforming x % 1 % -1 to x % -1 wouldn't strictly be valid (because
of undefined behavior from INT_MIN % -1), though hopefully cases with constant
1 or -1 get optimized to 0 anyway and the undefined behavior is only a problem
with a -1 that's not a constant.

[Bug c++/114461] [C++26] P3034R1 - Disallow module declarations to be macros

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2024-03-25
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

[Bug c++/114461] [C++26] P3034R1 - Disallow module declarations to be macros

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

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

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

[Bug c++/114459] [C++26] P2893R3 - Variadic friends

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2024-03-25
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

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

[Bug c++/114458] [C++26] P2573R2 - = delete("reason");

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2024-03-25
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

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

[Bug c++/114462] [C++26] P2809R3 - Trivial infinite loops are not undefined behavior

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2024-03-25
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

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

[Bug c++/114457] [C++26] P2795R5 - Erroneous behavior for uninitialized reads

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
This might require both gimple and rtl changes.
Well

[Bug tree-optimization/114471] [14 regression] ICE when building liblc3-1.0.4 with -fno-vect-cost-model -march=x86-64-v4

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

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

--- Comment #3 from Sam James  ---
float quantize_x_1, quantize_x_0;
short *quantize_xq;
short quantize_x0;
void quantize() {
  short x1 = quantize_xq[0] =
  quantize_x0 + ((quantize_x0 > 0) & (quantize_x_0 < 0));
  quantize_xq[1] = 1 + ((x1 > 0) & (quantize_x_1 < 0));
}

[Bug c++/114462] [C++26] P2809R3 - Trivial infinite loops are not undefined behavior

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

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

--- Comment #5 from Jakub Jelinek  ---
constexpr bool foo () { return true; }
volatile int v;

void
bar (int x)
{
  switch (x)
{
case 0:
  while (foo ()) ;
  break;
case 1:
  while (foo ()) {}
  break;
case 2:
  do ; while (foo ());
  break;
case 3:
  do {} while (foo ());
  break;
case 4:
  do {} while (foo ());
  break;
case 5:
  for (v = 42; foo (); ) ;
  break;
case 6:
  for (v = 42; foo (); ) {}
  break;
case 7:
  for (int w = 42; foo (); ) ;
  break;
case 8:
  for (int w = 42; foo (); ) {}
  break;
default:
  break;
}
}

[Bug c++/114462] [C++26] P2809R3 - Trivial infinite loops are not undefined behavior

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

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

--- Comment #4 from Jakub Jelinek  ---
Ah, if there is a declaration in the condition, then it is not a valid trivial
empty iteration statement.

Anyway, I'd say cp_fold should for WHILE_STMT, DO_STMT and FOR_STMT if the body
is
a STATEMENT_LIST with no statements at all or an empty statement (do we have
predicate for NOP_EXPR to void_type_node of integer_zero_node?) and in case of
FOR_STMT empty increment expression argument try to evaluate the condition as
mce_false constant expression and if it evaluates to constant non-zero, replace
the condition with boolean_true_node.

[Bug c++/114457] [C++26] P2795R5 - Erroneous behavior for uninitialized reads

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2024-03-25

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

[Bug c++/114456] [C++26] P0609R3 - Attributes for structured bindings

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2024-03-25

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

[Bug c++/114458] [C++26] P2573R2 - = delete("reason");

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

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

--- Comment #1 from Jakub Jelinek  ---
Considering taking this for stage1 as well.

[Bug c++/114456] [C++26] P0609R3 - Attributes for structured bindings

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

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

--- Comment #1 from Jakub Jelinek  ---
I'll probably take this for stage1.

[Bug tree-optimization/114471] [14 regression] ICE when building liblc3-1.0.4 with -fno-vect-cost-model -march=x86-64-v4

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

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

--- Comment #2 from Sam James  ---
Created attachment 57812
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57812=edit
spec.i.orig.xz

[Bug tree-optimization/114471] [14 regression] ICE when building liblc3-1.0.4 with -fno-vect-cost-model -march=x86-64-v4

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

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

--- Comment #1 from Sam James  ---
The original failed with:
```
../liblc3-1.0.4/src/spec.c: In function ‘quantize’:
../liblc3-1.0.4/src/spec.c:210:21: error: type mismatch in binary expression
  210 | LC3_HOT static void quantize(enum lc3_dt dt, enum lc3_srate sr,
  | ^~~~
vector(2) 

vector(2) 

vector(2) 

mask_patt_142.112_162 = mask__23.109_158 & mask_patt_141.111_161;
during GIMPLE pass: vect
../liblc3-1.0.4/src/spec.c:210:21: internal compiler error: verify_gimple
failed
0x559439cc2712 verify_gimple_in_cfg(function*, bool, bool)
   
/usr/src/debug/sys-devel/gcc-14.0.1_pre20240324/gcc-14-20240324/gcc/tree-cfg.cc:5663
0x559439ad9a28 execute_function_todo
   
/usr/src/debug/sys-devel/gcc-14.0.1_pre20240324/gcc-14-20240324/gcc/passes.cc:2088
0x559439ad9c8b do_per_function
   
/usr/src/debug/sys-devel/gcc-14.0.1_pre20240324/gcc-14-20240324/gcc/passes.cc:1687
0x559439ad9c8b execute_todo
   
/usr/src/debug/sys-devel/gcc-14.0.1_pre20240324/gcc-14-20240324/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  for instructions.
ninja: build stopped: subcommand failed.
```

i.e. vect, not slp.

[Bug c++/114455] [C++26] P2748R5 - Disallow binding a returned reference to a temporary

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

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1
   Last reconfirmed||2024-03-25

--- Comment #1 from Marek Polacek  ---
Confirmed.  I'm interested.

[Bug c++/114460] [C++26] P3106R1 - Clarifying rules for brace elision in aggregate initialization

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

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

Marek Polacek  changed:

   What|Removed |Added

   Last reconfirmed||2024-03-25
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #1 from Marek Polacek  ---
Confirmed.  I'm interested.

[Bug tree-optimization/114471] New: [14 regression] ICE when building liblc3-1.0.4

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

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

Bug ID: 114471
   Summary: [14 regression] ICE when building liblc3-1.0.4
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sjames at gcc dot gnu.org
  Target Milestone: ---

Created attachment 57811
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57811=edit
spec.c.i

Initially reported downstream in Gentoo by tdr.

```
$ gcc-14 /tmp/foo.c -c -O2 -fno-vect-cost-model -march=x86-64-v4
/tmp/foo.c: In function ‘quantize’:
/tmp/foo.c:4:6: error: type mismatch in binary expression
4 | void quantize(int i, short x1) {
  |  ^~~~
vector(2) 

vector(2) 

vector(2) 

mask_patt_47.14_40 = mask__2.11_44 & mask_patt_48.13_41;
during GIMPLE pass: slp
/tmp/foo.c:4:6: internal compiler error: verify_gimple failed
0x55ab954d6b85 verify_gimple_in_cfg(function*, bool, bool)
   
/usr/src/debug/sys-devel/gcc-14.0./gcc-14.0./gcc/tree-cfg.cc:5663
0x55ab96a54818 execute_function_todo
/usr/src/debug/sys-devel/gcc-14.0./gcc-14.0./gcc/passes.cc:2088
0x55ab96a54818 do_per_function
/usr/src/debug/sys-devel/gcc-14.0./gcc-14.0./gcc/passes.cc:1687
0x55ab96a54818 execute_todo
/usr/src/debug/sys-devel/gcc-14.0./gcc-14.0./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  for instructions.
```

[Bug target/114415] [13/14 Regression] wrong code with -Oz -fno-dce -fno-forward-propagate -flive-range-shrinkage -fweb since r13-1826

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

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

--- Comment #3 from Jakub Jelinek  ---
BTW, with additional -mno-red-zone there is still movement of these insns,
though they   
leaq128(%rbx), %rsp   ! level 0
movq%r13, %rsi
movl%r10d, %edx
rep stosl
andq$0, -424(%rbp)
movq%r12, %rdi
leaq-112(%rbp), %rax
movq$1, -432(%rbp)
pushq   $16
popq%rcx
rep movsl ! fill in second argument - at %rsp - 64
pushq   $16   ! again overwrite last 8 bytes of the
second argument
movq%rbx, %rdi
leaq-240(%rbp), %rsi
popq%rcx
movq%r12, %rsp! level 64
movq%rbx, %rsp! level 128
rep movsl ! fill in first argument
xchgq   %rax, %rdi
callbar1

Ah, and it is sched2 pass which moves the movq %r12, %rsp and movq %rbx, %rsp
instructions before the second rep movsl.

[Bug target/114415] [13/14 Regression] wrong code with -Oz -fno-dce -fno-forward-propagate -flive-range-shrinkage -fweb since r13-1826

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||sayle at gcc dot gnu.org,
   ||uros at gcc dot gnu.org,
   ||vmakarov at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Seems it is lr_shrinkage pass where things go wrong.
In bar0, all the 3 calls the function makes have 2 64-byte arguments (plus
64-byte return passed by hidden reference).  -Oz apparently uses
-mno-accumulate-outgoing-args, allocates some stack and then have (at least
initially) before each of the 3 calls two spots which decrement %rsp by 64 and
after each call one spot which increments %rsp by 128.
csa merges the first %rsp -= 64 with the previous much larger %rsp decrement
and in some cases the %rsp += 128 with following %rsp -= 64.
The function sets %r12 to be the REG_ARGS_SIZE 64 %rsp level and %rbx to be the
REG_ARGS_SIZE 128 %rsp level, i.e. %rbx = %r12 - 64.
In asmcons pass, we still have before the call to bar1 %rsp -= 64; rep_movsi
(fills in the second argument); %rsp -= 64; rep_movsi (fills in the first
argument).
But then lr_shrinkage pass moves both the stack decrements after all the
rep_movsi calls, so we then have:
(insn 60 71 66 2 (parallel [
(set (reg/f:DI 7 sp)
(plus:DI (reg/f:DI 7 sp)
(const_int -64 [0xffc0])))
(clobber (reg:CC 17 flags))
]) "pr114415.c":27:8 272 {*adddi_1}
 (expr_list:REG_UNUSED (reg:CC 17 flags)
(expr_list:REG_ARGS_SIZE (const_int 64 [0x40])
(nil
(insn 66 60 72 2 (parallel [
(set (reg/f:DI 7 sp)
(plus:DI (reg/f:DI 129)
(const_int -64 [0xffc0])))
(clobber (reg:CC 17 flags))
]) "pr114415.c":27:8 272 {*adddi_1}
 (expr_list:REG_DEAD (reg/f:DI 129)
(expr_list:REG_UNUSED (reg:CC 17 flags)
(expr_list:REG_ARGS_SIZE (const_int 128 [0x80])
(nil)
and just set of %rdi and call to bar1.

Now, as x86-64 has red zone, this in theory could still work fine (dunno if
backend is supposed to have some barriers which prevent moving the rep movsl
insns across it, unfortunately the fact that it uses some %rsp based address is
not visible directly in the insn due to CSE), but then comes peephole2
;; With -Oz, transform mov $imm,reg to the shorter push $imm; pop reg.
and converts the (set (reg:DI %rcx) (const_int 16)) insns to push/pop pair,
which when
the stack pointer is higher than it should have been causes clobbering of the
value.

[Bug target/114466] mips: ICE during RTL pass: zero_call_used_regs

[rene at exactcode dot de via Gcc-bugs]

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

--- Comment #6 from René Rebe  ---
ok - good to know. I guess someone should tell the openssh developers and maybe
gcc should error out with a warning. Actually if gcc would error out it would
signal openssl's configure not to automatically try to use it, ...

[Bug fortran/114470] New: [OOP] Defined, type-bound assignment(=) of component not called within class, allocatable parent

[Linxwiler_Benjamin at bah dot com via Gcc-bugs]

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

Bug ID: 114470
   Summary: [OOP] Defined, type-bound assignment(=) of component
not called within class, allocatable parent
   Product: gcc
   Version: 13.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Linxwiler_Benjamin at bah dot com
  Target Milestone: ---

The following code prints
   42
   42
with gfortran and
   42
7
with ifort (2021.11.1 20231117) and ifx (2024.0.2 20231213).

Per my reading of the relevant portions of the standard (given below), the
latter is the correct behavior.

module myMod
   implicit none
   type component
  integer :: i = 42
  contains
  generic   :: assignment(=) => copy
  procedure :: copy
   end type
   type container
  type(component) :: foo
   end type
   contains
   subroutine copy(lhs,rhs)
  class(component), intent(out) :: lhs
  class(component), intent(in)  :: rhs
  lhs%i = 7
   end subroutine
end module

program main
   use myMod
   implicit none
   type(container)   :: right
!   type(container),  allocatable :: left
   class(container), allocatable :: left
   print *, right%foo%i
   left = right
   print *, left%foo%i
end program

If "left" in the program is made "type, allocatable" instead of "class,
allocatable", then the program prints
   42
7
as expected.

The relevant portions of the Fortran 2008 standard are found in "7.2.1.3
Interpretation of intrinsic assignments" and are as follows:
 - Per paragraph 3 (excerpt):
   "If the variable is or becomes an unallocated allocatable variable, it is 
   then allocated with
  - if the variable is polymorphic, the same dynamic type as expr..."
 - Per paragraph 13 (excerpt):
   "An intrinsic assignment where the variable is of derived type is performed 
   as if each component of the variable were assigned from the corresponding 
   component of expr using... defined assignment for each nonpointer 
   nonallocatable conponent of a type that has a type-bound defined assignment 
   consistent with the component..."
Paragraph 3 pertains to assignment of "left" while paragraph 13 explains the
assignment of component "foo".

This issue is related to the following bugs, with the following similarities
and differences:
 - For PR46897 [solved], both issues involve a defined, type-bound assignment
on 
   a component that is not being called. The difference is with the container 
   holding the object; it is "class, allocatable" in this new issue.
 - For PR57696 [unsolved], both issues involved a defined, type-bound
assignment
   on a component that is not being called. The difference is that the
component 
   is "type, allocatable" while the container holding it is "type" in the 
   previous issue, and in the new issue, the component is "type" while the 
   container holding it is "class, allocatable".
 - For PR57697 [solved], both issues are the same except that in the former the 
   container holding the component is "type, allocatable" while in the latter
it 
   is "class, allocatable".

[Bug analyzer/113314] [14 Regression] -Wanalyzer-infinite-loop false positive seen on haproxy's fd.c

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

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

--- Comment #2 from David Malcolm  ---
(In reply to David Malcolm from comment #1)

[...]

> 70redo_next:
> 71  next = fdtab[fd].update.next;
> 72  if (next > -2)
> 73goto done;
> 74  if (next == -2)
> 75goto redo_next;
> 
> does look like an infinite loop when next == 2.

Presumably I meant -2 here.

[Bug sanitizer/71962] error: ‘((& x) != 0u)’ is not a constant expression

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

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

Barry Revzin  changed:

   What|Removed |Added

 CC||barry.revzin at gmail dot com

--- Comment #12 from Barry Revzin  ---
Similar failure:

struct A {
void f();
};

int main() {
constexpr auto pmf = ::f;
static_assert(pmf != nullptr); // error with UBSAN only
}

This surfaces from attempting to implement function_ref
(https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p0792r14.html) which
has a constructor that takes the callable as a non-type template parameter and
static_asserts that it's not a null pointer.

Which apparently doesn't work with UBSAN.

[Bug target/114466] mips: ICE during RTL pass: zero_call_used_regs

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

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

Xi Ruoyao  changed:

   What|Removed |Added

 CC||xry111 at gcc dot gnu.org

--- Comment #5 from Xi Ruoyao  ---
-fzero-call-used-regs=all is just completely broken on mips as at now.  Please
don't use it for mips.

[Bug target/114468] unixbench compilation performance results vary with different gcc compilers

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
 Ever confirmed|0   |1
   Last reconfirmed||2024-03-25

[Bug target/114415] [13/14 Regression] wrong code with -Oz -fno-dce -fno-forward-propagate -flive-range-shrinkage -fweb since r13-1826

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

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|wrong code with -Oz |[13/14 Regression] wrong
   |-fno-dce|code with -Oz -fno-dce
   |-fno-forward-propagate  |-fno-forward-propagate
   |-flive-range-shrinkage  |-flive-range-shrinkage
   |-fweb   |-fweb since r13-1826
   Target Milestone|--- |13.3
   Last reconfirmed||2024-03-25
 Status|UNCONFIRMED |NEW
   Keywords|needs-bisection |
 Ever confirmed|0   |1
 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Started with r13-1826-g16aafa3194d4851a07cc204f56a5f0618f77e5d7

[Bug c++/114439] [14 Regression] icu4c-73.2 build failure: invalid initializer for array member with initialization of array of struct containing arrays since r14-9622

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

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

Marek Polacek  changed:

   What|Removed |Added

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

[Bug analyzer/113923] Segfault in gcc/gcc/tree-diagnostic.cc:265

[bouanto at zoho dot com via Gcc-bugs]

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

--- Comment #9 from Antoni  ---
Created attachment 57810
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57810=edit
Patch to fix the issue

I was unable to create a reproducer in C for the tests.
It seems the problem was actually in libgccjit because it was not setting
BLOCK_SUPERCONTEXT.

I'm not sure how best to test it, though.
The only idea I have would be to attempt to create a libgccjit test that adds
-fanalyzer to its arguments.
Do you have a better idea?

[Bug target/114468] unixbench compilation performance results vary with different gcc compilers

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

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

--- Comment #1 from Andrew Pinski  ---
Gcc 10 is no longer supported. Can you test a newer gcc? Register allocation is
always improving between versions so this might be already fixed.

[Bug target/114466] mips: ICE during RTL pass: zero_call_used_regs

[rene at exactcode dot de via Gcc-bugs]

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

--- Comment #4 from René Rebe  ---
Created attachment 57809
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57809=edit
preprocessed source from -freport-bug

preprocessed source from -freport-bug

[Bug tree-optimization/114469] New: gcc.dg/torture/bitint-64.c failure with -O2 -flto -std=c23 -fwrapv

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

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

Bug ID: 114469
   Summary: gcc.dg/torture/bitint-64.c failure with -O2 -flto
-std=c23 -fwrapv
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

This test fails with
make check-gcc GCC_TEST_RUN_EXPENSIVE=1
RUNTESTFLAGS="dg-torture.exp=bitint-64.c"
FAIL: gcc.dg/torture/bitint-64.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  execution test
The question is if _Atomic _BitInt(5) should be in memory always sign extended,
or as the ABI says the upper bits are unspecified.
If the former, then I'd say the problem is on the
/* Strip inner integral conversions that do not change precision or size, or
   zero-extend while keeping the same size (for bool-to-char).  */
(simplify
  (view_convert (convert@0 @1))
  (if ((INTEGRAL_TYPE_P (TREE_TYPE (@0)) || POINTER_TYPE_P (TREE_TYPE (@0)))
   && (INTEGRAL_TYPE_P (TREE_TYPE (@1)) || POINTER_TYPE_P (TREE_TYPE (@1)))
   && TYPE_SIZE (TREE_TYPE (@0)) == TYPE_SIZE (TREE_TYPE (@1))
   && (TYPE_PRECISION (TREE_TYPE (@0)) == TYPE_PRECISION (TREE_TYPE (@1))
   || (TYPE_PRECISION (TREE_TYPE (@0)) > TYPE_PRECISION (TREE_TYPE
(@1))
   && TYPE_UNSIGNED (TREE_TYPE (@1)
   (view_convert @1)))
match.pd simplification which transforms
  _5 = (unsigned _BitInt(5)) _4;
  _7 = (unsigned _BitInt(5)) e.0_1;
  _8 = _5 + _7;
  _9 = (_BitInt(5)) _8;
  _10 = VIEW_CONVERT_EXPR(_9);
to just
  _5 = (unsigned _BitInt(5)) _4;
  _7 = (unsigned _BitInt(5)) e.0_1;
  _8 = _5 + _7;
  _10 = VIEW_CONVERT_EXPR(_8);
so it is no longer sign extended in the unsigned char.
If the upper bits are undefined as the psABI on x86 says, then perhaps the
VIEW_CONVERT_EXPR emitted by c-common.cc (resolve_overloaded_builtin) is the
culprit:
  _13 = __atomic_load_1 (, 5);
  _14 = VIEW_CONVERT_EXPR<_BitInt(5)>(_13);
and we should change that
/* Cast function result from I{1,2,4,8,16} to the required type. 
*/
result = build1 (VIEW_CONVERT_EXPR, TREE_TYPE (new_return),
result);
to something like if (INTEGRAL_TYPE_P (TREE_TYPE (new_return))IINTEGRAL_TYPE_P
(TREE_TYPE (new_return))NTEGRAL_TYPE_P (TREE_TYPE (new_return)))
if (INTEGRAL_TYPE_P (TREE_TYPE (new_return)))
  result = fold_convert (TREE_TYPE (new_return), result);
else
  result = build1 (VIEW_CONVERT_EXPR, TREE_TYPE (new_return),
result);
Joseph, thoughts on this?

[Bug lto/114337] LTO symbol table doesn't include builtin functions

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

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

Alexander Monakov  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org

--- Comment #5 from Alexander Monakov  ---
Gold handles such rescanning correctly. BFD ld regressed in 2.27, this
bugreport contains references to previous discussions about rescanning:
https://sourceware.org/bugzilla/show_bug.cgi?id=23935

(in the above bug there's a patch for ld.bfd that seemingly went nowhere)

[Bug pch/114381] (Sporadic) crash generating x86_64-pc-cygwin/bits/extc++.h.gch/O2g.gch

[roland.mainz at nrubsig dot org via Gcc-bugs]

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

--- Comment #2 from Roland Mainz  ---
Same issue happens on Cygwin 3.6.x

[Bug c/114468] New: unixbench compilation performance results vary with different gcc compilers

[jiangchuanganghw at outlook dot com via Gcc-bugs]

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

Bug ID: 114468
   Summary: unixbench compilation performance results vary with
different gcc compilers
   Product: gcc
   Version: 10.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jiangchuanganghw at outlook dot com
  Target Milestone: ---

We used Unixbench to compare gcc 10.3.0 with gcc8.5 on an intel Sapphire Rapids
CPU and found that the performance of the dhry2reg test project compiled with
gcc 10.3.0 deteriorated by about 10%. We found that this commit affected
performance, and after rolling back the changes in that patch, performance was
restored.
https://github.com/gcc-mirror/gcc/commit/3133bed5d0327e8a9cd0a601b7ecdb9de4fc825d

We expect to find the cause of this result.Looking forward to your help.

[Bug target/112980] 64-bit powerpc ELFv2 does not allow nops to be generated before function global entry point

[naveen at kernel dot org via Gcc-bugs]

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

--- Comment #7 from Naveen N Rao  ---
I have been looking at an alternative approach to see if we can move the entire
function patching sequence out of line. However, the approach I am considering
is very specific to the linux kernel, and I don't see it applying for userspace
in a generic way. As such, I think there is value in addressing the current
limitation with -fpatchable-function-entry one way or another.

[Bug target/114466] mips: ICE during RTL pass: zero_call_used_regs

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

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

Sam James  changed:

   What|Removed |Added

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

--- Comment #3 from Sam James  ---
Oh, no, it isn't. Yeah, preprocessed source please.

[Bug target/114466] mips: ICE during RTL pass: zero_call_used_regs

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

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

--- Comment #2 from Sam James  ---
Also:
>Please submit a full bug report, with preprocessed source (by using 
>-freport-bug).

But no need here.

[Bug target/110934] m68k: ICE with -fzero-call-used-regs=all compiling openssh 9.3p2

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

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

Sam James  changed:

   What|Removed |Added

 CC||rene at exactcode dot de

--- Comment #16 from Sam James  ---
*** Bug 114466 has been marked as a duplicate of this bug. ***

[Bug target/114466] mips: ICE during RTL pass: zero_call_used_regs

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

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

Sam James  changed:

   What|Removed |Added

 CC||sjames at gcc dot gnu.org
 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #1 from Sam James  ---
Dupe.

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

[Bug fortran/114467] New: f951: internal compiler error: Segmentation fault

[thomas.kalscheuer at geo dot uu.se via Gcc-bugs]

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

Bug ID: 114467
   Summary: f951: internal compiler error: Segmentation fault
   Product: gcc
   Version: 13.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: thomas.kalscheuer at geo dot uu.se
  Target Milestone: ---

I use a system with dual Intel(R) Xeon(R) CPU E5-2630 v4 @ 2.20GHz cpus, CentOS
Linux 7 and gfortran v. 13.2.0

According to gcc -v, gcc was configured with the options "Configured with:
../gcc-13.2.0/configure --enable-languages=c,c++,fortran"

By compiling a fortran code with 
gfortran -O2 -march=native -mtune=native -malign-data=cacheline
-finline-functions -std=f2018 -ffree-form -ffree-line-length-none -pedantic
-Wsurprising -Wopenmp-simd -Wvector-operation-performance -ftree-vectorize
-ftree-vectorizer-verbose=2 -fopt-info -fopenmp -I/usr/include
-I/usr/include/hdf5/serial/ -freport-bug -save-temps -x f95-cpp-input -DRMT -c
code.f90 -o code.o
I get the following error message:
f951: internal compiler error: Segmentation fault
0xd29d7f crash_signal
../../gcc-13.2.0/gcc/toplev.cc:314
0x7c2a65 gfc_expression_rank(gfc_expr*)
../../gcc-13.2.0/gcc/fortran/resolve.cc:5643
0x7c2c14 gfc_op_rank_conformable(gfc_expr*, gfc_expr*)
../../gcc-13.2.0/gcc/fortran/resolve.cc:5676
0x709e9c eval_intrinsic
../../gcc-13.2.0/gcc/fortran/arith.cc:1674
0x781cfc match_level_4
../../gcc-13.2.0/gcc/fortran/matchexp.cc:636
0x781cfc match_and_operand
../../gcc-13.2.0/gcc/fortran/matchexp.cc:693
0x781d66 match_or_operand
../../gcc-13.2.0/gcc/fortran/matchexp.cc:722
0x781e76 match_equiv_operand
../../gcc-13.2.0/gcc/fortran/matchexp.cc:765
0x781f88 match_level_5
../../gcc-13.2.0/gcc/fortran/matchexp.cc:811
0x7810e4 gfc_match_expr(gfc_expr**)
../../gcc-13.2.0/gcc/fortran/matchexp.cc:870
0x78132b match_primary
../../gcc-13.2.0/gcc/fortran/matchexp.cc:165
0x78132b match_level_1
../../gcc-13.2.0/gcc/fortran/matchexp.cc:211
0x78132b match_mult_operand
../../gcc-13.2.0/gcc/fortran/matchexp.cc:267
0x7815c8 match_add_operand
../../gcc-13.2.0/gcc/fortran/matchexp.cc:356
0x78189c match_level_2
../../gcc-13.2.0/gcc/fortran/matchexp.cc:480
0x781a56 match_level_3
../../gcc-13.2.0/gcc/fortran/matchexp.cc:551
0x781b90 match_level_4
../../gcc-13.2.0/gcc/fortran/matchexp.cc:599
0x781b90 match_and_operand
../../gcc-13.2.0/gcc/fortran/matchexp.cc:693
0x781d66 match_or_operand
../../gcc-13.2.0/gcc/fortran/matchexp.cc:722
0x781e76 match_equiv_operand
../../gcc-13.2.0/gcc/fortran/matchexp.cc:765
Please submit a full bug report, with preprocessed source.
Please include the complete backtrace with any bug report.
See  for instructions.
make: *** [code.o] Error 1

Compilation with
gfortran -g -std=f2018 -ffree-form -ffree-line-length-none -pedantic -Wall
-I/usr/include -I/usr/include/hdf5/serial/ -freport-bug -save-temps -x
f95-cpp-input -DRMT -c code.f90 -o code.o
leads to the same error message.

Note, that inclusion of the -save-temps option has not led to any *.* file
being generated by the compiler.

[Bug target/114466] New: mips: ICE during RTL pass: zero_call_used_regs

[rene at exactcode dot de via Gcc-bugs]

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

Bug ID: 114466
   Summary: mips: ICE during RTL pass: zero_call_used_regs
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rene at exactcode dot de
  Target Milestone: ---

Compiling the latest openssh-9.7p1 (and openssh-9.6p1) for mips-linux or
mips64n32 linux causes and internal compiler error: Segmentation fault:

uring RTL pass: zero_call_used_regs
misc.c: In function 'bandwidth_limit':
misc.c:1807:1: internal compiler error: Segmentation fault
 1807 | }
  | ^
0x128fff5 internal_error(char const*, ...)
???:0
0x863ad0 emit_move_insn(rtx_def*, rtx_def*)
???:0
0xac9967 default_zero_call_used_regs(HARD_REG_SET)
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

at least 14-20240324 and 13-20240224 are affected. I would expect at leaste
13.2 as well.

[Bug c++/114377] [13/14 Regression] GCC crashes on an example of CTAD for alias templates

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P1  |P2
Version|unknown |13.2.1

--- Comment #2 from Richard Biener  ---
P2, we released with this bug.

[Bug c++/114303] [11/12/13/14 Regression] ICE with constexpr if and accessing captures across nested generic lambdas

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P1  |P2

--- Comment #4 from Richard Biener  ---
P2, we releases with this bug.

[Bug target/112470] [11/12/13/14 regression] [AARCH64] stack-protector vulnerability fixing solution impact code size and performance

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P1  |P2

--- Comment #15 from Richard Biener  ---
P2 since it's a minor missed-optimization and possibly an unwanted optimization
even.  "importance" is priority of the reporter, so I'm leaving that critical.