[Bug target/120840] CPython miscompiled with preserve_none

[hjl.tools at gmail dot com via Gcc-bugs]

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

H.J. Lu  changed:

   What|Removed |Added

   Target Milestone|--- |16.0

[Bug target/120841] gcc prefer non-volatile register produces sub optimal code

[rockeet at gmail dot com via Gcc-bugs]

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

--- Comment #2 from rockeet  ---
(In reply to Andrew Pinski from comment #1)
> Gcc is already better than llvm by figuring out the return of memcpy is the
> first argument.
> 
> I am not sure if the one extra move is going hurt here either.

Yes, gcc is better than clang for this case. I think gcc can be better if it is
possible.

[Bug target/120841] gcc prefer non-volatile register produces sub optimal code

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

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

Richard Biener  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Target|X86_64  |x86_64-*-*
   Last reconfirmed||2025-06-27
 Status|UNCONFIRMED |NEW

[Bug middle-end/120842] optimization for check many equal by bits or

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|c++ |middle-end
   Severity|normal  |enhancement
   Keywords||missed-optimization

[Bug middle-end/120842] optimization for check many equal by bits or

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

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

--- Comment #1 from Andrew Pinski  ---
There might be a dup of this one already.

[Bug c++/120842] New: optimization for check many equal by bits or

[rockeet at gmail dot com via Gcc-bugs]

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

Bug ID: 120842
   Summary: optimization for check many equal by bits or
   Product: gcc
   Version: 16.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rockeet at gmail dot com
  Target Milestone: ---

bool many_eq_max_13(unsigned int val) {
[[assume(val < 32)]];
return val ==  1 || val ==  4 || val ==  7 || val ==  9 ||
   val == 10 || val == 13;
}
bool many_eq_max_31(unsigned int val) {
[[assume(val < 32)]];
return val ==  1 || val ==  4 || val ==  7 || val ==  9 ||
   val == 10 || val == 13 || val == 31;
}
bool many_eq_max_63(unsigned int val) {
[[assume(val < 64)]];
return val ==  1 || val ==  4 || val ==  7 || val ==  9 ||
   val == 10 || val == 13 || val == 31 || val == 63;
}

gcc just produce optimal code for many_eq_max_31:
(https://godbolt.org/z/jrf8rexj7)

"many_eq_max_13(unsigned int)":
mov eax, 658
mov edx, 9216
bt  rax, rdi
setcal
bt  rdx, rdi
setcdl
testal, al
cmove   eax, edx
ret
"many_eq_max_31(unsigned int)":
mov eax, 2147493522
bt  rax, rdi
setcal
ret
"many_eq_max_63(unsigned int)":
mov eax, 9874
bt  rax, rdi
setcal
testal, al
je  .L7
ret
.L7:
and edi, -33
cmp edi, 31
seteal
ret

both gcc and clang is not perfect for this case, clang is a bit better.

[Bug target/120839] [16 Regression] ICE on x86_64-linux-gnu: in ix86_finalize_stack_frame_flags, at config/i386/i386.cc:8738 at -O1 and above with aligned on struct

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

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

Richard Biener  changed:

   What|Removed |Added

 Target|X86_64  |x86_64-*-*
   Priority|P3  |P1

[Bug fortran/120843] New: [Coarray] Inconsistent ranks for operator reported when coarray ranks differ

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

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

Bug ID: 120843
   Summary: [Coarray] Inconsistent ranks for operator reported
when coarray ranks differ
   Product: gcc
   Version: 16.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vehre at gcc dot gnu.org
  Target Milestone: ---

Reproducer:

program p
  implicit none

  integer, allocatable :: arr(:,:) [:,:]

  integer :: c[*]
  integer :: i,j

  c = 7

  allocate(arr(4,3)[2,*], source=6)

  do i = 1, 4
do j = 1, 3
  print *, arr(i, j)* c
end do
  end do

end program p

results in:

$ gfortran-16 -c p.f90 -fcoarray=lib
p.f90:15:18-27:

   15 |   print *, arr(i, j)* c
  |  12
Error: Inconsistent ranks for operator at (1) and (2)

[Bug fortran/120843] [Coarray] Inconsistent ranks for operator reported when coarray ranks differ

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

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

Andre Vehreschild  changed:

   What|Removed |Added

   Priority|P3  |P4
  Known to fail||16.0
   Keywords||rejects-valid

[Bug c/120844] New: ICE on x86_64-linux-gnu: Segmentation fault during GIMPLE pass: omplower

[jiangchangwu at smail dot nju.edu.cn via Gcc-bugs]

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

Bug ID: 120844
   Summary: ICE on x86_64-linux-gnu: Segmentation fault during
GIMPLE pass: omplower
   Product: gcc
   Version: 16.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jiangchangwu at smail dot nju.edu.cn
  Target Milestone: ---

Compiler Explorer: https://gcc.godbolt.org/z/x1T9a6ejq

***
gcc version:
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/home/software/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/16.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --disable-multilib --disable-bootstrap
--enable-languages=c,c++ --prefix=/home/software/gcc-trunk --enable-coverage
--disable-werror --enable-checking=yes
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 16.0.0 20250613 (experimental) (GCC)

***
Program:
$ cat mutant.c
extern int a[];
int b;
void c() {
#pragma omp target parallel for map(a[0])
  for (b = 0; b < 0; b++)
a;
}

***
Command Lines:
$ gcc -fopenmp mutant.c
during GIMPLE pass: omplower
mutant.c: In function 'c':
mutant.c:4:9: internal compiler error: Segmentation fault
4 | #pragma omp target parallel for map(a[0])
  | ^~~
0x5554b38 internal_error(char const*, ...)
../../gcc/gcc/diagnostic-global-context.cc:517
0x21651ec crash_signal
../../gcc/gcc/toplev.cc:321
0xec7e7d non_type_check(tree_node*, char const*, int, char const*)
../../gcc/gcc/tree.h:3921
0x1d4d475 fixup_remapped_decl
../../gcc/gcc/omp-low.cc:911
0x1d56686 scan_sharing_clauses
../../gcc/gcc/omp-low.cc:1891
0x1d5a798 scan_omp_parallel
../../gcc/gcc/omp-low.cc:2374
0x1d6854d scan_omp_1_stmt
../../gcc/gcc/omp-low.cc:4177
0x18f6101 walk_gimple_stmt(gimple_stmt_iterator*, tree_node*
(*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**,
int*, void*), walk_stmt_info*)
../../gcc/gcc/gimple-walk.cc:618
0x18f32bc walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*,
bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
../../gcc/gcc/gimple-walk.cc:51
0x18f6367 walk_gimple_stmt(gimple_stmt_iterator*, tree_node*
(*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**,
int*, void*), walk_stmt_info*)
../../gcc/gcc/gimple-walk.cc:645
0x18f32bc walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*,
bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
../../gcc/gcc/gimple-walk.cc:51
0x1d692f5 scan_omp
../../gcc/gcc/omp-low.cc:4322
0x1d619f2 scan_omp_target
../../gcc/gcc/omp-low.cc:3150
0x1d68f9e scan_omp_1_stmt
../../gcc/gcc/omp-low.cc:4268
0x18f6101 walk_gimple_stmt(gimple_stmt_iterator*, tree_node*
(*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**,
int*, void*), walk_stmt_info*)
../../gcc/gcc/gimple-walk.cc:618
0x18f32bc walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*,
bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
../../gcc/gcc/gimple-walk.cc:51
0x18f6367 walk_gimple_stmt(gimple_stmt_iterator*, tree_node*
(*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**,
int*, void*), walk_stmt_info*)
../../gcc/gcc/gimple-walk.cc:645
0x18f32bc walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*,
bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
../../gcc/gcc/gimple-walk.cc:51
0x1d692f5 scan_omp
../../gcc/gcc/omp-low.cc:4322
0x1dc77ec execute_lower_omp
../../gcc/gcc/omp-low.cc:15067
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 c/120850] New: provide an special __builtin_memset_explicit

[crrodriguez at opensuse dot org via Gcc-bugs]

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

Bug ID: 120850
   Summary: provide an special __builtin_memset_explicit
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: crrodriguez at opensuse dot org
  Target Milestone: ---

It is not possible for library to implement memset_explicit as specified on the
C23 standard..because it is up to the compiler to honour the "never elided,
regardless of optimizations" part. unless this is a special function known to
the compiler it still be subject to optimizations that will break this rules.

[Bug c/120850] provide an special __builtin_memset_explicit

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

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

--- Comment #2 from Andrew Pinski  ---
Using an inline-asm to cause compiler barriers should be enough to stop gcc
from optimizing the code away.

[Bug c/120850] provide an special __builtin_memset_explicit

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

--- Comment #1 from Andrew Pinski  ---
I don't think that is true. In fact I think the opposite is true. Having a
builtin might be abused internally to the compiler.

[Bug c/120850] provide an special __builtin_memset_explicit

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2025-06-28

--- Comment #4 from Andrew Pinski  ---
Do you have an example where this builtin would be used?

[Bug target/120840] [16 Regression] CPython miscompiled with preserve_none

[hjl.tools at gmail dot com via Gcc-bugs]

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

--- Comment #10 from H.J. Lu  ---
Python/ceval.o is miscompiled.

[Bug c/120851] New: internal compiler error: in expand_call, at calls.cc:3729

[bic60176 at gmail dot com via Gcc-bugs]

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

Bug ID: 120851
   Summary: internal compiler error: in expand_call, at
calls.cc:3729
   Product: gcc
   Version: 16.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bic60176 at gmail dot com
  Target Milestone: ---

Created attachment 61742
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61742&action=edit
testcase

Compiler Explorer: https://godbolt.org/z/83hPr7vE1

Console:
: In function 'main':
:24:3: sorry, unimplemented: passing too large argument on stack
   24 |   foo(*&q);
  |   ^~~~
during RTL pass: expand
:24:3: internal compiler error: in expand_call, at calls.cc:3729
0x250ccf5 diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, diagnostic_option_id, char const*, __va_list_tag
(*) [1], diagnostic_t)
???:0
0x252f896 internal_error(char const*, ...)
???:0
0x9fd4f2 fancy_abort(char const*, int, char const*)
???:0
0xbbd83c expand_call(tree_node*, rtx_def*, int)
???:0
0xd0f4fd expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
???: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.
ASM generation compiler returned: 1
: In function 'main':
:24:3: sorry, unimplemented: passing too large argument on stack
   24 |   foo(*&q);
  |   ^~~~
during RTL pass: expand
:24:3: internal compiler error: in expand_call, at calls.cc:3729
0x250ccf5 diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, diagnostic_option_id, char const*, __va_list_tag
(*) [1], diagnostic_t)
???:0
0x252f896 internal_error(char const*, ...)
???:0
0x9fd4f2 fancy_abort(char const*, int, char const*)
???:0
0xbbd83c expand_call(tree_node*, rtx_def*, int)
???:0
0xd0f4fd expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
???: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.
Execution build compiler returned: 1
Build failed

[Bug c/120850] provide an special __builtin_memset_explicit

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

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

--- Comment #8 from Andrew Pinski  ---
> unless this is a special function known to the compiler it still be subject 
> to optimizations that will break this rules.

Why do you think that is the case? Do you any examples of that because that
would be wrong code in general. The only time gcc optimizes functions if it is
know to the compiler (so special functions and ones known via lto or in the
same tu or known behavior via attributes).

[Bug c/120850] provide an special __builtin_memset_explicit

[crrodriguez at opensuse dot org via Gcc-bugs]

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

--- Comment #9 from Cristian Rodríguez  ---
(In reply to Andrew Pinski from comment #2)
> Using an inline-asm to cause compiler barriers should be enough to stop gcc
> from optimizing the code away.

The library implementation does that. but callers wont know, the implementation
is not inline..

[Bug c/120851] internal compiler error: in expand_call, at calls.cc:3729

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Dup

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

[Bug middle-end/115411] ICE : in expand_call, at calls.cc:3668

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||bic60176 at gmail dot com

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

[Bug c/120852] New: internal compiler error: in analyze_functions, at cgraphunit.cc:1418

[bic60176 at gmail dot com via Gcc-bugs]

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

Bug ID: 120852
   Summary: internal compiler error: in analyze_functions, at
cgraphunit.cc:1418
   Product: gcc
   Version: 16.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bic60176 at gmail dot com
  Target Milestone: ---

Created attachment 61743
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61743&action=edit
testcase

Compiler Explorer: https://godbolt.org/z/vK1vGjGzn

Console:
: In function 'check9':
:14:38: error: incompatible types when returning type 'int' but 'C' was
expected
   14 | extern WURAI C check9(void) { return 0;
  |  ^
:18:18: error: nested function 'check11' declared 'extern'
   18 | extern WURAI int check11(void) { return baz(); }
  |  ^~~
:27:1: error: expected declaration or statement at end of input
   27 | }
  | ^
At top level:
cc1: internal compiler error: in analyze_functions, at cgraphunit.cc:1418
0x250ccf5 diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, diagnostic_option_id, char const*, __va_list_tag
(*) [1], diagnostic_t)
???:0
0x252f896 internal_error(char const*, ...)
???:0
0x9fd4f2 fancy_abort(char const*, int, char const*)
???:0
0xc238e1 symbol_table::finalize_compilation_unit()
???: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.
Compiler returned: 1

[Bug c/120850] provide an special __builtin_memset_explicit

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

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

Sam James  changed:

   What|Removed |Added

 CC||sjames at gcc dot gnu.org

--- Comment #3 from Sam James  ---
https://inbox.sourceware.org/libc-alpha/CAPBLoAetbSpZswTG_QYD_pqVTKOdMz5EvtyTGHeuJSVEn=t...@mail.gmail.com/

[Bug c/120850] provide an special __builtin_memset_explicit

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

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

--- Comment #5 from Andrew Pinski  ---
Again I think it is wrong to have a builtin.

[Bug c/120850] provide an special __builtin_memset_explicit

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

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

--- Comment #6 from Andrew Pinski  ---
I don't see a reason for the builtin unless you want to optimization it away
which should not happen with the _exlicit functions at all.

Access and the other attributes for nullness should be enough for the function.
Adding a builtin just is asking for trouble.

[Bug c/120850] provide an special __builtin_memset_explicit

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

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

--- Comment #7 from Andrew Pinski  ---
> standard..because it is up to the compiler to honour the "never elided, 
> regardless of optimizations" 

Gcc does not elide away any unknown function so why not make it unknown to gcc.

[Bug c/120850] provide an special __builtin_memset_explicit

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

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

--- Comment #10 from Andrew Pinski  ---
(In reply to Cristian Rodríguez from comment #9)
> (In reply to Andrew Pinski from comment #2)
> > Using an inline-asm to cause compiler barriers should be enough to stop gcc
> > from optimizing the code away.
> 
> The library implementation does that. but callers wont know, the
> implementation is not inline..

Right, gcc can't assume anything about a function it does not know.

[Bug c/120853] New: ICE: Segmentation fault at contains_struct_check()

[bic60176 at gmail dot com via Gcc-bugs]

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

Bug ID: 120853
   Summary: ICE: Segmentation fault at contains_struct_check()
   Product: gcc
   Version: 15.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bic60176 at gmail dot com
  Target Milestone: ---

Created attachment 61744
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61744&action=edit
testcase

Compiler Explorer: https://godbolt.org/z/5GEhnbG8n

Console:
during GIMPLE pass: isel
: In function 'tst_notcomplex':
:7:6: internal compiler error: Segmentation fault
7 | void tst_notcomplex(int *pi, long *pl, long double *pld) {
  |  ^~
0x20bd0f5 diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, diagnostic_option_id, char const*, __va_list_tag
(*) [1], diagnostic_t)
???:0
0x20ce646 internal_error(char const*, ...)
???: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.
Compiler returned: 1

[Bug middle-end/120369] [15 Regression] internal compiler error: Segmentation fault during GIMPLE pass: cplxlower0 only in version 15.1 and trunk

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||bic60176 at gmail dot com

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

[Bug c/120853] ICE: Segmentation fault at contains_struct_check()

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Dup, fixed on the trunk already, will backport it to the 15 branch next week.

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

[Bug c/120852] [12/13/14/15/16 Regression] internal compiler error: in analyze_functions, at cgraphunit.cc:1418

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

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

[Bug c/95145] [12/13/14/15/16 Regression]internal compiler error: in analyze_functions, at cgraphunit.c:1380

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||bic60176 at gmail dot com

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

[Bug sanitizer/120837] False-positive from -fsanitize=undefined

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

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

Sam James  changed:

   What|Removed |Added

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

--- Comment #5 from Sam James  ---
.

[Bug libstdc++/100795] ranges::sample, ranges::sort etc should not use std::sample, std::sort etc directly

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

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

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

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

commit r16-1746-g4fc387e2f6990986d72b023ee44b4e0030903247
Author: Patrick Palka 
Date:   Fri Jun 27 13:53:37 2025 -0400

libstdc++: Directly implement ranges::sample [PR100795]

PR libstdc++/100795

libstdc++-v3/ChangeLog:

* include/bits/ranges_algo.h (__sample_fn::operator()):
Reimplement the forward_iterator branch directly, based
on the stl_algo.h implementation.  Add explicit cast to
_Out's difference_type in the !forward_iterator branch.
* testsuite/25_algorithms/sample/constrained.cc (test02):
New test.

Reviewed-by: Jonathan Wakely 

[Bug libstdc++/100795] ranges::sample, ranges::sort etc should not use std::sample, std::sort etc directly

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

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

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

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

commit r16-1747-gb4aadc60154c62425c36c61d23c7549d31fe1397
Author: Patrick Palka 
Date:   Fri Jun 27 13:53:40 2025 -0400

libstdc++: Directly implement ranges::shuffle [PR100795]

PR libstdc++/100795

libstdc++-v3/ChangeLog:

* include/bits/ranges_algo.h (shuffle_fn::operator()):
Reimplement directly, based on the stl_algo.h implementation.
* testsuite/25_algorithms/shuffle/constrained.cc (test02):
New test.

Reviewed-by: Jonathan Wakely 

[Bug sanitizer/120837] False-positive from -fsanitize=undefined

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

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

--- Comment #4 from Sam James  ---
Created attachment 61736
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61736&action=edit
a-sqlite3.i.xz

The fix for PR120471 is in the C++ FE. Attached preprocessed source from
releases/gcc-13.

[Bug libstdc++/100795] ranges::sample, ranges::sort etc should not use std::sample, std::sort etc directly

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

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

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

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

commit r16-1742-g9d3467a14bbd75469f114b047590ebbffa4a9c8b
Author: Patrick Palka 
Date:   Fri Jun 27 13:53:26 2025 -0400

libstdc++: Directly implement ranges::inplace_merge [PR100795]

As with the previous patch, this patch reimplements ranges::inplace_merge
directly instead of incorrectly forwarding to std::inplace_merge.  In
addition to the compatibility changes listed in the previous patch we
also:

  - explicitly cast the difference type (which can be an integer class) to
ptrdiff_t when constructing a _Temporary_buffer

PR libstdc++/100795

libstdc++-v3/ChangeLog:

* include/bits/ranges_algo.h (__detail::__move_merge_adaptive):
New, based on the stl_algo.h implementation.
(__detail::__move_merge_adaptive_backward): Likewise.
(__detail::__rotate_adaptive): Likewise.
(__detail::__merge_adaptive): Likewise.
(__detail::__merge_adaptive_resize): Likewise.
(__detail::__merge_without_buffer): Likewise.
(__inplace_merge_fn::operator()): Reimplement in terms of the
above.
* testsuite/25_algorithms/inplace_merge/constrained.cc (test03):
New test.

Reviewed-by: Jonathan Wakely 

[Bug sanitizer/120837] [12/13/14/15/16 regression] False-positive from -fsanitize=undefined

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

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

Sam James  changed:

   What|Removed |Added

   Target Milestone|--- |12.5
Summary|False-positive from |[12/13/14/15/16 regression]
   |-fsanitize=undefined|False-positive from
   ||-fsanitize=undefined
   Keywords||wrong-code

[Bug fortran/120784] fortran: issue with use-association renames and interface

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

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

--- Comment #7 from anlauf at gcc dot gnu.org ---
Created attachment 61738
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61738&action=edit
New testcase

The committed patch unfortunately broke this (reduced) testcase:

pr120784-v2.f90:23:21:

   23 |   end interface local
  | 1
Error: Expecting 'END INTERFACE ' at (1)
pr120784-v2.f90:25:8:

   25 | contains
  |1
Error: Unexpected CONTAINS statement in INTERFACE block at (1)
pr120784-v2.f90:29:18:

   29 | local = .true.
  |  1
Error: Unexpected assignment statement at (1) in INTERFACE body
pr120784-v2.f90:30:25:

   30 |   end function local_invt
  | 1
Error: Entity 'local_invt' at (1) is already present in the interface
pr120784-v2.f90:32:3:

   32 | end module mod2
  |   1
Error: Expecting END INTERFACE statement at (1)
f951: Error: Unexpected end of file in 'pr120784-v2.f90'

[Bug fortran/120784] fortran: issue with use-association renames and interface

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

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

--- Comment #8 from anlauf at gcc dot gnu.org ---
(In reply to anlauf from comment #7)
> Created attachment 61738 [details]
> New testcase
> 
> The committed patch unfortunately broke this (reduced) testcase:

We run into the following:

(gdb) p current_interface.sym->attr.use_assoc
$4 = 1
(gdb) p current_interface.sym->attr.use_rename
$5 = 1
(gdb) p current_interface.sym->ns->use_stmts->rename->local_name[0]
$13 = 0 '\000'

Looks like we need to protect from this happening...

[Bug c++/120845] [16 Regression] C++ multiline module declaration causes ice

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|[16 Regression] C++ |[16 Regression] C++
   |multiline module|multiline module
   |declaration is not accepted |declaration causes ice
   |by g++  |
   Keywords|ice-on-valid-code,  |ice-on-invalid-code
   |rejects-valid   |

--- Comment #6 from Andrew Pinski  ---
Ice on invalid as P3034R1 paper was also considered as a defect fix to both
c++20 and c++23.

[Bug c++/120845] [16 Regression] C++ multiline module declaration causes ice

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #7 from Jakub Jelinek  ---
Created attachment 61732
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61732&action=edit
gcc16-pr120845.patch

Untested fix.

[Bug c++/120845] [15/16 Regression] C++ multiline module declaration causes ice

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

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[16 Regression] C++ |[15/16 Regression] C++
   |multiline module|multiline module
   |declaration causes ice  |declaration causes ice
   Target Milestone|16.0|15.2

[Bug sanitizer/120471] [12/13/14/15/16 regression] -fsanitize=undefined causes read of uninitialized variable when accessing element in an array at -O0 level

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Keywords|needs-bisection |

--- Comment #13 from Jakub Jelinek  ---
Fails since r0-124938-gde5a5fa1395db2cb5da4d0593fef40ec22378576 when
-fsanitize=undefined has been introduced.

[Bug fortran/120843] [Coarray] Inconsistent ranks for operator reported when coarray ranks differ

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

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

Andre Vehreschild  changed:

   What|Removed |Added

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

--- Comment #1 from Andre Vehreschild  ---
Patch proposed at https://gcc.gnu.org/pipermail/fortran/2025-June/062386.html
Waiting for review.

[Bug target/55212] [SH] Switch to LRA

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #455 from John Paul Adrian Glaubitz  ---
Created attachment 61734
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61734&action=edit
Error log for building gcc-16 with LRA enabled, no patches

(In reply to John Paul Adrian Glaubitz from comment #454)
> (In reply to Oleg Endo from comment #453)
> > As we have already learned from this PR here, a bootstrap is not sufficient
> > evidence that everything works normally.  If it bootstraps and can't compile
> > other software we're back to sqrt(1).  So it needs at least full testing of
> > the included gcc testsuite.
> 
> I didn't say I would stop after the bootstrap ;-). Of course, I will perform
> more tests if the LRA bootstrap works.

Bootstrap fails with a very long list of errors. I'll attach the error log.

[Bug libstdc++/100795] ranges::sample, ranges::sort etc should not use std::sample, std::sort etc directly

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

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

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

https://gcc.gnu.org/g:04c597c05494e38cc9c231581737c1d7d7579e51

commit r16-1743-g04c597c05494e38cc9c231581737c1d7d7579e51
Author: Patrick Palka 
Date:   Fri Jun 27 13:53:29 2025 -0400

libstdc++: Directly implement ranges::stable_sort [PR100795]

PR libstdc++/100795

libstdc++-v3/ChangeLog:

* include/bits/ranges_algo.h (__detail::__move_merge): New,
based on the stl_algo.h implementation.
(__detail::__merge_sort_loop): Likewise.
(__detail::__chunk_insertion_sort): Likewise.
(__detail::__merge_sort_with_buffer): Likewise.
(__detail::__stable_sort_adaptive): Likewise.
(__detail::__stable_sort_adaptive_resize): Likewise.
(__detail::__inplace_stable_sort): Likewise.
(__stable_sort_fn::operator()): Reimplement in terms of the above.
* testsuite/25_algorithms/stable_sort/constrained.cc:

Reviewed-by: Jonathan Wakely 

[Bug libstdc++/100795] ranges::sample, ranges::sort etc should not use std::sample, std::sort etc directly

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

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

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

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

commit r16-1740-ga148b0377805376e33f36bed0e48a401a6dd82c6
Author: Patrick Palka 
Date:   Fri Jun 27 13:52:56 2025 -0400

libstdc++: Directly implement ranges::heap algos [PR100795]

ranges::push_heap, ranges::pop_heap, ranges::make_heap and
ranges::sort_heap are currently defined in terms of the corresponding
STL-style algorithms, but this is incorrect because the STL-style
algorithms rely on the legacy iterator system, and so misbehave when
passed a narrowly C++20 random access iterator.  The other ranges heap
algos, ranges::is_heap and ranges::is_heap_until, are implemented
directly already and have no known issues.

This patch reimplements these ranges:: algos directly instead, based
closely on the legacy stl_heap.h implementation, with the following
changes for compatibility with the C++20 iterator system:

  - handle non-common ranges by computing the corresponding end iterator
  - use ranges::iter_move instead of std::move(*iter)
  - use iter_value_t / iter_difference_t instead of iterator_traits

Besides these changes, the implementation of these algorithms is
intended to mirror the stl_heap.h implementations, for ease of
maintenance and review.

Note that we don't explicitly pass the projection function throughout,
instead we just create and pass a composite predicate via __make_comp_proj.

PR libstdc++/100795

libstdc++-v3/ChangeLog:

* include/bits/ranges_algo.h (__detail::__push_heap): New,
based on the stl_heap.h implementation.
(__push_heap_fn::operator()): Reimplement in terms of the above.
(__detail::__adjust_heap): New, based on the stl_heap.h
implementation.
(__deatil::__pop_heap): Likewise.
(__pop_heap_fn::operator()): Reimplement in terms of the above.
(__make_heap_fn::operator()): Likewise.
(__sort_heap_fn::operator()): Likewise.
* testsuite/25_algorithms/heap/constrained.cc (test03): New
test.

Reviewed-by: Tomasz KamiÅski 
Reviewed-by: Jonathan Wakely 

[Bug libstdc++/100795] ranges::sample, ranges::sort etc should not use std::sample, std::sort etc directly

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

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

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

https://gcc.gnu.org/g:07832a5205389b4dc2b92fe58213386fe30ca618

commit r16-1744-g07832a5205389b4dc2b92fe58213386fe30ca618
Author: Patrick Palka 
Date:   Fri Jun 27 13:53:32 2025 -0400

libstdc++: Directly implement ranges::stable_partition [PR100795]

PR libstdc++/100795

libstdc++-v3/ChangeLog:

* include/bits/ranges_algo.h (__detail::__find_if_not_n): New,
based on the stl_algo.h implementation.
(__detail::__stable_partition_adaptive): Likewise.
(__stable_partition_fn::operator()): Reimplement in terms of
the above.
* testsuite/25_algorithms/stable_partition/constrained.cc
(test03): New test.

Reviewed-by: Jonathan Wakely 

[Bug libstdc++/100795] ranges::sample, ranges::sort etc should not use std::sample, std::sort etc directly

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

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

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

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

commit r16-1745-gd06373fa3483a1ccb182c2da7e6cf2330f48bac1
Author: Patrick Palka 
Date:   Fri Jun 27 13:53:34 2025 -0400

libstdc++: Directly implement ranges::nth_element [PR100795]

PR libstdc++/100795

libstdc++-v3/ChangeLog:

* include/bits/ranges_algo.h (__detail::__introselect): New,
based on the stl_algo.h implementation.
(nth_element_fn::operator()): Reimplement in terms of the above.
* testsuite/25_algorithms/nth_element/constrained.cc:

Reviewed-by: Jonathan Wakely 

[Bug libstdc++/118209] ranges::sort doesn't use iter_move, cannot sort zip of move-only type

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

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

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

https://gcc.gnu.org/g:92417c387365033cac4fff7ec8da2b42bd75dfba

commit r16-1741-g92417c387365033cac4fff7ec8da2b42bd75dfba
Author: Patrick Palka 
Date:   Fri Jun 27 13:53:06 2025 -0400

libstdc++: Directly implement ranges::sort [PR100795]

As with the previous patch, this patch reimplements ranges::sort
directly instead of incorrectly forwarding to std::sort.  In addition to
the compatibility changes listed in the previous patch we also:

  - use ranges::iter_swap instead of std::iter_swap
  - use ranges::move_backward instead of std::move_backward
  - use __bit_width and __to_unsigned_like instead of __lg

PR libstdc++/100795
PR libstdc++/118209

libstdc++-v3/ChangeLog:

* include/bits/max_size_type.h (__bit_width): New explicit
specialization for __max_size_type.
* include/bits/ranges_algo.h (__detail::__move_median_to_first):
New, based on the stl_algo.h implementation.
(__detail::__unguarded_liner_insert): Likewise.
(__detail::__insertion_sort): Likewise.
(__detail::__sort_threshold): Likewise.
(__detail::__unguarded_insertion_sort): Likewise.
(__detail::__final_insertion_sort): Likewise.
(__detail::__unguarded_partition): Likewise.
(__detail::__unguarded_partition_pivot): Likewise.
(__detail::__heap_select): Likewise.
(__detail::__partial_sort): Likewise.
(__detail::__introsort_loop): Likewise.
(__sort_fn::operator()): Reimplement in terms of the above.
* testsuite/25_algorithms/sort/118209.cc: New test.
* testsuite/25_algorithms/sort/constrained.cc (test03): New test.

Reviewed-by: Tomasz KamiÅski 
Reviewed-by: Jonathan Wakely 

[Bug libstdc++/100795] ranges::sample, ranges::sort etc should not use std::sample, std::sort etc directly

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

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

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

https://gcc.gnu.org/g:92417c387365033cac4fff7ec8da2b42bd75dfba

commit r16-1741-g92417c387365033cac4fff7ec8da2b42bd75dfba
Author: Patrick Palka 
Date:   Fri Jun 27 13:53:06 2025 -0400

libstdc++: Directly implement ranges::sort [PR100795]

As with the previous patch, this patch reimplements ranges::sort
directly instead of incorrectly forwarding to std::sort.  In addition to
the compatibility changes listed in the previous patch we also:

  - use ranges::iter_swap instead of std::iter_swap
  - use ranges::move_backward instead of std::move_backward
  - use __bit_width and __to_unsigned_like instead of __lg

PR libstdc++/100795
PR libstdc++/118209

libstdc++-v3/ChangeLog:

* include/bits/max_size_type.h (__bit_width): New explicit
specialization for __max_size_type.
* include/bits/ranges_algo.h (__detail::__move_median_to_first):
New, based on the stl_algo.h implementation.
(__detail::__unguarded_liner_insert): Likewise.
(__detail::__insertion_sort): Likewise.
(__detail::__sort_threshold): Likewise.
(__detail::__unguarded_insertion_sort): Likewise.
(__detail::__final_insertion_sort): Likewise.
(__detail::__unguarded_partition): Likewise.
(__detail::__unguarded_partition_pivot): Likewise.
(__detail::__heap_select): Likewise.
(__detail::__partial_sort): Likewise.
(__detail::__introsort_loop): Likewise.
(__sort_fn::operator()): Reimplement in terms of the above.
* testsuite/25_algorithms/sort/118209.cc: New test.
* testsuite/25_algorithms/sort/constrained.cc (test03): New test.

Reviewed-by: Tomasz KamiÅski 
Reviewed-by: Jonathan Wakely 

[Bug sanitizer/120837] False-positive from -fsanitize=undefined

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

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

--- Comment #6 from Sam James  ---
Created attachment 61737
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61737&action=edit
a-shell.i.xz

[Bug tree-optimization/120358] [15/16 regression] qtbase-6.9.0 miscompiled since r15-580-gf3e5f4c58591f5

[holger--- via Gcc-bugs]

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

--- Comment #7 from Holger Hoffstätte  ---
Sorry if the following is unhelpful - I'm just an interested observer.

Since I could easily reproduce the problem I decided to poke at things
in gdb and got a bit annoyed at the bad test code style. So I un-inlined
the call to expected.join() into a local and .. all tests pass.
Yay?

--- a/tst_qstringtokenizer.cpp.ii
+++ b/tst_qstringtokenizer_hh.cpp.ii
@@ -257685,7 +257685,8 @@ void tst_QStringTokenizer::basics() const
 expected = skipped(expected);

 using namespace std::string_literals;
-auto tok = qTokenize(expected.join(u'x'), QLatin1Char('x'), cs, sb);
+auto joined = expected.join(u'x');
+auto tok = qTokenize(joined, QLatin1Char('x'), cs, sb);
 do { if (!QTest::qCompare(toQStringList(tok), expected,
"toQStringList(tok)", "expected",
"/home/sam/bugs/qt/qtbase-everywhere-src-6.9.0/tests/auto/corelib/text/qs>
 }

Is this maybe a temporary/lifetime thing going wrong?

[Bug sanitizer/120837] False-positive from -fsanitize=undefined

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

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

--- Comment #7 from Jakub Jelinek  ---
Self-contained testcase:

[[gnu::noipa]] void
bar (void **x, void **y)
{
  x[0] = 0;
  x[1] = 0;
  x[2] = 0;
  y[0] = 0;
  y[1] = 0;
  y[2] = 0;
  y[3] = 0;
  y[4] = 0;
}

[[gnu::noipa]] void *
foo (int x, int y)
{
  void *a[3];
  void *b[5];
  bar (a, b);
  return (x > y ? b : a)[y - 1];
}

int
main ()
{
  if (foo (2, 1) != 0)
__builtin_abort ();
}

Something during the C GENERIC folding creates invalid code out of it (but C++
doesn't):
*((nNew > nOld ? (void * *) &apNew + 18446744073709551608 : (void * *) &apOld +
18446744073709551608) + (sizetype) ((long unsigned int) nOld * 8))
and later comes ubsan and is really unhappy about the negative offsets to
arrays.

[Bug fortran/120784] fortran: issue with use-association renames and interface

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

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

--- Comment #9 from anlauf at gcc dot gnu.org ---
Fixed by:

diff --git a/gcc/fortran/interface.cc b/gcc/fortran/interface.cc
index cdb838d8336..7899864158c 100644
--- a/gcc/fortran/interface.cc
+++ b/gcc/fortran/interface.cc
@@ -457,7 +457,9 @@ gfc_match_end_interface (void)

   if (current_interface.sym->attr.use_assoc
  && current_interface.sym->attr.use_rename
- && current_interface.sym->ns->use_stmts->rename)
+ && current_interface.sym->ns->use_stmts->rename
+ && (current_interface.sym->ns->use_stmts->rename->local_name[0]
+ != '\0'))
local_name = current_interface.sym->ns->use_stmts->rename->local_name;

   if (type != current_interface.type

Will regtest...

[Bug target/120818] [16 Regression] g++.target/i386/shrink_wrap_separate.C FAILs

[ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs]

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

--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
Hi Lili,

> Thank you for reporting this issue and giving the actual output. I have 
> relaxed
> the testcase check. Could you test this patch in your environment? Thank you
> very much.

I've just successfully tested your patch on i386-pc-solaris2.11 (32 and
64-bit).  Thanks for the quick fix.

Btw., there's a typo in the ChangeLog entry:

PR target/120818
* g++.target/i386/shrink_wrap_separate.C: Ralax the check.
   ^

[Bug c++/120845] [16 Regression] C++ multiline module declaration is not accepted by g++

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

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

--- Comment #4 from Jakub Jelinek  ---
A new-line character ends the preprocessing directive even ...

[Bug libstdc++/112641] : `drop_view::begin const` has O(n) complexity

[hewillk at gmail dot com via Gcc-bugs]

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

--- Comment #7 from 康桓瑋  ---
(In reply to Patrick Palka from comment #6)
> Fixed for 15 / 14.3 / 13.4

But you didn't *optimize* the non-const begin, right?

[Bug c++/120845] [16 Regression] C++ multiline module declaration is not accepted by g++

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

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

Jonathan Wakely  changed:

   What|Removed |Added

Summary|C++ multiline module|[16 Regression] C++
   |declaration is not accepted |multiline module
   |by g++  |declaration is not accepted
   ||by g++
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2025-06-27
 Blocks||103524
   Keywords||ice-on-valid-code,
   ||rejects-valid
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
It's rejects-valid for GCC 14 and 15:

mod.cc:2:37: error: expected end of line at end of input
2 | [[this_is_a_useless_attribute]];
  | ^
mod.cc:2: confused by earlier errors, bailing out



And ice-on-valid-code for trunk, since r15-4847:

./mod.cc:2:36: internal compiler error: in declare_module, at
cp/module.cc:21566
2 | [[this_is_a_useless_attribute]];
  |^
0x23cfbe1 internal_error(char const*, ...)
/home/jwakely/src/gcc/gcc/gcc/diagnostic-global-context.cc:517
0x71976d fancy_abort(char const*, int, char const*)
/home/jwakely/src/gcc/gcc/gcc/diagnostic.cc:1810
0x479043 declare_module(module_state*, unsigned long, bool, tree_node*,
cpp_reader*)
/home/jwakely/src/gcc/gcc/gcc/cp/module.cc:21566
0x905e7e cp_parser_module_declaration
/home/jwakely/src/gcc/gcc/gcc/cp/parser.cc:15745
0x9326db cp_parser_translation_unit
/home/jwakely/src/gcc/gcc/gcc/cp/parser.cc:5461
0x9326db c_parse_file()
/home/jwakely/src/gcc/gcc/gcc/cp/parser.cc:54298
0xa94981 c_common_parse_file()
/home/jwakely/src/gcc/gcc/gcc/c-family/c-opts.cc:1385
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524
[Bug 103524] [meta-bug] modules issue

[Bug target/120840] [16 Regression] CPython miscompiled with preserve_none

[hjl.tools at gmail dot com via Gcc-bugs]

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

--- Comment #9 from H.J. Lu  ---
Created attachment 61731
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61731&action=edit
A workaround patch

This workaround patch works for me.

[Bug testsuite/120846] vect_dotprod_hisi is used inconsistently with documentation and name in Test of autovectorization of different dot-prod modes

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

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

--- Comment #1 from Richard Biener  ---
I guess the testcase assumes that the qi->si case gets an intermediate
qi->hi promotion and then dotprod_hisi being used.  But it fails to check
for the ability to do qi->hi promotion.  Is that what your target is missing?

OTOH I didn't check what the aarch64 codegen does but I understood Tamar
that aarch64 only has hisi dotprod, not qisi.

[Bug testsuite/120846] vect_dotprod_hisi is used inconsistently with documentation and name in Test of autovectorization of different dot-prod modes

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

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

--- Comment #2 from Richard Biener  ---
vect_unpack would be required to perform qi->hi promotion.

[Bug c++/120845] [16 Regression] C++ multiline module declaration is not accepted by g++

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |16.0

[Bug fortran/120847] [Coarray] ICE after "Component ... already declared at..." when type with coarray comp is defined

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

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

Andre Vehreschild  changed:

   What|Removed |Added

   Priority|P3  |P4
   Keywords||rejects-valid

[Bug c++/120845] New: C++20 module syntax

[shyeyian at petalmail dot com via Gcc-bugs]

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

Bug ID: 120845
   Summary: C++20 module syntax
   Product: gcc
   Version: 15.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: shyeyian at petalmail dot com
  Target Milestone: ---

Codes below is not accepted in g++(15.1), while accepted in clang++(20.1) and
msvc(17):
```cpp
export module my_module
[[this_is_a_useless_attribute]];
```


g++ requires this attribute to be in same line as `my_module`, like
```cpp
export module my_module [[attribute_in_same_line]];
```
while clang++ and msvc does not have this requirement


According to
[cppreference](https://cppreference.com/w/cpp/language/modules.html), an
`export module` declaration has syntax below:
```
export(optional) module module-name module-partition (optional) attr
(optional) ;
```
It seems that module declaration is not demanded to be in one line. Maybe a
tiny change in AST will work :)


/*
As is known to all, no attributes is useful to modules currently. However
someone (like me) will write some additional module like this:
```cpp
export module my_module
[[cmake(./path/to/dir/CMakeLists.txt)]]
[[import_library(library.a)]];
```
and an external parser
```py
python_parse_and_cmake_and_integrate_install(module.cpp)
```
In this corner case we hope the module declaration (with attributes) can be
multi-lined.
*/

Thank you!

[Bug tree-optimization/120358] [15/16 regression] qtbase-6.9.0 miscompiled since r15-580-gf3e5f4c58591f5

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

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

--- Comment #5 from Richard Biener  ---
(In reply to Sam James from comment #0)
> Looking at dumps between r15-579-ga9251ab3c91c8c and
> r15-580-gf3e5f4c58591f5, there's a lot of noise like:
> ```
> -  # PT = nonlocal escaped null { D.387695 D.418643 } (nonlocal, escaped)
> -  # USE = nonlocal escaped null { D.387695 D.418643 } (nonlocal, escaped)
> -  # CLB = nonlocal escaped null { D.387695 D.418643 } (nonlocal, escaped)
> +  # PT = nonlocal escaped null const-pool { D.387695 D.418643 } (nonlocal,
> escaped)
> +  # USE = nonlocal escaped null const-pool { D.387695 D.418643 } (nonlocal,
> escaped)
> +  # CLB = nonlocal escaped null const-pool { D.387695 D.418643 } (nonlocal,
> escaped)
> ```

without a testcase it's hard to see what goes wrong - the above is a
correctness fix, we get strictly larger points-to sets.  For ptr-ptr
compares we rely on those being conservative, so possibly we miss more.

I'll note the newer preprocessed source doesn't build around the offending rev
(the old does).

The first actual IL difference happens in VRP1.  Differences in wc -l for
all dump files (w/o details):

qt.ii.120t.threadfull1 0
qt.ii.121t.vrp1 20
qt.ii.122t.dse2 30
..
qt.ii.149t.walloca2 20
qt.ii.150t.pre 29
qt.ii.151t.sink1 53
qt.ii.155t.dse3 43
...
qt.ii.202t.thread2 7
qt.ii.203t.dom3 49
qt.ii.204t.strlen1 39
qt.ii.205t.threadfull2 180
qt.ii.206t.vrp2 106

it's not definite data since there's stuff that should be in -details
leaking into normal dumps.  It's quite difficult to isolate an
offending transform.  Possibly adding a dbgcnt to ptrs_compare_unequal
when it triggers the ptr-vs.-ptr case can track down the bogus offender...

[Bug target/120818] [16 Regression] g++.target/i386/shrink_wrap_separate.C FAILs

[ubizjak at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Uroš Bizjak  ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #2)
> Hi Lili,
> 
> > Thank you for reporting this issue and giving the actual output. I have 
> > relaxed
> > the testcase check. Could you test this patch in your environment? Thank you
> > very much.
> 
> I've just successfully tested your patch on i386-pc-solaris2.11 (32 and
> 64-bit).  Thanks for the quick fix.
> 
> Btw., there's a typo in the ChangeLog entry:
> 
>   PR target/120818
>   * g++.target/i386/shrink_wrap_separate.C: Ralax the check.
>^

LGTM.

[Bug target/120818] [16 Regression] g++.target/i386/shrink_wrap_separate.C FAILs

[lili.cui at intel dot com via Gcc-bugs]

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

--- Comment #4 from cuilili  ---
Thank you all！

[Bug testsuite/120846] New: vect_dotprod_hisi is used inconsistently with documentation and name in Test of autovectorization of different dot-prod modes

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

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

Bug ID: 120846
   Summary: vect_dotprod_hisi is used inconsistently with
documentation and name in Test of autovectorization of
different dot-prod modes
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: amylaar at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org, victorldn at gcc dot gnu.org
  Target Milestone: ---

The documentation for check_effective_target_vect_dotprod_hisi says:
# Return 1 if the target supports two-way dot products on inpus of hi mode
# producing si outputs, 0 otherwise.

However, gcc.dg/vect/vect-dotprod-conv-optab.c uses this check to also gate a
test
for a v4qisi dot product.

I am trying to get sensible test results for a processor family that has v2hi
-> si
dot product across a large part of the subtargets, but has byte vectors and the
related conversions only for a much smaller subset.

The udot4 function clearly requires v4qi->si dotproduct functionality to
vectorize,
so I can't understand the reasoning in
https://gcc.gnu.org/pipermail/gcc-patches/2024-August/660867.html
.

Is the test supposed to check vectorization of both the hisi and qisi
dotproduct, but only if both are supported, or should it check each depending
on if the specific operations is expected to be vectorized?

[Bug c++/120845] [16 Regression] C++ multiline module declaration is not accepted by g++

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

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

--- Comment #5 from Jakub Jelinek  ---
The more important is the
The last preprocessing token in the sequence is the first preprocessing token
within the sequence that is immediately followed by whitespace containing a
new-line character.
line before that.
So, for
export module my_module
[[this_is_a_useless_attribute]];
the last preprocessing token in the sequence is my_module and so it isn't a
valid preprocessing directive because export module must have ; as the last
preprocessing token.

[Bug c++/120848] New: -fmodule-header -fmodules-ts -x c++-system-header dives into symbolic links

[piotr5 at netscape dot net via Gcc-bugs]

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

Bug ID: 120848
   Summary: -fmodule-header -fmodules-ts -x c++-system-header
dives into symbolic links
   Product: gcc
   Version: 14.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: piotr5 at netscape dot net
  Target Milestone: ---

I compiled gcc while my root directory is a bunch of symbolic links into the
directory /systemd/.
then a cpp file with 

import ;

will search for the module in 
gcm.cache/./systemd/usr/lib/gcc/x86_64-pc-linux-gnu/14/include/g++-v14/print.gcm
whereas the command

g++ -std=c++26 -fmodule-header -fmodules-ts -x c++-system-header
/usr/lib/gcc/x86_64-pc-linux-gnu/14/include/g++-v14/print

will create a file
gcm.cache/usr/lib/gcc/x86_64-pc-linux-gnu/14/include/g++-v14/print.gcm
which naturally cannot be found by said sourcefile.
quick fix is to make systemd a symbolic link to ./ in gcm.cache

now the question is how to fix that bug properly.
the fix I'd prefer is if building gcc wouldn't look up link-redirection when
setting the include directories and others. but that might as well be the fault
of the gentoo build-system. next best solution is to discover the symlink and
populate gcm-cache accordingly by creating necessary reverse-symlinks. what is
a bad solution is to outright eliminate all symlinks before deciding on a
pathname inside the gcm.cache directory. recompiling gcc in a chroot
environment would render such a directory uselessly cluttered with outputs from
old version. as it is, I could provide that "resolved" path too, so there
wouldn't be any new functionality. i.e. what I want is to build the directory
structure I provide at command line and then add a symlink emulating the actual
directory structure. so if I give to the command-line the most symlink-heavy
path, partial resolving of symlink elements would still find the right file in
gcm.cache anyway...

anyway, however you approach this problem, keep in mind this is not a high
priority issue but rather a quality-of-life enhancement. if you do find a
solution, would be nice if it eventually found a way into stdlib for a future
standard as I do think other programs might struggle with similar issues in
linux filesystems...

[Bug target/119971] [15 Regression] RISC-V: Wrong code with bitmanip extension

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

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

--- Comment #8 from GCC Commits  ---
The master branch has been updated by Jeff Law :

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

commit r16-1732-gde6124c9e5ed472f567b51fa76f18335cdddbbaf
Author: Jeff Law 
Date:   Fri Jun 27 07:00:15 2025 -0600

[RISC-V][PR target/119971] Avoid losing shift count masking

Fix typo spotted by Bernhard Reutner-Fischer.

PR target/119971

gcc/testsuite/
* gcc.target/riscv/pr119971.c: Fix typo.

[Bug middle-end/56183] [meta-bug][avr] Problems with register allocation

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

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

Bug 118591 Summary: [lra][avr] Wrong code with -mlra in pr43879-3.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118591

   What|Removed |Added

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

[Bug target/113934] Switch avr to LRA

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

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

Bug 118591 Summary: [lra][avr] Wrong code with -mlra in pr43879-3.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118591

   What|Removed |Added

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

[Bug rtl-optimization/118591] [lra][avr] Wrong code with -mlra in pr43879-3.c

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

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

Georg-Johann Lay  changed:

   What|Removed |Added

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

--- Comment #7 from Georg-Johann Lay  ---
The test case works now after the patches for PR120424 are upstream.

[Bug c++/120471] [12/13/14/15/16 regression] -fsanitize=undefined causes read of uninitialized variable when accessing element in an array at -O0 level

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #14 from Jakub Jelinek  ---
Created attachment 61733
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61733&action=edit
gcc16-pr120471.patch

Untested fix.

[Bug c++/120040] Module ICE when constexpr function calls new on class withe empty destructor.

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

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

Nathaniel Shead  changed:

   What|Removed |Added

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

--- Comment #4 from Nathaniel Shead  ---
Fixed for GCC 16.

[Bug tree-optimization/120358] [15/16 regression] qtbase-6.9.0 miscompiled since r15-580-gf3e5f4c58591f5

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

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

--- Comment #6 from Sam James  ---
(In reply to Richard Biener from comment #5)

I'll find some time to try make more progress. Will try adding a counter if I
cannot get further with reducing, but luckily, the C++ in the file isn't too
complex ;)

[Bug fortran/120843] [Coarray] Inconsistent ranks for operator reported when coarray ranks differ

[jvdelisle2 at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Jerry DeLisle  ---
This is the error I am seeing.

On Fri, Jun 27, 2025, 12:38 AM vehre at gcc dot gnu.org via Gcc-bugs <
gcc-bugs@gcc.gnu.org> wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120843
>
> Bug ID: 120843
>Summary: [Coarray] Inconsistent ranks for operator reported
> when coarray ranks differ
>Product: gcc
>Version: 16.0
> Status: UNCONFIRMED
>   Severity: normal
>   Priority: P3
>  Component: fortran
>   Assignee: unassigned at gcc dot gnu.org
>   Reporter: vehre at gcc dot gnu.org
>   Target Milestone: ---
>
> Reproducer:
>
> program p
>   implicit none
>
>   integer, allocatable :: arr(:,:) [:,:]
>
>   integer :: c[*]
>   integer :: i,j
>
>   c = 7
>
>   allocate(arr(4,3)[2,*], source=6)
>
>   do i = 1, 4
> do j = 1, 3
>   print *, arr(i, j)* c
> end do
>   end do
>
> end program p
>
> results in:
>
> $ gfortran-16 -c p.f90 -fcoarray=lib
> p.f90:15:18-27:
>
>15 |   print *, arr(i, j)* c
>   |  12
> Error: Inconsistent ranks for operator at (1) and (2)

[Bug target/113934] Switch avr to LRA

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

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

--- Comment #14 from Segher Boessenkool  ---
Congratulations, and thank you!

[Bug middle-end/120608] [15/16 regression] error: cannot tail-call: other reasons when using address sanitizer with musttail

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

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

--- Comment #20 from Jakub Jelinek  ---
Created attachment 61735
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61735&action=edit
gcc16-pr120608.patch

Untested fix.

[Bug target/55212] [SH] Switch to LRA

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

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

--- Comment #456 from Oleg Endo  ---
(In reply to John Paul Adrian Glaubitz from comment #455)
> Created attachment 61734 [details]
> Error log for building gcc-16 with LRA enabled, no patches
> 
> (In reply to John Paul Adrian Glaubitz from comment #454)
> > (In reply to Oleg Endo from comment #453)
> > > As we have already learned from this PR here, a bootstrap is not 
> > > sufficient
> > > evidence that everything works normally.  If it bootstraps and can't 
> > > compile
> > > other software we're back to sqrt(1).  So it needs at least full testing 
> > > of
> > > the included gcc testsuite.
> > 
> > I didn't say I would stop after the bootstrap ;-). Of course, I will perform
> > more tests if the LRA bootstrap works.
> 
> Bootstrap fails with a very long list of errors. I'll attach the error log.

That was almost expected.  Of course we can't just omit all the changes per se.

[Bug debug/120849] New: Missing debug (tree)

[hjl.tools at gmail dot com via Gcc-bugs]

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

Bug ID: 120849
   Summary: Missing debug (tree)
   Product: gcc
   Version: 16.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
  Target Milestone: ---

There is no

extern void debug (tree);

[Bug target/120839] [16 Regression] ICE on x86_64-linux-gnu: in ix86_finalize_stack_frame_flags, at config/i386/i386.cc:8738 at -O1 and above with aligned on struct

[hjl.tools at gmail dot com via Gcc-bugs]

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

--- Comment #4 from H.J. Lu  ---
User alignment is ignored for parameters passed on stack:

static unsigned int
ix86_function_arg_boundary (machine_mode mode, const_tree type) 
{
  unsigned int align;
  if (type)
{
  /* Since the main variant type is used for call, we convert it to
 the main variant type.  */
  type = TYPE_MAIN_VARIANT (type);
  align = TYPE_ALIGN (type);
  if (TYPE_EMPTY_P (type))
return PARM_BOUNDARY;
}
  else  
align = GET_MODE_ALIGNMENT (mode);

But RTL expansion has

(insn 5 2 6 2 (set (reg:XF 100)
(mem/c:XF (reg/f:DI 92 virtual-incoming-args) [1 f.a+0 S16 A256]))
"x.c":9:8 -1
 (nil))

It should be A128, not A256.

[Bug c++/55004] [meta-bug] constexpr issues

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

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

Bug 120777 Summary: [C++26] P3533R2 - constexpr virtual inheritance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120777

   What|Removed |Added

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

[Bug c++/110338] Implement C++26 language features

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

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

Bug 120777 Summary: [C++26] P3533R2 - constexpr virtual inheritance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120777

   What|Removed |Added

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

[Bug c++/120756] [12/13/14/15/16 Regression] internal compiler error: error reporting routines re-entered with [[deprecated]]

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

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

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

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

commit r16-1754-ga394cfb29adf603b72151d2423270db6516b05ed
Author: Marek Polacek 
Date:   Wed Jun 25 10:29:49 2025 -0400

c++: fix ICE with [[deprecated]] [PR120756]

Here we end up with "error reporting routines re-entered" because
resolve_nondeduced_context isn't passing complain to mark_used.

PR c++/120756

gcc/cp/ChangeLog:

* pt.cc (resolve_nondeduced_context): Pass complain to mark_used.

gcc/testsuite/ChangeLog:

* g++.dg/warn/deprecated-22.C: New test.

Reviewed-by: Jason Merrill 

[Bug middle-end/89544] Argument marshalling incorrectly assumes stack slots are naturally aligned.

[hjl.tools at gmail dot com via Gcc-bugs]

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

H.J. Lu  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2025-06-27
 CC||hjl.tools at gmail dot com
 Status|UNCONFIRMED |NEW

--- Comment #10 from H.J. Lu  ---
On x86, arguments on stack also have natural alignment:

[hjl@gnu-tgl-3 pr120839]$ cat x.c
typedef struct {
  long double a;
  long double b;
} c __attribute__((aligned(32)));
extern double d;
void
e (c f)
{
  _Static_assert (__alignof (f) == 16, "__alignof (f) == 16)");
  d = f.a;
}
[hjl@gnu-tgl-3 pr120839]$ make CC=gcc  
gcc -O2 -S x.c
x.c: In function ‘e’:
x.c:9:3: error: static assertion failed: "__alignof (f) == 16)"
9 |   _Static_assert (__alignof (f) == 16, "__alignof (f) == 16)");
  |   ^~
make: *** [Makefile:36: x.s] Error 1
[hjl@gnu-tgl-3 pr120839]$

[Bug sanitizer/119356] [15 Regression] libsanitizer fails to build on riscv musl

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

Summary|[15/16 regression]  |[15 Regression]
   |libsanitizer fails to build |libsanitizer fails to build
   |on riscv musl   |on riscv musl

--- Comment #8 from Jeffrey A. Law  ---
Should be fixed on the trunk.  If you could verify Sam it'd be appreciated.

[Bug fortran/120784] fortran: issue with use-association renames and interface

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

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

--- Comment #12 from GCC Commits  ---
The releases/gcc-15 branch has been updated by Harald Anlauf
:

https://gcc.gnu.org/g:1b8a32a0bb69b52fa8d1b80cdb6a1581d0cfa5d4

commit r15-9869-g1b8a32a0bb69b52fa8d1b80cdb6a1581d0cfa5d4
Author: Harald Anlauf 
Date:   Fri Jun 27 23:00:48 2025 +0200

Fortran: follow-up fix to checking of renamed-on-use interface name
[PR120784]

Commit r16-1633 introduced a regression for imported interfaces that were
not renamed-on-use, since the related logic did not take into account that
the absence of renaming could be represented by an empty string.

PR fortran/120784

gcc/fortran/ChangeLog:

* interface.cc (gfc_match_end_interface): Detect empty local_name.

gcc/testsuite/ChangeLog:

* gfortran.dg/interface_63.f90: Extend testcase.

(cherry picked from commit ddff83b3dde4a8308d0e156f85693e7176b85524)

[Bug target/120839] [16 Regression] ICE on x86_64-linux-gnu: in ix86_finalize_stack_frame_flags, at config/i386/i386.cc:8738 at -O1 and above with aligned on struct

[hjl.tools at gmail dot com via Gcc-bugs]

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

--- Comment #3 from H.J. Lu  ---
crtl->parm_stack_boundary == 128 looks odd:

(gdb) list
2612 stack.  */
2613  if (!in_regs && crtl->parm_stack_boundary < data->locate.boundary)
2614crtl->parm_stack_boundary = data->locate.boundary;
2615
2616  /* Adjust offsets to include the pretend args.  */
2617  pretend_bytes = all->extra_pretend_bytes - pretend_bytes;
2618  data->locate.slot_offset.constant += pretend_bytes;
2619  data->locate.offset.constant += pretend_bytes;
2620
2621  data->entry_parm = entry_parm;
(gdb) call debug_tree (data->arg->type)
  constant 256>
unit-size  constant 32>
user align:256 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7fffe99cebd0
fields 
unit-size 
align:128 warn_if_not_align:0 symtab:0 alias-set 1 canonical-type
0x7fffe982a3f0 precision:80
pointer_to_this >
XF x.c:2:15 size  unit-size

align:128 warn_if_not_align:0 offset_align 128 decl_not_flexarray: 1
offset 
bit-offset  context 
chain 
XF x.c:3:15 size  unit-size

align:128 warn_if_not_align:0 offset_align 128 decl_not_flexarray:
1 offset  bit-offset  context >>
pointer_to_this >
(gdb) p data->locate.boundary
$9 = 128
 Shouldn't it be 256?
(gdb)

[Bug fortran/120812] [regression] buffer(80:80) = C_NEW_LINE not working with gfortran 15.1 under Mac

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

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

--- Comment #12 from anlauf at gcc dot gnu.org ---
(In reply to Christophe Peyret from comment #11)
> same on Mac ARM :)

Good.  So it is most likely the issue with SAVEd pointer/allocatable
that was recently fixed.

To verify, you can try the following using the code where the => NULL()
was removed from the declaration:

- compile with -fno-automatic
  --> this will very likely reproduce your issue with 15.1

- compile with -fautomatic (which is the default)
  --> I expect this to work

[Bug fortran/120784] fortran: issue with use-association renames and interface

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

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

--- Comment #10 from anlauf at gcc dot gnu.org ---
Regtested fine here.

Submitted: https://gcc.gnu.org/pipermail/fortran/2025-June/062395.html

[Bug fortran/120784] fortran: issue with use-association renames and interface

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

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

--- Comment #11 from GCC Commits  ---
The master branch has been updated by Harald Anlauf :

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

commit r16-1749-gddff83b3dde4a8308d0e156f85693e7176b85524
Author: Harald Anlauf 
Date:   Fri Jun 27 23:00:48 2025 +0200

Fortran: follow-up fix to checking of renamed-on-use interface name
[PR120784]

Commit r16-1633 introduced a regression for imported interfaces that were
not renamed-on-use, since the related logic did not take into account that
the absence of renaming could be represented by an empty string.

PR fortran/120784

gcc/fortran/ChangeLog:

* interface.cc (gfc_match_end_interface): Detect empty local_name.

gcc/testsuite/ChangeLog:

* gfortran.dg/interface_63.f90: Extend testcase.

[Bug c++/120777] [C++26] P3533R2 - constexpr virtual inheritance

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

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

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

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

commit r16-1751-gf86ebb00406dafed3b8ebeae6e9e9d613abdf2ec
Author: Jakub Jelinek 
Date:   Fri Jun 27 23:39:30 2025 +0200

c++: Implement C++26 P3533R2 - constexpr virtual inheritance [PR120777]

The following patch implements the C++26
P3533R2 - constexpr virtual inheritance
paper.
The changes include not rejecting it for C++26, tweaking the
error wording to show that it is valid in C++26, adjusting
synthesized_method_walk not to make synthetized cdtors non-constexpr
just because of virtual base classes in C++26 and various tweaks in
constexpr.cc so that it can deal with the expressions used for
virtual base member accesses or cdtor calls which need __in_chrg
and/or __vtt_parm arguments to be passed in some cases implicitly when
they aren't passed explicitly.  And dynamic_cast constant evaluation
tweaks so that it handles also expressions with types with virtual bases.

2025-06-27  Jakub Jelinek  

PR c++/120777
gcc/
* gimple-fold.cc (gimple_get_virt_method_for_vtable): Revert
2018-09-18 changes.
gcc/c-family/
* c-cppbuiltin.cc (c_cpp_builtins): Predefine
__cpp_constexpr_virtual_inheritance=202506L for C++26.
gcc/cp/
* constexpr.cc: Implement C++26 P3533R2 - constexpr virtual
inheritance.
(is_valid_constexpr_fn): Don't reject constexpr cdtors in classes
with virtual bases for C++26, adjust error wording.
(cxx_bind_parameters_in_call): Add ORIG_FUN argument, add
values for __in_chrg and __vtt_parm arguments when needed.
(cxx_eval_dynamic_cast_fn): Adjust function comment, HINT -1
should be possible.  For C++26 if obj is cast from
POINTER_PLUS_EXPR,
attempt to use cxx_fold_indirect_ref to simplify it and if
successful,
build ADDR_EXPR of that.
(cxx_eval_call_expression): Add orig_fun variable, set it to
fun before looking through clones, pass it to
cxx_bind_parameters_in_call.
(reduced_constant_expression_p): Add SZ argument, pass DECL_SIZE
of FIELD_DECL e.index to recursive calls and don't return false
if SZ is non-NULL and there are unfilled fields with bit position
at or above SZ.
(cxx_fold_indirect_ref_1): Handle reading of vtables using
ptrdiff_t dynamic type instead of some pointer type.  Set el_sz
to DECL_SIZE_UNIT value rather than TYPE_SIZE_UNIT of
DECL_FIELD_IS_BASE fields in classes with virtual bases.
(cxx_fold_indirect_ref): In canonicalize_obj_off lambda look
through COMPONENT_REFs with DECL_FIELD_IS_BASE in classes with
virtual bases and adjust off correspondingly.  Remove assertion
that
off is integer_zerop, pass tree_to_uhwi (off) instead of 0 to the
cxx_fold_indirect_ref_1 call.
* cp-tree.h (publicly_virtually_derived_p): Declare.
(reduced_constant_expression_p): Add another tree argument
defaulted
to NULL_TREE.
* method.cc (synthesized_method_walk): Don't clear *constexpr_p
if there are virtual bases for C++26.
* class.cc (build_base_path): Compute fixed_type_p and
virtual_access before checks for build_simple_base_path instead of
after that and conditional cp_build_addr_expr.  Use
build_simple_path
if !virtual_access even when v_binfo is non-NULL.
(layout_virtual_bases): For build_base_field calls use
access_public_node rather than access_private_node if
publicly_virtually_derived_p.
(build_vtbl_initializer): Revert 2018-09-18 and 2018-12-11 changes.
(publicly_virtually_derived_p): New function.
gcc/testsuite/
* g++.dg/cpp26/constexpr-virt-inherit1.C: New test.
* g++.dg/cpp26/constexpr-virt-inherit2.C: New test.
* g++.dg/cpp26/constexpr-virt-inherit3.C: New test.
* g++.dg/cpp26/feat-cxx26.C: Add
__cpp_constexpr_virtual_inheritance
tersts.
* g++.dg/cpp2a/constexpr-dtor3.C: Don't expect one error for C++26.
* g++.dg/cpp2a/constexpr-dtor16.C: Don't expect errors for C++26.
* g++.dg/cpp2a/constexpr-dynamic10.C: Likewise.
* g++.dg/cpp0x/constexpr-ice21.C: Likewise.
* g++.dg/cpp0x/constexpr-ice4.C: Likewise.
* g++.dg/abi/mangle1.C: Guard the test on c++23_down.
* g++.dg/abi/mangle81.C: New test.
* g++.dg/ipa/ipa-icf-4.C (A::A): For
__cpp_constexpr_virtual_inheritance >= 202506L add user provided
non-constexpr cons

[Bug c++/120777] [C++26] P3533R2 - constexpr virtual inheritance

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Resolution|--- |FIXED
   Target Milestone|--- |16.0

--- Comment #5 from Jakub Jelinek  ---
Implemented for 16.1+.

[Bug target/120839] [16 Regression] Incorrect alignment for arguments on stack

[hjl.tools at gmail dot com via Gcc-bugs]

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

H.J. Lu  changed:

   What|Removed |Added

Summary|[16 Regression] ICE on  |[16 Regression] Incorrect
   |x86_64-linux-gnu: in|alignment for arguments on
   |ix86_finalize_stack_frame_f |stack
   |lags, at|
   |config/i386/i386.cc:8738 at |
   |-O1 and above with aligned  |
   |on struct   |

--- Comment #5 from H.J. Lu  ---
set_mem_attrs has

  if (!MEM_ATTRS (mem)
  || !mem_attrs_eq_p (attrs, MEM_ATTRS (mem)))
{
  MEM_ATTRS (mem) = ggc_alloc ();
  memcpy (MEM_ATTRS (mem), attrs, sizeof (mem_attrs));
}

But a backend may ignore user type alignment for arguments passed on stack.
As the result, arguments passed on stack may have wrong MEM_ALIGN.

[Bug target/120839] [16 Regression] Incorrect alignment for arguments on stack

[hjl.tools at gmail dot com via Gcc-bugs]

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

--- Comment #6 from H.J. Lu  ---
Created attachment 61739
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61739&action=edit
A patch

I am testing this.

[Bug tree-optimization/120358] [15/16 regression] qtbase-6.9.0 miscompiled since r15-580-gf3e5f4c58591f5

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

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

--- Comment #9 from Sam James  ---
Created attachment 61740
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61740&action=edit
foo.ii.xz

[Bug tree-optimization/120358] [15/16 regression] qtbase-6.9.0 miscompiled since r15-580-gf3e5f4c58591f5

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

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

Sam James  changed:

   What|Removed |Added

 CC||kacper.slominski72 at gmail 
dot co
   ||m

--- Comment #8 from Sam James  ---
Kacper Słomiński has got it down to:
```
#include 
#include 

int main() {
auto expected = QStringList{"a", "b", "c", "d", "e"};
auto tok = qTokenize(expected.join(u'x'), QLatin1Char('x'),
Qt::CaseSensitive, Qt::SkipEmptyParts);

QStringList r;
for (auto &&e : tok)
r.push_back(e.toString());

if (r.size() != expected.size()) abort();
}
```

which fails with:
```
$ g++ -DQT_NO_DEBUG $(pkg-config --libs --cflags Qt6Core) -std=gnu++17 foo.cxx
-o foo -O3 && ./foo
```

I'll attach preprocessed source for that but we're working on killing the Qt
dependency next.