[Bug c/101478] [12 Regression] ICE with statement expression and offsetof like expression since r10-7127-gcb99630f254aae

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

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

--- Comment #11 from GCC Commits  ---
The releases/gcc-12 branch has been updated by Richard Biener
:

https://gcc.gnu.org/g:05b347c5322a50195aa3ab0d06f2058f0ccee956

commit r12-11217-g05b347c5322a50195aa3ab0d06f2058f0ccee956
Author: Richard Biener 
Date:   Wed Jul 31 10:07:45 2024 +0200

middle-end/101478 - ICE with degenerate address during gimplification

When we gimplify &MEM[0B + 4] we are re-folding the address in case
types are not canonical which ends up with a constant address that
recompute_tree_invariant_for_addr_expr ICEs on.  Properly guard
that call.

PR middle-end/101478
* gimplify.cc (gimplify_addr_expr): Check we still have an
ADDR_EXPR before calling recompute_tree_invariant_for_addr_expr.

* gcc.dg/pr101478.c: New testcase.

(cherry picked from commit 33ead6400ad59d4b38fa0527a9a7b53a28114ab7)

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

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

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

--- Comment #12 from GCC Commits  ---
The releases/gcc-12 branch has been updated by Richard Biener
:

https://gcc.gnu.org/g:83f764a9ac925d479ad3fee8c44e6053adb3475a

commit r12-11220-g83f764a9ac925d479ad3fee8c44e6053adb3475a
Author: Richard Biener 
Date:   Fri Feb 28 11:44:26 2025 +0100

ipa/111245 - bogus modref analysis for store in call that might throw

We currently record a kill for

  *x_4(D) = always_throws ();

because we consider the store always executing since the appropriate
check for whether the stmt could throw is guarded by
!cfun->can_throw_non_call_exceptions.

PR ipa/111245
* ipa-modref.cc (modref_access_analysis::analyze_store): Do
not guard the check of whether the stmt could throw by
cfun->can_throw_non_call_exceptions.

* g++.dg/torture/pr111245.C: New testcase.

(cherry picked from commit e6037af6d5e5a43c437257580d75bc8b35a6dcfd)

[Bug lto/113207] [12 Regression] error: type variant has different 'TREE_TYPE' with noreturn or const

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

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

--- Comment #17 from GCC Commits  ---
The releases/gcc-12 branch has been updated by Richard Biener
:

https://gcc.gnu.org/g:07490d983161912fa314607c5a5beb9c49cc4a3f

commit r12-11223-g07490d983161912fa314607c5a5beb9c49cc4a3f
Author: Richard Biener 
Date:   Mon Feb 3 14:27:01 2025 +0100

lto/113207 - fix free_lang_data_in_type

When we process function types we strip volatile and const qualifiers
after building a simplified type variant (which preserves those).
The qualified type handling of both isn't really compatible, so avoid
bad interaction by swapping this, first dropping const/volatile
qualifiers and then building the simplified type thereof.

PR lto/113207
* ipa-free-lang-data.cc (free_lang_data_in_type): First drop
const/volatile qualifiers from function argument types,
then build a simplified type.

* gcc.dg/pr113207.c: New testcase.

(cherry picked from commit a55e14b239181381204c615335929b3316d75370)

[Bug middle-end/115110] [15 regression] several failures after r15-512-g9b7cad5884f21c

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

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

--- Comment #18 from GCC Commits  ---
The releases/gcc-12 branch has been updated by Richard Biener
:

https://gcc.gnu.org/g:87d788926ba4ccca9a086c138584c10d1e63084d

commit r12-11219-g87d788926ba4ccca9a086c138584c10d1e63084d
Author: Sam James 
Date:   Mon Oct 21 12:11:42 2024 +0100

testsuite: add testcase for fixed PR107467

PR107467 ended up being fixed by the fix for PR115110, but let's
add the testcase on top.

gcc/testsuite/ChangeLog:
PR tree-optimization/107467
PR middle-end/115110

* g++.dg/lto/pr107467_0.C: New test.

(cherry picked from commit 4e09ae37dbe0a10f48490214f50ff733cc92280a)

[Bug c++/79786] [12 Regression] ICE tree check: expected class 'type', have 'declaration' (var_decl) in iamcu_alignment, at config/i386/i386.c:30263

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

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

Richard Biener  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED
  Known to work||12.4.1
  Known to fail||12.4.0

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

[Bug lto/113207] [12 Regression] error: type variant has different 'TREE_TYPE' with noreturn or const

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||12.4.1
  Known to fail||12.4.0
 Resolution|--- |FIXED

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

[Bug tree-optimization/115347] [12 Regression] wrong code at -O3 on x86_64-linux-gnu since r12-2097

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

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||12.4.1
  Known to fail||12.4.0
 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

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

[Bug tree-optimization/119057] [12 regression] ICE at -O{2,3} with "-fno-tree-vrp -fno-tree-forwprop" on x86_64-linux-gnu: in operator[], at vec.h:910 since r15-1055

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

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

Richard Biener  changed:

   What|Removed |Added

  Known to fail||12.4.0
 Resolution|--- |FIXED
  Known to work||12.4.1
 Status|ASSIGNED|RESOLVED

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

[Bug c/101478] [12 Regression] ICE with statement expression and offsetof like expression since r10-7127-gcb99630f254aae

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

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||12.4.1
  Known to fail||12.4.0
 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

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

[Bug tree-optimization/107467] [12 Regression] Miscompilation involving -Os, flto, and -fno-strict-aliasing since r12-656-ga564da506f52be66

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

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

Richard Biener  changed:

   What|Removed |Added

 Resolution|--- |FIXED
  Known to work||12.4.1
 Status|ASSIGNED|RESOLVED
  Known to fail||12.4.0

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

[Bug tree-optimization/120747] [16 Regression] 435.gromacs miscompares since r16-1550-g9244ea4bf55638

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

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

--- Comment #7 from Sam James  ---
(In reply to Filip Kastl from comment #6)
> (In reply to Andrew Macleod from comment #5)
> > Even knowing which file is miscompiled and what the compile options are 
> > would be a start.
> 
> Not sure how I would figure out which file it is right now.  I'll give it
> some thought.

Do you understand how to do it in general, or just in the context of SPEC? I
can give the gist for the general way (or on IRC if it's easier).

[Bug libstdc++/120717] Passing reference to incomplete type to std::move_only_function emits false-positive '-Wsfinae-incomplete' warning

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

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

Patrick Palka  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |ppalka at gcc dot 
gnu.org
  Component|c++ |libstdc++

--- Comment #2 from Patrick Palka  ---
This requires a libstdc++ workaround, the warning is behaving as expected.

[Bug target/120814] gcc does not compute on nvptx device when the loop is given over a variable whose pointer was offloaded in another function....

[schulz.benjamin at googlemail dot com via Gcc-bugs]

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

--- Comment #1 from Benjamin Schulz  ---
Created attachment 61704
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61704&action=edit
mainn_omp.cpp contains the main program

[Bug target/118518] gcc 14.2.1 nvptx cross compiler complains about alias definitions in a struct with two constructors that are not aliases

[schulz.benjamin at googlemail dot com via Gcc-bugs]

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

--- Comment #16 from Benjamin Schulz  ---
Hi @all

I just wanted to give you an update how my library progresses and what
additional bugs I've found in GCC so far.

Since some of you are familiar with my code, perhaps you can help to fix them,
as these are, I think, problems of gcc...


I ported my code to openmp and tried to make the gpu offloading more object
oriented, i.e. instead of having global values for the offload, put the
offloading code into the mdspan class which can also make some checks and
support many offloading devices and so on before it calls the globally
available mapping functions for the offloading references

Apparently , gcc can then no longer see in the accellerated loops that the
datastructs were really offloaded... 

I filed a bug on this here. 

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

I also compared with clang.

It is embarassing to load a computation into a computer, and exactly the same
code will yield a totally different result on 2 compilers. Unfortunately, the
result of gcc is incorrect. It appears to compute on the host for whatever
reason instead of on the device...

Note that if i map the structs with the globally available helper functions,
instead of with object members, it works fine. But of course this is
inconvenient for multi device support and so on

one can replace the mapping macros of course with pointers. My attempts to do
that yielded problems where the runtime exits with errors that the mapping was
not complete or something... the macros do not yield these problems but when
the variables are not recognized as mapped by the loop construct (even if the
data are mapped), it is still a bit inconvenient...



Ah and I also came up on this here:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120753

the offloading functions want that also has space on the host allocated, making
it problematic to use mappings for temporary data on gpu. functions like
device_alloc would help, but then one is left with a device pointer. 

If that device ptr is a member of a struct, the loop constructs do not
recognize it in is_device_ptr as they can not follow the dots.. The mapping
commands can follow the dots but they require host allocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120753

[Bug go/89173] FAIL: runtime/pprof

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

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

--- Comment #2 from Jeffrey A. Law  ---
Still happens on the BPI.  But I think we have bigger issues to resolve, so
deferring further action for now.

[Bug target/120813] [15/16 Regression] RISC-V: Miscompile at -O[23] since r15-9239

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |15.2
Summary|[15/16 Regression] RISC-V:  |[15/16 Regression] RISC-V:
   |Miscompile at -O[23]|Miscompile at -O[23] since
   ||r15-9239
   Keywords||wrong-code

[Bug fortran/120711] [14/15/16 regression] Growing arrays segfaults

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

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

--- Comment #3 from anlauf at gcc dot gnu.org ---
(In reply to Andre Vehreschild from comment #1)
> Confirmed, but this is not coarray dependent. For me it also crashes without
> -fcoarray=single.

Indeed.  valgrind reports an invalid read with -fcoarray=none.
But I do not see this on 14-branch.

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

[kargls at comcast dot net via Gcc-bugs]

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

--- Comment #5 from kargls at comcast dot net ---
(In reply to kargls from comment #4)
> (In reply to anlauf from comment #3)
> 
> troutmask:sgk[215] gfcx --version
> GNU Fortran (GCC) 16.0.0 20250528 (experimental)
> 

There are a couple of string related patches after 20250528.
I'm rebuilding gcc now to get to top-of-tree to see if the
issue is fixed in newer gfortran.

[Bug c/120780] Missed __builtin_dynamic_object_size optimization(?)

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

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

--- Comment #16 from Jakub Jelinek  ---
If it happens at runtime, better testcase would be to test it at runtime...

[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 #6 from anlauf at gcc dot gnu.org ---
(In reply to kargls from comment #5)
> (In reply to kargls from comment #4)
> > (In reply to anlauf from comment #3)
> > 
> > troutmask:sgk[215] gfcx --version
> > GNU Fortran (GCC) 16.0.0 20250528 (experimental)
> > 
> 
> There are a couple of string related patches after 20250528.
> I'm rebuilding gcc now to get to top-of-tree to see if the
> issue is fixed in newer gfortran.

May be related to the issue with SAVEd allocatable character?

[Bug c++/120742] ICE: tree check: expected tree_vec, have type_pack_expansion in coerce_template_parameter_pack, at cp/pt.cc:9042

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
  Known to fail||10.1.0
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2025-06-24

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

[Bug target/120814] gcc does not compute on nvptx device when the loop is given over a variable whose pointer was offloaded in another function....

[schulz.benjamin at googlemail dot com via Gcc-bugs]

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

--- Comment #3 from Benjamin Schulz  ---
I want to note that if one comments out



//A.device_upload(true);
//B.device_upload(true);
//C.device_alloc(true);



and

// C.host_update(true);



in 
bool matrix_multiply_dot( mdspan& A,   mdspan& B, mdspan&
C, bool on_gpu=false,bool default_device=true,int devicenum=0)


and replaces these calls by

device_datastruct_upload(dA,devicenum);
device_datastruct_upload(dB,devicenum);
device_datastruct_alloc(dC,devicenum);


and 
   host_datastruct_update(dC,devicenum);

then, the loop of the matrix multiplication recognizes that dA,dB,dC have been
offloaded and works fine on gpu. 

It just does not work with the member functions of A,B,C called
//A.device_upload(true);
//B.device_upload(true);
//C.device_alloc(true);
and
// C.host_update(true);

which, however, do nothing than set the default device number and then calling

device_datastruct_upload(dA,devicenum);
device_datastruct_upload(dB,devicenum);
device_datastruct_alloc(dC,devicenum);


and 
   host_datastruct_update(dC,devicenum)

with the reference of A.pdatastruct, which is the same as dA later and so on...

So the 

#pragma omp target teams loop should definitely recognize by the adresses and
in both cases that dA,dB,dC have been off-loaded by using
omp_has_device_addr

[Bug target/120216] openmp unified shared memory currently requires pageableMemoryAccess perhaps Heterogeneous Memory Management (HMM) or even just managedMemory would suffice

[schulz.benjamin at googlemail dot com via Gcc-bugs]

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

--- Comment #4 from Benjamin Schulz  ---
I did a benchmark here with my new card :

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

In many nvidia graphics cards on a pci bus, unified shared memory, in form of
hmm is currently not very suitable due to low speed. Perhaps this is an issue
of Nvidia's cuda implementation? So the recommendation, for now, is to work
with mapping macros.

[Bug c/120801] New: Using const variables as immediate values in extended assembly constraints with -O0 (x86)

[oskari.alaranta at bananymous dot com via Gcc-bugs]

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

Bug ID: 120801
   Summary: Using const variables as immediate values in extended
assembly constraints with -O0 (x86)
   Product: gcc
   Version: 15.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: oskari.alaranta at bananymous dot com
  Target Milestone: ---

Passing immediate values to instructions from const(/constexpr in c++)
variables does not seem to be working correctly on gcc 15.1.0/15.1.1. I have
tested with custom gcc and gcc from Arch linux's repositories. With gcc 12.2.0
I had no issues and I could not find anything regarding this from
https://gcc.gnu.org/bugs/#upgrading. This issue seems to only happen with -O0.

For example x86 instruction int takes 8 bit immediate, but inline assembly
constraint 'i' does not work with uint8_t/char/unsigned char (with 8 bit char).
The following code reports "impossible constraint in `asm`" with -O0 but not
with other optimization levels. Using larger variables short/int/long/long long
work fine even with -O0 though.

void foo(void) {
const uint8_t value = 0x80;
asm("int %0" :: "i"(value));
}

I also tested other instructions (add, test, ret) that should accept immediates
but the same problem occurs. Passing the value as an integer literal works in
the failing cases.

Preprocessed output and compiler configuration for `int` instruction with imm8
passed from const unsigned char variable.
// Target: x86_64-pc-linux-gnu
// Configured with: /build/gcc/src/gcc/configure
--enable-languages=ada,c,c++,d,fortran,go,lto,m2,objc,obj-c++,rust,cobol
--enable-bootstrap --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib
--mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://gitlab.archlinux.org/archlinux/packaging/packages/gcc/-/issues
--with-build-config=bootstrap-lto --with-linker-hash-style=gnu
--with-system-zlib --enable-__cxa_atexit --enable-cet=auto
--enable-checking=release --enable-clocale=gnu --enable-default-pie
--enable-default-ssp --enable-gnu-indirect-function --enable-gnu-unique-object
--enable-libstdcxx-backtrace --enable-link-serialization=1
--enable-linker-build-id --enable-lto --enable-multilib --enable-plugin
--enable-shared --enable-threads=posix --disable-libssp --disable-libstdcxx-pch
--disable-werror
// Thread model: posix
// Supported LTO compression algorithms: zlib zstd
// gcc version 15.1.1 20250425 (GCC) 
// 
//gcc-int.c: In function ‘foo’:
//gcc-int.c:3:5: warning: ‘asm’ operand 0 probably does not match constraints
//3 | asm("int %0" :: "i"(irq) : "memory");
//  | ^~~
//gcc-int.c:3:5: error: impossible constraint in ‘asm’

// gcc gcc-int.c

# 0 "gcc-int.c"
# 0 ""
# 0 ""
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 0 "" 2
# 1 "gcc-int.c"
void foo(void) {
const unsigned char irq = 0x80;
asm("int %0" :: "i"(irq) : "memory");
}

[Bug tree-optimization/119534] [12 Regression] ICE when building libaom-3.10.0 since r12-5392

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

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

--- Comment #16 from GCC Commits  ---
The releases/gcc-12 branch has been updated by Richard Biener
:

https://gcc.gnu.org/g:550edc99476376ee0350be90b9e61b337ffb0ff3

commit r12-11229-g550edc99476376ee0350be90b9e61b337ffb0ff3
Author: Richard Biener 
Date:   Tue Apr 1 14:13:03 2025 +0200

tree-optimization/119534 - reject bogus emulated vectorized gather

The following makes sure to reject the attempts to emulate a vector
gather when the discovered index vector type is a vector mask.

PR tree-optimization/119534
* tree-vect-stmts.cc (get_load_store_type): Reject
VECTOR_BOOLEAN_TYPE_P offset vector type for emulated gathers.

* gcc.dg/vect/pr119534.c: New testcase.

(cherry picked from commit d0cc14c62ad7403afcab3c2e38851d3ab179352f)

[Bug c++/79786] [12 Regression] ICE tree check: expected class 'type', have 'declaration' (var_decl) in iamcu_alignment, at config/i386/i386.c:30263

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

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

--- Comment #14 from GCC Commits  ---
The releases/gcc-12 branch has been updated by Richard Biener
:

https://gcc.gnu.org/g:32ad5415b926ca25e9102309e92561c1a30aa8ff

commit r12-11214-g32ad5415b926ca25e9102309e92561c1a30aa8ff
Author: Richard Biener 
Date:   Mon Feb 3 11:27:20 2025 +0100

c++/79786 - bougs invocation of DATA_ABI_ALIGNMENT macro

The first argument is supposed to be a type, not a decl.

PR c++/79786
gcc/cp/
* rtti.cc (emit_tinfo_decl): Fix DATA_ABI_ALIGNMENT invocation.

(cherry picked from commit 6ec19825b4e72611cdbd4749feed67b61392aa81)

[Bug c/120801] Using const variables as immediate values in extended assembly constraints with -O0 (x86)

[oskari.alaranta at bananymous dot com via Gcc-bugs]

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

Oskari Alaranta  changed:

   What|Removed |Added

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

--- Comment #4 from Oskari Alaranta  ---
Sorry for the amount of messages, the actual bug I'm looking for is happening
in C++ and does not seem to affect C. Compilation with -O0 is probably just
failing because the compiler cannot "prove" that the value is actually a
constant without optimizations.

I'll close this and create an issue with proper details.

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

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

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

Richard Biener  changed:

   What|Removed |Added

  Known to fail||12.4.0
 Resolution|--- |FIXED
  Known to work||12.4.1
 Status|ASSIGNED|RESOLVED

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

[Bug tree-optimization/119534] [12 Regression] ICE when building libaom-3.10.0 since r12-5392

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

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||12.4.1
 Resolution|--- |FIXED
  Known to fail||12.4.0
 Status|ASSIGNED|RESOLVED

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

[Bug middle-end/111125] [14 Regression] tree-ssa.exp and vect.exp failures after commit r14-3281-g99b5921bfc8f91

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

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

--- Comment #10 from GCC Commits  ---
The releases/gcc-12 branch has been updated by Richard Biener
:

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

commit r12-11213-gb908ad2b836b761f7b27b8dc650422ce9a7efecd
Author: Richard Biener 
Date:   Thu Aug 24 11:10:43 2023 +0200

tree-optimization/25 - avoid BB vectorization in novector loops

When a loop is marked with

  #pragma GCC novector

the following makes sure to also skip BB vectorization for contained
blocks.  That avoids gcc.dg/vect/bb-slp-29.c failing on aarch64
because of extra BB vectorization therein.  I'm not specifically
dealing with sub-loops of novector loops, the desired semantics
isn't documented.

PR tree-optimization/25
* tree-vect-slp.cc (vect_slp_function): Split at novector
loop entry, do not push blocks in novector loops.

(cherry picked from commit 43da77a4f1636280c4259402c9c2c543e6ec6c0b)

[Bug middle-end/87984] [12 Regression] wrong code for local reg var input to asm inside a loop

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

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

Richard Biener  changed:

   What|Removed |Added

  Known to fail||12.4.0
  Known to work||12.4.1
 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

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

[Bug middle-end/120803] New: inline assembly sign extends unsigned constraints

[oskari.alaranta at bananymous dot com via Gcc-bugs]

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

Bug ID: 120803
   Summary: inline assembly sign extends unsigned constraints
   Product: gcc
   Version: 15.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: oskari.alaranta at bananymous dot com
  Target Milestone: ---

Following code possibly incorrectly sign extends constexpr value passed to
inline assembly. Compiled with `g++ --std=c++20 -O2 -c foo.cpp`.

void foo() {
constexpr unsigned char value = 0x80;
asm("int %0" :: "i"(value));
}

Generated assembly for the int instruction is `int $-128` which fails to
assemble with message "Error: operand size mismatch for `int'".

I'm not sure if this is a bug in GCC or binutils. After updating from GCC
12.2.0->15.1.0 and binutils 2.39->2.44 my codebase fails to compile because of
this. GCC's behaviour has not changed, it used to produce `int $-128` even in
12.2.0 but binutils 2.39 accepted it.

Compiler configuration
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/15.1.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure
--enable-languages=ada,c,c++,d,fortran,go,lto,m2,objc,obj-c++,rust,cobol
--enable-bootstrap --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib
--mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://gitlab.archlinux.org/archlinux/packaging/packages/gcc/-/issues
--with-build-config=bootstrap-lto --with-linker-hash-style=gnu
--with-system-zlib --enable-__cxa_atexit --enable-cet=auto
--enable-checking=release --enable-clocale=gnu --enable-default-pie
--enable-default-ssp --enable-gnu-indirect-function --enable-gnu-unique-object
--enable-libstdcxx-backtrace --enable-link-serialization=1
--enable-linker-build-id --enable-lto --enable-multilib --enable-plugin
--enable-shared --enable-threads=posix --disable-libssp --disable-libstdcxx-pch
--disable-werror
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 15.1.1 20250425 (GCC)

[Bug c/120801] Using const variables as immediate values in extended assembly constraints with -O0 (x86)

[oskari.alaranta at bananymous dot com via Gcc-bugs]

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

--- Comment #2 from Oskari Alaranta  ---
(In reply to Andreas Schwab from comment #1)
> You need to use constexpr from C23.

Oh thank you. The bug may be with something else then. This happened in c++
with --std=c++20 using a constexpr variable and I reduced it to this and
thought it was the same problem. I'll take a deeper look then.

[Bug middle-end/120803] inline assembly sign extends unsigned constraints

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

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

--- Comment #3 from Jakub Jelinek  ---
Plus there is an easy workaround, just cast it to some wider type.  For -O0
purposes, better as constexpr as well.  So constexpr unsigned char value =
0x80; constexpr int value_promoted = var; asm("int %0" :: "i"(value_promoted));
in this case.

[Bug libstdc++/120717] Passing reference to incomplete type to std::move_only_function emits false-positive '-Wsfinae-incomplete' warning

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

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

Patrick Palka  changed:

   What|Removed |Added

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

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

[Bug target/120807] [15/16 Regression] LoongArch: "ICE: unrecognizable insn" building box64

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

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

Xi Ruoyao  changed:

   What|Removed |Added

 Target||loongarch64-linux-gnu
   Keywords||ice-on-valid-code,
   ||needs-reduction

--- Comment #2 from Xi Ruoyao  ---
Tentative patch:

>From b7a57d60ae132783e53dde156beb749ac0172643 Mon Sep 17 00:00:00 2001
From: Xi Ruoyao 
Date: Tue, 24 Jun 2025 21:07:55 +0800
Subject: [PATCH] LoongArch: Prevent subreg of subreg in CRC

The register_operand predicate can match subreg, then we'd have a subreg
of subreg and it's invalid.  Use lowpart_subreg to avoid the nested
 subreg.

gcc/ChangeLog:

* config/loongarch/loongarch.md (crc_combine): Avoid nested
subreg.
---
 gcc/config/loongarch/loongarch.md | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/gcc/config/loongarch/loongarch.md
b/gcc/config/loongarch/loongarch.md
index a13398fdff4..8cf2ac90c64 100644
--- a/gcc/config/loongarch/loongarch.md
+++ b/gcc/config/loongarch/loongarch.md
@@ -4603,9 +4603,10 @@
   "&& true"
   [(set (match_dup 3) (match_dup 2))
(set (match_dup 0)
-   (unspec:SI [(match_dup 3) (subreg:SI (match_dup 1) 0)] CRC))]
+   (unspec:SI [(match_dup 3) (match_dup 1)] CRC))]
   {
 operands[3] = gen_reg_rtx (mode);
+operands[1] = lowpart_subreg (SImode, operands[1], DImode);
   })

 ;; With normal or medium code models, if the only use of a pc-relative
-- 
2.50.0

Needing a test case reduced from the preprocessed file before submitting the
patch.

[Bug target/120807] [15/16 Regression] LoongArch: "ICE: unrecognizable insn" building box64

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

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

Xi Ruoyao  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |xry111 at gcc dot 
gnu.org
 Ever confirmed|0   |1
   Last reconfirmed||2025-06-24
 Status|UNCONFIRMED |ASSIGNED

--- Comment #1 from Xi Ruoyao  ---
Created attachment 61700
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61700&action=edit
preprocessed source file

[Bug libstdc++/120717] Passing reference to incomplete type to std::move_only_function emits false-positive '-Wsfinae-incomplete' warning

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

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

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

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

commit r16-1653-gbc8f5424977b74e107543b34af00768cdbb3a3cf
Author: Patrick Palka 
Date:   Tue Jun 24 09:33:25 2025 -0400

libstdc++: Unnecessary type completion in __is_complete_or_unbounded
[PR120717]

When checking __is_complete_or_unbounded on a reference to incomplete
type, we overeagerly try to instantiate/complete the referenced type
which besides being unnecessary may also produce an unexpected
-Wsfinae-incomplete warning (added in r16-1527) if the referenced type
is later defined.

This patch fixes this by effectively restricting the sizeof check to
object (except unknown-bound array) types.  In passing simplify the
implementation by using is_object instead of is_function/reference/void
and introducing a __maybe_complete_object_type helper.

PR libstdc++/120717

libstdc++-v3/ChangeLog:

* include/std/type_traits (__maybe_complete_object_type): New
helper trait, factored out from ...
(__is_complete_or_unbounded): ... here.  Only check sizeof on a
__maybe_complete_object_type type.  Fix formatting.
* testsuite/20_util/is_complete_or_unbounded/120717.cc: New test.

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

[Bug target/120807] New: [15/16 Regression] LoongArch: "ICE: unrecognizable insn" building box64

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

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

Bug ID: 120807
   Summary: [15/16 Regression] LoongArch: "ICE: unrecognizable
insn" building box64
   Product: gcc
   Version: 16.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: xry111 at gcc dot gnu.org
  Target Milestone: ---

$ /usr/bin/loongarch64-linux-gnu-gcc -DCONFIG_64BIT -DDYNAREC -DLA64
-DTEST_INTERPRETER -I/src/dynarec/la64
-I/home/runner/work/box64/box64/src/include -I/home/runner/work/box64/box64/src
-I/home/runner/work/box64/box64/src/wrapped/generated -O3 -DNDEBUG  
-Wno-pointer-type-mismatch -std=gnu11 -funwind-tables -fvisibility=hidden -pipe
-march=loongarch64 -MD -MT
CMakeFiles/test_interpreter.dir/src/emu/x64runf20f.c.o -MF
CMakeFiles/test_interpreter.dir/src/emu/x64runf20f.c.o.d -o
CMakeFiles/test_interpreter.dir/src/emu/x64runf20f.c.o -c
/home/runner/work/box64/box64/src/emu/x64runf20f.c
/home/runner/work/box64/box64/src/emu/x64runf20f.c: In function ‘TestF20F’:
/home/runner/work/box64/box64/src/emu/x64runf20f.c:480:1: error: unrecognizable
insn:
  480 | }
  | ^
(insn 3341 3340 557 54 (set (reg:SI 841)
(unspec:SI [
(reg:QI 1681)
(subreg:SI (subreg:DI (reg:SI 843 [ opgd_901->dword[0] ]) 0) 0)
] UNSPEC_CRCC)) -1
 (expr_list:REG_DEAD (reg:QI 1681)
(expr_list:REG_DEAD (reg:SI 843 [ opgd_901->dword[0] ])
(nil
during RTL pass: sched1
/home/runner/work/box64/box64/src/emu/x64runf20f.c:480:1: internal compiler
error: in extract_insn, at recog.cc:2882
0x1ba0fe5 diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, diagnostic_option_id, char const*, __va_list_tag
(*) [1], diagnostic_t)
???:0
0x1bb352f internal_error(char const*, ...)
???:0
0x68ea81 fancy_abort(char const*, int, char const*)
???:0
0x66a616 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
???:0
0x66a632 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
???:0
0xbac672 ira_set_pseudo_classes(bool, _IO_FILE*)
???:0
0x19e3df1 sched_init()
???:0
0x19e7a1c haifa_sched_init()
???: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.

[Bug testsuite/120805] gcc.target/powerpc/p9-vec-length-epil-4.c fail starting with r16-1645-g309dbcea2cabb3

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

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

--- Comment #1 from Kishan Parmar  ---
make -k check-gcc RUNTESTFLAGS="powerpc.exp=p9-vec-length-epil-*"

gives below failures,

Running CI/gcc/gcc/testsuite/gcc.target/powerpc/powerpc.exp ...
FAIL: gcc.target/powerpc/p9-vec-length-epil-4.c scan-assembler-times
\\mlxvx?\\M 120
FAIL: gcc.target/powerpc/p9-vec-length-epil-4.c scan-assembler-times
\\mstxvx?\\M 70
FAIL: gcc.target/powerpc/p9-vec-length-epil-4.c scan-assembler-times \\mlxvl\\M
70
FAIL: gcc.target/powerpc/p9-vec-length-epil-4.c scan-assembler-times
\\mstxvl\\M 70
FAIL: gcc.target/powerpc/p9-vec-length-epil-5.c scan-assembler-times
\\mlxvx?\\M 49
FAIL: gcc.target/powerpc/p9-vec-length-epil-5.c scan-assembler-times
\\mstxvx?\\M 21
FAIL: gcc.target/powerpc/p9-vec-length-epil-5.c scan-assembler-times \\mlxvl\\M
21
FAIL: gcc.target/powerpc/p9-vec-length-epil-5.c scan-assembler-times
\\mstxvl\\M 21

=== gcc Summary ===

# of expected passes45
# of unexpected failures8

[Bug c++/120797] ICE: in iterative_hash_template_arg, at cp/pt.cc:1775 under '-std=c++2a'

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

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #1 from Patrick Palka  ---
Thanks for the bug report, I think this is essentially a dup of PR105644

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

[Bug tree-optimization/119706] [12 regression] ICE in gimple pass 'dom' for -O3 -mcpu=grace --param=aarch64-autovec-preference=sve-only

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

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||12.4.1
  Known to fail||12.4.0
 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

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

[Bug c++/120800] [14/15/16 Regression] internal compiler error when using partially initialized class with private constructor and friend

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

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

Patrick Palka  changed:

   What|Removed |Added

Summary|internal compiler error |[14/15/16 Regression]
   |when using partially|internal compiler error
   |initialized class with  |when using partially
   |private constructor and |initialized class with
   |friend  |private constructor and
   ||friend
  Known to work||14.2.0
  Known to fail||14.3.0, 15.1.0, 16.0
 Ever confirmed|0   |1
   Last reconfirmed||2025-06-24
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=118285
   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
 CC||jason at gcc dot gnu.org,
   ||ppalka at gcc dot gnu.org
   Target Milestone|--- |14.4

--- Comment #1 from Patrick Palka  ---
Confirmed, the ICE (with -std=c++20) started with r15-7260 "c++: constexpr
VEC_INIT_EXPR [PR118285]", which was backported for 14.3.

[Bug tree-optimization/119706] [12 regression] ICE in gimple pass 'dom' for -O3 -mcpu=grace --param=aarch64-autovec-preference=sve-only

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

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

--- Comment #16 from GCC Commits  ---
The releases/gcc-12 branch has been updated by Richard Biener
:

https://gcc.gnu.org/g:75f255c11f7e5a5099ad909606e21ec6bf9b82cc

commit r12-11230-g75f255c11f7e5a5099ad909606e21ec6bf9b82cc
Author: Richard Biener 
Date:   Thu Apr 10 13:30:42 2025 +0200

middle-end/119706 - allow POLY_INT_CST as is_gimple_mem_ref_addr

We currently only INTEGER_CST, but not POLY_INT_CST, which leads
to the situation that when the POLY_INT_CST is only indrectly
present via a SSA def the IL is valid but when propagated it's not.
That's unsustainable.

PR middle-end/119706
* gimple-expr.cc (is_gimple_mem_ref_addr): Also allow
POLY_INT_CST.

(cherry picked from commit bf812c6ad83ec0b241bb3fecc7e68f883b6083df)

[Bug target/120807] [15/16 Regression] LoongArch: "ICE: unrecognizable insn" building box64

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |15.2

[Bug cobol/120786] strange message for NOT=

[simonsobisch at gnu dot org via Gcc-bugs]

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

--- Comment #2 from Simon Sobisch  ---
Just keep in mind that a , and ; are valid separators as well, not only spaces
(they can be inserted nearly every place where a space can, with the exception
of places where they are required).

Rechecked with MF:

   program-id.t.
   data Division.
   WORKING-STORAGE Section.
   01  var  pic 9.
   PROCEDURE Division.
   if var NOT= var DISPLAY "BAD".
   if var NOT<=-var+ 9 DISPLAY "GOOD".  *> does not work when the
space before 9 is removed as well
   goback.

compiles without any warnings. And indeed there are > 30 programs in my test
bed using this code.

The lexical rule implied in GC and seemingly in MF: scan for
">="
"<="
">"
"<"
"="
" -"
"- "
" +"
"+ "

and transfer those to their own token.

As those "basic special characters" may not be part of a COBOL word, this was
doable.

[Bug lto/91299] [12 Regression] LTO inlines a weak definition in presence of a non-weak definition from an ELF file

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

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||12.4.1
  Known to fail||12.4.0
 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

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

[Bug tree-optimization/120808] SLP unable to combine .FMA and .FMS to VEC_FMADDSUB

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

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

[christophe.peyret at onera dot fr via Gcc-bugs]

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

Bug ID: 120812
   Summary: [regression] buffer(80:80) = C_NEW_LINE not working
with gfortran 15.1 under Mac
   Product: gcc
   Version: 15.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: christophe.peyret at onera dot fr
  Target Milestone: ---

Created attachment 61702
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61702&action=edit
buffer(80:80) = C_NEW_LINE not working

Hello,

I face a problem with gfortran 15.1 on my Mac Intel and Mac Apple Silicon (that
didn't exist with gfortran 14)

I declare :

character(len=:), pointer :: buffer=>null()
allocate( character(len=80) :: buffer )

when I enter :

buffer(80:80) = C_NEW_LINE

the C_NEW_LINE is inserted at buffer(1:1). 
If I want it to work I need to enter:

buffer(1:80) = buffer(1:79) // C_NEW_LINE


I join a small example that reproduces the problem

Sincerely
Christophe

[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 #3 from anlauf at gcc dot gnu.org ---
(In reply to kargls from comment #2)
> Harald, there's a bug (at least it fails on FreeBSD).Here's 
> a testcase based on the original code.  On FreeBSD, I see
> 
> % gfcx -o z a.f90 && ./z
> STOP 2
> 
> In sub2, the line 'str(11:11) = c_new_line' places the new line
> character in str(1:1).

Interesting.

The dump of sub2 shows here:

  *(str + 10) = 10;

Can you provide details on what's different for you?

[Bug rtl-optimization/120795] [16 regression] ICE when building folly-2025.04.14.00 (df_refs_verify, at df-scan.cc:4029)

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

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

--- Comment #9 from Sam James  ---
```
int a;
void b();
struct e {
  int ab;
  int d() { return ab; }
};
struct f {
  e g;
  auto d() { return g.d(); }
};
template  struct i : h {
  f j;
  template  int ad(ac) {
unsigned char k = j.d();
a = __builtin_ia32_bzhi_di(1, k);
b();
return a;
  }
};
struct l {
  void af();
};
template  class, typename al> void am(al m) { m(1); }
template  using ar = int;
struct n {
  void ap() {
at.af();
am([&](auto... au) { at.ad(au...); });
  }
  i at;
};
struct aw {
  aw() {
n b;
b.ap();
  }
} c;
```

I'll submit that when I get a chance.

[Bug libstdc++/120810] [DR 461] std::time_get::do_get_date should consider date_order()

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

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

--- Comment #2 from Jonathan Wakely  ---
If we had a working time_get::do_date_order (see Bug 9635) then we could
implement DR 461 something like this:

--- a/libstdc++-v3/include/bits/locale_facets_nonio.tcc
+++ b/libstdc++-v3/include/bits/locale_facets_nonio.tcc
@@ -1347,13 +1347,42 @@ _GLIBCXX_END_NAMESPACE_LDBL_OR_CXX11
 do_get_date(iter_type __beg, iter_type __end, ios_base& __io,
ios_base::iostate& __err, tm* __tm) const
 {
-  const locale& __loc = __io._M_getloc();
-  const __timepunct<_CharT>& __tp = use_facet<__timepunct<_CharT>
>(__loc);
-  const char_type*  __dates[2];
-  __tp._M_date_formats(__dates);
+  char_type __buf[]{ '%', 'm', '/', '%', 'd',  '/', '%', 'y', 0 };
+  const char_type* __fmt = __buf;
+  const dateorder __ord = this->do_date_order();
+  switch (__ord)
+   {
+   case time_base::dmy:
+ __buf[1] = 'd';
+ __buf[4] = 'm';
+ __buf[7] = 'y';
+ break;
+   case time_base::mdy:
+ break;
+   case time_base::ymd:
+ __buf[1] = 'm';
+ __buf[4] = 'd';
+ __buf[7] = 'y';
+ break;
+   case time_base::ydm:
+ __buf[1] = 'y';
+ __buf[4] = 'm';
+ __buf[7] = 'd';
+ break;
+   default:
+ {
+   const locale& __loc = __io._M_getloc();
+   const __timepunct<_CharT>& __tp
+ = use_facet<__timepunct<_CharT> >(__loc);
+   const char_type*  __dates[2];
+   __tp._M_date_formats(__dates);
+   if (__dates[0] && __dates[0][0])
+ __fmt = __dates[0];
+ }
+   }
   __time_get_state __state = __time_get_state();
   __beg = _M_extract_via_format(__beg, __end, __io, __err, 
-   __tm, __dates[0], __state);
+   __tm, __fmt, __state);
   __state._M_finalize_state(__tm);
   if (__beg == __end)
__err |= ios_base::eofbit;

[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 #1 from anlauf at gcc dot gnu.org ---
Works as expected on Linux.

What happens if you replace C_NEW_LINE by something different,
like c_carriage_return, or c_null_char, and pipe the output
through "cat -v"?

[Bug c/120780] Missed __builtin_dynamic_object_size optimization(?)

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

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

--- Comment #11 from Siddhesh Poyarekar  ---
OK, so we don't really need a FAM based reproducer either, here's one without
it.  FAM just makes this case more likely because due to it, __bdos succeeds
more often in the kernel code:

typedef __SIZE_TYPE__ size_t;

struct inner
{
  int dummy;
};

struct container
{ 
  int mcast_rate[6];
  struct inner mesh;
};

extern void __warn (void)
 __attribute__ ((__warning__ ("__builtin_dynamic_object_size failed")));

static void
child (struct inner *ifmsh)
{ 
  struct container *sdata =
(struct container *) ((void *) ifmsh
  - __builtin_offsetof (struct container, mesh));

  if (__builtin_dynamic_object_size(sdata->mcast_rate, 1) 
  != sizeof (sdata->mcast_rate))
__warn ();
}

int
parent (size_t sz)
{ 
  struct container *sdata = __builtin_malloc (sz);
  struct inner *ifmsh = &sdata->mesh;
  child (ifmsh);
} 

$ gcc/cc1 -fdump-tree-objsz-details -std=gnu17 -quiet -O2 -o /dev/null -Werror
../cfg-min.c
In function ‘child’,
inlined from ‘parent’ at ../cfg-min.c:34:3:
../cfg-min.c:26:5: error: call to ‘__warn’ declared with attribute warning:
__builtin_dynamic_object_size failed [-Werror=attribute-warning]
   26 | __warn ();
  | ^
cc1: all warnings being treated as errors

[Bug c/120780] Missed __builtin_dynamic_object_size optimization(?)

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

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

--- Comment #10 from Siddhesh Poyarekar  ---
Minimal reproducer, I've written this independently, not reduced from the
preprocessed source, but I'm pretty sure this is essentially what it is:

typedef __SIZE_TYPE__ size_t;

struct inner
{ 
  int a;
  int b;
  int c;
};

struct fam_struct
{ 
  int dummy;
  int priv_size;
  char priv[] __attribute__((__counted_by__ (priv_size)));
};

struct container
{ 
  int mcast_rate[6];
  struct inner mesh;
};

extern void __warn (void)
 __attribute__ ((__warning__ ("__builtin_dynamic_object_size failed")));

static void
child (struct inner *ifmsh)
{ 
  struct container *sdata =
(struct container *) ((void *) ifmsh
  - __builtin_offsetof (struct container, mesh));

  if (__builtin_dynamic_object_size(sdata->mcast_rate, 1) 
  != sizeof (sdata->mcast_rate))
__warn ();
}

int
parent (struct fam_struct *dev)
{ 
  struct container *sdata = (void *) dev->priv;
  struct inner *ifmsh = &sdata->mesh;
  child (ifmsh);
} 

$ gcc/cc1 -fdump-tree-objsz-details -std=gnu17 -quiet -O2 -o /dev/null -Werror
../cfg-min.c
In function ‘child’,
inlined from ‘parent’ at ../cfg-min.c:43:3:
../cfg-min.c:35:5: error: call to ‘__warn’ declared with attribute warning:
__builtin_dynamic_object_size failed [-Werror=attribute-warning]
   35 | __warn ();
  | ^
cc1: all warnings being treated as errors

[Bug target/120811] RISC-V: missed load offset

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

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

--- Comment #1 from Vineet Gupta  ---
Perhaps worth looking into the new RISC-V pass fold-memory-offset ?

[Bug c/120780] Missed __builtin_dynamic_object_size optimization(?)

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

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

--- Comment #15 from Siddhesh Poyarekar  ---
(In reply to Jakub Jelinek from comment #14)
> 
> So, __bdos returns something larger than that?  That would be weird.
> Or do the two calls result in different results?

It's basically comment 9; __bdos returns 0 because it thinks the negative
offset to access the parent struct using the child pointer is an invalid
access.  That will basically happen at runtime too, with the MAX(sz, offset) -
offset pattern we emit.

What we basically need is a way to identify the MEM_REF in such cases and use
the parent struct to get the size:

_1 = MEM[(struct container *)ifmsh_5 + -24B]

recognize that TREE_TYPE(_1) contains TREE_TYPE(ifmsh_5) and adjust for it.

[Bug c/120780] Missed __builtin_dynamic_object_size optimization(?)

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

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

--- Comment #13 from Siddhesh Poyarekar  ---
(In reply to Jakub Jelinek from comment #12)
> (In reply to Siddhesh Poyarekar from comment #11)
> > OK, so we don't really need a FAM based reproducer either, here's one
> > without it.  FAM just makes this case more likely because due to it, __bdos
> > succeeds more often in the kernel code:
> 
> And the problem with that is what?
> Using warning attribute with __bdos based guards makes no sense.
> __bdos is intentionally dynamic, so often it doesn't yield a constant, e.g.
> can result in minimum of a constant and some variable.
> With warning attribute you get a warning whenever it doesn't fold into a
> constant.

Ahh sorry, I should have clarified, the kernel code is not exactly that, it is
of the form:

  if ((__builtin_constant_p (__builtin_dynamic_object_size(sdata->mcast_rate,
1) 
   < sizeof (sdata->mcast_rate)))
  && (__builtin_dynamic_object_size(sdata->mcast_rate, 1) 
  < sizeof (sdata->mcast_rate)))
__warn ();

I'll fix it up with the test case.

[Bug rtl-optimization/120795] [16 regression] ICE when building folly-2025.04.14.00 (df_refs_verify, at df-scan.cc:4029)

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

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

--- Comment #10 from Andrew Pinski  ---
This might be slightly smaller, (removes c++20 specific stuff) (I can't test it
with the failing case):
```

int a;
void b();
struct e {
  int ab;
  int d() { return ab; }
};
struct f {
  e g;
  auto d() { return g.d(); }
};
template  struct i : h {
  f j;
  template  int ad(ac) {
unsigned char k = j.d();
a = __builtin_ia32_bzhi_di(1, k);
b();
return a;
  }
};
struct l {
  void af();
};
struct n {
  void ap() {
at.af();
at.ad(1);
  }
  i at;
};
void f() {
n b;
b.ap();
}
```

[Bug c++/120798] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in check_bit_cast_type, at cp/constexpr.cc:5035

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2025-06-24
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
  Known to fail||11.1.0

--- Comment #1 from Andrew Pinski  ---
Reduced testcase:
```
struct S { int s;S t; };
auto t = __builtin_bit_cast (S, (0)); 
```

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

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||needs-bisection
  Known to work||4.9.0, 4.9.4
Summary|internal compiler error:|[12/13/14/15/16 Regression]
   |error reporting routines|internal compiler error:
   |re-entered with |error reporting routines
   |[[deprecated]]  |re-entered with
   ||[[deprecated]]
   Target Milestone|--- |12.5

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

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2025-06-24

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

[Bug tree-optimization/120724] [missed optimization] bit test in a loop

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug fortran/120743] [16 regression] ice in verify_gimple_in_seq

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

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

[Bug target/119100] RISC-V: missed opportunities for vector-scalar instructions

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

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

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

https://gcc.gnu.org/g:92e1893e0155b6b3baef2a935efd5936d23a67ea

commit r16-1659-g92e1893e0155b6b3baef2a935efd5936d23a67ea
Author: Paul-Antoine Arras 
Date:   Tue Jun 24 15:42:50 2025 -0600

RISC-V: Add patterns for vector-scalar multiply-(subtract-)accumulate
[PR119100]

This pattern enables the combine pass (or late-combine, depending on the
case)
to merge a vec_duplicate into a plus-mult or minus-mult RTL instruction.

Before this patch, we have two instructions, e.g.:
  vfmv.v.f   v6,fa0
  vfmacc.vv  v2,v6,v4

After, we get only one:
  vfmacc.vf  v2,fa0,v4

PR target/119100

gcc/ChangeLog:

* config/riscv/autovec-opt.md (*_vf_): Handle both add
and
acc FMA variants.
* config/riscv/vector.md (*pred_mul__scalar_undef):
New.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/autovec/vx_vf/vf-1-f16.c: Add vfmacc and
vfmsac.
* gcc.target/riscv/rvv/autovec/vx_vf/vf-1-f32.c: Likewise.
* gcc.target/riscv/rvv/autovec/vx_vf/vf-1-f64.c: Likewise.
* gcc.target/riscv/rvv/autovec/vx_vf/vf-2-f16.c: Likewise.
* gcc.target/riscv/rvv/autovec/vx_vf/vf-2-f32.c: Likewise.
* gcc.target/riscv/rvv/autovec/vx_vf/vf-2-f64.c: Likewise.
* gcc.target/riscv/rvv/autovec/vx_vf/vf-3-f16.c: Likewise.
* gcc.target/riscv/rvv/autovec/vx_vf/vf-3-f32.c: Likewise.
* gcc.target/riscv/rvv/autovec/vx_vf/vf-3-f64.c: Likewise.
* gcc.target/riscv/rvv/autovec/vx_vf/vf-4-f16.c: Likewise.
* gcc.target/riscv/rvv/autovec/vx_vf/vf-4-f32.c: Likewise.
* gcc.target/riscv/rvv/autovec/vx_vf/vf-4-f64.c: Likewise.
* gcc.target/riscv/rvv/autovec/vx_vf/vf_mulop.h: Add support for
acc
variants.
* gcc.target/riscv/rvv/autovec/vx_vf/vf_mulop_run.h: Likewise.
* gcc.target/riscv/rvv/autovec/vx_vf/vf_vfmadd-run-1-f16.c: Define
TEST_OUT.
* gcc.target/riscv/rvv/autovec/vx_vf/vf_vfmadd-run-1-f32.c:
Likewise.
* gcc.target/riscv/rvv/autovec/vx_vf/vf_vfmadd-run-1-f64.c:
Likewise.
* gcc.target/riscv/rvv/autovec/vx_vf/vf_vfmsub-run-1-f16.c:
Likewise.
* gcc.target/riscv/rvv/autovec/vx_vf/vf_vfmsub-run-1-f32.c:
Likewise.
* gcc.target/riscv/rvv/autovec/vx_vf/vf_vfmsub-run-1-f64.c:
Likewise.
* gcc.target/riscv/rvv/autovec/vx_vf/vf_vfnmadd-run-1-f16.c:
Likewise.
* gcc.target/riscv/rvv/autovec/vx_vf/vf_vfnmadd-run-1-f32.c:
Likewise.
* gcc.target/riscv/rvv/autovec/vx_vf/vf_vfnmadd-run-1-f64.c:
Likewise.
* gcc.target/riscv/rvv/autovec/vx_vf/vf_vfnmsub-run-1-f16.c:
Likewise.
* gcc.target/riscv/rvv/autovec/vx_vf/vf_vfnmsub-run-1-f32.c:
Likewise.
* gcc.target/riscv/rvv/autovec/vx_vf/vf_vfnmsub-run-1-f64.c:
Likewise.
* gcc.target/riscv/rvv/autovec/vx_vf/vf_vfmacc-run-1-f16.c: New
test.
* gcc.target/riscv/rvv/autovec/vx_vf/vf_vfmacc-run-1-f32.c: New
test.
* gcc.target/riscv/rvv/autovec/vx_vf/vf_vfmacc-run-1-f64.c: New
test.
* gcc.target/riscv/rvv/autovec/vx_vf/vf_vfmsac-run-1-f16.c: New
test.
* gcc.target/riscv/rvv/autovec/vx_vf/vf_vfmsac-run-1-f32.c: New
test.
* gcc.target/riscv/rvv/autovec/vx_vf/vf_vfmsac-run-1-f64.c: New
test.

[Bug target/119007] RISC-V: The optimization ignored the side effects of the rounding mode, resulting in incorrect results for rvv

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

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

--- Comment #3 from Jeffrey A. Law  ---
I think that's reasonable as well and one of the options discussed weeks ago in
the patchwork call.

I was thinking that having the relevant intrinsics set the flag was slightly
better solution because it automatically does the right thing with no
additional need from the user.

I guess one thing to look at is how LLVM handles this scenario and try to be
compatible.

[Bug lto/91299] [12 Regression] LTO inlines a weak definition in presence of a non-weak definition from an ELF file

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

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

--- Comment #24 from GCC Commits  ---
The releases/gcc-12 branch has been updated by Richard Biener
:

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

commit r12-11216-ge5d24c4e89ae6d8c08f85f3425ea9c29dd0e6646
Author: Richard Biener 
Date:   Fri Feb 28 14:09:29 2025 +0100

lto/91299 - weak definition inlined with LTO

The following fixes a thinko in the handling of interposed weak
definitions which confused the interposition check in
get_availability by setting DECL_EXTERNAL too early.

PR lto/91299
gcc/lto/
* lto-symtab.cc (lto_symtab_merge_symbols): Set DECL_EXTERNAL
only after calling get_availability.

gcc/testsuite/
* gcc.dg/lto/pr91299_0.c: New testcase.
* gcc.dg/lto/pr91299_1.c: Likewise.

(cherry picked from commit bc34db5b12e008f6ec4fdf4ebd22263c8617e5e3)

[Bug tree-optimization/107467] [12 Regression] Miscompilation involving -Os, flto, and -fno-strict-aliasing since r12-656-ga564da506f52be66

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

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

--- Comment #22 from GCC Commits  ---
The releases/gcc-12 branch has been updated by Richard Biener
:

https://gcc.gnu.org/g:87d788926ba4ccca9a086c138584c10d1e63084d

commit r12-11219-g87d788926ba4ccca9a086c138584c10d1e63084d
Author: Sam James 
Date:   Mon Oct 21 12:11:42 2024 +0100

testsuite: add testcase for fixed PR107467

PR107467 ended up being fixed by the fix for PR115110, but let's
add the testcase on top.

gcc/testsuite/ChangeLog:
PR tree-optimization/107467
PR middle-end/115110

* g++.dg/lto/pr107467_0.C: New test.

(cherry picked from commit 4e09ae37dbe0a10f48490214f50ff733cc92280a)

[Bug ipa/119119] [12 Regression] ICE in create_tmp_var

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

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||12.4.1
  Known to fail||12.4.0
 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

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

[Bug c/120801] Using const variables as immediate values in extended assembly constraints with -O0 (x86)

[oskari.alaranta at bananymous dot com via Gcc-bugs]

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

--- Comment #3 from Oskari Alaranta  ---
(In reply to Andreas Schwab from comment #1)
> You need to use constexpr from C23.

Although this also seems to happen when compiling my example code using
--std=c17.

[Bug tree-optimization/120747] [16 Regression] 435.gromacs miscompares since r16-1550-g9244ea4bf55638

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

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

Filip Kastl  changed:

   What|Removed |Added

   Keywords|wrong-code  |

--- Comment #6 from Filip Kastl  ---
Removing the 'wrong-code' keyword.  Talked about -Ofast SPEC miscompares with
Richi and now I understand that those aren't really miscompilations:  With
-Ofast, FP computations can always have large numerical error.

However, we still want to be able to compile and run SPEC benchmarks with
-Ofast so this is still worth looking into.  Perhaps we can change something in
GCC to get rid of this numerical error.  Or we find out that it makes more
sense to compile the benchmark with some additional flags or something like
that.

(In reply to Andrew Macleod from comment #5)
> Even knowing which file is miscompiled and what the compile options are would 
> be a start.

Not sure how I would figure out which file it is right now.  I'll give it some
thought.

[Bug tree-optimization/119057] [12 regression] ICE at -O{2,3} with "-fno-tree-vrp -fno-tree-forwprop" on x86_64-linux-gnu: in operator[], at vec.h:910 since r15-1055

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

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

--- Comment #8 from GCC Commits  ---
The releases/gcc-12 branch has been updated by Richard Biener
:

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

commit r12-11227-gad756e186f6352b1369c8094ec8973736142933e
Author: Richard Biener 
Date:   Mon Mar 3 13:21:53 2025 +0100

tree-optimization/119057 - bogus double reduction detection

We are detecting a cycle as double reduction where the inner loop
cycle has extra out-of-loop uses.  This clashes at least with
assumptions from the SLP discovery code which says the cycle
isn't reachable from another SLP instance.  It also was not intended
to support this case, in fact with GCC 14 we seem to generate wrong
code here.

PR tree-optimization/119057
* tree-vect-loop.cc (check_reduction_path): Add argument
specifying whether we're analyzing the inner loop of a
double reduction.  Do not allow extra uses outside of the
double reduction cycle in this case.
(vect_is_simple_reduction): Adjust.

* gcc.dg/vect/pr119057.c: New testcase.

(cherry picked from commit 758de6263dfc7ba8701965fa468691ac23cb7eb5)

[Bug cobol/120804] New: FR: allow SET of numeric-display variables

[simonsobisch at gnu dot org via Gcc-bugs]

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

Bug ID: 120804
   Summary: FR: allow SET of numeric-display variables
   Product: gcc
   Version: 16.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: cobol
  Assignee: unassigned at gcc dot gnu.org
  Reporter: simonsobisch at gnu dot org
  Target Milestone: ---

test.cob: error: invalid SET Z-INT-ZAEHLER (FldNumericDisplay) TO _literaln_2
(FldLiteralN): not a field index
test.cob: error: invalid SET T05-IND (FldNumericBinary) TO _literaln_60
(FldLiteralN): not a field index

the code

  SET Z-INT-ZAEHLER UP BY 1
  SET Z-GES-ZAEHLER UP BY 1.

compiles,

  SET Z-INT-ZAEHLER TO 0
  SET T05-IND TO 40.

doesn't.

I think that according to ISO neither should compile, but with -std=mf/gnu this
may go through with a warning.

Also note that the literal should be printed in the message, instead of its
literal-id.

[Bug fortran/88076] Shared Memory implementation for Coarrays

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

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

Andre Vehreschild  changed:

   What|Removed |Added

 CC||vehre at gcc dot gnu.org
 Status|ASSIGNED|WAITING

--- Comment #20 from Andre Vehreschild  ---
Proposed caf-ABI compatible version at:

https://gcc.gnu.org/pipermail/fortran/2025-June/062331.html
https://gcc.gnu.org/pipermail/fortran/2025-June/062335.html
https://gcc.gnu.org/pipermail/fortran/2025-June/062334.html
https://gcc.gnu.org/pipermail/fortran/2025-June/062333.html
https://gcc.gnu.org/pipermail/fortran/2025-June/062332.html
https://gcc.gnu.org/pipermail/fortran/2025-June/062337.html
https://gcc.gnu.org/pipermail/fortran/2025-June/062336.html

Waiting for review/comments.

[Bug testsuite/120805] New: gcc.target/powerpc/p9-vec-length-epil-4.c fail starting with r16-1645-g309dbcea2cabb3

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

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

Bug ID: 120805
   Summary: gcc.target/powerpc/p9-vec-length-epil-4.c fail
starting with r16-1645-g309dbcea2cabb3
   Product: gcc
   Version: 16.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kishan at gcc dot gnu.org
CC: tamar.christina at arm dot com
  Target Milestone: ---
Target: powerpc64le-linux-gnu

Below failure occurs on BE as well.

Running /home/kishan/CI/gcc/gcc/testsuite/gcc.target/powerpc/powerpc.exp ...
FAIL: gcc.target/powerpc/p9-vec-length-epil-4.c scan-assembler-times
\\mlxvx?\\M 120
FAIL: gcc.target/powerpc/p9-vec-length-epil-4.c scan-assembler-times
\\mstxvx?\\M 70
FAIL: gcc.target/powerpc/p9-vec-length-epil-4.c scan-assembler-times \\mlxvl\\M
70
FAIL: gcc.target/powerpc/p9-vec-length-epil-4.c scan-assembler-times
\\mstxvl\\M 70

=== gcc Summary ===

# of expected passes1
# of unexpected failures4

[Bug middle-end/120803] inline assembly sign extends unsigned constraints

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
This is not a bug, that is how GNU inline asms have behaved since forever.
The reason is that in RTL CONST_INTs don't have a mode and are treated as
signed.
Changing this now would break a lot of real-world code.

[Bug middle-end/120803] inline assembly sign extends unsigned constraints

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||documentation

--- Comment #2 from Andrew Pinski  ---
Hmm, I thought this was documented too. Maybe only in the internals manual
rather the user guide.

[Bug target/120814] New: gcc does not compute on nvptx device when the loop is given over a variable whose pointer was offloaded in another function....

[schulz.benjamin at googlemail dot com via Gcc-bugs]

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

Bug ID: 120814
   Summary: gcc does not compute on nvptx device when the loop is
given over a variable whose pointer was offloaded in
another function
   Product: gcc
   Version: 15.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: schulz.benjamin at googlemail dot com
  Target Milestone: ---

Created attachment 61703
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61703&action=edit
mdspan class with offload support and array and vector support

Hi there, the attached code, compiled with clang and 

 -std=c++20  -fopenmp -fopenmp-targets=nvptx64-nvidia-cuda  -Wall

yields this (correct) output:

Ordinary matrix multiplication, on gpu
1 2 3 4 
5 6 7 8 
9 10 11 12 
13 14 15 16 

0 1 2 3 
4 5 6 7 
8 9 10 11 
12 13 14 15 

1 1 1 1 
1 1 1 1 
1 1 1 1 
1 1 1 1 

Multiplication should start with a teams loop 
80 90 100 110 
176 202 228 254 
272 314 356 398 
368 426 484 542 


while with gcc, and the options
 -fopenmp -foffload=nvptx-none  -fno-stack-protector -Wall
 I get this:

Ordinary matrix multiplication, on gpu
1 2 3 4 
5 6 7 8 
9 10 11 12 
13 14 15 16 

0 1 2 3 
4 5 6 7 
8 9 10 11 
12 13 14 15 

1 1 1 1 
1 1 1 1 
1 1 1 1 
1 1 1 1 

Multiplication should start with a teams loop 
0 0 0 0 
0 0 0 0 
0 0 0 0 

What the code does:

Most code is in mdspan_omp.h and contains a struct called datastruct with
pointers that can be offloaded to gpu, called datastruct. This struct contains
data, the extents of the tensor, and the strides. And some functions for
accessing the multi dimensional tensor elements.

mdspan_omp.h also contains a class called mdspan. It has constructors where it
accepts arrays and numbers as extents, strides, and data. It contains the
struct  datastruct as a member variable and one can access this struct as a
reference via a function get_datastruct()

the class mdspan has functions for offloading to the gpu.

At first, in the main function of main_omp.cpp, three matrices are defined and
filled as mdspan objects and successfully printed out.

Then a function called matrix_multiply_dot in mdspan_omp.h is called, which
accepts three mdspan objects..


Then, they are offloaded to gpu. The two input matrices are offloaded  with the
functions called device_offload and the result with a function called
device_alloc. 

These functions are member functions of mdspan, and make some checks and then
they call the functions device_datastruct_upload, and device_datastruct_alloc
that contain the mapping macros of openmp. The functions
device_datastruct_upload device_datastruct_alloc then use the mapping macros to
offload the reference of the datastruct member variable to gpu..

Then the get_datastruct() function is called by matrix_multiply to obtain a
reference of the 3 datastruct structs.


Then a loop for matrix multiplication follows as this, the variables dC,dA,dB
are the references to the uploaded datastruct structs. the other variables are
from the extents and strides of the mdspan classes...:

   #pragma omp target teams distribute parallel for collapse(2) 
shared(inner_dim, rows,
cols,strA1,strA0,strB0,strB1,strC0,strC1)device(devicenum)
for (size_t i = 0; i < rows; ++i)
{
for (size_t j = 0; j < cols; ++j)
{
T sum=0;
#pragma omp simd reduction (+:sum)
for (size_t k = 0; k < inner_dim; ++k)
{
sum+=dA(i,k,strA0,strA1)*dB(k,j,strB0,strB1);
}
   dC.pdata[i*strC0+j*strC1]=sum;
}
}


and then the member function host_update of the result C mdspan class is
called.

Finally, the result C is updated on the host, with the function update_host.

One can test by defining a matrix, reserving space by device_alloc, and then
and updating the host with the random values from the reservation, that the
offloading works.


The problem appears to be that the matrix multiplication is not carried out
anymore on the device,  despite this pragma:

   #pragma omp target teams distribute parallel for collapse(2) 
shared(inner_dim, rows,
cols,strA1,strA0,strB0,strB1,strC0,strC1)device(devicenum)


That seems to be because the references to the datastruct structs where
offloaded with functions that are members of the mdspan classes A, B and C.

Because, if I offload the datastruct references dA,dB,dC directly, by calling
the globally available functions device_datastruct_upload
device_datastruct_alloc, then, gcc and the openmp pragma can apparently
associate them in the loop with the offloaded variables and result coincides
with that of clang and is correct.

But if  device_datastruct_upload device_datastruct_alloc are called from a
different function, which is a member of mdspan class 

[Bug libstdc++/9635] time_get<>::date_order unimplemented

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

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

--- Comment #12 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #11)
> We could also have a custom facet derived from time_get that we store in the
> std::locale when it is created by name from a C locale, and store a
> dateorder enum in that derived type on construction. That would allow
> std::time_get facets that are associated with a C locale to return a correct
> dateorder for the locale (but only if the locale's D_FMT happens to map to
> one of the four distinct dateorder formats!)

Like so ...

--- a/libstdc++-v3/src/c++11/localename.cc
+++ b/libstdc++-v3/src/c++11/localename.cc
@@ -36,6 +36,43 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION

   using namespace __gnu_cxx;

+  template
+struct __time_get : std::time_get
+{
+  explicit
+  __time_get(time_base::dateorder ord, size_t refs = 0)
+  : time_get(refs), _M_order(ord)
+  { }
+
+  time_base::dateorder do_date_order() const override { return _M_order; }
+
+  time_base::dateorder _M_order;
+};
+
+  inline template class __time_get;
+#ifdef _GLIBCXX_USE_WCHAR_T
+  inline template class __time_get;
+#endif
+
+  static inline time_base::dateorder
+  get_date_order(__timepunct* tp)
+  {
+const char*  dates[2];
+tp->_M_date_formats(dates);
+if (const char* d = dates[0])
+  {
+   if (!strcmp(d, "%d/%m/%y"))
+ return time_base::dmy;
+   if (!strcmp(d, "%m/%d/%y"))
+ return time_base::mdy;
+   if (!strcmp(d, "%y/%m/%d"))
+ return time_base::ymd;
+   if (!strcmp(d, "%y/%d/%m"))
+ return time_base::ydm;
+  }
+return time_base::no_order;
+  }
+
   static inline bool
   is_C_locale(const char* s)
   {
@@ -266,8 +303,10 @@ const int num_facets = (
_M_init_facet(new moneypunct(__cloc, 0));
_M_init_facet(new money_get);
_M_init_facet(new money_put);
-   _M_init_facet(new __timepunct(__cloc, __s));
-   _M_init_facet(new time_get);
+   auto tp = new __timepunct(__cloc, __s);
+   _M_init_facet(tp);
+   auto ord = get_date_order(tp);
+   _M_init_facet(new __time_get(ord));
_M_init_facet(new time_put);
_M_init_facet(new std::messages(__cloc, __s));

@@ -283,7 +322,7 @@ const int num_facets = (
_M_init_facet(new money_get);
_M_init_facet(new money_put);
_M_init_facet(new __timepunct(__cloc, __s));
-   _M_init_facet(new time_get);
+   _M_init_facet(new time_get(ord));
_M_init_facet(new time_put);
_M_init_facet(new std::messages(__cloc, __s));
 #endif

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

[kargls at comcast dot net via Gcc-bugs]

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

kargls at comcast dot net changed:

   What|Removed |Added

 CC||kargls at comcast dot net

--- Comment #2 from kargls at comcast dot net ---
(In reply to anlauf from comment #1)
> Works as expected on Linux.
> 
> What happens if you replace C_NEW_LINE by something different,
> like c_carriage_return, or c_null_char, and pipe the output
> through "cat -v"?

Harald, there's a bug (at least it fails on FreeBSD).Here's 
a testcase based on the original code.  On FreeBSD, I see

% gfcx -o z a.f90 && ./z
STOP 2

In sub2, the line 'str(11:11) = c_new_line' places the new line
character in str(1:1).


! { dg-do run }
program main

   use iso_c_binding

   implicit none

   character(len=*), parameter :: const = '0123456789'

   call sub1   ! OK. No pointer initialization.
   call suba   ! OK. Allocatable attribute instead of pointer
   call sub2   ! Not OK. Pointer initialized to null()/ 

   contains

  subroutine sub1
 character(len=:), pointer :: str
 allocate(character(len=11) :: str)
 str = const // 'x'
 str(11:11) = c_new_line
 if (str(1:10) /= const) stop 1
  end subroutine sub1

  subroutine sub2
 character(len=:), pointer :: str => null()
 allocate(character(len=11) :: str)
 str = const // 'x'
 str(11:11) = c_new_line
 if (str(1:10) /= const) stop 2
  end subroutine sub2

  subroutine suba
 character(len=:), allocatable :: str
 str = const // 'x'
 str(11:11) = c_new_line
 if (str(1:10) /= const) stop 3
  end subroutine suba
end

[Bug fortran/120743] [16 regression] ice in verify_gimple_in_seq

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |anlauf at gcc dot 
gnu.org

--- Comment #7 from anlauf at gcc dot gnu.org ---
Submitted: https://gcc.gnu.org/pipermail/fortran/2025-June/062344.html

[Bug fortran/120743] [16 regression] ice in verify_gimple_in_seq

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

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

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

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

commit r16-1658-g5bc92717b804483a17dd5095f8b6d4fd75a472b1
Author: Harald Anlauf 
Date:   Tue Jun 24 20:46:38 2025 +0200

Fortran: fix ICE in verify_gimple_in_seq with substrings [PR120743]

PR fortran/120743

gcc/fortran/ChangeLog:

* trans-expr.cc (gfc_conv_substring): Substring indices are of
type gfc_charlen_type_node.  Convert to size_type_node for
pointer arithmetic only after offset adjustments have been made.

gcc/testsuite/ChangeLog:

* gfortran.dg/pr120743.f90: New test.

Co-authored-by: Jerry DeLisle 
Co-authored-by: Mikael Morin 

[Bug fortran/120711] [14/15/16 regression] Growing arrays segfaults

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

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

Andre Vehreschild  changed:

   What|Removed |Added

Summary|[15/16 regression] Growing  |[14/15/16 regression]
   |arrays segfaults|Growing arrays segfaults
   Priority|P3  |P4

[Bug libstdc++/120806] std::out_ptr is not conforming to the standard

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2025-06-24
 Status|UNCONFIRMED |NEW

[Bug tree-optimization/117113] [12 regression] ICE on valid code at -O3 with "-fno-tree-dce -fno-inline" on x86_64-linux-gnu: verify_ssa failed since r8-5204-gdc236397e4d966

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

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

--- Comment #8 from GCC Commits  ---
The releases/gcc-12 branch has been updated by Richard Biener
:

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

commit r12-11225-gf4dbdeabb2944d014d506a537a576a6f9a1f4c1f
Author: Richard Biener 
Date:   Mon Feb 3 15:12:52 2025 +0100

tree-optimization/117113 - ICE with unroll-and-jam

When there's an inner loop without virtual header PHI but the outer
loop has one the fusion process cannot handle the need to create
an inner loop virtual header PHI.  Punt in this case.

PR tree-optimization/117113
* gimple-loop-jam.cc (unroll_jam_possible_p): Detect when
we cannot handle virtual SSA update.

* gcc.dg/torture/pr117113.c: New testcase.

(cherry picked from commit 0675eb17480bada678bf2769d39732027abcd6d0)

[Bug tree-optimization/120802] Erroneous warning, -Warray-bounds, on accessing memory returned from a function declared with the alloc_size attribute with int pointers on optimisation -02 and above.

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

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

Richard Biener  changed:

   What|Removed |Added

  Known to fail||14.3.0, 15.1.0
  Known to work||15.1.1, 16.0
   Keywords||needs-bisection
 Ever confirmed|0   |1
   Last reconfirmed||2025-06-24
 Status|UNCONFIRMED |NEW

--- Comment #1 from Richard Biener  ---
The diagnostic is no longer emitted on the gcc-15 branch (but with GCC 15.1)
for me.  We might be confused by the IL which is

  ma_9 = xmalloc (_4);
  _5 = ma_9 + 8;
  ma_9->arr = _5;
  MEM[(int *)ma_9 + 8B] = 0;

[Bug testsuite/120805] [16 Regression] gcc.target/powerpc/p9-vec-length-epil-4.c fail starting with r16-1645-g309dbcea2cabb3

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

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

Tamar Christina  changed:

   What|Removed |Added

 CC||tnfchris at gcc dot gnu.org

--- Comment #2 from Tamar Christina  ---
the instruction counts are different because the loops were unrolled less.

Before I look more into it, was the exact unroll amount something tested by the
test? or only that it unrolled?

>From looking at the git log it seems to be more interested in that it got
vectorized, not the unroll amount?

[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)

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

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

Bug 113833 Summary: 435.gromacs fails verification on with -Ofast 
-march={cascadelake,icelake-server} and PGO after r14-7272-g57f611604e8bab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113833

   What|Removed |Added

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

[Bug target/82106] [RISCV] Misaligned loads generated when doubles are split between stack and registers

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

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

Palmer Dabbelt  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |palmer at gcc dot 
gnu.org
 CC||palmer at gcc dot gnu.org

--- Comment #8 from Palmer Dabbelt  ---
This came up in the patchwork meeting, and I guess since I'd commented before
I'm on the hook.  It's been 8-ish years, but here's my best attempt at decoding
what I was saying back then:

By "I'd like to call this an ABI bug", I think I meant that the ABI is
essentially proscribing a misaligned access here and it'd be nice to change
that.  It's definitely too late to do that now, though.

Looking at the code from Jim's patch, I'd expect something different --
essentially we'd just forbid the fld as it's likely misaligned and thus slow,
and instead fall back to lw;lw;shift;or;fmv.x.  Maybe that's just slower than
the load/store juggling, though.

Either way, I'm assigning this to myself.  Mostly as a test to see if I can get
any work done these days... ;)

[Bug tree-optimization/120808] New: SLP unable to combine .FMA and .FMS to VEC_FMADDSUB

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

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

Bug ID: 120808
   Summary: SLP unable to combine .FMA and .FMS to VEC_FMADDSUB
   Product: gcc
   Version: 16.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: amonakov at gcc dot gnu.org
  Target Milestone: ---

void f(double x[restrict], double *y, double *z)
{
x[0] = x[0] * y[0] + z[0];
x[1] = x[1] * y[1] - z[1];
}

with -O2 -mfma -ffp-contract=on yields two individual FMAs rather than
fmsubaddpd.

[Bug tree-optimization/120808] SLP unable to combine .FMA and .FMS to VEC_FMADDSUB

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

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

--- Comment #1 from Andrew Pinski  ---
Hmm, I think there is a dup.

[Bug target/93738] [12/13/14/15/16 regression] test case gcc.target/powerpc/20050603-3.c fails

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

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

--- Comment #9 from Kishan Parmar  ---
I've went through the RTLs for both PowerPC LE and BE. Whether r3 is used or
not now depends on the reload pass.
In LE, reload often removes the extra copies added by combine. In BE, that
extra instruction remains. I'm currently going through reload pass to check if
it can be eliminated there as well.

[Bug libstdc++/9635] time_get<>::date_order unimplemented

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed|2003-12-01 00:55:30 |2025-6-24

--- Comment #11 from Jonathan Wakely  ---
(In reply to Paolo Carlini from comment #5)
> Unfortunately, at the time I overlooked this comment in locale_facets.tcc:
> 
>   // NB: Not especially useful. Without an ios_base object or some
>   // kind of locale reference, we are left clawing at the air where
>   // the side of the mountain used to be...
>   template
> time_base::dateorder
> time_get<_CharT, _InIter>::do_date_order() const
> { return time_base::no_order; }
> 
> Having written the parsing code, now I have no idea how to circumvent the
> above issue, for the moment I'm unassigning myself from the PR.

Yeah, nice ... we can't access the __timepunct facet without a reference to the
std::locale, so we can't get the D_FMT string.

A derived std::time_get can return something different from its
do_date_order(), if it wants to.

We could also have a custom facet derived from time_get that we store in the
std::locale when it is created by name from a C locale, and store a dateorder
enum in that derived type on construction. That would allow std::time_get
facets that are associated with a C locale to return a correct dateorder for
the locale (but only if the locale's D_FMT happens to map to one of the four
distinct dateorder formats!)

Of course this seems pretty useless since our std::time_get::do_get_date
ignores the dateorder anyway, and just uses D_FMT directly, which is much more
useful (and supports alternative formats like the is_IS one).

What we could do is change the default do_date_order() to return mdy instead of
no_order, which would be correct for the C locale and _some_ locales such as
en_US (see Bug 99556), but completely wrong for most other locales. I'm not
sure that's an improvement.

[Bug tree-optimization/115347] [12 Regression] wrong code at -O3 on x86_64-linux-gnu since r12-2097

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

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

--- Comment #11 from GCC Commits  ---
The releases/gcc-12 branch has been updated by Richard Biener
:

https://gcc.gnu.org/g:6258d3f06740c3a77cd7a91606107451d71df68d

commit r12-11221-g6258d3f06740c3a77cd7a91606107451d71df68d
Author: Richard Biener 
Date:   Thu Jan 23 13:10:17 2025 +0100

tree-optimization/112859 - bogus loop distribution

When we get a zero distance vector we still have to check for the
situation of a common inner loop with zero distance.  But we can
still allow a zero distance for the loop we distribute
(gcc.dg/tree-ssa/ldist-33.c is such a case).  This is because
zero distances in non-outermost loops are a misrepresentation
of dependence by dependence analysis.

Note that test coverage of loop distribution of loop nests is
very low.

PR tree-optimization/112859
PR tree-optimization/115347
* tree-loop-distribution.cc
(loop_distribution::pg_add_dependence_edges): For a zero
distance vector still make sure to not have an inner
loop with zero distance.

* gcc.dg/torture/pr112859.c: New testcase.
* gcc.dg/torture/pr115347.c: Likewise.
* gcc.dg/tree-ssa/ldist-36.c: Adjust.

(cherry picked from commit 04ba1300407f106a6dd10d346f58a51d87e6d43e)

[Bug libstdc++/120810] New: [DR 461] std::time_get::do_get_date should consider date_order()

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

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

Bug ID: 120810
   Summary: [DR 461] std::time_get::do_get_date should consider
date_order()
   Product: gcc
   Version: 16.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
Depends on: 9635
Blocks: 86976
  Target Milestone: ---

https://cplusplus.github.io/LWG/issue461

We use the locale's D_FMT format (which is what strftime %x uses too). I think
that works OK in general, and actually seems preferable to DR 461.

DR 461 says we should consider the result of date_order() when deciding how to
parse a date, but that seems to be a poor substitute for knowing the locale's
D_FMT format. DR 461 says "figure out the locale's preferred date format from
one of these four distinct options" but that assumes that the locale _uses_ one
of those options, and that you can find a way to get it from do_date_order()
(which we can't! see Bug 9635).

We could add code to std::time_get::do_get_date() which calls do_date_order()
and if it's not no_order then use the format it specifies. That would do the
right thing for facets derived from std::time_get which override
do_date_order(). If it returns no_order, then fallback to using D_FMT as we do
now.

N.B. testsuite/22_locale/time_get/get_time/char/6.cc (and the wchar_t
equivalent) mention 461 and have some commented out checks that depend on it.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9635
[Bug 9635] time_get<>::date_order unimplemented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86976
[Bug 86976] [meta-bug] Issues with std::time_get, std::time_put etc.

[Bug rtl-optimization/120745] SEGV in process_uses_of_deleted_def, at rtl-ssa/changes.cc:271

[ondrejmachota at gmail dot com via Gcc-bugs]

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

Ondřej Machota  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #3 from Ondřej Machota  ---
Thank you very much for the patch. I can confirm that it fixes the provided
tests. It doesn't seem to break any tests and it also fixes some other tests
from the testsuite that were failing due to cycles in SSA form. I will mark
this and PR120750 as resolved.

[Bug fortran/120711] [14/15/16 regression] Growing arrays segfaults

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

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

--- Comment #2 from anlauf at gcc dot gnu.org ---
There is another recent PR on using array constructors of derived types
with allocatable character components, quite similar to this one.

Cannot find it now, but very likely related.

[Bug middle-end/87984] [12 Regression] wrong code for local reg var input to asm inside a loop

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

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

--- Comment #49 from GCC Commits  ---
The releases/gcc-12 branch has been updated by Richard Biener
:

https://gcc.gnu.org/g:80aab83b90d0a1c9e3037a952c138ac2f1ce3f41

commit r12-11215-g80aab83b90d0a1c9e3037a952c138ac2f1ce3f41
Author: Richard Biener 
Date:   Fri Feb 28 10:36:11 2025 +0100

tree-optimization/87984 - hard register assignments not preserved

The following disables redundant store elimination to hard register
variables which isn't valid.

PR tree-optimization/87984
* tree-ssa-dom.cc (dom_opt_dom_walker::optimize_stmt): Do
not perform redundant store elimination to hard register
variables.
* tree-ssa-sccvn.cc (eliminate_dom_walker::eliminate_stmt):
Likewise.

* gcc.target/i386/pr87984.c: New testcase.

(cherry picked from commit 535115caaf97f5201fb528f67f15b4c52be5619d)

[Bug tree-optimization/117424] [12 regression] Miscompile with different optimization flags since r12-4871-g502ffb1f389011

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

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

--- Comment #17 from GCC Commits  ---
The releases/gcc-12 branch has been updated by Richard Biener
:

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

commit r12-11226-geafe890ea3904c109b6bce663a81a91d61356cb4
Author: Richard Biener 
Date:   Tue Jan 28 12:28:14 2025 +0100

tree-optimization/117424 - invalid LIM of trapping ref

The following addresses a bug in tree_could_trap_p leading to
hoisting of a possibly trapping, because of out-of-bound, access.
We only ensured the first accessed byte is within a decl there,
the patch makes sure the whole base of the reference is within it.
This is pessimistic if a handled component would then subset to
a sub-object within the decl but upcasting of a decl to larger
types should be uncommon, questionable, and wrong without
-fno-strict-aliasing.

The testcase is a bit fragile, but I could not devise a (portable)
way to ensure an out-of-bound access to a decl would fault.

PR tree-optimization/117424
* tree-eh.cc (tree_could_trap_p): Verify the base is
fully contained within a decl.

* gcc.dg/tree-ssa/ssa-lim-25.c: New testcase.

(cherry picked from commit f1e776ce58ae4a6ae67886adb4ae806598e2c7ef)

[Bug c/120801] Using const variables as immediate values in extended assembly constraints with -O0 (x86)

[schwab--- via Gcc-bugs]

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

--- Comment #1 from Andreas Schwab  ---
You need to use constexpr from C23.