[Bug fortran/119948] Source allocation of pure function result rejected

2025-04-25 Thread kargls at comcast dot net via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119948

--- Comment #2 from kargls at comcast dot net ---
(In reply to Damian Rouson from comment #0)
>
> % gfortran -c source-allocate-pure-function-result-component.f90 
> source-allocate-pure-function-result.f90:17:20:
> 
>17 | allocate(test%i, source = 0)
>   |1
> Error: Bad allocate-object at (1) for a PURE procedure

This one is interesting.  The error checks for an impure variable,
but it is not set up to deal with result-name.

>From match.cc(lines 4684-4689):

  bool impure = gfc_impure_variable (tail->expr->symtree->n.sym);
  if (impure && gfc_pure (NULL))
{
  gfc_error ("Bad allocate-object at %C for a PURE procedure");
  goto cleanup;
}

The function gfc_impure_variable is contained in resolve.cc.  The result-name
is not marked as pure (, yet?), so the function returns true.

(gdb) p tail->expr->symtree->n.sym->attr.result
$9 = 1
(gdb) p tail->expr->symtree->n.sym->attr.pure
$10 = 0

(gdb) p tail->expr->symtree->n.sym->ns->proc_name->name
$13 = 0x804e174b0 "construct_test"
(gdb) p tail->expr->symtree->n.sym->ns->proc_name->result->name
$15 = 0x804e15198 "test"

So, this patch seems to do the right things.

diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
index f03708efef7..18bc0254cb3 100644
--- a/gcc/fortran/resolve.cc
+++ b/gcc/fortran/resolve.cc
@@ -18460,6 +18460,17 @@ gfc_impure_variable (gfc_symbol *sym)
   if (sym->attr.use_assoc || sym->attr.in_common)
 return 1;

+  /* If sym is for a result-name, then its pure attribute may not be set.
+ Check the namespace to see if this a procedure, and if it is a 
+ pure function.  FIXME: what about elemental?  */
+  if (sym->attr.result && !sym->attr.pure)
+{
+  if (sym->ns->proc_name
+ && sym->ns->proc_name->attr.pure
+ && sym->ns->proc_name->attr.function)
+   return 0;
+}
+
   /* Check if the symbol's ns is inside the pure procedure.  */
   for (ns = gfc_current_ns; ns; ns = ns->parent)
 {

[Bug target/119949] New: -Wnarrowing in arm's comp_not_to_clear_mask_str_un

2025-04-25 Thread sjames at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119949

Bug ID: 119949
   Summary: -Wnarrowing in arm's comp_not_to_clear_mask_str_un
   Product: gcc
   Version: 16.0
Status: UNCONFIRMED
  Keywords: build
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sjames at gcc dot gnu.org
  Target Milestone: ---

```
armv7a-unknown-linux-gnueabihf-g++ -std=c++14  -fPIE -c -DDEF_GENTOO_SCP
-DDEF_GENTOO_ZNOW -O2 -DIN_GCC-fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-error=narrowing -Wwrite-strings
-Wcast-qual -Wno-format -Wmissing-format-attribute -Wconditionally-supported
-Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings  -DHAVE_CONFIG_H -fPIE -I. -I.
-I/var/tmp/portage/sys-devel/gcc-15.1./work/gcc-15.1./gcc
-I/var/tmp/portage/sys-devel/gcc-15.1./work/gcc-15.1./gcc/.
-I/var/tmp/portage/sys-devel/gcc-15.1./work/gcc-15.1./gcc/../include 
-I/var/tmp/portage/sys-devel/gcc-15.1./work/gcc-15.1./gcc/../libcpp/include
-I/var/tmp/portage/sys-devel/gcc-15.1./work/gcc-15.1./gcc/../libcody 
-I/var/tmp/portage/sys-devel/gcc-15.1./work/gcc-15.1./gcc/../libdecnumber
-I/var/tmp/portage/sys-devel/gcc-15.1./work/gcc-15.1./gcc/../libdecnumber/dpd
-I../libdecnumber
-I/var/tmp/portage/sys-devel/gcc-15.1./work/gcc-15.1./gcc/../libbacktrace
 -D_GENTOO_TIME64_FORCE=0 -o arm.o -MT arm.o -MMD -MP -MF ./.deps/arm.TPo
/var/tmp/portage/sys-devel/gcc-15.1./work/gcc-15.1./gcc/config/arm/arm.cc
/var/tmp/portage/sys-devel/gcc-15.1./work/gcc-15.1./gcc/config/arm/arm.cc:
In function ‘long long unsigned int comp_not_to_clear_mask_str_un(tree, int*,
uint32_t*, unsigned int, int*)’:
/var/tmp/portage/sys-devel/gcc-15.1./work/gcc-15.1./gcc/config/arm/arm.cc:18660:12:
warning: narrowing conversion of ‘-1’ from ‘int’ to ‘uint32_t’ {aka ‘unsigned
int’} [-Wnarrowing]
18660 | = {-1, -1, -1, -1};
  |^~
/var/tmp/portage/sys-devel/gcc-15.1./work/gcc-15.1./gcc/config/arm/arm.cc:18660:16:
warning: narrowing conversion of ‘-1’ from ‘int’ to ‘uint32_t’ {aka ‘unsigned
int’} [-Wnarrowing]
18660 | = {-1, -1, -1, -1};
  |^~
/var/tmp/portage/sys-devel/gcc-15.1./work/gcc-15.1./gcc/config/arm/arm.cc:18660:20:
warning: narrowing conversion of ‘-1’ from ‘int’ to ‘uint32_t’ {aka ‘unsigned
int’} [-Wnarrowing]
18660 | = {-1, -1, -1, -1};
  |^~
/var/tmp/portage/sys-devel/gcc-15.1./work/gcc-15.1./gcc/config/arm/arm.cc:18660:24:
warning: narrowing conversion of ‘-1’ from ‘int’ to ‘uint32_t’ {aka ‘unsigned
int’} [-Wnarrowing]
18660 | = {-1, -1, -1, -1};
  |^~
```

[Bug tree-optimization/119946] memset/memcpy with a null argument should be folded into `if (size_arg) __builtin_unreachable();`

2025-04-25 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119946

Andrew Pinski  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |pinskia at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2025-04-26
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
I will handle nonnull_if_nonzero in gimple-ssa-isolate-paths.cc . But maybe
next week.

[Bug target/119937] [15/16 Regression] ICE: Error detected at a-sttebu.ads:56:30

2025-04-25 Thread doko at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119937

Matthias Klose  changed:

   What|Removed |Added

 Ever confirmed|1   |0
 Status|WAITING |UNCONFIRMED

--- Comment #3 from Matthias Klose  ---
Configured with: -v
 --with-pkgversion='Debian 15-20250423-1'
 --with-bugurl='file:///usr/share/doc/gcc-15/README.Bugs'
 --enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2,rust,algol68
 --prefix=/usr
 --with-gcc-major-version-only
 --program-suffix=-15
 --program-prefix=arm-linux-gnueabihf-
 --enable-shared
 --enable-linker-build-id
 --libexecdir=/usr/libexec
 --without-included-gettext
 --enable-threads=posix
 --libdir=/usr/lib
 --enable-nls
 --enable-bootstrap
 --enable-clocale=gnu
 --enable-libstdcxx-debug
 --enable-libstdcxx-time=yes
 --with-default-libstdcxx-abi=new
 --enable-libstdcxx-backtrace
 --enable-gnu-unique-object
 --disable-libitm
 --disable-libquadmath
 --disable-libquadmath-support
 --enable-plugin
 --enable-default-pie
 --with-system-zlib
 --enable-libphobos-checking=release
 --with-target-system-zlib=auto
 --enable-objc-gc=auto
 --enable-multiarch
 --disable-sjlj-exceptions
 --with-arch=armv7-a+fp
 --with-float=hard
 --with-mode=thumb
 --disable-werror
 --enable-checking=yes
 --build=arm-linux-gnueabihf
 --host=arm-linux-gnueabihf
 --target=arm-linux-gnueabihf

[Bug target/119937] [15/16 Regression] ICE: Error detected at a-sttebu.ads:56:30

2025-04-25 Thread doko at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119937

--- Comment #4 from Matthias Klose  ---
a cross compiler targeting arm-linux-gnueabihf is built successful.

[Bug cobol/119364] building a cobol cross compiler on i686-linux-gnu targeting x86_64-linux-gnu fails

2025-04-25 Thread doko at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119364

--- Comment #21 from Matthias Klose  ---
the attached patch doesn't apply anymore for the 15.1.0 release, and the build
on i686 fails with

In file included from ../../src/gcc/cobol/cdf.y:37:
../../src/gcc/cobol/../../libgcobol/common-defs.h:186:23: error: enumerator
value '4294967296' is outside the range of underlying type 'size_t' {aka
'unsigned int'}
  186 |   depends_on_e  = 0x01, // A group hierachy contains a
DEPENDING_ON
  |   ^~~~
../../src/gcc/cobol/../../libgcobol/common-defs.h:187:23: error: enumerator
value '8589934592' is outside the range of underlying type 'size_t' {aka
'unsigned int'}
  187 |   initialized_e = 0x02, // Don't call parser_initialize
from parser_symbol_add
  |   ^~~~

[Bug target/119937] [15/16 Regression] ICE: Error detected at a-sttebu.ads:56:30

2025-04-25 Thread sjames at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119937

--- Comment #5 from Sam James  ---
Lemme try repro.

[Bug c/119878] __builtin_has_attribute(VAR, nonstring) does not work on multidimensional arrays marked with nonstring

2025-04-25 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119878

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
??
There are no nostring attributes in the above addition and it is syntactically
incorrect as well (multiple places).

When I compile:
static const char single[] __attribute__((nonstring)) = "ohai";
_Static_assert (__builtin_has_attribute (single, nonstring));
static const char multi2[][4] __attribute__((nonstring)) = { "hola" };
_Static_assert (__builtin_has_attribute (multi2, nonstring));
static const char multi3[][16][5] __attribute__((nonstring)) = { { "hello" } };
_Static_assert (__builtin_has_attribute (multi3, nonstring));
it compiles just fine.

[Bug c++/119939] New: [modules] Constraints attached to defaulted friend functions don't work correctly

2025-04-25 Thread nshead at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119939

Bug ID: 119939
   Summary: [modules] Constraints attached to defaulted friend
functions don't work correctly
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nshead at gcc dot gnu.org
Blocks: 103524
  Target Milestone: ---

Consider the following:

  // test.h
  template  concept A = true;
  template  concept B = requires { T{}; };
  template  struct S {
friend bool operator==(const S&, const S&) requires B = default;
  };

  // test.cpp
  import "test.h";
  int main() {
S s;
s == s;
  }

$ g++ -std=c++20 -fmodules -S test.h test.cpp -fconcepts-diagnostics-depth=2
test.cpp: In function ‘int main()’:
test.cpp:5:5: error: no match for ‘operator==’ (operand types are ‘S’ and
‘S’)
5 |   s == s;
  |   ~ ^~ ~
  |   ||
  |   |S<[...]>
  |   S<[...]>
test.cpp:5:5: note: there is 1 candidate
5 |   s == s;
  |   ~~^~~~
In module test.h, imported at test.cpp:1:
test.h:4:15: note: candidate 1: ‘bool operator==(const S&, const S&)
requires  B’
4 |   friend bool operator==(const S&, const S&) requires B = default;
  |   ^~~~
test.h:4:15: note: constraints not satisfied
test.h: In instantiation of ‘bool operator==(const S&, const S&)
requires  B’:
test.cpp:5:8:   required from here
5 |   s == s;
  |^
test.h:2:31:   required for the satisfaction of ‘B’
test.h:2:35:   in requirements  [with T = T]
test.h:2:46: note: the required expression ‘T{}’ is invalid, because
2 | template  concept B = requires { T{}; };
  |  ^~~
test.h:2:46: error: invalid use of template type parameter ‘T’

This is because by the time we get to satisfy_declaration_constraints in the
importing module, the friend function no longer has template arguments attached
to it, and so constraint satisfaction gets confused.  When not importing the
DECL_TEMPLATE_INFO is still attached to this declaration; it seems that module
streaming should still stream this info even if the decl isn't strictly a
template anymore.


Referenced Bugs:

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

[Bug target/119937] [15/16 Regression] ICE in maybe_record_trace_start, at dwarf2cfi.cc:2591

2025-04-25 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119937

Andrew Pinski  changed:

   What|Removed |Added

Summary|[15 Regression] ICE in  |[15/16 Regression] ICE in
   |maybe_record_trace_start,   |maybe_record_trace_start,
   |at dwarf2cfi.cc:2591|at dwarf2cfi.cc:2591
   Target Milestone|--- |15.2

[Bug target/118141] GCC miscompiles __builtin_convertvector() narrowing operation on amd64 above -O1

2025-04-25 Thread uecker at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118141

uecker at gcc dot gnu.org changed:

   What|Removed |Added

 CC||uecker at gcc dot gnu.org

--- Comment #17 from uecker at gcc dot gnu.org ---

In C, type punning via unions is not undefined behavior. Reading via a
different member than last written could be undefined behavior when it is a
non-value (trap) representation for the type.

[Bug target/119873] s390x musttail call failure on s390x

2025-04-25 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119873

--- Comment #3 from GCC Commits  ---
The releases/gcc-15 branch has been updated by Jakub Jelinek
:

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

commit r15-9587-ga36dd9ee5bb1d2f2f19b8d935db29468a35bb47e
Author: Jakub Jelinek 
Date:   Thu Apr 24 23:44:28 2025 +0200

s390: Allow 5+ argument tail-calls in some special cases [PR119873]

protobuf (and therefore firefox too) currently doesn't build on
s390*-linux.
The problem is that it uses [[clang::musttail]] attribute heavily, and in
llvm (IMHO llvm bug) [[clang::musttail]] calls with 5+ arguments on
s390*-linux are silently accepted and result in a normal non-tail call.
In GCC we just reject those because the target hook refuses to tail call it
(IMHO the right behavior).
Now, the reason why that happens is as s390_function_ok_for_sibcall
attempts
to explain, the 5th argument (assuming normal <= wordsize integer or
pointer
arguments, nothing that needs 2+ registers) is passed in %r6 which is not
call clobbered, so we can't do tail call when we'd have to change content
of that register and then caller would assume %r6 content didn't change and
use it again.
In the protobuf case though, the 5th argument is always passed through
from the caller to the musttail callee unmodified, so one can actually
emit just jg tail_called_function or perhaps tweak some registers but
keep %r6 untouched, and in that case I think it is just fine to tail call
it (at least unless the stack slots used for 6+ argument can't be modified
by the callee in the ABI and nothing checks for that).

So, the following patch checks for this special case, where the argument
which uses %r6 is passed in a single register and it is passed default
definition of SSA_NAME of a PARM_DECL with the same DECL_INCOMING_RTL.

It won't really work at -O0 but should work for -O1 and above, at least
when
one doesn't really try to modify the parameter conditionally and hope it
will
be optimized away in the end.

2025-04-24  Jakub Jelinek  
Stefan Schulze Frielinghaus  

PR target/119873
* config/s390/s390.cc (s390_call_saved_register_used): Don't return
true if default definition of PARM_DECL SSA_NAME of the same
register
is passed in call saved register.
(s390_function_ok_for_sibcall): Adjust comment.

* gcc.target/s390/pr119873-1.c: New test.
* gcc.target/s390/pr119873-2.c: New test.
* gcc.target/s390/pr119873-3.c: New test.
* gcc.target/s390/pr119873-4.c: New test.

(cherry picked from commit 567684733e0c4f28158e19b72f4e7f660ad81561)

[Bug tree-optimization/119399] [12 Backport] Overlap check in vectorized code may invoke UB

2025-04-25 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119399

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

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

commit r12-11070-gd419ea32d8968d8e88d0e7f5d8ecc57d610a5a3b
Author: Richard Sandiford 
Date:   Fri Apr 25 12:04:47 2025 +0100

Avoid using POINTER_DIFF_EXPR for overlap checks [PR119399]

In r10-4803-g8489e1f45b50600c I'd used POINTER_DIFF_EXPR to subtract
the two pointers involved in an overlap test.  I'm not sure whether
I'd specifically chosen that over MINUS_EXPR or not; if so, the only
reason I can think of is that it is probably faster on targets with
PSImode pointers.  Regardless, as the PR points out, subtracting
unrelated pointers using POINTER_DIFF_EXPR is undefined behaviour.

gcc/
PR tree-optimization/119399
* tree-data-ref.cc (create_waw_or_war_checks): Use a MINUS_EXPR
on two converted pointers, rather than converting a
POINTER_DIFF_EXPR
on the pointers.

gcc/testsuite/
PR tree-optimization/119399
* gcc.dg/vect/pr119399.c: New test.

(cherry picked from commit 4c8c373495d7d863dfb7102726ac3b4b41685df4)

[Bug tree-optimization/116125] [12 Regression] Does not fully checking for overlapping memory regions with the vectorizer

2025-04-25 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116125

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

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

commit r12-11069-ga895b98c6722277c5129dd5d813bbb2e8ac9c98f
Author: Richard Sandiford 
Date:   Fri Apr 25 12:04:46 2025 +0100

vect: Enforce dr_with_seg_len::align precondition [PR116125]

tree-data-refs.cc uses alignment information to try to optimise
the code generated for alias checks.  The assumption for "normal"
non-grouped, full-width scalar accesses was that the access size
would be a multiple of the alignment.  As Richi notes in the PR,
this is a documented precondition of dr_with_seg_len:

  /* The minimum common alignment of DR's start address, SEG_LEN and
 ACCESS_SIZE.  */
  unsigned int align;

PR115192 was a case in which this assumption didn't hold.  The access
was part of an aligned 4-element group, but only the first 2 elements
of the group were accessed.  The alignment was therefore double the
access size.

In r15-820-ga0fe4fb1c8d78045 I'd "fixed" that by capping the
alignment in one of the output routines.  But I think that was
misconceived.  The precondition means that we should cap the
alignment at source instead.

Failure to do that caused a similar wrong code bug in this PR,
where the alignment comes from a short bitfield access rather
than from a group access.

gcc/
PR tree-optimization/116125
* tree-vect-data-refs.cc (vect_prune_runtime_alias_test_list): Make
the dr_with_seg_len alignment fields describe tha access sizes as
well as the pointer alignment.
* tree-data-ref.cc (create_intersect_range_checks): Don't
compensate
for invalid alignment fields here.

gcc/testsuite/
PR tree-optimization/116125
* gcc.dg/vect/pr116125.c: New test.

(cherry picked from commit e8651b80aeb86da935035e218747a6b41b611497)

[Bug c++/119936] New: add warning if assume expression is compile-time evaluated to false

2025-04-25 Thread drepper.fsp+rhbz at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119936

Bug ID: 119936
   Summary: add warning if assume expression is compile-time
evaluated to false
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: drepper.fsp+rhbz at gmail dot com
  Target Milestone: ---

I incorrectly used the assume attribute like this (simplified):

template
int f(int v)
{
  [[assume(eq && v < 10)]];
  return v + 1;
}

template int f(int);
template int f(int);


The function was larger and unlike in this case, there was actually code being
generated for it (here, code is only created for the second instantiation).  In
my case the generated code was nonsense and lead to hard-to-find crashes. 
Correctly the attribute should have been something like

  [[assume(!eq || v<10)]];

The C++ standard requires that the assume expression can be evaluated to 'true'
in some cases.  Otherwise, I guess, the behavior is undefined.

Therefore I think the compiler should issue a warning in case the expression is
always evaluating to false and the compiler acts on this.

[Bug libstdc++/119918] formattable returns true for types other than char and wchar_t

2025-04-25 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119918

--- Comment #2 from GCC Commits  ---
The master branch has been updated by Tomasz Kaminski :

https://gcc.gnu.org/g:74605294950e4a49627fb71fdedefea176f5ecf7

commit r16-137-g74605294950e4a49627fb71fdedefea176f5ecf7
Author: Tomasz KamiÅski 
Date:   Thu Apr 24 09:32:24 2025 +0200

libstdc++: Constrain formatter for thread::id [PR119918]

This patch add constraint __formatter::__char to _CharT type parameter
of formatter specialization, matching the constraint
of formatting of integer/pointers that are used as native handles.

The dependency on  header, is changed to .
To achieve that, formatting of pointers is extracted from void const*
specialization to internal __formatter_ptr<_CharT>, that can be forward
declared.

Finally, the handle representation is now printed directly to __fc.out(),
by the formatter for handle type. To support this, internal formatters
can now be constructed from _Spec object as alternative to invoking parse
method.

PR libstdc++/119918

libstdc++-v3/ChangeLog:

* include/bits/formatfwd.h (__format::_Align): Moved from
std/format.
(std::__throw_format_error, __format::__formatter_str)
(__format::__formatter_ptr): Declare.
* include/std/format (__format::_Align): Moved to bits/formatfwd.h.
(__formatter_int::__formatter_int): Define.
(__format::__formatter_ptr): Extracted from formatter for const
void*.
(std::formatter, formatter)
(std::formatter): Delegate to
__formatter_ptr<_CharT>.
* include/std/thread (std::formatter):
Constrain
_CharT template parameter.
(formatter::parse): Specify default aligment,
and
qualify __throw_format_error to disable ADL.
(formatter::format): Use formatters to write
directly
to output.
* testsuite/30_threads/thread/id/output.cc: Tests for formatting
thread::id
representing not-a-thread with padding and formattable concept.

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

[Bug libstdc++/109162] C++23 improvements to std::format

2025-04-25 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109162

--- Comment #15 from GCC Commits  ---
The master branch has been updated by Tomasz Kaminski :

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

commit r16-135-gbacf741a92a9a84becd23542b73186da4e4acbf6
Author: Tomasz KamiÅski 
Date:   Fri Apr 18 14:56:39 2025 +0200

libstdc++: Implement formatters for queue, priority_queue and stack
[PR109162]

This patch implements formatter specializations for standard container
adaptors
(queue, priority_queue and stack) from P2286R8.

To be able to access the protected `c` member, the adaptors befriend
corresponding formatter specializations. Note that such specialization
may be disable if the container is formattable, in such case
specializations are unharmful.

As in the case of previous commits, the signatures of the user-facing parse
and format methods of the provided formatters deviate from the standard by
constraining types of parameters:
 * _CharT is constrained __formatter::__char
 * basic_format_parse_context<_CharT> for parse argument
 * basic_format_context<_Out, _CharT> for format second argument
The standard specifies all above as unconstrained types. In particular
_CharT constrain, allow us to befriend all allowed specializations.

Furthermore the standard specifies these formatters as delegating to
formatter, charT>, which in turn
delegates to range_formatter. This patch avoids one level of indirection,
and dependency of ranges::ref_view.  This is technically observable if
user specializes formatter> where PD is program defined
container, but I do not think this is the case worth extra indirection.

This patch also moves the formattable and it's dependencies to the
formatfwd.h,
so it can be used in adapters formatters, without including format header.
The definition of _Iter_for is changed from alias to denoting
back_insert_iterator>, to struct with type nested
typedef
that points to same type, that is forward declared.

PR libstdc++/109162

libstdc++-v3/ChangeLog:

* include/bits/formatfwd.h (__format::__parsable_with)
(__format::__formattable_with, __format::__formattable_impl)
(__format::__has_debug_format, __format::__const_formattable_range)
(__format::__maybe_const_range, __format::__maybe_const)
(std::formattable): Moved from std/format.
(__format::Iter_for, std::range_formatter): Forward declare.
* include/bits/stl_queue.h (std::formatter): Forward declare.
(std::queue, std::priority_queue): Befriend formatter
specializations.
* include/bits/stl_stack.h (std::formatter): Forward declare.
(std::stack): Befriend formatter specializations.
* include/std/format (__format::_Iter_for): Define as struct with
(__format::__parsable_with, __format::__formattable_with)
(__format::__formattable_impl, __format::__has_debug_format)
(_format::__const_formattable_range, __format::__maybe_const_range)
(__format::__maybe_const, std::formattable): Moved to
bits/formatfwd.h.
(std::range_formatter): Remove default argument specified in
declaration
in bits/formatfwd.h.
* include/std/queue: Include bits/version.h before
bits/stl_queue.h.
(formatter, _CharT>)
(formatter, _CharT>):
Define.
* include/std/stack: Include bits/version.h before bits/stl_stack.h
(formatter, _CharT>): Define.
* testsuite/std/format/ranges/adaptors.cc: New test.

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

[Bug tree-optimization/116125] [12 Regression] Does not fully checking for overlapping memory regions with the vectorizer

2025-04-25 Thread rsandifo at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116125

Richard Sandiford  changed:

   What|Removed |Added

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

--- Comment #14 from Richard Sandiford  ---
Fixed.

[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations

2025-04-25 Thread rsandifo at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
Bug 53947 depends on bug 116125, which changed state.

Bug 116125 Summary: [12 Regression] Does not fully checking for overlapping 
memory regions with the vectorizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116125

   What|Removed |Added

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

[Bug middle-end/118443] [Meta bug] Bugs triggered by and blocking more smtgcc testing

2025-04-25 Thread rsandifo at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118443
Bug 118443 depends on bug 119399, which changed state.

Bug 119399 Summary: [12 Backport] Overlap check in vectorized code may invoke UB
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119399

   What|Removed |Added

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

[Bug tree-optimization/119399] [12 Backport] Overlap check in vectorized code may invoke UB

2025-04-25 Thread rsandifo at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119399

Richard Sandiford  changed:

   What|Removed |Added

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

--- Comment #11 from Richard Sandiford  ---
Fixed.

[Bug c++/119936] add warning if assume expression is compile-time evaluated to false

2025-04-25 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119936

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed||2025-04-25
 Blocks||87403
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87403
[Bug 87403] [Meta-bug] Issues that suggest a new warning

[Bug tree-optimization/113416] ICE: in force_constant_size, at gimplify.cc:742 (in convert_move, at expr.cc:223) with -march=rv64gcv (-march=rv32gcv) and -ftree-parallelize-loops=2

2025-04-25 Thread rsandifo at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113416
Bug 113416 depends on bug 101018, which changed state.

Bug 101018 Summary: ICE when enabling OpenMP on a simple loop with SVE 
intrinsics (aarch64)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101018

   What|Removed |Added

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

[Bug middle-end/101018] ICE when enabling OpenMP on a simple loop with SVE intrinsics (aarch64)

2025-04-25 Thread rsandifo at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101018

Richard Sandiford  changed:

   What|Removed |Added

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

--- Comment #10 from Richard Sandiford  ---
Fixed.

[Bug target/96191] aarch64 stack_protect_test canary leak

2025-04-25 Thread rsandifo at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96191

Richard Sandiford  changed:

   What|Removed |Added

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

--- Comment #11 from Richard Sandiford  ---
Fixed.

[Bug c++/119938] New: [15/16 Regression][modules] Class type NTTPs are not considered constant when imported

2025-04-25 Thread nshead at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119938

Bug ID: 119938
   Summary: [15/16 Regression][modules] Class type NTTPs are not
considered constant when imported
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nshead at gcc dot gnu.org
Blocks: 103524
  Target Milestone: ---

There are a large number of issues caused by CNTTPs not properly being
considered constant when imported.  Some examples:

===

  // eg1.h
  struct A { int x; };
  template  struct B { static_assert(a.x == 5); };
  using C = B;

  // eg1.cpp
  import "eg1.h";
  C c;

$ g++ -std=c++20 -fmodules -S eg1.h eg1.cpp
eg1.cpp:2:3: error: aggregate ‘C c’ has incomplete type and cannot be defined
2 | C c;
  |   ^

===

  // eg2.h
  struct A { int x; };
  template  void foo() { static_assert(a.x == 5); };
  inline void bar() { foo(); }

  // eg2.cpp
  import "eg2.h";
  int main() { bar(); }

$ g++ -std=c++20 -fmodules -S eg2.h eg2.cpp
eg2.cpp:2:21: internal compiler error: Segmentation fault
2 | int main() { bar(); }
  | ^
0x3ce0f35 internal_error(char const*, ...)
../../gcc/gcc/diagnostic-global-context.cc:517
0x1d35e92 crash_signal
../../gcc/gcc/toplev.cc:322
0x7f0490a2732f ???
./signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0
0xec9815 tree_check(tree_node const*, char const*, int, char const*, tree_code)
../../gcc/gcc/tree.h:3979
0x158fde8 symbol_table::decl_assembler_name_hash(tree_node const*)
../../gcc/gcc/symtab.cc:84
0x1592d30 symtab_node::get_for_asmname(tree_node const*)
../../gcc/gcc/symtab.cc:1067
0x1592fe1 symtab_node::verify_base()
../../gcc/gcc/symtab.cc:1158
0x15ac085 cgraph_node::verify_node()
../../gcc/gcc/cgraph.cc:3499
0x159394b symtab_node::verify()
../../gcc/gcc/symtab.cc:1362
0x1593d2d symtab_node::verify_symtab_nodes()
../../gcc/gcc/symtab.cc:1482
0x15bdd0e symtab_node::checking_verify_symtab_nodes()
../../gcc/gcc/cgraph.h:702
0x15bd1e7 symbol_table::compile()
../../gcc/gcc/cgraphunit.cc:2332
0x15bd899 symbol_table::finalize_compilation_unit()
../../gcc/gcc/cgraphunit.cc:2607
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.

===

  // eg3.h
  struct A { int x; };
  template  struct B { static constexpr int result = a.x; };
  template  constexpr int foo() { return B::result; };

  // eg3.cpp
  import "eg3.h";
  static_assert(foo() == 5);

$ g++ -std=c++20 -fmodules -S eg3.h eg3.cpp
eg3.cpp:2:21: error: non-constant condition for static assertion
2 | static_assert(foo() == 5);
  |   ~~^~~~
In module eg3.h, imported at eg3.cpp:1:
eg3.cpp:2:18:   in ‘constexpr’ expansion of ‘foo<>()’
eg3.h:3:56: error: the value of ‘B::result’ is not usable in a constant
expression
3 | template  constexpr int foo() { return B::result; };
  |   ~^~
eg3.h:2:48: note: ‘B::result’ used in its own initialiser
2 | template  struct B { static constexpr int result = a; };
   ^~

==

... and so forth.  This worked correctly in GCC14.  I have a patch that fixes
all these cases.


Referenced Bugs:

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

[Bug c++/113920] Make -std=gnu++20 default for GCC 16

2025-04-25 Thread mpolacek at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113920

Marek Polacek  changed:

   What|Removed |Added

   Target Milestone|15.2|---

[Bug target/119873] s390x musttail call failure on s390x

2025-04-25 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119873

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

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

commit r16-139-g3d156c9e9bdaf351f77e3348b7d0d75e08f65580
Author: Jakub Jelinek 
Date:   Fri Apr 25 14:42:01 2025 +0200

s390: Allow 5+ argument tail-calls in some -m31 -mzarch special cases
[PR119873]

Here is a patch to handle the PARALLEL case too.
I think we can just use rtx_equal_p there, because it will always use
SImode in the EXPR_LIST REGs in that case.

2025-04-25  Jakub Jelinek  

PR target/119873
* config/s390/s390.cc (s390_call_saved_register_used): Don't return
true if default definition of PARM_DECL SSA_NAME of the same
register
is passed in call saved register in the PARALLEL case either.

* gcc.target/s390/pr119873-5.c: New test.

[Bug libstdc++/109162] C++23 improvements to std::format

2025-04-25 Thread hewillk at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109162

--- Comment #21 from 康桓瑋  ---
> Furthermore the standard specifies these formatters as delegating to
> formatter, charT>, which in turn
> delegates to range_formatter. This patch avoids one level of indirection,
> and dependency of ranges::ref_view.  This is technically observable if
> user specializes formatter> where PD is program defined
> container, but I do not think this is the case worth extra indirection.

That is highly intentional to fix incorrect formatting when the container is a
string. See https://cplusplus.github.io/LWG/issue3881

[Bug target/119873] s390x musttail call failure on s390x

2025-04-25 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119873

--- Comment #5 from GCC Commits  ---
The releases/gcc-15 branch has been updated by Jakub Jelinek
:

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

commit r15-9590-gf36ec88aa85a1a8f4ec300dfcd862fc4fbca1c53
Author: Jakub Jelinek 
Date:   Fri Apr 25 14:42:01 2025 +0200

s390: Allow 5+ argument tail-calls in some -m31 -mzarch special cases
[PR119873]

Here is a patch to handle the PARALLEL case too.
I think we can just use rtx_equal_p there, because it will always use
SImode in the EXPR_LIST REGs in that case.

2025-04-25  Jakub Jelinek  

PR target/119873
* config/s390/s390.cc (s390_call_saved_register_used): Don't return
true if default definition of PARM_DECL SSA_NAME of the same
register
is passed in call saved register in the PARALLEL case either.

* gcc.target/s390/pr119873-5.c: New test.

(cherry picked from commit 3d156c9e9bdaf351f77e3348b7d0d75e08f65580)

[Bug target/119873] s390x musttail call failure on s390x

2025-04-25 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119873

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #6 from Jakub Jelinek  ---
Implemented for 16.1+ and for 15.2+ (for the latter only for musttail calls).

[Bug libstdc++/109162] C++23 improvements to std::format

2025-04-25 Thread tkaminsk at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109162

--- Comment #22 from Tomasz Kamiński  ---
> That is highly intentional to fix incorrect formatting when the container is 
> a string. See https://cplusplus.github.io/LWG/issue3881

I am well aware of this quirk, but my implementation uses range_formatter
in this case, and also produce sequence of characters, instead of string
presentation.
See corresponding test case:
```
// Sequence output is always used
std::queue<_CharT, std::basic_string<_CharT>> qs(
std::from_range,
std::basic_string_view<_CharT>(WIDEN("321")));

  res = std::format(WIDEN("{}"), qs);
  VERIFY( res == WIDEN("['3', '2', '1']") );
```

So I still see no reason to using formatter> over range_formatter.

[Bug c/119528] __attribute__((deprecated(text)) triggers with __attribute__((malloc(deallocator, index)))

2025-04-25 Thread akallabeth+gnu at posteo dot net via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119528

--- Comment #8 from akallabeth+gnu at posteo dot net ---
Update on the workaround:
while this indeed silences the deprecation warnings you now get
-Wredundant-decl warnings instead...

On 31.03.25 09:38, rguenth at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119528
> 
> Richard Biener  changed:
> 
> What|Removed |Added
> 
> Keywords||documentation
> 
> --- Comment #7 from Richard Biener  ---
> I can see that it's useful to have a related pack of deprecated functions 
> which
> might reference each other.  But that's not how deprecated is designed.
> Whether attribution should be a use and diagnosed directly, or only diagnosed
> when the attributed function is used is another thing.
> 
> I think this should possibly be clarified in documentation and the workaround
> pointed out there.
>

[Bug libstdc++/109162] C++23 improvements to std::format

2025-04-25 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109162

--- Comment #25 from GCC Commits  ---
The master branch has been updated by Tomasz Kaminski :

https://gcc.gnu.org/g:01e5ef3e8b91288f5d387a27708f9f8979a50edf

commit r16-142-g01e5ef3e8b91288f5d387a27708f9f8979a50edf
Author: Tomasz KamiÅski 
Date:   Wed Apr 23 13:17:09 2025 +0200

libstdc++: Minimalize temporary allocations when width is specified
[PR109162]

When width parameter is specified for formatting range, tuple or escaped
presentation of string, we used to format characters to temporary string,
and write produce sequence padded according to the spec. However, once the
estimated width of formatted representation of input is larger than the
value
of spec width, it can be written directly to the output. This limits size
of
required allocation, especially for large ranges.

Similarly, if precision (maximum) width is provided for string
presentation,
only a prefix of sequence with estimated width not greater than precision,
needs
to be buffered.

To realize above, this commit implements a new _Padding_sink
specialization.
This sink holds an output iterator, a value of padding width, (optionally)
maximum width and a string buffer inherited from _Str_sink.
Then any incoming characters are treated in one of following ways,
depending of
estimated width W of written sequence:
* written to string if W is smaller than padding width and maximum width
(if present)
* ignored, if W is greater than maximum width
* written to output iterator, if W is greater than padding width

The padding sink is used instead of _Str_sink in __format::__format_padded,
__formatter_str::_M_format_escaped functions.

Furthermore __formatter_str::_M_format implementation was reworked, to:
* reduce number of instantiations by delegating to _Rg& and const _Rg&
overloads,
* non-debug presentation is written to _Out directly or via _Padding_sink
* if maximum width is specified for debug format with non-unicode encoding,
  string size is limited to that number.

PR libstdc++/109162

libstdc++-v3/ChangeLog:

* include/bits/formatfwd.h (__simply_formattable_range): Moved from
std/format.
* include/std/format (__formatter_str::_format): Extracted escaped
string handling to separate method...
(__formatter_str::_M_format_escaped): Use __Padding_sink.
(__formatter_str::_M_format): Adjusted implementation.
(__formatter_str::_S_trunc): Extracted as namespace function...
(__format::_truncate): Extracted from __formatter_str::_S_trunc.
(__format::_Seq_sink): Removed forward declarations, made members
protected and non-final.
(_Seq_sink::_M_trim): Define.
(_Seq_sink::_M_span): Renamed from view.
(_Seq_sink::view): Returns string_view instead of span.
(__format::_Str_sink): Moved after _Seq_sink.
(__format::__format_padded): Use _Padding_sink.
* testsuite/std/format/debug.cc: Add timeout and new tests.
* testsuite/std/format/ranges/sequence.cc: Specify unicode as
encoding and new tests.
* testsuite/std/format/ranges/string.cc: Likewise.
* testsuite/std/format/tuple.cc: Likewise.

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

[Bug libstdc++/109162] C++23 improvements to std::format

2025-04-25 Thread tkaminsk at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109162

--- Comment #26 from Tomasz Kamiński  ---
The latest commit (optimization) is for GCC 16 only.

[Bug tree-optimization/119811] calls.h should not be needed for tree-ssa-phiopt.cc

2025-04-25 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119811

--- Comment #2 from GCC Commits  ---
The trunk branch has been updated by Andrew Pinski :

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

commit r16-144-gc565e0d3c4ad7c58697f3661269483ce6067e313
Author: Andrew Pinski 
Date:   Fri Apr 18 17:10:12 2025 -0700

phiopt: Remove calls.h include [PR119811]

When the patch,
https://gcc.gnu.org/pipermail/gcc-patches/2024-August/660807.html was rewroked
into r15-3047-g404d947d8ddd3c,
the include for calls.h was still included and missed that it was no longer
needed.

Pushed as obvious.

PR tree-optimization/119811
gcc/ChangeLog:

* tree-ssa-phiopt.cc: Remove calls.h include.

Signed-off-by: Andrew Pinski 

[Bug target/119937] [15/16 Regression] ICE: Error detected at a-sttebu.ads:56:30

2025-04-25 Thread ebotcazou at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119937

Eric Botcazou  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2025-04-25
 CC||ebotcazou at gcc dot gnu.org

--- Comment #2 from Eric Botcazou  ---
The configure line is missing as per https://gcc.gnu.org/bugs/

[Bug tree-optimization/119811] calls.h should not be needed for tree-ssa-phiopt.cc

2025-04-25 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119811

Andrew Pinski  changed:

   What|Removed |Added

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

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

[Bug target/110998] Inconsistent -Wformat warnings issued for %I64d

2025-04-25 Thread ossman at cendio dot se via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110998

Pierre Ossman  changed:

   What|Removed |Added

 CC||ossman at cendio dot se

--- Comment #1 from Pierre Ossman  ---
The issue seems to be that gcc assumes that MinGW's printf() (not Microsoft's)
is more strictly POSIX and doesn't support I64. You can easily see this if you
toggle which version is used:

> $ x86_64-w64-mingw32-gcc -D__USE_MINGW_ANSI_STDIO=0 -Wformat -o printf.exe 
> printf.c 
> 
> $ x86_64-w64-mingw32-gcc -D__USE_MINGW_ANSI_STDIO=1 -Wformat -o printf.exe 
> printf.c 
> printf.c: In function 'main':
> printf.c:8:17: warning: 'I' flag used with '%x' gnu_printf format [-Wformat=]
> 8 | printf("%I64x\n", x);
>   | ^
> printf.c:8:17: warning: format '%x' expects argument of type 'unsigned int', 
> but argument 2 has type 'long long unsigned int' [-Wformat=]
> 8 | printf("%I64x\n", x);
>   | ^ ~
>   | | |
>   | | long long unsigned int
>   | unsigned int
>   | %I64llx

Runtime test shows that the warning is incorrect, though. MinGW's printf()
supports I64 just fine.

Issue seen with gcc 14.2.1 here.

[Bug c/119940] New: Incorrect calculate MD5 (for -gcodeview) under windows

2025-04-25 Thread bc-info at styx dot cabel.net via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119940

Bug ID: 119940
   Summary: Incorrect calculate MD5 (for -gcodeview) under windows
   Product: gcc
   Version: 15.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bc-info at styx dot cabel.net
  Target Milestone: ---

When build gcc under windows (mingw-w64, etc) incorrect calculation MD5 for
option -gcodeview. 

Patch for fix this bug:

--- gcc-15.0/gcc/dwarf2codeview.cc.orig 2025-04-25 11:18:00 +0300
+++ gcc-15.0/gcc/dwarf2codeview.cc  2025-04-25 18:17:58 +0300
@@ -1746,7 +1746,7 @@
   sf->string_offset = string_offset;
   sf->filename = xstrdup (filename);

-  f = fopen (filename, "r");
+  f = fopen (filename, "rb");
   if (!f)
 internal_error ("could not open %s for reading", filename);

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

2025-04-25 Thread glaubitz at physik dot fu-berlin.de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212

--- Comment #441 from John Paul Adrian Glaubitz  ---
(In reply to John Paul Adrian Glaubitz from comment #440)
> The branch for GCC 16 has opened now, so I assume it would be a good time to
> rebase the patches so I can re-test them.

I just tried rebasing devel/sh-lra and at least the rebase works without
problems.

Will run the various tests now over the next days in the hope to get this going
again.

[Bug fortran/102900] ICE via gfc_class_data_get with alloc_comp_class_4.f03 or proc_ptr_52.f90 using -fcheck=all

2025-04-25 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102900

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

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

commit r16-150-gcc8d86ee4680d56eefeb76a8f2f752282e2631e3
Author: Harald Anlauf 
Date:   Thu Apr 24 21:28:35 2025 +0200

Fortran: fix procedure pointer handling with -fcheck=pointer [PR102900]

PR fortran/102900

gcc/fortran/ChangeLog:

* trans-decl.cc (gfc_generate_function_code): Use sym->result
when generating fake result decl for functions returning
allocatable or pointer results.
* trans-expr.cc (gfc_conv_procedure_call): When checking the
pointer status of an actual argument passed to a non-allocatable,
non-pointer dummy which is of type CLASS, do not check the
class container of the actual if it is just a procedure pointer.
(gfc_trans_pointer_assignment): Fix treatment of assignment to
NULL of a procedure pointer.

gcc/testsuite/ChangeLog:

* gfortran.dg/proc_ptr_52.f90: Add -fcheck=pointer to options.
* gfortran.dg/proc_ptr_57.f90: New test.

[Bug c++/119764] noexcept lambdas do not have unused captures get pruned

2025-04-25 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119764

--- Comment #2 from GCC Commits  ---
The trunk branch has been updated by Jason Merrill :

https://gcc.gnu.org/g:44e31eb265ba1984638908466a88095744a88709

commit r16-149-g44e31eb265ba1984638908466a88095744a88709
Author: Jason Merrill 
Date:   Mon Apr 14 12:18:06 2025 -0400

c++: pruning non-captures in noexcept lambda [PR119764]

The patch for PR87185 fixed the ICE without fixing the underlying problem,
that we were failing to find the declaration of the capture proxy that we
are trying to decide whether to prune.  Fixed by looking at the right index
in stmt_list_stack.

Since this changes captures, it changes the ABI of noexcept lambdas; we
haven't worked hard to maintain lambda capture ABI, but it's easy enough to
control here.

PR c++/119764
PR c++/87185

gcc/cp/ChangeLog:

* lambda.cc (insert_capture_proxy): Handle noexcept lambda.
(prune_lambda_captures): Likewise, in ABI v21.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/lambda/lambda-noexcept1.C: New test.

[Bug fortran/119836] [15 Regression] Elemental intrinsic treated as IMPURE within BLOCK within DO CONCURRENT

2025-04-25 Thread anlauf at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119836

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #23 from anlauf at gcc dot gnu.org ---
Fortunately this was fixed in time for 15.1-release.

Thanks, Jerry & Steve!

[Bug c++/87185] [8/9 Regression] ICE in prune_lambda_captures()

2025-04-25 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87185

--- Comment #7 from GCC Commits  ---
The trunk branch has been updated by Jason Merrill :

https://gcc.gnu.org/g:44e31eb265ba1984638908466a88095744a88709

commit r16-149-g44e31eb265ba1984638908466a88095744a88709
Author: Jason Merrill 
Date:   Mon Apr 14 12:18:06 2025 -0400

c++: pruning non-captures in noexcept lambda [PR119764]

The patch for PR87185 fixed the ICE without fixing the underlying problem,
that we were failing to find the declaration of the capture proxy that we
are trying to decide whether to prune.  Fixed by looking at the right index
in stmt_list_stack.

Since this changes captures, it changes the ABI of noexcept lambdas; we
haven't worked hard to maintain lambda capture ABI, but it's easy enough to
control here.

PR c++/119764
PR c++/87185

gcc/cp/ChangeLog:

* lambda.cc (insert_capture_proxy): Handle noexcept lambda.
(prune_lambda_captures): Likewise, in ABI v21.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/lambda/lambda-noexcept1.C: New test.

[Bug fortran/119836] [15 Regression] Elemental intrinsic treated as IMPURE within BLOCK within DO CONCURRENT

2025-04-25 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119836

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|15.2|15.0

[Bug middle-end/119941] New: -Warray-bounds warning in adjust_offset_for_component_ref when building for bpf-unknown-none

2025-04-25 Thread sjames at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119941

Bug ID: 119941
   Summary: -Warray-bounds warning in
adjust_offset_for_component_ref when building for
bpf-unknown-none
   Product: gcc
   Version: 16.0
Status: UNCONFIRMED
  Keywords: build
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sjames at gcc dot gnu.org
  Target Milestone: ---

When building a cross-compiler for bpf-unknown-none with LTO and -O3, I saw:
```
In function ‘canonize’,
inlined from ‘arshift_large’ at
/var/tmp/portage/sys-devel/bpf-toolchain-15.1.0_p1/work/gcc/gcc/wide-int.cc:2173:19,
inlined from ‘arshift’ at
/var/tmp/portage/sys-devel/bpf-toolchain-15.1.0_p1/work/gcc/gcc/wide-int.h:3700:17,
inlined from ‘operator>>’ at
/var/tmp/portage/sys-devel/bpf-toolchain-15.1.0_p1/work/gcc/gcc/wide-int.h:3871:22,
inlined from
‘_ZL31adjust_offset_for_component_refP9tree_nodePbP8poly_intILj1ElE.part.0’ at
/var/tmp/portage/sys-devel/bpf-toolchain-15.1.0_p1/work/gcc/gcc/alias.cc:2793:11:
/var/tmp/portage/sys-devel/bpf-toolchain-15.1.0_p1/work/gcc/gcc/wide-int.cc:95:7:
warning: array subscript 4294967295 is outside array bounds of ‘struct
signed_shift_result_type[1]’ [-Warray-bounds=]
   95 |   top = val[len - 1];
  |   ^
  ‘_ZL31adjust_offset_for_component_refP9tree_nodePbP8poly_intILj1ElE.part.0’:
events 1-2
   92 |   if (len == 1)
  |   ^
  |   |
  |   (1) when the condition is evaluated to false
..
   95 |   top = val[len - 1];
  |   ~
  |   |
  |   (2) out of array bounds here
/var/tmp/portage/sys-devel/bpf-toolchain-15.1.0_p1/work/gcc/gcc/alias.cc: In
function
‘_ZL31adjust_offset_for_component_refP9tree_nodePbP8poly_intILj1ElE.part.0’:
/var/tmp/portage/sys-devel/bpf-toolchain-15.1.0_p1/work/gcc/gcc/alias.cc:2793:18:
note: at offset 34359738360 into object ‘’ of size 24
 2793 |   >> LOG2_BITS_PER_UNIT)
  |  ^
In function ‘canonize’,
inlined from ‘arshift_large’ at
/var/tmp/portage/sys-devel/bpf-toolchain-15.1.0_p1/work/gcc/gcc/wide-int.cc:2173:19,
inlined from ‘arshift’ at
/var/tmp/portage/sys-devel/bpf-toolchain-15.1.0_p1/work/gcc/gcc/wide-int.h:3700:17,
inlined from ‘operator>>’ at
/var/tmp/portage/sys-devel/bpf-toolchain-15.1.0_p1/work/gcc/gcc/wide-int.h:3871:22,
inlined from
‘_ZL31adjust_offset_for_component_refP9tree_nodePbP8poly_intILj1ElE.part.0’ at
/var/tmp/portage/sys-devel/bpf-toolchain-15.1.0_p1/work/gcc/gcc/alias.cc:2793:11:
/var/tmp/portage/sys-devel/bpf-toolchain-15.1.0_p1/work/gcc/gcc/wide-int.cc:95:7:
warning: array subscript 4294967295 is outside array bounds of ‘struct
signed_shift_result_type[1]’ [-Warray-bounds=]
   95 |   top = val[len - 1];
  |   ^
  ‘_ZL31adjust_offset_for_component_refP9tree_nodePbP8poly_intILj1ElE.part.0’:
events 1-2
   92 |   if (len == 1)
  |   ^
  |   |
  |   (1) when the condition is evaluated to false
..
   95 |   top = val[len - 1];
  |   ~
  |   |
  |   (2) out of array bounds here
/var/tmp/portage/sys-devel/bpf-toolchain-15.1.0_p1/work/gcc/gcc/alias.cc: In
function
‘_ZL31adjust_offset_for_component_refP9tree_nodePbP8poly_intILj1ElE.part.0’:
/var/tmp/portage/sys-devel/bpf-toolchain-15.1.0_p1/work/gcc/gcc/alias.cc:2793:18:
note: at offset 34359738360 into object ‘’ of size 24
 2793 |   >> LOG2_BITS_PER_UNIT)
```

[Bug tree-optimization/119945] New: [14/15/16 Regression] missed tail call due to IPA-VRP and different type but same mode

2025-04-25 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119945

Bug ID: 119945
   Summary: [14/15/16 Regression] missed tail call due to IPA-VRP
and different type but same mode
   Product: gcc
   Version: 16.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: enhancement
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

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

Take the attached testcase. Starting in GCC 14, GCC won't tail call f inside g.
But f1 is handled inside g1 just fine still.

This is because the useless_type_conversion_p check inside find_tail_calls is
stronger than what is included for process_assignment .

[Bug c/119878] __builtin_has_attribute(VAR, nonstring) does not work on multidimensional arrays marked with nonstring

2025-04-25 Thread kees at outflux dot net via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119878

--- Comment #2 from Kees Cook  ---
Ugh, I'm sorry I botched this example so badly. I'm not sure where I got off
track in trying to get it into one of the selftests. The problem I ran into was
with querying array members of the multidimensional array. Here are correct
examples. These should all pass, but looking into the "middle" of the array
fails, similar to how the warning was failing before:


static const char single[] __attribute__((nonstring)) = "ohai";
_Static_assert (__builtin_has_attribute(single, nonstring)); // array of char
_Static_assert (!__builtin_has_attribute(single[2], nonstring)); // is a char,
not array

static const char multi2[][4] __attribute__((nonstring)) = {
"hola", "here", "test"
};
_Static_assert (__builtin_has_attribute(multi2, nonstring)); // array of array
of char
_Static_assert (__builtin_has_attribute(multi2[1], nonstring)); // array of
char [missed]
_Static_assert (!__builtin_has_attribute(multi2[1][3], nonstring)); // is a
char, not array

static const char multi3[][16][5] __attribute__((nonstring)) = {
{ "hello", "test!", "again", },
{ "haloo", "!test", "check", },
};
_Static_assert (__builtin_has_attribute(multi3, nonstring)); // array of array
of array of char
_Static_assert (__builtin_has_attribute(multi3[0], nonstring)); // array of
array of char [missed]
_Static_assert (__builtin_has_attribute(multi3[0][1], nonstring)); // array of
char [missed]
_Static_assert (!__builtin_has_attribute(multi3[0][1][4], nonstring)); // is a
char, not array



$ gcc -Wall -O2 -c multi.c
multi.c:9:1: error: static assertion failed
9 | _Static_assert (__builtin_has_attribute(multi2[1], nonstring)); //
array of char [missed]
  | ^~
multi.c:17:1: error: static assertion failed
   17 | _Static_assert (__builtin_has_attribute(multi3[0], nonstring)); //
array of array of char [missed]
  | ^~
multi.c:18:1: error: static assertion failed
   18 | _Static_assert (__builtin_has_attribute(multi3[0][1], nonstring)); //
array of char [missed]
  | ^~

[Bug target/119919] 7% exchange2 regression between g:6390fc86995fbd5239497cb9e1797a3af51d3936 and g:f72a2d221539cede358f2487b94bc370c6fc44b5

2025-04-25 Thread hubicka at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119919

--- Comment #6 from Jan Hubicka  ---
Exchange2 regression is solved and tonto seem to be noise (performance is back
today w/o change of a checksum of the text segment).

still we account one extra setcc and misaccount scatter, so lets keep this to
track the remaining problems.
The testcase likely needs -msse2 -mfpmath=sse. I will check

[Bug middle-end/119943] -O3 forgets trivial code shift. causing significant slowdown

2025-04-25 Thread aleks at physik dot tu-berlin.de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119943

--- Comment #2 from Alexander Kleinsorge  ---
Created attachment 61197
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61197&action=edit
full sample code (1 file)

version above has the issue active.
gcc -o radix.exe -march=native -O3 radix.c
./radix 60 50

[Bug target/115777] [12/13/14/15/16 regression] Severe performance regression on insertion sort at -O2 or above

2025-04-25 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115777

Andrew Pinski  changed:

   What|Removed |Added

 CC||aleks at physik dot 
tu-berlin.de

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

[Bug middle-end/119943] -O3 forgets trivial code shift. causing significant slowdown

2025-04-25 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119943

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|WAITING |RESOLVED

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

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

[Bug tree-optimization/119945] [14/15/16 Regression] missed tail call due to IPA-VRP and different type but same mode

2025-04-25 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119945

--- Comment #3 from Andrew Pinski  ---
(In reply to Jakub Jelinek from comment #2)
> Well, you'd need to know during tailc pass that the target returns char *
> the same as size_t, which isn't guaranteed.
> Especially e.g. int and unsigned could be returned differently (e.g. sign
> vs. zero extended to 64-bits).

Yes and no, looking into a few examples of this, the tree level marking of a
function is still a hint saying if the return is the same then we should do it.

you can see it with this example:
```
typedef unsigned char utype;
typedef signed char stype;

utype f1(void);
stype g1(void)
{
  return (stype)f1();
}
```
Which we get the correct behavior on mips of not doing a tail call even if the
function was marked as a tail call. where signed char and unsigned char are
returned differently (one is returned zero extended while the other is retuned
signed extended).

So in this case the MODE stays the same like it is checked in
process_assignment  is all that is needed I think. (well MODE stays the same
and the precision is the same)

[Bug middle-end/119943] -O3 forgets trivial code shift. causing significant slowdown

2025-04-25 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119943

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|DUPLICATE   |---
 Ever confirmed|1   |0
 Status|RESOLVED|UNCONFIRMED
   Severity|normal  |enhancement

--- Comment #5 from Andrew Pinski  ---
So what happens is with `cfg_t cfg` initialized after:
```
if (n <= 60u) {
if (n > 1u) quickSort(array, 0, n - 1);
return 0u;
}

```

GCC is able to inline the above case.

This is because we don't sink the initialization of cfg until much later.

[Bug middle-end/119943] improve function splitting by sinking expressions early on

2025-04-25 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119943

Andrew Pinski  changed:

   What|Removed |Added

Summary|-O3 forgets trivial code|improve function splitting
   |shift. causing significant  |by sinking expressions
   |slowdown|early on

--- Comment #6 from Andrew Pinski  ---
So I suspect you need to mark radixSort as noinline for benchmarking reasons
anyways. Because I suspect radixSort is not going to be inlinable in your non
benchmark code.

[Bug tree-optimization/119946] New: memset/memcpy with a null argument should be folded into `if (size_arg) __builtin_unreachable();`

2025-04-25 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119946

Bug ID: 119946
   Summary: memset/memcpy with a null argument should be folded
into `if (size_arg) __builtin_unreachable();`
   Product: gcc
   Version: 16.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: enhancement
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

Take:
```
unsigned char my_func(int n)
{
  __builtin_memset((void*)0, 0, n);
  return n+1;
}
```

Since C23, the memset here is only undefined if `n!=0`, I think we should be
able to fold the memset into:
```
if (n != 0)
  __builtin_unreachable();
```

which is exactly what LLVM does starting in LLVM 20.

Thought maybe a trap instead would be better.  If anything this could be part
of path isolation.

Note I noticed this while working through the review of the patches of PR
67797.

[Bug libstdc++/57272] node-based containers don't use allocator's pointer type internally

2025-04-25 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57272

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|15.0|15.2

--- Comment #12 from Jakub Jelinek  ---
GCC 15.1 is being released, retargeting bugs to GCC 15.2.

[Bug fortran/82250] Fortran OpenACC acc_on_device early folding

2025-04-25 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82250

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|15.0|15.2

--- Comment #14 from Jakub Jelinek  ---
GCC 15.1 is being released, retargeting bugs to GCC 15.2.

[Bug c++/113920] Make -std=gnu++20 default for GCC 16

2025-04-25 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113920

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|15.0|15.2

--- Comment #2 from Jakub Jelinek  ---
GCC 15.1 is being released, retargeting bugs to GCC 15.2.

[Bug tree-optimization/116998] [15/16 Regression] 5% slowdown of 400.perlbench on AMD Zen3/4 since r15-3986-g3e1bd6470e4deb

2025-04-25 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116998

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|15.0|15.2

--- Comment #2 from Jakub Jelinek  ---
GCC 15.1 is being released, retargeting bugs to GCC 15.2.

[Bug target/116994] [15/16 regression] GCC trunk generates larger code than GCC 14 at -Os since r15-313-gd826f794560904

2025-04-25 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116994

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|15.0|15.2

--- Comment #5 from Jakub Jelinek  ---
GCC 15.1 is being released, retargeting bugs to GCC 15.2.

[Bug target/117006] [15/16 regression] GCC trunk generates larger code than GCC 14 at -Os

2025-04-25 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117006

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|15.0|15.2

--- Comment #9 from Jakub Jelinek  ---
GCC 15.1 is being released, retargeting bugs to GCC 15.2.

[Bug c++/117152] [12/13/14/15/16 Regression] Segmentation fault in permerror(unsigned int, char const*, ...)

2025-04-25 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117152

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|15.0|15.2

--- Comment #6 from Jakub Jelinek  ---
GCC 15.1 is being released, retargeting bugs to GCC 15.2.

[Bug tree-optimization/117055] [meta-bug] GCC15+ O2 vectorization enhancement

2025-04-25 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117055

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|15.0|15.2

--- Comment #1 from Jakub Jelinek  ---
GCC 15.1 is being released, retargeting bugs to GCC 15.2.

[Bug target/115650] [15/16 Regression] ARC backend bug exposed by late-combine pass

2025-04-25 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115650

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|15.0|15.2

--- Comment #1 from Jakub Jelinek  ---
GCC 15.1 is being released, retargeting bugs to GCC 15.2.

[Bug middle-end/117160] [15/16 regression] GCC trunk generates larger code than GCC 14 at -Os/-Oz (progressed in 14) since r15-3986-g3e1bd6470e4deb

2025-04-25 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117160

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|15.0|15.2

--- Comment #4 from Jakub Jelinek  ---
GCC 15.1 is being released, retargeting bugs to GCC 15.2.

[Bug tree-optimization/116518] GCC does not optimize-out useless operations. Clang does.

2025-04-25 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116518

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|15.0|15.2

--- Comment #9 from Jakub Jelinek  ---
GCC 15.1 is being released, retargeting bugs to GCC 15.2.

[Bug target/116686] [15/16 Regression] RISC-V: gcc.target/riscv/rvv/autovec/pr114734.c failing with zvl1024b lmul2

2025-04-25 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116686

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|15.0|15.2

--- Comment #9 from Jakub Jelinek  ---
GCC 15.1 is being released, retargeting bugs to GCC 15.2.

[Bug rtl-optimization/116479] [15/16 Regression] wrong code with -O -funroll-loops -finline-stringops -fmodulo-sched --param=max-iterations-computation-cost=637924876 on aarch64 since r15-1447-g5d0c1b

2025-04-25 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116479

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|15.0|15.2

--- Comment #5 from Jakub Jelinek  ---
GCC 15.1 is being released, retargeting bugs to GCC 15.2.

[Bug target/116507] [15/16 Regression] movhi_aarch64 should use fmov if FP16

2025-04-25 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116507

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|15.0|15.2

--- Comment #5 from Jakub Jelinek  ---
GCC 15.1 is being released, retargeting bugs to GCC 15.2.

[Bug tree-optimization/116761] [15/16 Regression] 4-6% slowdown of 465.tonto on AMD Zen3/4 since r15-3509-gd34cda72098867

2025-04-25 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116761

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|15.0|15.2

--- Comment #4 from Jakub Jelinek  ---
GCC 15.1 is being released, retargeting bugs to GCC 15.2.

[Bug target/116955] [15/16 Regression] GCN '-march=gfx1100': [-PASS:-]{+FAIL:+} gcc.dg/vect/pr81740-2.c execution test

2025-04-25 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116955

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|15.0|15.2

--- Comment #4 from Jakub Jelinek  ---
GCC 15.1 is being released, retargeting bugs to GCC 15.2.

[Bug driver/116794] gcc -pipe does not work on macOS with as from Xcode 16 (on macOS 15)

2025-04-25 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116794

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|15.0|15.2

--- Comment #3 from Jakub Jelinek  ---
GCC 15.1 is being released, retargeting bugs to GCC 15.2.

[Bug libstdc++/116924] -ffast-math -Wunused-value warnings in

2025-04-25 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116924

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|15.0|15.2

--- Comment #3 from Jakub Jelinek  ---
GCC 15.1 is being released, retargeting bugs to GCC 15.2.

[Bug fortran/119459] gfortran.dg/gomp/interop-5.f90 FAILs

2025-04-25 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119459

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|15.0|15.2

--- Comment #2 from Jakub Jelinek  ---
GCC 15.1 is being released, retargeting bugs to GCC 15.2.

[Bug target/119737] GCN/C++ vs. 'as': 'LLVM ERROR: Size expression must be absolute.'

2025-04-25 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119737

--- Comment #9 from GCC Commits  ---
The trunk branch has been updated by Thomas Schwinge :

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

commit r16-128-gdfc43afe719898c3eafbed37fac7e6809d8b97ab
Author: Andrew Pinski 
Date:   Mon Apr 21 22:32:26 2025 +

GCN: Properly switch sections in 'gcn_hsa_declare_function_name' [PR119737]

There are GCN/C++ target as well as offloading codes, where the hard-coded
section names in 'gcn_hsa_declare_function_name' do not fit, and assembly
thus
fails:

LLVM ERROR: Size expression must be absolute.

This commit progresses GCN target:

[-FAIL: g++.dg/init/call1.C  -std=gnu++17 (internal compiler error:
Aborted signal terminated program as)-]
[-FAIL:-]{+PASS:+} g++.dg/init/call1.C  -std=gnu++17 (test for excess
errors)
[-UNRESOLVED:-]{+PASS:+} g++.dg/init/call1.C  -std=gnu++17
[-compilation failed to produce executable-]{+execution test+}
[-FAIL: g++.dg/init/call1.C  -std=gnu++26 (internal compiler error:
Aborted signal terminated program as)-]
[-FAIL:-]{+PASS:+} g++.dg/init/call1.C  -std=gnu++26 (test for excess
errors)
[-UNRESOLVED:-]{+PASS:+} g++.dg/init/call1.C  -std=gnu++26
[-compilation failed to produce executable-]{+execution test+}
UNSUPPORTED: g++.dg/init/call1.C  -std=gnu++98: exception handling not
supported

..., and GCN offloading:

[-XFAIL: libgomp.c++/target-exceptions-throw-1.C (internal compiler
error: Aborted signal terminated program as)-]
[-XFAIL: libgomp.c++/target-exceptions-throw-1.C PR119737 at line 7
(test for bogus messages, line )-]
[-XFAIL:-]{+PASS:+} libgomp.c++/target-exceptions-throw-1.C (test for
excess errors)
[-UNRESOLVED:-]{+PASS:+} libgomp.c++/target-exceptions-throw-1.C
[-compilation failed to produce executable-]{+execution test+}
{+PASS: libgomp.c++/target-exceptions-throw-1.C output pattern test+}

[-XFAIL: libgomp.c++/target-exceptions-throw-2.C (internal compiler
error: Aborted signal terminated program as)-]
[-XFAIL: libgomp.c++/target-exceptions-throw-2.C PR119737 at line 7
(test for bogus messages, line )-]
[-XFAIL:-]{+PASS:+} libgomp.c++/target-exceptions-throw-2.C (test for
excess errors)
[-UNRESOLVED:-]{+PASS:+} libgomp.c++/target-exceptions-throw-2.C
[-compilation failed to produce executable-]{+execution test+}
{+PASS: libgomp.c++/target-exceptions-throw-2.C output pattern test+}

[-XFAIL: libgomp.oacc-c++/exceptions-throw-1.C
-DACC_DEVICE_TYPE_radeon=1 -DACC_MEM_SHARED=0 -foffload=amdgcn-amdhsa  -O2 
(internal compiler error: Aborted signal terminated program as)-]
[-XFAIL: libgomp.oacc-c++/exceptions-throw-1.C
-DACC_DEVICE_TYPE_radeon=1 -DACC_MEM_SHARED=0 -foffload=amdgcn-amdhsa  -O2 
PR119737 at line 7 (test for bogus messages, line )-]
[-XFAIL:-]{+PASS:+} libgomp.oacc-c++/exceptions-throw-1.C
-DACC_DEVICE_TYPE_radeon=1 -DACC_MEM_SHARED=0 -foffload=amdgcn-amdhsa  -O2 
(test for excess errors)
[-UNRESOLVED:-]{+PASS:+} libgomp.oacc-c++/exceptions-throw-1.C
-DACC_DEVICE_TYPE_radeon=1 -DACC_MEM_SHARED=0 -foffload=amdgcn-amdhsa  -O2 
[-compilation failed to produce executable-]{+execution test+}
{+PASS: libgomp.oacc-c++/exceptions-throw-1.C
-DACC_DEVICE_TYPE_radeon=1 -DACC_MEM_SHARED=0 -foffload=amdgcn-amdhsa  -O2 
output pattern test+}

[-XFAIL: libgomp.oacc-c++/exceptions-throw-2.C
-DACC_DEVICE_TYPE_radeon=1 -DACC_MEM_SHARED=0 -foffload=amdgcn-amdhsa  -O2 
(internal compiler error: Aborted signal terminated program as)-]
[-XFAIL: libgomp.oacc-c++/exceptions-throw-2.C
-DACC_DEVICE_TYPE_radeon=1 -DACC_MEM_SHARED=0 -foffload=amdgcn-amdhsa  -O2 
PR119737 at line 9 (test for bogus messages, line )-]
[-XFAIL:-]{+PASS:+} libgomp.oacc-c++/exceptions-throw-2.C
-DACC_DEVICE_TYPE_radeon=1 -DACC_MEM_SHARED=0 -foffload=amdgcn-amdhsa  -O2 
(test for excess errors)
[-UNRESOLVED:-]{+PASS:+} libgomp.oacc-c++/exceptions-throw-2.C
-DACC_DEVICE_TYPE_radeon=1 -DACC_MEM_SHARED=0 -foffload=amdgcn-amdhsa  -O2 
[-compilation failed to produce executable-]{+execution test+}
{+PASS: libgomp.oacc-c++/exceptions-throw-2.C
-DACC_DEVICE_TYPE_radeon=1 -DACC_MEM_SHARED=0 -foffload=amdgcn-amdhsa  -O2 
output pattern test+}

PR target/119737
gcc/
* config/gcn/gcn.cc (gcn_hsa_declare_function_name): Properly
switch sections.
libgomp/
* testsuite/libgomp.c++/target-exceptions-throw-1.C: Remove
PR119737 XFAILing.
* testsuite/libgomp.c++/target-exceptions-throw-2.C: Likewise.
* testsuite/libgomp.oacc-c++/exceptions-throw-1.C: Likewise.
* testsuite/libgomp.oacc-c++/exceptions-throw-2.C: Likewise.

Co-authored-by: Thomas Schwinge 

[Bug tree-optimization/119532] [avr] ICE: in build_minus_one_cst with _Accum/_Fract types , at tree.cc:2698

2025-04-25 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119532

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|15.0|15.2

--- Comment #9 from Jakub Jelinek  ---
GCC 15.1 is being released, retargeting bugs to GCC 15.2.

[Bug target/118794] The attached c++ openmp offload code fails, because the c sqrt function makes nonlocal gotos..

2025-04-25 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118794

--- Comment #14 from GCC Commits  ---
The trunk branch has been updated by Thomas Schwinge :

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

commit r16-127-g8a1f5424b04130f88e9dcd5cbecd58300bc5166e
Author: Thomas Schwinge 
Date:   Tue Apr 22 13:41:22 2025 +0200

Adjust 'libgomp.c++/target-exceptions-pr118794-1.C' for
'targetm.arm_eabi_unwinder' [PR118794]

Fix-up for commit aa3e72f943032e5f074b2bd2fd06d130dda8760b
"Add test cases for exception handling constructs in dead code for GCN,
nvptx target and OpenMP 'target' offloading [PR118794]":
we need to adjust for configurations with 'targetm.arm_eabi_unwinder', as
per:

gcc/config/arm/arm.cc:#define TARGET_ARM_EABI_UNWINDER true
gcc/config/c6x/c6x.cc:#define TARGET_ARM_EABI_UNWINDER true

..., which for ARM is conditional to '#if ARM_UNWIND_INFO' (defined in
'gcc/config/arm/bpabi.h', used for various GCC configurations), and for
C6x unconditional.

This gets us:

--- target-exceptions-pr118794-1.C.269t.optimized
+++ target-exceptions-pr118794-1.C.270t.optimized
[...]
 __attribute__((omp declare target))
 void f ()
[...]
   gimple_call <__dt_comp , NULL, &c>
-  gimple_call <__builtin_eh_pointer, _7, 2>
-  gimple_call <__builtin_unwind_resume, NULL, _7>
+  gimple_call <__builtin_cxa_end_cleanup, NULL>

 }
[...]

PR target/118794
libgomp/
* testsuite/libgomp.c++/target-exceptions-pr118794-1.C: Adjust for
'targetm.arm_eabi_unwinder'.
*
testsuite/libgomp.c++/target-exceptions-pr118794-1-offload-sorry-GCN.C:
Likewise.
*
testsuite/libgomp.c++/target-exceptions-pr118794-1-offload-sorry-nvptx.C:
Likewise.

[Bug target/119413] [15/16 Regression] 11% slowdown (but only 3% regression against GCC 14) of 507.cactuBSSN_r on Aarch64

2025-04-25 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119413

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|15.0|15.2

--- Comment #1 from Jakub Jelinek  ---
GCC 15.1 is being released, retargeting bugs to GCC 15.2.

[Bug tree-optimization/119393] [15/16 Regression] Worse vectorization of imagick_r hot loop on aarch64 since r15-5024-g2a2e6784074e1f

2025-04-25 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119393

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|15.0|15.2

--- Comment #11 from Jakub Jelinek  ---
GCC 15.1 is being released, retargeting bugs to GCC 15.2.

[Bug target/119108] [15/16 Regression] AArch64 Commit 'vect: Force alignment peeling ...' (r15-6807-g68326d5d1a593d) causes regression in Snappy workload for -mcpu=neoverse-v2.

2025-04-25 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119108

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|15.0|15.2

--- Comment #13 from Jakub Jelinek  ---
GCC 15.1 is being released, retargeting bugs to GCC 15.2.

[Bug rust/119508] Hundreds of rust tests XPASS

2025-04-25 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119508

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|15.0|15.2

--- Comment #26 from Jakub Jelinek  ---
GCC 15.1 is being released, retargeting bugs to GCC 15.2.

[Bug lto/119839] [15/16 regression] RISC-V gobmk performance regression with Node clones share order patch (bad LTO partitioning) since r15-6345-g0895aef01c64c3

2025-04-25 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119839

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|15.0|15.2

--- Comment #6 from Jakub Jelinek  ---
GCC 15.1 is being released, retargeting bugs to GCC 15.2.

[Bug libstdc++/119620] flat_set::emplace is constrained, and always constructs element on the stack

2025-04-25 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119620

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|15.0|15.2

--- Comment #9 from Jakub Jelinek  ---
GCC 15.1 is being released, retargeting bugs to GCC 15.2.

[Bug target/119854] nvptx offloading: omptests' 'xt-declare-target-ctors': 'unresolved symbol __dso_handle'

2025-04-25 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119854

--- Comment #1 from GCC Commits  ---
The trunk branch has been updated by Thomas Schwinge :

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

commit r16-130-gaafe942227baf8c2bcd4cac2cb150e49a4b895a9
Author: Thomas Schwinge 
Date:   Wed Apr 23 10:51:48 2025 +0200

GCN, nvptx offloading: Host/device compatibility: Itanium C++ ABI, DSO
Object Destruction API [PR119853, PR119854]

'__dso_handle' for '__cxa_atexit', '__cxa_finalize'.  See
.

PR target/119853
PR target/119854
libgcc/
* config/gcn/crt0.c (_fini_array): Call
'__GCC_offload___cxa_finalize'.
* config/nvptx/gbl-ctors.c (__static_do_global_dtors): Likewise.
libgomp/
* target-cxa-dso-dtor.c: New.
* config/accel/target-cxa-dso-dtor.c: Likewise.
* Makefile.am (libgomp_la_SOURCES): Add it.
* Makefile.in: Regenerate.
* testsuite/libgomp.c++/target-cdtor-1.C: New.
* testsuite/libgomp.c++/target-cdtor-2.C: Likewise.

[Bug libstdc++/111250] __glibcxx_requires_subscript assertions are not checked during constant evaluation

2025-04-25 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111250

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|15.2|14.3

[Bug libstdc++/111676] Race condition in std::ios::Init

2025-04-25 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111676

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|15.2|16.0

[Bug libstdc++/119606] [15/16 regression] Commit 'Optimize string constructor' causes regression in Snappy workload for -mcpu=neoverse-v2 with LTO

2025-04-25 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119606

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|15.0|15.2

--- Comment #8 from Jakub Jelinek  ---
GCC 15.1 is being released, retargeting bugs to GCC 15.2.

[Bug libstdc++/119754] std::uninitialized_value_construct does not begin lifetime of trivial types

2025-04-25 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119754

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|15.0|15.2

--- Comment #4 from Jakub Jelinek  ---
GCC 15.1 is being released, retargeting bugs to GCC 15.2.

[Bug rtl-optimization/119841] [15/16 Regression] gcc.target/cris/pr93372-2.c

2025-04-25 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119841

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|15.0|15.2

--- Comment #2 from Jakub Jelinek  ---
GCC 15.1 is being released, retargeting bugs to GCC 15.2.

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

2025-04-25 Thread sjames at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119356

Sam James  changed:

   What|Removed |Added

 Status|SUSPENDED   |NEW

--- Comment #7 from Sam James  ---
Upstream patch merged.

[Bug fortran/119836] [15 Regression] Elemental intrinsic treated as IMPURE within BLOCK within DO CONCURRENT

2025-04-25 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119836

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|15.0|15.2

--- Comment #22 from Jakub Jelinek  ---
GCC 15.1 is being released, retargeting bugs to GCC 15.2.

[Bug tree-optimization/119872] [15/16 regression] wrong code at -O{1,2,s} since r15-1809-g735edbf1e2479f

2025-04-25 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119872

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|15.0|15.2

--- Comment #11 from Jakub Jelinek  ---
GCC 15.1 is being released, retargeting bugs to GCC 15.2.

[Bug c/119842] [15/16 Regression] ICE: in c_type_tag, at c/c-typeck.cc:606

2025-04-25 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119842

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|15.0|15.2

--- Comment #6 from Jakub Jelinek  ---
GCC 15.1 is being released, retargeting bugs to GCC 15.2.

[Bug libgomp/119849] libgomp.c++/allocator-1.C etc. FAIL

2025-04-25 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119849

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|15.0|15.2

--- Comment #3 from Jakub Jelinek  ---
GCC 15.1 is being released, retargeting bugs to GCC 15.2.

[Bug libstdc++/109162] C++23 improvements to std::format

2025-04-25 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109162

--- Comment #18 from GCC Commits  ---
The releases/gcc-15 branch has been updated by Tomasz Kaminski
:

https://gcc.gnu.org/g:17e0decc1dbf827747aebfa0573cc8e50969ae3f

commit r15-9589-g17e0decc1dbf827747aebfa0573cc8e50969ae3f
Author: Tomasz KamiÅski 
Date:   Tue Apr 22 09:56:42 2025 +0200

libstdc++: Define __cpp_lib_format_ranges in format header [PR109162]

As P2286R8 and P2585R1 as now fully implemented, we now define
__cpp_lib_format_ranges feature test macro with __cpp_lib_format_ranges.
This macro is provided only in .

Uses of internal __glibcxx_format_ranges are also updated.

PR libstdc++/109162

libstdc++-v3/ChangeLog:

* include/bits/version.def (format_ranges): Remove no_stdname and
update value.
* include/bits/version.h: Regenerate.
* src/c++23/std.cc.in: Replace __glibcxx_format_ranges with
__cpp_lib_format_ranges.
* testsuite/std/format/formatter/lwg3944.cc: Likewise.
* testsuite/std/format/parse_ctx.cc: Likewise.
* testsuite/std/format/string.cc: Likewise.
* testsuite/std/format/ranges/feature_test.cc: New test.

Reviewed-by: Jonathan Wakely 
Signed-off-by: Tomasz KamiÅski 
(cherry picked from commit 049fefd7e1501ac9dcc66a5ef6c34cea0331dc43)

[Bug libstdc++/109162] C++23 improvements to std::format

2025-04-25 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109162

--- Comment #17 from GCC Commits  ---
The releases/gcc-15 branch has been updated by Tomasz Kaminski
:

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

commit r15-9588-g5bd02daf8430ecce1d7fd847ef4fc9c369179542
Author: Tomasz KamiÅski 
Date:   Fri Apr 18 14:56:39 2025 +0200

libstdc++: Implement formatters for queue, priority_queue and stack
[PR109162]

This patch implements formatter specializations for standard container
adaptors
(queue, priority_queue and stack) from P2286R8.

To be able to access the protected `c` member, the adaptors befriend
corresponding formatter specializations. Note that such specialization
may be disable if the container is formattable, in such case
specializations are unharmful.

As in the case of previous commits, the signatures of the user-facing parse
and format methods of the provided formatters deviate from the standard by
constraining types of parameters:
 * _CharT is constrained __formatter::__char
 * basic_format_parse_context<_CharT> for parse argument
 * basic_format_context<_Out, _CharT> for format second argument
The standard specifies all above as unconstrained types. In particular
_CharT constrain, allow us to befriend all allowed specializations.

Furthermore the standard specifies these formatters as delegating to
formatter, charT>, which in turn
delegates to range_formatter. This patch avoids one level of indirection,
and dependency of ranges::ref_view.  This is technically observable if
user specializes formatter> where PD is program defined
container, but I do not think this is the case worth extra indirection.

This patch also moves the formattable and it's dependencies to the
formatfwd.h,
so it can be used in adapters formatters, without including format header.
The definition of _Iter_for is changed from alias to denoting
back_insert_iterator>, to struct with type nested
typedef
that points to same type, that is forward declared.

PR libstdc++/109162

libstdc++-v3/ChangeLog:

* include/bits/formatfwd.h (__format::__parsable_with)
(__format::__formattable_with, __format::__formattable_impl)
(__format::__has_debug_format, __format::__const_formattable_range)
(__format::__maybe_const_range, __format::__maybe_const)
(std::formattable): Moved from std/format.
(__format::Iter_for, std::range_formatter): Forward declare.
* include/bits/stl_queue.h (std::formatter): Forward declare.
(std::queue, std::priority_queue): Befriend formatter
specializations.
* include/bits/stl_stack.h (std::formatter): Forward declare.
(std::stack): Befriend formatter specializations.
* include/std/format (__format::_Iter_for): Define as struct with
(__format::__parsable_with, __format::__formattable_with)
(__format::__formattable_impl, __format::__has_debug_format)
(_format::__const_formattable_range, __format::__maybe_const_range)
(__format::__maybe_const, std::formattable): Moved to
bits/formatfwd.h.
(std::range_formatter): Remove default argument specified in
declaration
in bits/formatfwd.h.
* include/std/queue: Include bits/version.h before
bits/stl_queue.h.
(formatter, _CharT>)
(formatter, _CharT>):
Define.
* include/std/stack: Include bits/version.h before bits/stl_stack.h
(formatter, _CharT>): Define.
* testsuite/std/format/ranges/adaptors.cc: New test.

Reviewed-by: Jonathan Wakely 
Signed-off-by: Tomasz KamiÅski 
(cherry picked from commit 3d808ede38b959d283baaed1864434392eeb41e3)

[Bug libstdc++/109162] C++23 improvements to std::format

2025-04-25 Thread tkaminsk at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109162

Tomasz Kamiński  changed:

   What|Removed |Added

 CC||tkaminsk at gcc dot gnu.org

--- Comment #19 from Tomasz Kamiński  ---
All papers are now fully implemented in for GCC 15.2 and GCC 16.0.

[Bug target/115842] [15/16 Regression] 6.5% slowdown of 548.exchange2_r on Intel Ice Lake

2025-04-25 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115842

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|15.0|15.2

--- Comment #10 from Jakub Jelinek  ---
GCC 15.1 is being released, retargeting bugs to GCC 15.2.

  1   2   3   >