[Bug libstdc++/119037] New: Incorrect calculations of max_size involving basic_strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119037
Bug ID: 119037
Summary: Incorrect calculations of max_size involving
basic_strings
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: luigighiron at gmail dot com
Target Milestone: ---
The following example demonstrates situations where the max_size of a
basic_string is calculated incorrectly in libstdc++ (compiled with C++20 or
newer):
#include
#include
#include
templatestruct A:std::allocator{
A::allocator::size_type max_size()const noexcept{
return 1;
}
};
templatestruct B:std::allocator{
B::allocator::size_type max_size()const noexcept{
return 0;
}
};
int main(){
//issue one
{
std::basic_string,A>s;
s.push_back('a');
s.push_back('b');
std::couts;
std::cout< _GLIBCXX_NODISCARD _GLIBCXX20_CONSTEXPR
> size_type
> size() const _GLIBCXX_NOEXCEPT
> {
> size_type __sz = _M_string_length;
> if (__sz > max_size ())
> __builtin_unreachable ();
> return __sz;
> }
Issue two: An empty string is created using the allocator B which has a
max_size of zero. Then, the max_size of this string is printed which is the
maximum value representable in size_type. Lastly, the max_size of an empty
string created using the default allocator (std::allocator) is printed.
The max_size of the string created using the allocator B is greater than the
max_size of the string created using the default allocator, which seems very
unintended. The issue in this case is that the max_size of the string created
using the allocator B is not representable in the difference_type, which is
what the max_size of the string created using the default allocator avoids.
> _GLIBCXX_NODISCARD _GLIBCXX20_CONSTEXPR
> size_type
> max_size() const _GLIBCXX_NOEXCEPT
> {
> const size_t __diffmax
> = __gnu_cxx::__numeric_traits::__max / sizeof(_CharT);
> const size_t __allocmax = _Alloc_traits::max_size(_M_get_allocator());
> return (std::min)(__diffmax, __allocmax) - 1;
> }
This is how max_size is defined, and the two issues are present here. Issue one
is caused by this definition not considering small string optimization. Issue
two is caused by the subtraction of one not considering that max_size of the
allocator can return zero, which causes wraparound to the maximum value.
Additionally, it looks like __allocmax being of the type size_t instead of
size_type could cause the result to be incorrect if max_size returned a value
greater than SIZE_MAX (causing unintended wraparound, saturating is probably
intended). This last issue is impossible to demonstrate on x86_64, so I didn't
include it in the example.
Theoretically, unintended wraparound could also happen in __diffmax if
PTRDIFF_MAX/sizeof(_CharT) is greater than SIZE_MAX and sizeof(_CharT) is not a
positive integer power of two. However, I'm not sure any targets exist where
this combination can arise so it's probably not worth considering (assuming
_CharT is a character type, other types for _CharT should be very rare).
[Bug libstdc++/119037] Incorrect calculations of max_size involving basic_strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119037
--- Comment #1 from Andrew Pinski ---
Most likely max_size in std::basic_string should be something like:
```
/// Returns the size() of the largest possible %string.
_GLIBCXX_NODISCARD _GLIBCXX20_CONSTEXPR
size_type
max_size() const _GLIBCXX_NOEXCEPT
{
const size_t __diffmax
= __gnu_cxx::__numeric_traits::__max / sizeof(_CharT);
const size_t __allocmax = _Alloc_traits::max_size(_M_get_allocator());
return (std::max)(_S_local_capacity, (std::min)(__diffmax, __allocmax))
- 1;
}
```
That is taking into account the _S_local_capacity which does not need to call
the allocator.
[Bug jit/117047] [15 regression] Segfault in libgccjit garbage collection when compiling GNU Emacs with Native Compilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117047 --- Comment #25 from Sam James --- I've reproduced it
[Bug jit/117047] [15 regression] Segfault in libgccjit garbage collection when compiling GNU Emacs with Native Compilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117047 Sam James changed: What|Removed |Added Keywords||wrong-code --- Comment #26 from Sam James --- I've reproduced it on cfarm420. It requires bootstrapping (building libgccjit w/ --disable-bootstrap with 14 works fine) and some specific CFLAGS. Narrowing it down more now then will give a script.
[Bug middle-end/118819] [15 Regression] runtime error: signed integer overflow during bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118819 --- Comment #7 from GCC Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:b570f48c3dfb9ca3d640467cff67e569904009d4 commit r15-7722-gb570f48c3dfb9ca3d640467cff67e569904009d4 Author: Jakub Jelinek Date: Thu Feb 27 08:48:18 2025 +0100 alias: Perform offset arithmetics in poly_offset_int rather than poly_int64 [PR118819] This PR is about ubsan error on the c - cx1 + cy1 evaluation in the first hunk. The following patch hopefully fixes that by doing the additions/subtractions in poly_offset_int rather than poly_int64 and then converting back to poly_int64. If it doesn't fit, -1 is returned (which means it is unknown if there is a conflict or not). 2025-02-27 Jakub Jelinek PR middle-end/118819 * alias.cc (memrefs_conflict_p): Perform arithmetics on c, xsize and ysize in poly_offset_int and return -1 if it is not representable in poly_int64.
[Bug testsuite/116143] [15 regression] gcc.dg/plugin/diagnostic-* test fails intermittently
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116143
--- Comment #12 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:fb684f1654bdc831e17a5e538bdfee63ec0a5e4b
commit r15-7723-gfb684f1654bdc831e17a5e538bdfee63ec0a5e4b
Author: Jakub Jelinek
Date: Thu Feb 27 08:50:47 2025 +0100
Makefile: Link in {simple,lazy}-diagnostic-path.o [PR116143]
Some of the plugin.exp tests FAIL in --enable-checking=release builds while
they succeed in --enable-checking=yes builds.
Initially I've changed some small simple out of line methods into inline
ones
in the header, but the tests kept failing, just with different symbols.
The _ZN22simple_diagnostic_path9add_eventEmP9tree_nodeiPKcz symbol (and the
others too) are normally emitted in simple-diagnostic-path.o, it isn't some
fancy C++ optimization of classes with final method or LTO optimization.
The problem is that simple-diagnostic-path.o is like most objects added
into
libbackend.a and we then link libbackend.a without -Wl,--whole-archive ...
-Wl,--no-whole-archive around it (and can't easily, not all system
compilers
and linkers will support that).
With --enable-checking=yes simple-diagnostic-path.o is pulled in, because
selftest-run-tests.o calls simple_diagnostic_path_cc_tests and so
simple-diagnostic-path.o is linked in.
With --enable-checking=release self-tests aren't done and nothing links in
simple-diagnostic-path.o, because nothing in the compiler proper needs
anything from it, only the plugin tests.
Using -Wl,-M on cc1 linking, I see that in --enable-checking=release
build
analyzer/analyzer-selftests.o
digraph.o
dwarf2codeview.o
fibonacci_heap.o
function-tests.o
hash-map-tests.o
hash-set-tests.o
hw-doloop.o
insn-peep.o
lazy-diagnostic-path.o
options-urls.o
ordered-hash-map-tests.o
pair-fusion.o
print-rtl-function.o
resource.o
rtl-tests.o
selftest-rtl.o
selftest-run-tests.o
simple-diagnostic-path.o
splay-tree-utils.o
typed-splay-tree.o
vmsdbgout.o
aren't linked into cc1 (the *test* for obvious reasons of not doing
selftests, pair-fusion.o because it is aarch64 specific, hw-doloop.o
because
x86 doesn't have doloop opts, vmsdbgout.o because not on VMS).
So, the question is if and what from digraph.o, fibinacci_heap.o,
hw-doloop.o, insn-peep.o, lazy-diagnostic-path.o, options-urls.o,
pair-fusion.o, print-rtl-function.o, resource.o, simple-diagnostic-path.o,
splay-tree-utils.o, typed-splay-tree.o are supposed to be part of the
plugin API if anything and how we arrange for those to be linked in when
plugins are enabled.
The following patch just adds unconditionally the
{simple,lazy}-diagnostic-path.o objects to the link lines before
libbackend.a
so that their content is available to plugin users.
2025-02-27 Jakub Jelinek
PR testsuite/116143
* Makefile.in (EXTRA_BACKEND_OBJS): New variable.
(BACKEND): Use it before libbackend.a.
[Bug libstdc++/119037] Incorrect calculations of max_size involving basic_strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119037
--- Comment #2 from Halalaluyafail3 ---
(In reply to Andrew Pinski from comment #1)
> Most likely max_size in std::basic_string should be something like:
>
> ```
> /// Returns the size() of the largest possible %string.
> _GLIBCXX_NODISCARD _GLIBCXX20_CONSTEXPR
> size_type
> max_size() const _GLIBCXX_NOEXCEPT
> {
> const size_t __diffmax
> = __gnu_cxx::__numeric_traits::__max / sizeof(_CharT);
> const size_t __allocmax =
> _Alloc_traits::max_size(_M_get_allocator());
> return (std::max)(_S_local_capacity, (std::min)(__diffmax,
> __allocmax)) - 1;
> }
> ```
>
> That is taking into account the _S_local_capacity which does not need to
> call the allocator.
_S_local_capacity doesn't include the zero terminator (based off of the
definition _CharT _M_local_buf[_S_local_capacity + 1];) so there should be an
extra + 1. If that is changed, then this should fix the issues (aside from
max_size exceeding SIZE_MAX).
[Bug c++/119035] Problem of __attribute__ and maybe gcc 14 and 15 accepts invalid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119035 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- GCC 14 implements the assume attribute. https://gcc.gnu.org/onlinedocs/gcc-14.2.0/gcc/Statement-Attributes.html#index-assume-statement-attribute
[Bug c++/119034] Nested using-declaration doesn't do ADL or uses wrong associated namespace (overly strict use of deleted function before ADL)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119034
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
--- Comment #5 from Patrick Palka ---
(In reply to Andrew Pinski from comment #4)
> So the problem is not exactly an issue with ADL but rather an `overly strict
> use of deleted function before argument-dependent lookup`.
>
> That is if I take the original testcase and remove `delete` and change the
> return type to int for the function foo inside bar; GCC works.
>
> So this is another case of PR 68942.
Yep, looks like the partial instantiation version of that PR. The error
happens when substituting the outer args {true} into the alias member template.
A minimal workaround is to use a function template for the deleted overload:
template void func() = delete;
[Bug target/118992] Redundant argument set up for call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118992 H.J. Lu changed: What|Removed |Added Attachment #60590|0 |1 is obsolete|| --- Comment #15 from H.J. Lu --- Created attachment 60596 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60596&action=edit An updated patch with the second testcase
[Bug target/118992] Redundant argument set up for call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118992 --- Comment #14 from H.J. Lu --- (In reply to Hongtao Liu from comment #13) > (In reply to H.J. Lu from comment #11) > > Created attachment 60590 [details] > > A patch > > > > Can you try this on SPEC CPU? > > No big impact for both O2 and Ofast on SPEC2017. Codegen improvement is small. Since it isn't in the hot code path in SPEC 2017, the impact is very small.
[Bug middle-end/119036] New: [OpenMP] dispatch with interop(obj) clause and obj == omp_interop_none should not set default-device-var ICV
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119036
Bug ID: 119036
Summary: [OpenMP] dispatch with interop(obj) clause and obj ==
omp_interop_none should not set default-device-var ICV
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: openmp
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
CC: sandra at gcc dot gnu.org
Target Milestone: ---
OpenMP has:
"If the 'interop' clause is present and has only one interop-var, and the
'device' clause is not specified, the behavior is as if the 'device' clause is
present with a device-description equivalent to the device_num property of the
interop-var."
This does not (yet) specify what happens when interop-var has the value
omp_interop_none but IMHO, it makes most sense to not touch the
default-device-var ICV.
→ associated OpenMP issue is #4459
Currently, the GCC uses - in gcc/gimplify.cc's gimplify_omp_dispatch:
dev_num = omp_get_interop_int(obj, omp_ipr_device_num, NULL);
Expected - either of
(a) Use omp_default_device, i.e.
dev_num = obj == omp_interop_none ? omp_default_device
: omp_get_interop_int(obj, omp_ipr_device_num, NULL);
→ This requires that omp_default_device support has been added to
omp_set_default_device + omp_default_device added to
include/gomp-constants.h
(b) Guard the code, i.e.
if (obj != omp_interop_none)
{
dev_num = omp_get_interop_int(obj, omp_ipr_device_num, NULL);
saved_device = omp_get_default_device ();
omp_set_default_device (dev_num);
}
...
if (obj != omp_interop_none)
omp_set_default_device (saved_dev_num);
Regarding (a): To make that OpenMP 6.1/TR15 feature available to the users, it
additionally has to be added to libgomp/{omp.h.in,omp_lib.{f90,h}.in} and
libgomp/target.c.
[Bug c/119011] -Wsign-compare: Split it into several levels
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119011 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #16 from Eric Gallager --- I'd just like to restate my preference for using separate named options instead of numerical warning levels. Brainstorming some ideas for potential names of potential sub-options to split -Wsign-compare into: * -Wsign-compare-literal * -Wsign-compare-expression * -Wsign-compare-equality * -Wsign-compare-negation
[Bug c/119011] -Wsign-compare: Split it into several levels
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119011 --- Comment #17 from Alejandro Colomar --- (In reply to Eric Gallager from comment #16) > I'd just like to restate my preference for using separate named options > instead of numerical warning levels. Brainstorming some ideas for potential > names of potential sub-options to split -Wsign-compare into: > > * -Wsign-compare-literal > * -Wsign-compare-expression > * -Wsign-compare-equality > * -Wsign-compare-negation +1
[Bug c/119011] -Wsign-compare: Split it into several levels
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119011
--- Comment #18 from Alejandro Colomar ---
(In reply to Alejandro Colomar from comment #13)
> (In reply to Paul Eggert from comment #12)
> > Plus, i + 1 == 0 does not necessarily work if time_t is 'unsigned short'
> > (yes that'd be really weird for time_t, but ISO C and POSIX allow it and
> > I try to write to the standards, and the problem has come up with other
> > system types).
>
> ==-1 wouldn't work either for unsigned short. That's why we mentioned the
> requirement that the variable should be of a type with rank no less than int.
On the other hand, my own response shows that the requirement of the rank is
useless, because default promotions apply before this diagnostic even kicks in.
As my example quoted below shows, in case of an unsigned integer of rank lower
than int, we trigger -Wtype-limits, which is different.
So for this diagnostic, we could just avoid diagnosing for literal -1 always.
>
> With unsigned short, you first promote it to an int, since int can hold any
> value of unsigned short, and it holds a USHRT_MAX, which is a small-ish
> positive number, while -1 keeps being negative.
>
> alx@debian:~/tmp$ cat ushrt.c
> int
> main(void)
> {
> unsigned short uh = -1;
>
> if (uh == -1)
> return 0;
> return 1;
> }
> alx@debian:~/tmp$ gcc -Wall -Wextra ushrt.c
> ushrt.c: In function ‘main’:
> ushrt.c:6:16: warning: comparison is always false due to limited range of
> data type [-Wtype-limits]
> 6 | if (uh == -1)
> |^~
> alx@debian:~/tmp$ ./a.out
> alx@debian:~/tmp$ echo $?
> 1
>
>
> Still, both working on the same cases, ==-1 is going to cause less mental
> surprises.
[Bug c++/118981] "_GLOBAL__sub_I.00099_tzdb.cc" defined twice in the assembly output for c++20/tzdb.cc with -fvtable-verify=std (--enable-vtable-verify)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118981 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #43 from Eric Gallager --- (In reply to Andrew Pinski from comment #14) > (In reply to Jonathan Wakely from comment #13) > > (In reply to Andrew Pinski from comment #6) > > > init_priority attribute should most likely link back to the constructor > > > function attribute for the description of the priority . > > > > And the constructor attribute docs should mention 101-65535. The valid range > > for user code and the reserved range should both be stated together, not > > split across two locations. > > let me file that as a seperate bug; I might get to doing that next week or > so. ...this is bug 118982, correct?
[Bug target/118835] [12 Regression] ICE in s390_valid_shift_count since r10-1731-ge2839e47894f0b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118835 --- Comment #5 from GCC Commits --- The releases/gcc-12 branch has been updated by Stefan Schulze Frielinghaus : https://gcc.gnu.org/g:b27fa6a7ca86a9b885cb4dbe8a55991e7fb666f0 commit r12-10967-gb27fa6a7ca86a9b885cb4dbe8a55991e7fb666f0 Author: Stefan Schulze Frielinghaus Date: Thu Feb 13 09:13:06 2025 +0100 s390: Fix s390_valid_shift_count() for TI mode [PR118835] During combine we may end up with (set (reg:DI 66 [ _6 ]) (ashift:DI (reg:DI 72 [ x ]) (subreg:QI (and:TI (reg:TI 67 [ _1 ]) (const_wide_int 0x0aabf)) 15))) where the shift count operand does not trivially fit the scheme of address operands. Reject those operands, especially since strip_address_mutations() expects expressions of the form (and ... (const_int ...)) and fails for (and ... (const_wide_int ...)). Thus, be more strict here and accept only CONST_INT operands. Done by replacing immediate_operand() with const_int_operand() which is enough since the former only additionally checks for LEGITIMATE_PIC_OPERAND_P and targetm.legitimate_constant_p which are always true for CONST_INT operands. While on it, fix indentation of the if block. gcc/ChangeLog: PR target/118835 * config/s390/s390.cc (s390_valid_shift_count): Reject shift count operands which do not trivially fit the scheme of address operands. gcc/testsuite/ChangeLog: * gcc.target/s390/pr118835.c: New test. (cherry picked from commit ac9806dae30d07ab082ac341fe5646987753adcb)
[Bug target/118949] [15 regression] RISC-V: Extra FRM writes since GCC-14.2 since r15-5943-gdc0dea98c96e02
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118949 --- Comment #9 from Jeffrey A. Law --- I'd kind of lean towards the scheduler to fix this up. I've got an old patch that I put on ICE that might be helpful. https://inbox.sourceware.org/gcc-patches/d59x71nu21wx.3ndzz35ya8...@gmail.com/T/
[Bug c++/118986] [15 Regression] internal compiler error: in replace_decl, at cp/constexpr.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118986 --- Comment #9 from Marek Polacek --- In cp_fold_r we have: TARGET_EXPR >>> so object=D.2701, and init is the expr_stmt. We unwrap the EXPR_STMT/INIT_EXPR/TARGET_EXPR and end up evaluating the f1 call. f1 returns c2; the type of D.2701 is struct ._anon_0. So then we crash in replace_decl on: 2730 gcc_checking_assert (same_type_ignoring_top_level_qualifiers_p 2731 (TREE_TYPE (decl), TREE_TYPE (replacement)));
[Bug target/118835] ICE in s390_valid_shift_count since r10-1731-ge2839e47894f0b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118835
Stefan Schulze Frielinghaus changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED |RESOLVED
--- Comment #6 from Stefan Schulze Frielinghaus
---
Fixed on trunk and release branches {12,13,14}.
[Bug c/119011] -Wsign-compare: Split it into several levels
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119011 Vincent Lefèvre changed: What|Removed |Added CC||vincent-gcc at vinc17 dot net --- Comment #9 from Vincent Lefèvre --- (In reply to Paul Eggert from comment #8) > (In reply to Jakub Jelinek from comment #4) > > just use ~(time_t)0 or similar. > That has a cast, and part of the point of this bug report is to avoid casts > which are too powerful in C. Yes, and in a more general case, if the type of the variable changes, one may forget to update the type of the cast. But instead of the i == -1 comparison, one could do i + 1 == 0. This should avoid the sign-compare warning in this particular case. > -Wsign-compare gives so many false positives in good code that it’s > typically more trouble than it’s worth. Agreed. That's the case in GNU MPFR, and it does not seem to be possible to avoid all false positives without making the code less maintainable, though fixing PR38470 (VRP) might avoid all of them in our case (or we could improve the code in this way).
[Bug rtl-optimization/118739] [15 Regression] wrong code at -O{s,3} with "-fno-tree-forwprop -fno-tree-vrp" on x86_64-linux-gnu since r15-268-g9dbff9c05520a7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118739 --- Comment #17 from Uroš Bizjak --- V2 patch at [1]: [1] https://gcc.gnu.org/pipermail/gcc-patches/2025-February/676494.html
[Bug libstdc++/118185] ranges::clamp doesn't perfectly forward its projected arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118185 Patrick Palka changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |14.3 --- Comment #4 from Patrick Palka --- Fixed for 14.3, this seems to be obscure enough of a bug that more backporting isn't worth it.
[Bug libstdc++/108823] ranges::transform could be smarter with two sized ranges
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108823
--- Comment #1 from Jonathan Wakely ---
So maybe something like:
--- a/libstdc++-v3/include/bits/ranges_algo.h
+++ b/libstdc++-v3/include/bits/ranges_algo.h
@@ -758,11 +758,21 @@ namespace ranges
_Out __result, _Fp __binary_op,
_Proj1 __proj1 = {}, _Proj2 __proj2 = {}) const
{
- for (; __first1 != __last1 && __first2 != __last2;
-++__first1, (void)++__first2, ++__result)
- *__result = std::__invoke(__binary_op,
- std::__invoke(__proj1, *__first1),
- std::__invoke(__proj2, *__first2));
+ if constexpr (sized_sentinel_for<_Sent1, _Iter1>
+ && sized_sentinel_for<_Sent2, _Iter2>)
+ for (auto __sz = std::min(__last1 - __first1,
+ __last2 - __first2);
+ __sz--;
+ ++__first1, (void)++__first2, ++__result)
+ *__result = std::__invoke(__binary_op,
+ std::__invoke(__proj1, *__first1),
+ std::__invoke(__proj2, *__first2));
+ else
+ for (; __first1 != __last1 && __first2 != __last2;
+ ++__first1, (void)++__first2, ++__result)
+ *__result = std::__invoke(__binary_op,
+ std::__invoke(__proj1, *__first1),
+ std::__invoke(__proj2, *__first2));
return {std::move(__first1), std::move(__first2), std::move(__result)};
}
@@ -778,10 +788,28 @@ namespace ranges
operator()(_Range1&& __r1, _Range2&& __r2, _Out __result, _Fp
__binary_op,
_Proj1 __proj1 = {}, _Proj2 __proj2 = {}) const
{
- return (*this)(ranges::begin(__r1), ranges::end(__r1),
- ranges::begin(__r2), ranges::end(__r2),
- std::move(__result), std::move(__binary_op),
- std::move(__proj1), std::move(__proj2));
+ if constexpr (sized_range<_Range1> && sized_range<_Range2>
+ && (random_access_range<_Range1>
+ || random_access_range<_Range2>))
+ {
+ auto __sz = std::min(ranges::size(__r1),
+ranges::size(__r2));
+ auto __b1 = ranges::begin(__r1);
+ auto __b2 = ranges::begin(__r2);
+ if constexpr (random_access_range<_Range1>)
+ return (*this)(__b1, __b1 + __sz, __b2, unreachable_sentinel,
+std::move(__result), std::move(__binary_op),
+std::move(__proj1), std::move(__proj2));
+ else
+ return (*this)(__b1, unreachable_sentinel, __b2, __b2 + __sz,
+std::move(__result), std::move(__binary_op),
+std::move(__proj1), std::move(__proj2));
+ }
+ else
+ return (*this)(ranges::begin(__r1), ranges::end(__r1),
+ranges::begin(__r2), ranges::end(__r2),
+std::move(__result), std::move(__binary_op),
+std::move(__proj1), std::move(__proj2));
}
};
So ranges::transform(i1, s1, i2, s2, out, op) calculates the loop count first
if sized_sentinel_for is satisfied for both ranges, and then loops that many
times instead of using i1 != s1 && i2 != s2
And ranges::transform(r1, r2, out, op) calculates the loop count using
ranges::size on both ranges and uses your unreachable_sentinel trick if either
of the ranges is random access. This way we can simplify the i1 != s1 && i2 !=
s2 check even if only one of the ranges is random access, e.g. transforming a
std::vector and std::list. In the latter case we probably won't get
vectorization because the iterators aren't pointers, but it might still be
beneficial to simplify the loop condition.
[Bug libstdc++/108823] ranges::transform could be smarter with two sized ranges
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108823 --- Comment #2 from Jonathan Wakely --- Is std::min(ranges::size(__r1), ranges::size(__r2)) safe? Probably not, since we could have iota(0LL, LLONG_MAX) on a 32-bit host where size_t is 32-bit. So I suppose it should be uintmax_t instead.
[Bug libstdc++/108823] ranges::transform could be smarter with two sized ranges
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108823 --- Comment #3 from Jonathan Wakely --- Or decltype(ranges::size(r1) + ranges::size(r2)) ?
[Bug middle-end/119021] [15 Regression] RTL checking ICEs after r15-7700
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119021
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW |RESOLVED
Assignee|unassigned at gcc dot gnu.org |vmakarov at gcc dot
gnu.org
--- Comment #7 from Jakub Jelinek ---
LGTM. Guess the other option would be just to
{
asm_p = true;
lra_asm_insn_error (insn);
if (JUMP_P (insn))
{
ira_nullify_asm_goto (insn);
lra_invalidate_insn_data (insn);
}
}
else if (!asm_p)
For the RTL checking, the problem wasn't with asm goto, but other asms which
are turned into NOTE_INSN_DELETED. So the lra_invalidate_insn_data or PATTERN
(insn) = gen_rtx_USE (VOIDmode, const0_rtx); on it was problematic.
[Bug tree-optimization/118953] [14/15 regression] Miscompile at -O2 since r14-2473-g602e824eec30a7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118953 --- Comment #6 from Jakub Jelinek --- I think the bug is in irange::union_bitmask with *this [irange] long long unsigned int [0, 0][17, 17][25, 25] MASK 0xc000 VALUE 0x2d and r [irange] long long unsigned int [0, 0] r.m_bitmask is MASK 0x VALUE 0x0. 2447 irange_bitmask bm = get_bitmask (); 2448 irange_bitmask save = bm; 2449 bm.union_ (r.get_bitmask ()); 2450 if (save == bm) 2451return false; uses get_bitmask though, which first computes independently 2375 irange_bitmask bm 2376= get_bitmask_from_range (type (), lower_bound (), upper_bound ()); and because lower_bound () is 0 (this is already partially merged) and upper_bound () is 25, bm is then MASK 0x1f VALUE 0x0 This is then 2377 if (!m_bitmask.unknown_p ()) 2378bm.intersect (m_bitmask); and we get MASK 0x VALUE 0x0 which is returned. Now, obviously bm.union_ (r.get_bitmask ()); yields the same MASK 0x VALUE 0x0 and so the code thinks ok, there is no change, we don't need to update m_bitmask. The comments talk about semantic bitmasks (what get_bitmask () returns) vs. what is stored in m_bitmask, it is true that the semantic bitmask didn't really change, it was already MASK 0x VALUE 0x0 when the range was just [irange] long long unsigned int [17, 17][25, 25] MASK 0xc000 VALUE 0x2d but guess this testcase shows that it is really undesirable to keep random garbage in m_bitmask when the semantic bitmask didn't change, because we can later union it with something that will change the semantic bitmask. So wonder at least about --- gcc/value-range.cc.jj 2025-01-02 11:23:25.118396777 +0100 +++ gcc/value-range.cc 2025-02-26 18:49:10.713107905 +0100 @@ -2447,7 +2447,7 @@ irange::union_bitmask (const irange &r) irange_bitmask bm = get_bitmask (); irange_bitmask save = bm; bm.union_ (r.get_bitmask ()); - if (save == bm) + if (m_bitmask == bm) return false; m_bitmask = bm; which fixes the testcase. I.e. still return false, just update m_bitmask.
[Bug libstdc++/118083] __possibly_const_range misses input_range constraint
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118083 --- Comment #3 from GCC Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:640697f7c2def415db81c84010ae25be0785d867 commit r15-7720-g640697f7c2def415db81c84010ae25be0785d867 Author: Patrick Palka Date: Wed Feb 26 14:51:38 2025 -0500 libstdc++: Add code comment documenting LWG 4027 change [PR118083] PR libstdc++/118083 libstdc++-v3/ChangeLog: * include/bits/ranges_base.h (ranges::__access::__possibly_const_range): Mention LWG 4027.
[Bug c++/118964] include in the module causes a compilation error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118964 Jason Merrill changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #6 from Jason Merrill --- (In reply to Nathaniel Shead from comment #4) > That said, looking at your provided code this seems odd as it doesn't > actually use any of these noted declarations from OpenCV; I guess maybe this > is some of the known issues we have with not fully eliding all unused > templates from the GMF in the case of deferred instantiations. Hmm, it doesn't seem to me that elision makes a difference to the standard; https://eel.is/c++draft/basic.link#17 just says a declaration in a module interface unit, so the templates are ill-formed whether or not they might be discarded later.
[Bug libstdc++/119029] [15 regression] abi_check FAILs on Solaris with gld
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119029 Jonathan Wakely changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2025-02-26 --- Comment #1 from Jonathan Wakely --- Hmm, does this imply we should have a separate baseline files for those two configurations?
[Bug middle-end/119021] [15 Regression] RTL checking ICEs after r15-7700
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119021 --- Comment #4 from Jakub Jelinek --- (In reply to Vladimir Makarov from comment #3) > (In reply to Jakub Jelinek from comment #2) > > So, either remove that call too, or move it into lra_asm_insn_error before > > the insn has been deleted. Vlad, I'll defer this to you. > > Sorry for the issues with my recent patch. > > Moving to the old code would result in LRA cycling on some wrong asms with > repeating the asm error (e.g. pr55512-3.c). So the solution is not so easy. > I'll work on it. Can't it just look at the present insn and if it is no longer asm but NOTE_INSN_DELETED, ignore it?
[Bug libstdc++/119029] [15 regression] abi_check FAILs on Solaris with gld
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119029 Jonathan Wakely changed: What|Removed |Added Keywords||ABI --- Comment #2 from Jonathan Wakely --- Although the ABI shouldn't depend on the choice of ld. So maybe we should hardcode the _GLIBCXX_USE_INIT_PRIORITY_ATTRIBUTE result for Solaris, so that the use of _ZSt21ios_base_library_initv doesn't depend on the linker used.
[Bug libstdc++/119029] [15 regression] abi_check FAILs on Solaris with gld
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119029
--- Comment #3 from Jonathan Wakely ---
The header has:
// For construction of filebuffers for cout, cin, cerr, clog et. al.
// When the init_priority attribute is usable, we do this initialization
// in the compiled library instead (src/c++98/globals_io.cc).
#if !(_GLIBCXX_USE_INIT_PRIORITY_ATTRIBUTE \
&& __has_attribute(__init_priority__))
static ios_base::Init __ioinit;
#elif defined(_GLIBCXX_SYMVER_GNU) && defined(__ELF__)
__extension__ __asm (".globl _ZSt21ios_base_library_initv");
#endif
and then src/c++98/ios_init.cc has:
#if defined(_GLIBCXX_SYMVER_GNU) && defined(__ELF__)
#pragma GCC diagnostic ignored "-Wattribute-alias"
void ios_base_library_init (void)
__attribute__((alias ("_ZNSt8ios_base4InitC1Ev")));
#endif
So that's why we define that symbol.
Maybe we just want to define that for _GLIBCXX_SYMVER_SUN too?
[Bug middle-end/119021] [15 Regression] RTL checking ICEs after r15-7700
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119021 --- Comment #3 from Vladimir Makarov --- (In reply to Jakub Jelinek from comment #2) > So, either remove that call too, or move it into lra_asm_insn_error before > the insn has been deleted. Vlad, I'll defer this to you. Sorry for the issues with my recent patch. Moving to the old code would result in LRA cycling on some wrong asms with repeating the asm error (e.g. pr55512-3.c). So the solution is not so easy. I'll work on it.
[Bug target/116032] [12/13/14/15 Regression] gcc.target/arm/pr40457-2.c produces larger code for armv7ve+neon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116032 --- Comment #6 from Christophe Lyon --- I mean in this case CONST_VECTOR already has a cost of 16
[Bug tree-optimization/119030] [15 Regression] wrong optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119030 Marek Polacek changed: What|Removed |Added Keywords|needs-bisection | CC||aoliva at gcc dot gnu.org, ||mpolacek at gcc dot gnu.org Component|c++ |tree-optimization Priority|P3 |P1 --- Comment #2 from Marek Polacek --- Appears to have started with r15-7597: commit 3768bedf7b5fcdd63a18871ecfce665ae1b8d87e Author: Alexandre Oliva Date: Mon Feb 17 23:17:21 2025 -0300 [ifcombine] cope with signbit tests of extended values
[Bug tree-optimization/119030] [15 Regression] wrong optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119030
--- Comment #3 from Jakub Jelinek ---
Started with r15-7597-g3768bedf7b5fcdd63a18871ecfce665ae1b8d87e
static inline unsigned
foo (long long tag)
{
return tag & 0x8000;
}
static inline long long
bar (long long tag)
{
if (foo (tag))
return -1000;
else
return tag >> 16;
}
long long tag = -0x2LL;
int
main ()
{
if (bar (tag) >= 0)
__builtin_abort ();
return 0;
}
[Bug c/119011] -Wsign-compare: Split it into several levels
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119011 --- Comment #11 from Vincent Lefèvre --- (In reply to Alejandro Colomar from comment #10) [about i + 1 == 0 instead of i == -1] > But this causes readability issues. For error-handling, programmers are > used to writing ==-1, and doing +1==0 would be significantly weird. Given > that comparison ==-1 isn't unsafe in any way (given that the LHS is of rank > no less than int), we should stop warning about it. OK. I completely agree.
[Bug libstdc++/119029] [15 regression] abi_check FAILs on Solaris with gld
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119029
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4 from Jakub Jelinek ---
Does it have in that case the desired effect? I mean, does Solaris dynamic
linker complain with that
__extension__ __asm (".globl _ZSt21ios_base_library_initv");
if one tries to run a program against older libstdc++.so.6?
Depending on that, we should be either using _GLIBCXX_SYMVER_SUN in both spots,
or just the second one.
[Bug libstdc++/119029] [15 regression] abi_check FAILs on Solaris with gld
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119029 --- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #1 from Jonathan Wakely --- > Hmm, does this imply we should have a separate baseline files for those two > configurations? I'd rather not if it can somehow be avoided. On top of that, install.texi strongly recommends using Solaris ld instead of GNU ld. I only run weekly bootstraps on the gas/gld configuration to make certain it keeps working in general.
[Bug libstdc++/119029] [15 regression] abi_check FAILs on Solaris with gld
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119029 --- Comment #5 from Jakub Jelinek --- Is _GLIBCXX_USE_INIT_PRIORITY_ATTRIBUTE defined on Solaris when using Solaris ld and/or when using gld?
[Bug c++/119030] New: 15 Regression wrong optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119030
Bug ID: 119030
Summary: 15 Regression wrong optimization
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: frank.mehnert at googlemail dot com
Target Milestone: ---
Compiling our local project reveals some unexpected behavior when using gcc-15.
I was able to extract the following example code.
Either this problem is specific to x86_64 (does not happen for aarch64) or the
compiler version matters:
- x86_64/wrong: 15.0.1 20250220
- aarch64/OK: 15.0.1 20250208
+++
#include
static inline unsigned check_bit_15_set(long tag)
{
return tag & 0x8000;
}
static inline long check_error(long tag)
{
if (check_bit_15_set(tag))
return -1000;
else
return tag >> 16;
}
long tag = 0x''fffe'L;
int main()
{
long ret = check_error(tag);
if (ret >= 0)
printf("gcc %u: UNEXPECTED!\n", __GNUC__);
else
printf("gcc %u: OK\n", __GNUC__);
return 0;
}
+++
Output of binary compiled with 'gcc-14 -O2 -m64' for x86_64:
gcc 14: OK
Output of binary compiled with 'gcc-15 -O2 -m64' for x86_64:
gcc 15: UNEXPECTED!
Output of binary compiled with 'gcc-15 -O1 -m64' for x86_64:
gcc 15: UNEXPECTED!
Output of binary compiled with 'gcc-15 -O0 -m64' for x86_64:
gcc 15: OK
$ x86_64-linux-gnu-g++-15 -v
Using built-in specs.
COLLECT_GCC=x86_64-linux-gnu-g++-15
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-linux-gnu/15/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 15-20250220-1'
--with-bugurl=file:///usr/share/doc/gcc-15/README.Bugs
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2,rust,cobol,algol68
--prefix=/usr --with-gcc-major-version-only --program-suffix=-15
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/libexec --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new
--enable-libstdcxx-backtrace --enable-gnu-unique-object --disable-vtable-verify
--enable-plugin --enable-default-pie --with-system-zlib
--enable-libphobos-checking=release --with-target-system-zlib=auto
--enable-objc-gc=auto --enable-multiarch --disable-werror --enable-cet
--with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none=/home/packages/gcc/15/gcc-15-15-20250220/debian/tmp-nvptx/usr,amdgcn-amdhsa=/home/packages/gcc/15/gcc-15-15-20250220/debian/tmp-gcn/usr
--enable-offload-defaulted --without-cuda-driver
--enable-checking=yes,extra,rtl --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 15.0.1 20250220 (experimental) [master r15-7637-g94d01a88470]
(Debian 15-20250220-1)
+++
Output of binary compiled with 'gcc-15 -O2' for aarch64-linux-gnu:
gcc-15: OK
$ aarch64-linux-gnu-g++ -v
Using built-in specs.
COLLECT_GCC=aarch64-linux-gnu-g++-15
COLLECT_LTO_WRAPPER=/usr/libexec/gcc-cross/aarch64-linux-gnu/15/lto-wrapper
Target: aarch64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 15-20250208-1'
--with-bugurl=file:///usr/share/doc/gcc-15/README.Bugs
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-15 --enable-shared
--enable-linker-build-id --libexecdir=/usr/libexec --without-included-gettext
--enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/
--enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-libstdcxx-backtrace
--enable-gnu-unique-object --disable-libquadmath --disable-libquadmath-support
--enable-plugin --enable-default-pie --with-system-zlib
--enable-libphobos-checking=release --without-target-system-zlib
--enable-multiarch --enable-fix-cortex-a53-843419 --disable-werror
--enable-checking=yes,extra,rtl --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=aarch64-linux-gnu
--program-prefix=aarch64-linux-gnu- --includedir=/usr/aarch64-linux-gnu/include
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 15.0.1 20250208 (experimental) [master r15-7437-g64d8ea056a5]
(Debian 15-20250208-1)
[Bug c++/119030] [15 Regression] wrong optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119030 Richard Biener changed: What|Removed |Added Target||x86_64-*-* Keywords||needs-bisection, wrong-code Ever confirmed|0 |1 Target Milestone|--- |15.0 Summary|15 Regression wrong |[15 Regression] wrong |optimization|optimization Status|UNCONFIRMED |NEW Last reconfirmed||2025-02-26 --- Comment #1 from Richard Biener --- Confirmed. Worked with r15-7499
[Bug c/119011] -Wsign-compare: Split it into several levels
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119011 --- Comment #10 from Alejandro Colomar --- (In reply to Vincent Lefèvre from comment #9) > (In reply to Paul Eggert from comment #8) > > (In reply to Jakub Jelinek from comment #4) > > > just use ~(time_t)0 or similar. > > That has a cast, and part of the point of this bug report is to avoid casts > > which are too powerful in C. > > Yes, and in a more general case, if the type of the variable changes, one > may forget to update the type of the cast. But instead of the i == -1 > comparison, one could do i + 1 == 0. This should avoid the sign-compare > warning in this particular case. But this causes readability issues. For error-handling, programmers are used to writing ==-1, and doing +1==0 would be significantly weird. Given that comparison ==-1 isn't unsafe in any way (given that the LHS is of rank no less than int), we should stop warning about it.
[Bug libstdc++/119029] [15 regression] abi_check FAILs on Solaris with gld
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119029 --- Comment #7 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #5 from Jakub Jelinek --- > Is _GLIBCXX_USE_INIT_PRIORITY_ATTRIBUTE defined on Solaris when using Solaris > ld and/or when using gld? On Solaris 11.4, it is always defined for all of the as/ld, gas/ld, and gas/gld combos. Things were different in Solaris 11.3 and before, but those versions are no longer supported by trunk.
[Bug libstdc++/119029] [15 regression] abi_check FAILs on Solaris with gld
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119029
--- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #4 from Jakub Jelinek ---
> Does it have in that case the desired effect? I mean, does Solaris dynamic
> linker complain with that
> __extension__ __asm (".globl _ZSt21ios_base_library_initv");
> if one tries to run a program against older libstdc++.so.6?
I'll try that later tonight.
> Depending on that, we should be either using _GLIBCXX_SYMVER_SUN in both
> spots,
> or just the second one.
I'll start trying the first variant (both spots) then.
However, please note I'll be on vacation starting tomorrow until the end
of next week, thus unlikely to respond further in that timeframe.
[Bug c++/119032] New: Should using brace elison for designated initializer be reminded under '-pedantic-errors'?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119032
Bug ID: 119032
Summary: Should using brace elison for designated initializer
be reminded under '-pedantic-errors'?
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: accepts-invalid, diagnostic
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rush102333 at gmail dot com
Target Milestone: ---
An interesting question that has also been submitted to LLVM' s bug tracker:
~~
struct A {
int a;
};
struct B {
int b;
};
struct C {
A a;
B b;
};
C c{.a=0, .b={12}};
~~
GCC accepts this after gcc-11.3 and rejects it before by giving the following
diagnostic:
~~
:14:18: error: 'A' has no non-static data member named 'b'
14 | C c{.a=0, .b={12}};
| ^
Compiler returned: 1
~~
https://godbolt.org/z/5nPzG3WGY
While the real question might be that the code uses brace elision inside a
designated initializer("{.a=0}"), which is actually a C99 extension, the
diagnostic seems not that accurate.
LLVM now ends up throwing a warning for that and erroring under
'-pedantic-errors', but GCC currently does not provide any diagnostic even
under '-pedantic-errors':
https://godbolt.org/z/4fdWWTKqr
[Bug target/116032] [12/13/14/15 Regression] gcc.target/arm/pr40457-2.c produces larger code for armv7ve+neon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116032
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment #5 from Christophe Lyon ---
{ 0, 1 } is NOT cheaper to generate than { 1, 0 }, we generate the same code in
both cases.
What would make the vector cost model take into account the fact that it needs
to introduce a constant pool entry?
[Bug ipa/119012] [riscv] Bootstrap comparison failure: gcc/rust/rust-lex.o differs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119012 --- Comment #2 from Levi Zim --- (In reply to Andrew Pinski from comment #1) > Can you attach the preprocessed source for rust-lex.cc ? Do you mean re-running the command that produces rust-lex.o but with -save-temps? > The big difference between stage1 and stage2 is debug info. Yes, but here what differs are stage 2 and stage 3. I could not relate it to stage 1. > Can can you post the exact configure command that you are building with > rather than the build script since it is NOT obvious the options being used. Configure: env CFLAGS=$'-march=rv64gc -mabi=lp64d -O2 -pipe -fno-plt -fexceptions -Wp,-D_FORTIFY_SOURCE=3 -Wformat -fstack-clash-protection -fno-omit-frame-pointer -g -ffile-prefix-map=/build/gcc/src=/usr/src/debug/gcc' \ CHOST=riscv64-unknown-linux-gnu COMMAND_MODE=legacy CXXFLAGS=$'-march=rv64gc -mabi=lp64d -O2 -pipe -fno-plt -fexceptions -Wp,-D_FORTIFY_SOURCE=3 -Wformat -fstack-clash-protection -fno-omit-frame-pointer -Wp,-D_GLIBCXX_ASSERTIONS -g -ffile-prefix-map=/build/gcc/src=/usr/src/debug/gcc' \ DEBUG_FFLAGS=$' -ffile-prefix-map=/build/gcc/src=/usr/src/debug/gcc' DEBUG_RUSTFLAGS=$' --remap-path-prefix=/build/gcc/src=/usr/src/debug/gcc' \ FCFLAGS=$' -ffile-prefix-map=/build/gcc/src=/usr/src/debug/gcc' FFLAGS=$' -ffile-prefix-map=/build/gcc/src=/usr/src/debug/gcc' \ LDFLAGS=$'-Wl,-O1 -Wl,--sort-common -Wl,--as-needed -Wl,-z,relro -Wl,-z,now' \ MAKEFLAGS=-j56 PYTHONHASHSEED=0 RUSTFLAGS=$' --remap-path-prefix=/build/gcc/src=/usr/src/debug/gcc' \ SHLVL=1 SOURCE_DATE_EPOCH=1740570247 LANG=C.UTF-8 \ ../gcc/configure $'--enable-languages=c,c++,lto,rust' --enable-bootstrap \ $'--prefix=/usr' $'--libdir=/usr/lib' $'--libexecdir=/usr/lib' $'--mandir=/usr/share/man' $'--infodir=/usr/share/info' \ $'--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 --disable-multilib --enable-plugin --enable-shared $'--enable-threads=posix' \ --disable-libssp --disable-libstdcxx-pch --disable-werror Build: env CFLAGS=$'-march=rv64gc -mabi=lp64d -O2 -pipe -fno-plt -fexceptions -Wp,-D_FORTIFY_SOURCE=3 -Wformat -fstack-clash-protection -fno-omit-frame-pointer -g -ffile-prefix-map=/build/gcc/src=/usr/src/debug/gcc' \ CHOST=riscv64-unknown-linux-gnu COMMAND_MODE=legacy \ CXXFLAGS=$'-march=rv64gc -mabi=lp64d -O2 -pipe -fno-plt -fexceptions -Wp,-D_FORTIFY_SOURCE=3 -Wformat -fstack-clash-protection -fno-omit-frame-pointer -Wp,-D_GLIBCXX_ASSERTIONS -g -ffile-prefix-map=/build/gcc/src=/usr/src/debug/gcc' \ DEBUG_FFLAGS=$' -ffile-prefix-map=/build/gcc/src=/usr/src/debug/gcc' DEBUG_RUSTFLAGS=$' --remap-path-prefix=/build/gcc/src=/usr/src/debug/gcc' \ FCFLAGS=$' -ffile-prefix-map=/build/gcc/src=/usr/src/debug/gcc' FFLAGS=$' -ffile-prefix-map=/build/gcc/src=/usr/src/debug/gcc' \ LDFLAGS=$'-Wl,-O1 -Wl,--sort-common -Wl,--as-needed -Wl,-z,relro -Wl,-z,now' MAKEFLAGS=-j56 PYTHONHASHSEED=0 \ RUSTFLAGS=$' --remap-path-prefix=/build/gcc/src=/usr/src/debug/gcc' SOURCE_DATE_EPOCH=1740570247 LANG=C.UTF-8 \ make -O $'STAGE1_CFLAGS=-O2' \ $'BOOT_CFLAGS=-march=rv64gc -mabi=lp64d -O2 -pipe -fno-plt -fexceptions -Wp,-D_FORTIFY_SOURCE=3 -Wformat -fstack-clash-protection -fno-omit-frame-pointer -g -ffile-prefix-map=/build/gcc/src=/usr/src/debug/gcc' \ $'BOOT_LDFLAGS=-Wl,-O1 -Wl,--sort-common -Wl,--as-needed -Wl,-z,relro -Wl,-z,now' \ $'LDFLAGS_FOR_TARGET=-Wl,-O1 -Wl,--sort-common -Wl,--as-needed -Wl,-z,relro -Wl,-z,now' bootstrap I am now also trying to reproduce it outside our packaging infra. > > Also the comparison script is different from the what you are doing for > comparison so what you think is the different is incorrect. > > It uses $(srcdir)/contrib/compare-lto to the comparison. I am aware of it. The output of diffscope is for reference only.
[Bug tree-optimization/118953] [14/15 regression] Miscompile at -O2 since r14-2473-g602e824eec30a7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118953 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- The _7 range looks correct. And given Global Exported: _7 = [irange] int [-INF, 2146435123] MASK 0xc000 VALUE 0x34 I wonder why Folding statement: switch (_7) [33.33%], case 8: [33.33%], case 24: [33.33%], case 32: [33.33%]> Not folded - neither 8, nor 24 nor 32 has the low 14 bits equal to 0x34, so I think it could be folded into just the default. Global Exported: i_20 = [irange] long long unsigned int [45, 45] MASK 0xc07d VALUE 0x0 is certainly wrong for # i_20 = PHI <_3(4), 0(3), _6(2)> where Global Exported: _3 = [irange] long long unsigned int [0, 2146435116][18446744071561019437, +INF] MASK 0xc000 VALUE 0x2d and Global Exported: _6 = [irange] long long unsigned int [0, 2146435160][18446744071562067968, +INF] MASK 0xc000 VALUE 0x59 45 == 0x2d.
[Bug c++/119034] New: Nested using-declaration doesn't do ADL or uses wrong associated namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119034
Bug ID: 119034
Summary: Nested using-declaration doesn't do ADL or uses wrong
associated namespace
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
namespace foo
{
struct X { };
void func(X) { }
}
namespace bar
{
void func() = delete;
template
concept adl_func = requires(T t) { func(t); }; // #1
template
struct result
{
template
using type = decltype(func(T{})); // #2
};
template<>
struct result
{
};
template
using type = typename result>::template type;
}
template constexpr bool is_same_v = false;
template constexpr bool is_same_v = true;
static_assert( is_same_v, void> );
Clang and EDG compile this OK. MSVC rejects it, but I don't understand the
error.
GCC says:
adl.cc: In instantiation of 'struct bar::result':
adl.cc:27:11: required by substitution of 'template using bar::type
= typename bar::result >::type [with T = foo::X]'
27 | using type = typename result>::template type;
| ^~~~
adl.cc:33:42: required from here
33 | static_assert( is_same_v, void> );
| ^
adl.cc:18:35: error: use of deleted function 'void bar::func()'
18 | using type = decltype(func(T{})); // #2
| ^
adl.cc:9:8: note: declared here
9 | void func() = delete;
|^~~~
It seems that the call func(T{}) at #2 does not use namespace foo as an
associated namespace, even though T is foo::X, and even though we can't even
reach #2 unless the concept at #1 has already confirmed that func(T{}) does use
ADL to find foo::func.
If the helper classes are written like this then all compilers are happy:
template
struct result
{
};
template
struct result
{
using type = decltype(func(T{})); // #2
};
template
using type = typename result::type;
But I was hoping to reduce the number of instantiations by only having
result and result, and using an alias template to find the result
of the ADL call.
[Bug c++/119034] Nested using-declaration doesn't do ADL or uses wrong associated namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119034 --- Comment #1 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #0) > If the helper classes are written like this then all compilers are happy: Actually that's not true, MSVC is still unhappy. I think the adl_func concept is not satisfied.
[Bug c++/119034] Nested using-declaration doesn't do ADL or uses wrong associated namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119034
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Last reconfirmed||2025-02-27
--- Comment #2 from Andrew Pinski ---
This is odd, doing this:
```
namespace foo
{
struct X { };
void func(X) { }
}
namespace bar
{
int func() = delete;
template
using type = decltype(func(T{})); // #2
}
template constexpr bool is_same_v = false;
template constexpr bool is_same_v = true;
static_assert( is_same_v, void> );
```
Works but if you add:
```
template
struct result
{
template
using type1 = type; // #2
};
```
After the type alias, GCC fails. even if result::type1 is unused.
That is this fails:
```
namespace foo
{
struct X { };
void func(X) { }
}
namespace bar
{
int func() = delete;
template
using type = decltype(func(T{})); // #2
template
struct result
{
template
using type1 = type; // #2
};
}
template constexpr bool is_same_v = false;
template constexpr bool is_same_v = true;
static_assert( is_same_v, void> );
```
[Bug c++/119034] Nested using-declaration doesn't do ADL or uses wrong associated namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119034
--- Comment #3 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #2)
> This is odd, doing this:
> ```
> namespace foo
> {
> struct X { };
> void func(X) { }
> }
>
> namespace bar
> {
> int func() = delete;
> template
> using type = decltype(func(T{})); // #2
> }
>
> template constexpr bool is_same_v = false;
> template constexpr bool is_same_v = true;
>
> static_assert( is_same_v, void> );
> ```
>
> Works
This started to work in GCC 12 (a variant of it [changing the template
variable] was failing since at least 4.9.0) so that might give an hint of where
the problem is located.
[Bug ipa/119012] [riscv] Bootstrap comparison failure: gcc/rust/rust-lex.o differs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119012 --- Comment #3 from Levi Zim --- Weird. It seems that I cannot reproduce it outside of our packaging infra.
[Bug middle-end/119033] [13/14/15 regression] Unsafe FRE of pointer assignment since r13-469-g9a53101caadae1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119033 Sam James changed: What|Removed |Added Summary|[13/14/15 regression] |[13/14/15 regression] |Unsafe FRE of pointer |Unsafe FRE of pointer |assignment |assignment since ||r13-469-g9a53101caadae1 --- Comment #1 from Sam James --- r13-469-g9a53101caadae1 but latent before I guess
[Bug c++/119034] Nested using-declaration doesn't do ADL or uses wrong associated namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119034 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=68942 --- Comment #4 from Andrew Pinski --- So the problem is not exactly an issue with ADL but rather an `overly strict use of deleted function before argument-dependent lookup`. That is if I take the original testcase and remove `delete` and change the return type to int for the function foo inside bar; GCC works. So this is another case of PR 68942.
[Bug middle-end/119033] [13/14/15 regression] Unsafe FRE of pointer assignment since r13-469-g9a53101caadae1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119033 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=93052 --- Comment #3 from Andrew Pinski --- Which means this is partly related to PR 93052.
[Bug middle-end/119033] [13/14/15 regression] Unsafe FRE of pointer assignment since r13-469-g9a53101caadae1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119033 --- Comment #2 from Andrew Pinski --- (In reply to Sam James from comment #1) > r13-469-g9a53101caadae1 but latent before I guess No I think that kinda of introdued it, it simplified `((size_t)a == (size_t)b) ? b : a` into just `a`: phiopt match-simplify trying: a.0_1 == b.1_2 ? &test.b[0] : a_7 Matching expression match.pd:161, gimple-match-10.cc:33 Matching expression match.pd:161, gimple-match-10.cc:33 Applying pattern match.pd:5297, gimple-match-2.cc:7854 Applying pattern match.pd:5436, gimple-match-2.cc:7977 Applying pattern match.pd:6377, gimple-match-10.cc:6173 phiopt match-simplify back: result: a_7
[Bug tree-optimization/118976] [12/13/14/15 regression] Correctness Issue: SVE vectorization results in data corruption when cpu has 128bit vectors but compiled with -mcpu=neoverse-v1 (which is only f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118976
--- Comment #14 from Andrew Pinski ---
(In reply to avieira from comment #13)
>
> the VECTOR_CST just goes over the elements in the VECTOR_CST and calls this
> recursively, making the change:
> --- a/gcc/fold-const.cc
> +++ b/gcc/fold-const.cc
> @@ -1964,7 +1964,7 @@ const_unop (enum tree_code code, tree type, tree arg0)
>if (TREE_CODE (arg0) == INTEGER_CST)
> return fold_not_const (arg0, type);
>else if (POLY_INT_CST_P (arg0))
> - return wide_int_to_tree (type, -poly_int_cst_value (arg0));
> + return wide_int_to_tree (type, ~poly_int_cst_value (arg0));
>/* Perform BIT_NOT_EXPR on each element individually. */
>else if (TREE_CODE (arg0) == VECTOR_CST)
> {
>
> fixes it for me.
>
> I'm going on holidays tomorrow, so I'll leave this for someone with a bit
> more time to pick up. Richard S it seems to have been your change in:
> https://gcc.gnu.org/git/?p=gcc.git;a=commit;
> h=36fd64086542ed734aded849304723218fa4d6fd so I'll wait for others to
> confirm my thinking here, I always get nervous around bit fiddling ;)
Yes that does look like the fix and it looks like obvious and looks like it was
just a typo.
Though I wonder if we could change fold_not_const to handle it instead. But
other than that looks correct.
[Bug target/118992] Redundant argument set up for call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118992 --- Comment #13 from Hongtao Liu --- (In reply to H.J. Lu from comment #11) > Created attachment 60590 [details] > A patch > > Can you try this on SPEC CPU? No big impact for both O2 and Ofast on SPEC2017.
[Bug rtl-optimization/119013] LoongArch and RISC-V: Redundant sign-extension after moving 32-bit values from FPR into 64-bit GPR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119013 Jeffrey A. Law changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2025-02-27 Status|UNCONFIRMED |NEW --- Comment #1 from Jeffrey A. Law --- The way we typically deal with these issues with rv64 is to create a DImode temporary and store the result in there. We then use a narrowing subreg to copy from the temporary to the ultimate destination. The narrowing subreg will have magic REG_PROMOTED_P bits set. That in turn allows removal of the explicit sign extension later. It's a bit awkward for a simple move pattern, but ought to still be doable.
[Bug gcov-profile/118442] -fprofile-generate wrongly adds instrumentation after musttail call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118442 --- Comment #6 from Andrew Pinski --- (In reply to Andrew Pinski from comment #5) > That comes from flow_call_edges_add, see gimple_flow_call_edges_add in > tree-cfg.cc Reading the comments in gimple_flow_call_edges_add is interesting because it looks like it was copied directly from the rtl version and we didn't insert the fake edge for tails calls back when the profiling was on the RTL.
[Bug fortran/118793] request NAMELIST reports of input errors indicate position of error and show line containing error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118793 --- Comment #2 from urbanjost at comcast dot net --- I can imagine that different parsing of the input might make this very difficult but might also be very straight-forward so was hoping for the best. With small inputs it is not too bad, but errors in input can be particularly difficult to find with no location provided when large input files are involved so even if the location is not available printing adjacent characters would be a significant improvement by itself.
[Bug middle-end/119021] [15 Regression] RTL checking ICEs after r15-7700
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119021 --- Comment #6 from Vladimir Makarov --- (In reply to Jakub Jelinek from comment #4) > Can't it just look at the present insn and if it is no longer asm but > NOTE_INSN_DELETED, ignore it? RA keep erroneous asm goto (for keeping CFG correctness), so it can not be deleted as regular asm. RA just removes operands from erroneous asm-goto. To avoid the loop in reporting (we introduced a new loop for pathological case of PR115458 and asm-goto now can be processed repeatedly) we need to invalidate some LRA internal (or cached) data and it was done not for all data. The patch I've just committed is now doing this.
[Bug middle-end/119021] [15 Regression] RTL checking ICEs after r15-7700
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119021 --- Comment #5 from GCC Commits --- The master branch has been updated by Vladimir Makarov : https://gcc.gnu.org/g:7ce3a8e872d945d537a7e7ba1bd3f45b1cf9a6d2 commit r15-7716-g7ce3a8e872d945d537a7e7ba1bd3f45b1cf9a6d2 Author: Vladimir N. Makarov Date: Wed Feb 26 11:28:08 2025 -0500 [PR119021][LRA]: Fix rtl correctness check failure in LRA. Patch to fix PR115458 contained a code change in dealing with asm errors to avoid cycling in reporting the error for asm gotos. This code was wrong and resulted in checking RTL correctness failure. This patch reverts the code change and solves cycling in asm error reporting in a different way. gcc/ChangeLog: PR middle-end/119021 * lra.cc (lra_asm_insn_error): Use lra_invalidate_insn_data instead of lra_update_insn_regno_info. * lra-assigns.cc (lra_split_hard_reg_for): Restore old code.
[Bug ipa/118318] [15 regression] ICE when building firefox-134.0 with PGO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118318 --- Comment #16 from Martin Jambor --- (In reply to Jan Hubicka from comment #13) > [...] > > Here are two calls to + and it is not clear which one triggers the ICE. > However sum += e->count.ipa (); quite obviously preserves the fact that sum > is an IPA count. So I think it is > > cs->count += desc->count > > which makes sense to me. dest->count is IPA count > if (cs->count.initialized_p ()) > desc->count += cs->count.ipa (); > > So I suppose what happens here is that we clone function with no profile > feedback available. This can happen in some cases, with profile mismatches > or with comdat merging. it is an incoming edge that has estimated profile, not the function. But yes. > > Martin, I think this is yours code, but I would say that if desc is IPA > count of 3694 while cs->count is locally estimated, we don't really have way > to add them together, so I would just skip the adjustment on > !cs->count.ipa_p () I think that the only thing we can do. I guess I should prepare a patch? > > However it is not clear to me how desc can be something non-zero in this > case? > From where the number comes? It is the difference between the count of the node and the sum of (ipa) counts of incoming edges, divided by the number of edges which have not yet been scaled. > > It is possible that we scaled down the profile from non-zero to 0 which > makes us to downgrade IPA profile to non-IPA, but in that case the updating > code attempts to do something fisly making call site within function with 0 > invocations to have non-zero count. > Yes, it might be because lenient_count_portion_handling kicked in.
[Bug tree-optimization/118953] [14/15 regression] Miscompile at -O2 since r14-2473-g602e824eec30a7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118953 --- Comment #5 from Jakub Jelinek --- So, I think this is incorrect handling of the masks/values during range union. As written earlier, we have # RANGE [irange] long long unsigned int [0, +INF] MASK 0xc000 VALUE 0x2d _3 = _2 + 18446744073708503085; and # RANGE [irange] long long unsigned int [0, +INF] MASK 0xc000 VALUE 0x59 _6 = (long long unsigned int) _5; # RANGE [irange] int [-INF, +INF] MASK 0xc000 VALUE 0x34 _7 = k_11 + -1048524; from ccp, those are correct. Now, when processing the PHI, we iterate over the PHI arguments, the first one is _3 and we figure out that to reach that edge _7 has to be 24 or 32 and as 0x34 - 0x2d is 7, that implies [irange] long long unsigned int [17, 17][25, 25] MASK 0xc000 VALUE 0x2d That is already in itself inconsistent, obviously when it has value of 17, then for the given MASK VALUE is 0x11 rather than 0x2d and for 25 the VALUE is 0x19. Anyway, the second PHI argument is 0, and union_ of [irange] long long unsigned int [17, 17][25, 25] MASK 0xc000 VALUE 0x2d and [irange] long long unsigned int [0, 0] results in incorrect [irange] long long unsigned int [0, 0][17, 17][25, 25] MASK 0xc000 VALUE 0x2d While the weird earlier range was perhaps ok because it was really from an unreachable edge, [0, 0] is from an reachable edge, so it should have adjusted the MASK and VALUE accordingly, so that 0 is a valid value there. And finally we union that with the [irange] long long unsigned int [45, 45] which is again questionable (the edge is unreachable though), 45 is 8 + 1048524 - 1048487 where 8 is the case value (the only one) and the two numbers are what is subtracted from k_11 to reach _7 and _6. MASK 0xc000 VALUE 0x59 is clearly ignored in that case. Anyway, we get [irange] long long unsigned int [0, 0][17, 17][25, 25][45, 45] MASK 0xc000 VALUE 0x2d and bet something later figures out that for this to be true, only [45, 45] is acceptable.
[Bug target/115458] [15 regression] [RISC-V] ICE in lra_split_hard_reg_for, at lra-assigns.cc:1868 unable to find a register to spill since r15-518-g99b1daae18c095
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115458 Jeffrey A. Law changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #20 from Jeffrey A. Law --- Should be resolved on the trunk. Thanks Vlad!
[Bug middle-end/119033] New: Unsafe FRE of pointer assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119033
Bug ID: 119033
Summary: Unsafe FRE of pointer assignment
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
Target Milestone: ---
The following (artificial) testcase (pointed to me by Filip Hejsek) is
miscompiled at -O2, since we miss the fact that test3(3) overwrites b[0].
#include
struct foo
{
int a[3];
int b[3];
};
void test2 (int *a);
__attribute__ ((noipa))
int test3 (int i)
{
struct foo test;
test.b[0]=1;
int *a = &test.a[i];
int *b = &test.b[0];
int *ptr = ((size_t)a == (size_t)b) ? b : a;
*ptr=2;
//test2 (ptr);
return test.b[0];
}
int main()
{
__builtin_printf ("%i %i\n",test3(0), test3(3));
return 0;
}
[Bug c++/112490] infinite meta error in reverse_iterator::iterator>>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112490
Chameleon changed:
What|Removed |Added
CC||gessos.paul at yahoo dot gr
--- Comment #4 from Chameleon ---
The same (14.2):
https://godbolt.org/z/MhM6Yqfo4
#include
#include
using namespace std;
template
struct permutated_iterator
{
Iter iter{};
constexpr permutated_iterator(Iter iter) noexcept : iter(iter) { }
constexpr bool operator==(const permutated_iterator& rhs) const noexcept {
return iter == rhs.iter; }
constexpr auto operator<=>(const permutated_iterator& rhs) const noexcept {
return iter <=> rhs.iter; }
};
int main()
{
using piter = unsigned int*;
using cpiter = std::basic_const_iterator ;
using iter1 = permutated_iterator ;
using iter2 = permutated_iterator>;
static_assert(std::totally_ordered);
static_assert(std::totally_ordered);
static_assert(std::totally_ordered);
static_assert(std::totally_ordered); // PROBLEM
// this is ok: iter2() == iter2()
// this is not ok: iter2() > iter2()
[Bug rtl-optimization/119002] [15 Regression] Comparison miscompilation on ppc64le and s390x since r15-6777
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119002 --- Comment #4 from GCC Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:40bf0770563501f4c6d7e92cdaa1fa361caa commit r15-7717-g40bf0770563501f4c6d7e92cdaa1fa361caa Author: Jakub Jelinek Date: Wed Feb 26 19:28:09 2025 +0100 arm: Fix up REVERSE_CONDITION macro [PR119002] The linaro CI found my PR119002 patch broke bootstrap on arm. Seems the problem is that it has incorrect REVERSE_CONDITION macro definition. All other target's REVERSE_CONDITION definitions and the default one just use the macro's arguments, while arm.h definition uses the MODE argument but uses code instead of CODE (the first argument). This happens to work because before my patch the only use of the macro was in jump.cc with /* First see if machine description supplies us way to reverse the comparison. Give it priority over everything else to allow machine description to do tricks. */ if (GET_MODE_CLASS (mode) == MODE_CC && REVERSIBLE_CC_MODE (mode)) return REVERSE_CONDITION (code, mode); but in my patch it is used with GT rather than code. 2025-02-26 Jakub Jelinek PR rtl-optimization/119002 * config/arm/arm.h (REVERSE_CONDITION): Use CODE - the macro argument - in the macro rather than code.
[Bug c/114870] [13/14/15 Regression] stddef.h problem with -Wsystem-headers and -std=gnu23 (which is the default since GCC 15)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114870
--- Comment #2 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:8d22474af76a386eed488b3c66124134f0e41363
commit r15-7718-g8d22474af76a386eed488b3c66124134f0e41363
Author: Jakub Jelinek
Date: Wed Feb 26 19:29:12 2025 +0100
c: stddef.h C23 fixes [PR114870]
The stddef.h header for C23 defines __STDC_VERSION_STDDEF_H__ and
unreachable macros multiple times in some cases.
The header doesn't have normal multiple inclusion guard, because it
supports
for glibc inclusion with __need_{size_t,wchar_t,ptrdiff_t,wint_t,NULL}.
While the definition of __STDC_VERSION_STDDEF_H__ and unreachable is done
solely in the #ifdef _STDDEF_H part, so they are defined only if stddef.h
is included without those __need_* macros defined. But actually once
stddef.h is included without the __need_* macros, _STDDEF_H is then defined
and while further stddef.h includes without __need_* macros don't do
anything:
#if (!defined(_STDDEF_H) && !defined(_STDDEF_H_) &&
!defined(_ANSI_STDDEF_H) \
&& !defined(__STDDEF_H__)) \
|| defined(__need_wchar_t) || defined(__need_size_t) \
|| defined(__need_ptrdiff_t) || defined(__need_NULL) \
|| defined(__need_wint_t)
if one includes whole stddef.h first and then stddef.h with some of the
__need_* macros defined, the #ifdef _STDDEF_H part is used again.
It isn't that big deal for most cases, as it uses extra guarding macros
like:
#ifndef _GCC_MAX_ALIGN_T
#define _GCC_MAX_ALIGN_T
...
#endif
etc., but for __STDC_VERSION_STDDEF_H__/unreachable nothing like that is
used.
So, either we do what the following patch does and just don't define
__STDC_VERSION_STDDEF_H__/unreachable second time, or use #ifndef
unreachable separately for the #define unreachable() case, or use
new _GCC_STDC_VERSION_STDDEF_H macro to guard this (or two, one for
__STDC_VERSION_STDDEF_H__ and one for unreachable), or rework the initial
condition to be just
#if !defined(_STDDEF_H) && !defined(_STDDEF_H_) &&
!defined(_ANSI_STDDEF_H) \
&& !defined(__STDDEF_H__)
- I really don't understand why the header should do anything at all after
it has been included once without __need_* macros. But changing how this
behaves after 35 years might be risky for various OS/libc combinations.
2025-02-26 Jakub Jelinek
PR c/114870
* ginclude/stddef.h (__STDC_VERSION_STDDEF_H__, unreachable): Don't
redefine multiple times if stddef.h is first included without
__need_*
defines and later with them. Move nullptr_t and unreachable and
__STDC_VERSION_STDDEF_H__ definitions into the same
defined (__STDC_VERSION__) && __STDC_VERSION__ > 201710L #if block.
* gcc.dg/c23-stddef-2.c: New test.
[Bug c/119001] [15 Regression] ICE: in output_constructor_regular_field, at varasm.cc:5833
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119001 --- Comment #7 from GCC Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:ad2908ed4ec5eff3cad3fd142cde5c1fac4788e9 commit r15-7719-gad2908ed4ec5eff3cad3fd142cde5c1fac4788e9 Author: Jakub Jelinek Date: Wed Feb 26 19:31:08 2025 +0100 c: Assorted fixes for flexible array members in unions [PR119001] r15-209 allowed flexible array members inside of unions, but as the following testcase shows, not everything has been adjusted for that. Unlike structures, in unions flexible array member (as an extension) can be any of the members, not just the last one, as in union all members are effectively last. The first hunk is about an ICE on the initialization of the FAM in union which is not the last FIELD_DECL with a string literal, the second hunk just formatting fix, third hunk fixes a bug in which we were just throwing away the initializers (except for with string literal) of FAMs in unions which aren't the last FIELD_DECL, and the last hunk is to diagnose FAM errors in unions the same as for structures, in particular trying to initialize a FAM with non-constant or initialization in nested context. 2025-02-26 Jakub Jelinek PR c/119001 gcc/ * varasm.cc (output_constructor_regular_field): Don't fail assertion if next is non-NULL and FIELD_DECL if TREE_CODE (local->type) is UNION_TYPE. gcc/c/ * c-typeck.cc (pop_init_level): Don't clear constructor_type if DECL_CHAIN of constructor_fields is NULL but p->type is UNION_TYPE. Formatting fix. (process_init_element): Diagnose non-static initialization of flexible array member in union or FAM in union initialization in nested context. gcc/testsuite/ * gcc.dg/pr119001-1.c: New test. * gcc.dg/pr119001-2.c: New test.
[Bug c/119001] [15 Regression] ICE: in output_constructor_regular_field, at varasm.cc:5833
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119001 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #8 from Jakub Jelinek --- Fixed.
[Bug c/114870] [13/14 Regression] stddef.h problem with -Wsystem-headers and -std=gnu23 (which is the default since GCC 15)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114870 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org CC||jakub at gcc dot gnu.org Summary|[13/14/15 Regression] |[13/14 Regression] stddef.h |stddef.h problem with |problem with |-Wsystem-headers and|-Wsystem-headers and |-std=gnu23 (which is the|-std=gnu23 (which is the |default since GCC 15) |default since GCC 15) Status|NEW |ASSIGNED --- Comment #3 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug c/119011] -Wsign-compare: Split it into several levels
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119011
--- Comment #13 from Alejandro Colomar ---
(In reply to Paul Eggert from comment #12)
> Plus, i + 1 == 0 does not necessarily work if time_t is 'unsigned short'
> (yes that'd be really weird for time_t, but ISO C and POSIX allow it and
> I try to write to the standards, and the problem has come up with other
> system types).
==-1 wouldn't work either for unsigned short. That's why we mentioned the
requirement that the variable should be of a type with rank no less than int.
With unsigned short, you first promote it to an int, since int can hold any
value of unsigned short, and it holds a USHRT_MAX, which is a small-ish
positive number, while -1 keeps being negative.
alx@debian:~/tmp$ cat ushrt.c
int
main(void)
{
unsigned short uh = -1;
if (uh == -1)
return 0;
return 1;
}
alx@debian:~/tmp$ gcc -Wall -Wextra ushrt.c
ushrt.c: In function ‘main’:
ushrt.c:6:16: warning: comparison is always false due to limited range of data
type [-Wtype-limits]
6 | if (uh == -1)
|^~
alx@debian:~/tmp$ ./a.out
alx@debian:~/tmp$ echo $?
1
Still, both working on the same cases, ==-1 is going to cause less mental
surprises.
[Bug fortran/108680] Wrong DTIO arguments with -fdefault-integer-8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108680 --- Comment #13 from anlauf at gcc dot gnu.org --- (In reply to kargls from comment #11) > If we're discussing derived-type IO, then it is clear from > Fortran 2023, 12.6.4.8.2, (see p. 255) that the unit number > has the default integer kind with the DT edit descriptor. Ah, yes, now I see it, too: "If the defined-io-generic-spec is ..., the characteristics shall be the same as those specified by the following interface:" for all variants. Thanks.
[Bug c/119011] -Wsign-compare: Split it into several levels
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119011 --- Comment #12 from Paul Eggert --- On 2/26/25 07:29, vincent-gcc at vinc17 dot net wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119011 > > --- Comment #11 from Vincent Lefèvre --- > (In reply to Alejandro Colomar from comment #10) > [about i + 1 == 0 instead of i == -1] >> But this causes readability issues. For error-handling, programmers are >> used to writing ==-1, and doing +1==0 would be significantly weird. Given >> that comparison ==-1 isn't unsafe in any way (given that the LHS is of rank >> no less than int), we should stop warning about it. > > OK. I completely agree. > Plus, i + 1 == 0 does not necessarily work if time_t is 'unsigned short' (yes that'd be really weird for time_t, but ISO C and POSIX allow it and I try to write to the standards, and the problem has come up with other system types).
[Bug c++/112490] infinite meta error in reverse_iterator::iterator>>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112490 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2025-02-26 --- Comment #5 from Patrick Palka --- (In reply to Barry Revzin from comment #3) > In this case, we're comparing two objects of type > wrapped> with <, so we should have two candidates: > > 1. wrapped's <=>, which has no constraints > 2. basic_const_iterator's friend operator<, which we start > instantiating with _It=int* and _It2=wrapped>. > > (2) requires checking if _It and _It2 can be ordered, which I think > recursively instantiates itself. > > Assuming that's correct (hopefully?), I think CWG 2369 should actually cause > this to be accepted - since wrapped> is not > convertible to basic_const_iterator, that should cause (2) to be > rejected before we even consider constraints since it's not viable. It's the other way around after CWG 2369 -- constraints must be checked checked _before_ non-dependent conversions. > > I have no idea what the public-ness of the member changes. Ah, that's because GCC 14 relaxed the CWG 2369 change for non-dependent conversions to/from an aggregate class, which we can safely check (and efficiently recognize) before checking constraints since doing so won't induce any template instantiations (and so won't change the semantics of valid code but will let us accept more code that's invalid after CWG 2369). Making the member public turns basic_const_iterator into an aggregate class, triggering the shortcut.
[Bug c/119011] -Wsign-compare: Split it into several levels
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119011 --- Comment #14 from Vincent Lefèvre --- (In reply to Jakub Jelinek from comment #4) > If you want to compare against all ones time_t, just use ~(time_t)0 or > similar. This one is a bad idea as it may have issues with signed types (when not in two's completed) but *also* on unsigned integer types of rank less than int. If you know the name of the type, say time_t, then just compare to (time_t)-1.
[Bug c/119011] -Wsign-compare: Split it into several levels
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119011 --- Comment #15 from Vincent Lefèvre --- (In reply to Vincent Lefèvre from comment #14) > (In reply to Jakub Jelinek from comment #4) > > If you want to compare against all ones time_t, just use ~(time_t)0 or > > similar. > > This one is a bad idea as it may have issues with signed types (when not in > two's completed) but *also* on unsigned integer types of rank less than int. ^ complement > If you know the name of the type, say time_t, then just compare to > (time_t)-1. Note: The context was that the name of the type was used in Jakub's proposal. I'm saying that this is an easy case to deal with correctly.
[Bug c++/112490] infinite meta error in reverse_iterator::iterator>>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112490 Patrick Palka changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #6 from Patrick Palka --- Created attachment 60595 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60595&action=edit library-side workaround The attached library-side workaround, which just encodes the non-dependent conversion to basic_const_iterator as another constraint, seems to fix the constraint recursion.
[Bug middle-end/119033] [13/14/15 regression] Unsafe FRE of pointer assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119033 Sam James changed: What|Removed |Added Keywords||wrong-code Target Milestone|--- |13.4 Summary|Unsafe FRE of pointer |[13/14/15 regression] |assignment |Unsafe FRE of pointer ||assignment
[Bug target/67771] integer-to-floating-point conversions wrongly produce -0 in FE_DOWNWARD mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67771 --- Comment #6 from John Paul Adrian Glaubitz --- (In reply to Joseph S. Myers from comment #5) > Various glibc functions work around this using FIX_INT_FP_CONVERT_ZERO, I > suppose the new log10f implementation taken from CORE-MATH needs such a > workaround as well. @Adhemerval: Do you think you could add such a workaround for 32-bit PowerPC?
[Bug fortran/108369] FM509 Fails to compile with error when using undocumented -x option
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108369 --- Comment #23 from Jerry DeLisle --- I have modified gcc.texi here to yield, after make info, the following pasted out of my terminal viewing with info: ‘-x LANGUAGE’ Specify explicitly the LANGUAGE for the following input files (rather than letting the compiler choose a default based on the file name suffix). This option applies to all following input files until the next ‘-x’ option. Possible values for LANGUAGE are: c c-header cpp-output c++ c++-header c++-system-header c++-user-header c++-cpp-output objective-c objective-c-header objective-c-cpp-output objective-c++ objective-c++-header objective-c++-cpp-output assembler assembler-with-cpp ada d f77 f77-cpp-input f95 f95-cpp-input go Note that ‘-x’ does not imply a particular language standard. For example ‘-x f77’ may also require ‘-std=legacy’ for some older source codes. ‘-x none’ Turn off any specification of a language, so that subsequent files are handled according to their file name suffixes (as they are if ‘-x’ has not been used at all). I think I will change that sentence in the parens for -x none while I am at it. It should simply be (as if '-x' has not been used at all).
[Bug c++/119020] Problem of constexpr static lambda and maybe GCC accepts invalid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119020 Andrew Pinski changed: What|Removed |Added Keywords||accepts-invalid --- Comment #1 from Andrew Pinski --- EDG accepts it. While MSVC rejects it for the same reason as clang.
[Bug c++/119020] Problem of constexpr static lambda and maybe GCC accepts invalid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119020 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=111923, ||https://github.com/cplusplu ||s/CWG/issues/449 --- Comment #2 from Andrew Pinski --- https://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#2852
[Bug c/119014] Extending _Float16 constant at compile and run time differs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119014 --- Comment #9 from Jakub Jelinek --- The reason for extended precision by default for _Float16 (and __bf16) on x86 (and most of other targets, I think RISC-V is an exception) is lack of hw support, same reason as for i387 extended precision. Either there are no instructions at all, or some conversion instructions, so without extended precision it means it is really slow, has to convert from float to _Float16 and back after every single arithmetic operation.
[Bug c/119014] Extending _Float16 constant at compile and run time differs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119014 --- Comment #10 from Andrew Pinski --- (In reply to Jakub Jelinek from comment #9) > The reason for extended precision by default for _Float16 (and __bf16) on > x86 (and most of other targets, I think RISC-V is an exception) is lack of > hw support, same reason as for i387 extended precision. Aarch64 has HW support just NOT with default armv8-a. armv8-a+fp16 will enable it. fp16 is also a requirement of armv9-a too.
[Bug fortran/108233] [Coarray] bcast to non-allocatable COMPLEX scalar coarray may generate wrong result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108233 --- Comment #2 from GCC Commits --- The master branch has been updated by Andre Vehreschild : https://gcc.gnu.org/g:751b37047b2ad3a358d41ac792487b42430e9901 commit r15-7712-g751b37047b2ad3a358d41ac792487b42430e9901 Author: Andre Vehreschild Date: Tue Feb 25 14:17:16 2025 +0100 Fortran: Remove SAVE_EXPR on lhs in assign [PR108233] With vectorial shaped datatypes like e.g. complex numbers, fold_convert inserts a SAVE_EXPR. Using that on the lhs in an assignment prevented the update of the variable, when in a coarray. PR fortran/108233 gcc/fortran/ChangeLog: * trans-expr.cc (gfc_trans_assignment_1): Remove SAVE_EXPR on lhs. gcc/testsuite/ChangeLog: * gfortran.dg/coarray/complex_1.f90: New test.
[Bug middle-end/119021] New: [15 Regression] RTL checking ICEs after r15-7700
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119021
Bug ID: 119021
Summary: [15 Regression] RTL checking ICEs after r15-7700
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
I'm seeing some RTL checking ICEs since
r15-7700-g2341f675edadd6370147d2bc55ca7761a7ecfaa1 :
+FAIL: gcc.target/i386/pr84876.c (internal compiler error: RTL check: expected
elt 3 type 'e' or 'u', have '0' (rtx note) in PATTERN, at rtl.h:1515)
+FAIL: gcc.target/i386/pr84876.c (test for excess errors)
+FAIL: gcc.target/i386/pr88414.c (internal compiler error: RTL check: expected
elt 3 type 'e' or 'u', have '0' (rtx note) in PATTERN, at rtl.h:1515)
+FAIL: gcc.target/i386/pr88414.c (test for excess errors)
on x86_64-linux and
+FAIL: gcc.target/i386/pr109137.c (internal compiler error: RTL check: expected
elt 3 type 'e' or 'u', have '0' (rtx note) in PATTERN, at rtl.h:1515)
+FAIL: gcc.target/i386/pr109137.c (test for excess errors)
+FAIL: gcc.target/i386/pr88414.c (internal compiler error: RTL check: expected
elt 3 type 'e' or 'u', have '0' (rtx note) in PATTERN, at rtl.h:1515)
+FAIL: gcc.target/i386/pr88414.c (test for excess errors)
on i686-linux.
All these tests have in common are inline asms that are impossible to reload,
so gcc emits
error: ‘asm’ operand has impossible constraints or there are not enough
registers
diagnostics and turns the inline asm into NOTE_INSN_DELETED note.
The ICE is then in lra_split_hard_reg_for
1858lra_asm_insn_error (insn);
1859if (JUMP_P (insn))
1860 ira_nullify_asm_goto (insn);
1861else
1862 PATTERN (insn) = gen_rtx_USE (VOIDmode, const0_rtx);
where lra_asm_insn_error does emit that error and
/* Avoid further trouble with this insn. */
if (JUMP_P (insn))
{
ira_nullify_asm_goto (insn);
lra_update_insn_regno_info (insn);
}
else
{
PATTERN (insn) = gen_rtx_USE (VOIDmode, const0_rtx);
lra_set_insn_deleted (insn);
}
so I fail to see the point of the lines 1859-1862 because it is already
nullified or pattern changed and insn deleted.
[Bug middle-end/119015] [14/15 Regression] g++ -O2 uses huge amounts of time and memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119015 --- Comment #3 from Adrian Bunk --- (In reply to Richard Biener from comment #1) > given -Os isn't affected this is likely triggered by inlining (-fno-inline > brings down compile-time again). I can confirm that this is the case on armhf (~ 20% time increase -Os -> -O2 -fno-inline).
[Bug c++/119027] New: Problem of 'case' statement not in switch statement and maybe gcc 10 accepts invalid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119027
Bug ID: 119027
Summary: Problem of 'case' statement not in switch statement
and maybe gcc 10 accepts invalid
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: qurong at ios dot ac.cn
Target Milestone: ---
For this program:
template < typename T > void f(int i) {
switch (i) if constexpr (false) {
case 42:;
}
}
int main() {
int a = 9;
f (a);
return 0;
}
This causes an error in clang and msvc, but gcc didn't report the error.
Compiler Explorer link: https://godbolt.org/z/KhKqbqePv
[Bug middle-end/108448] GCC Elides Assignment to Pointer and memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108448
Sam James changed:
What|Removed |Added
Keywords|needs-reduction |
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #20 from Sam James ---
This reduces to:
```
int a;
void abort();
_Bool y_map_existsStringKey_v() __attribute__((pure));
_Bool y_map_existsStringKey_v(int *m, char *, void *val_ptr) {
char **b = val_ptr;
*b = m;
return 1;
}
void pthread_getspecific();
void y_assert_fail() { abort(); }
void main() {
int *stack = 0;
pthread_getspecific();
if (y_map_existsStringKey_v(&a, 0, &stack))
stack || (y_assert_fail(), 0);
}
```
y_map_existsStringKey_v is NOT a candidate for pure, as it has side-effects (it
modifies val_ptr). Indeed, dropping the pure attribute from
y_map_existsStringKey_v on the original fixes it too.
[Bug tree-optimization/118976] [12/13/14/15 regression] Correctness Issue: SVE vectorization results in data corruption when cpu has 128bit vectors but compiled with -mcpu=neoverse-v1 (which is only f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118976
avieira at gcc dot gnu.org changed:
What|Removed |Added
CC||avieira at gcc dot gnu.org
--- Comment #13 from avieira at gcc dot gnu.org ---
Looked a bit into this and fre4 takes:
_30 = { POLY_INT_CST [4, 4], POLY_INT_CST [5, 4], POLY_INT_CST [6, 4], ... };
...
vect__3.13_46 = ~_30;
and simplifies that ~_30 to a constant:
{ POLY_INT_CST [-4, -4], POLY_INT_CST [-5, -4], POLY_INT_CST [-6, -4], ... }
Which seems wrong to me, as ~(4) = -5, not -4
looking at const_binop in fold-const.cc I see:
case BIT_NOT_EXPR:
if (TREE_CODE (arg0) == INTEGER_CST)
return fold_not_const (arg0, type);
else if (POLY_INT_CST_P (arg0))
return wide_int_to_tree (type, -poly_int_cst_value (arg0));
/* Perform BIT_NOT_EXPR on each element individually. */
else if (TREE_CODE (arg0) == VECTOR_CST)
...
the VECTOR_CST just goes over the elements in the VECTOR_CST and calls this
recursively, making the change:
--- a/gcc/fold-const.cc
+++ b/gcc/fold-const.cc
@@ -1964,7 +1964,7 @@ const_unop (enum tree_code code, tree type, tree arg0)
if (TREE_CODE (arg0) == INTEGER_CST)
return fold_not_const (arg0, type);
else if (POLY_INT_CST_P (arg0))
- return wide_int_to_tree (type, -poly_int_cst_value (arg0));
+ return wide_int_to_tree (type, ~poly_int_cst_value (arg0));
/* Perform BIT_NOT_EXPR on each element individually. */
else if (TREE_CODE (arg0) == VECTOR_CST)
{
fixes it for me.
I'm going on holidays tomorrow, so I'll leave this for someone with a bit more
time to pick up. Richard S it seems to have been your change in:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=36fd64086542ed734aded849304723218fa4d6fd
so I'll wait for others to confirm my thinking here, I always get nervous
around bit fiddling ;)
[Bug libstdc++/100795] ranges::sample should not use std::sample directly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100795 Jonathan Wakely changed: What|Removed |Added CC||curdeius at gmail dot com --- Comment #13 from Jonathan Wakely --- *** Bug 119022 has been marked as a duplicate of this bug. ***
[Bug libstdc++/119022] ranges::inplace_merge should check for iterator_concept, not iterator_category
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119022 康桓瑋 changed: What|Removed |Added CC||hewillk at gmail dot com --- Comment #2 from 康桓瑋 --- (In reply to Jonathan Wakely from comment #1) > (In reply to Curdeius Curdeius from comment #0) > > Related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100070 > > > > It's related to the above bug report, but it concerns algorithms, an example > > is std::ranges::inplace_merge. > > Bug 100070 is also about algorithms, and already mentions > ranges::inplace_merge. > > *** This bug has been marked as a duplicate of bug 100070 *** I assume you mean PR100795.
[Bug libstdc++/119022] ranges::inplace_merge should check for iterator_concept, not iterator_category
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119022 --- Comment #3 from Jonathan Wakely --- Yes, sorry, I was confusing 100070 with Bug 100795 (which depends on 100070). 100795 is about algorithms and already mentions inplace_merge. *** This bug has been marked as a duplicate of bug 100795 ***
