https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109884
Bug ID: 109884
Summary: __builtin_Xq returns _Float128 instead of __float128
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109874
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109884
--- Comment #1 from Andrew Pinski ---
I think this is expected behavior now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109877
Richard Biener changed:
What|Removed |Added
Target||*-darwin
Version|unknown
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109884
--- Comment #2 from Andrew Pinski ---
_Float128 is the standard specified way of defining these types in c++23 IIRC.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109712
--- Comment #9 from Richard Biener ---
Yes, using a newer libgcc_s.so.1 or libstdc++.so.6 should work fine - again,
unless we end up with mixing static/dynamic parts of the unwinder of different
versions.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109884
--- Comment #3 from g.peterh...@t-online.de ---
But these are different types (even if they are mathematically/behaviorally
equivalent)
std::is_same_v --> false
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109884
--- Comment #4 from Andrew Pinski ---
OK. And?
Q specifies the _Float128 type now.
I don't think we had any abi guarantees on the builtins nor on the q literals.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109884
--- Comment #5 from Jonathan Wakely ---
This changed with r13-2887 when adding _Float128 to C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989
--- Comment #41 from Richard Biener ---
(In reply to Jakub Jelinek from comment #40)
> Created attachment 55094 [details]
> gcc14-bitint-wip.patch
>
> So, on IRC we've agreed with Richi that given the limits we have in the
> compiler
> (what wi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109805
--- Comment #13 from rguenther at suse dot de ---
On Tue, 16 May 2023, sergiodj at sergiodj dot net wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109805
>
> --- Comment #12 from Sergio Durigan Junior ---
> Sorry, I have been busy with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109877
--- Comment #8 from Iain Sandoe ---
(In reply to Richard Biener from comment #7)
> can we fixinclude the headers?
1. not yet (PR105719) - although let us hope we can find a way to do that for
more limited cases (I've implemented the consumer co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109885
Bug ID: 109885
Summary: gcc does not generate movmskps and testps instructions
(clang does)
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109885
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
Component|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100052
--- Comment #13 from Jiu Fu Guo ---
Pass on trunk, gcc-12, gcc-11 for xtreme-header-* cases:
make check-gcc-c++ RUNTESTFLAGS="--target_board=unix'{-m64}'
modules.exp=xtreme-header-*"
=== g++ Summary ===
# of expected passes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101853
--- Comment #14 from Jiu Fu Guo ---
Pass on trunk, gcc-12, gcc-11 for xtreme-header-* cases:
make check-gcc-c++ RUNTESTFLAGS="--target_board=unix'{-m64}'
modules.exp=xtreme-header-*"
=== g++ Summary ===
# of expected passes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109868
--- Comment #16 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:78327cf06e6b65fc9c614622c98f6a3f3bfb7784
commit r14-927-g78327cf06e6b65fc9c614622c98f6a3f3bfb7784
Author: Jakub Jelinek
Date: W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109882
--- Comment #5 from Jonathan Wakely ---
Libstdc++ itself does this:
#if __SANITIZE_THREAD__
# define _GLIBCXX_TSAN 1
#elif defined __has_feature
# if __has_feature(thread_sanitizer)
# define _GLIBCXX_TSAN 1
# endif
#endif
The sanitizers coul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109882
--- Comment #6 from Jakub Jelinek ---
Looks ok to me. Now how to convince upstream to apply this? (Or we could keep
it as LOCAL_PATCHES.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109884
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109811
Jan Hubicka changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
Ever confi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109759
Martin Jambor changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109788
--- Comment #13 from Martin Jambor ---
*** Bug 109759 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63426
Bug 63426 depends on bug 109759, which changed state.
Bug 109759 Summary: UBSAN error: shift exponent 64 is too large for 64-bit type
'long unsigned int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109759
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109886
Bug ID: 109886
Summary: UBSAN error: shift exponent 64 is too large for 64-bit
type when compiling gcc.c-torture/compile/pr96796.c
Product: gcc
Version: 14.0
Status: UNC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109887
Bug ID: 109887
Summary: Different mangled name for template specialization for
clang and gcc
Product: gcc
Version: 12.3.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109884
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109884
--- Comment #8 from Jakub Jelinek ---
(In reply to Andrew Pinski from comment #4)
> Q specifies the _Float128 type now.
No, Q suffix specifies __float128 actually. F128 or f128 specify _Float128.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109811
--- Comment #5 from Jan Hubicka ---
Also forgot to mention, I used zen3 machine. So Raptor lake is not necessary.
Note that build systems appends -O2 after any CFLAGS specified, so it really is
-O2 build:
# Force build with optimizations in re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109875
--- Comment #1 from Tobias Burnus ---
Tested it now also with true offloading.
For AMD GCN, I get:
host: max_teams: 2
tgt: max_teams: 3
num_teams: 120
For nvptx, I get:
host: max_teams: 2
tgt: max_teams: 3
num_teams: 240
And for c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109875
--- Comment #2 from Tobias Burnus ---
The host-fallback explicitly sets the number of teams to the lower_bound,
if available, and otherwise to 1 - which is fine.
Regarding changing the default from 0 to the actually used number,
the problem is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109883
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
--- Comment #1 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109883
Xi Ruoyao changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109887
--- Comment #1 from Jonathan Wakely ---
(In reply to Chuanqi Xu from comment #0)
> _ZNK1n1S3getIbEENSt9enable_ifIXsrSt11is_integralIT_E5valueEN4llvm8OptionalIS4
> _EEE4typeENS6_9StringRefE
> ```
>
> and clang will mangle it as:
>
> ```
> _ZNK1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97048
--- Comment #3 from Tony Guilfoyle ---
I jumped through enough hoops already, I think. You can take it from
here if you want.
All the best,
Tony
On 16/05/2023 18:28, redi at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109888
Bug ID: 109888
Summary: GCC 13 Fails to Compile Code with Explicit Constructor
for std::array in Template Class
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109887
--- Comment #2 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #1)
> Clang mangles it as 3std::is_integral.
Oops, I mean 3std11is_integral of course.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109887
--- Comment #3 from Jakub Jelinek ---
So, simpler testcase would be
#include
template
std::enable_if_t ::value, int>
foo() { return 0; }
int a = foo ();
GCC mangles this as
_Z3fooIiENSt9enable_ifIXsrSt11is_integralIT_E5valueEiE4typeEv
while
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109888
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109247
Jonathan Wakely changed:
What|Removed |Added
CC||vincent.lebourlot@starqube.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109889
Bug ID: 109889
Summary: [13/14 Regression] Segfault in __run_exit_handlers
since r13-5309-gc3c6c307792026
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109889
--- Comment #1 from Jonathan Wakely ---
Tulio found out that __gnu_debug::_Safe_iterator_base::_M_reset() is
overwriting the stack where r2 (TOC pointer) was saved by __run_exit_handlers()
(at address 0x7fffe8e8). This function was calle
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109889
--- Comment #2 from Jakub Jelinek ---
r2 is the toc pointer, so having it 0 is weird.
Looking at glibc-2.36-10.fc37 (not sure if you are using a different one), I
see
0005b560 <__run_exit_handlers>:
5b560: 21 00 4c 3c addis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109889
--- Comment #3 from Jonathan Wakely ---
I wonder if we have a static destructor ordering problem.
The libstdc++ test code uses a local static std::map, which will be
constructed on first use and destroyed on exit. When built with
-D_GLIBCXX_DE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109889
--- Comment #4 from Jonathan Wakely ---
(In reply to Jakub Jelinek from comment #2)
> r2 is the toc pointer, so having it 0 is weird.
> Looking at glibc-2.36-10.fc37 (not sure if you are using a different one), I
glibc-2.36-9.fc37.ppc64le
> se
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109882
--- Comment #7 from Jonathan Wakely ---
I'll do a little more testing and submit it upstream.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109883
--- Comment #2 from Matt Borland ---
(In reply to Xi Ruoyao from comment #1)
> Cannot reproduce for me. Note that in this case GCC optimizes the entire
> function call away (see https://godbolt.org/z/968bPTvh9) even with -O0 so I
> can see no w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109883
Xi Ruoyao changed:
What|Removed |Added
Known to fail||13.1.0, 14.0
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109883
--- Comment #4 from Xi Ruoyao ---
It seems the function
__gnu_cxx::__promote_2::__value>::__type)(0))+((__gnu_cxx::__promote_2<_Float64,
std::__is_integer<_Float64>::__value>::__type)(0))), std::__is_integer::__value>::__type)(0))+((__gnu_cxx::
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109811
--- Comment #6 from Jan Hubicka ---
hottest loop in clang's profile is:
for (size_t y = 0; y < opsin.ysize(); y++) {
for (size_t x = 0; x < opsin.xsize(); x++) {
if (is_background_row[y * is_background_stride + x]) continue;
cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109883
--- Comment #5 from Xi Ruoyao ---
1203
<_ZSt3powIDF64_DF64_EN9__gnu_cxx11__promote_2IDTplcvNS1_IT_XsrSt12__is_integerIS2_E7__valueEE6__typeELi0EcvNS1_IT0_XsrS3_IS7_E7__valueEE6__typeELi0EEXsrS3_ISB_E7__valueEE6__typeES2_S7_>:
120
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109883
--- Comment #6 from Matt Borland ---
(In reply to Xi Ruoyao from comment #4)
> It seems the function
>
> __gnu_cxx::__promote_2 std::__is_integer<_Float64>::__value>::__type)(0))+((__gnu_cxx::
> __promote_2<_Float64, std::__is_integer<_Float64>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109883
--- Comment #7 from Jakub Jelinek ---
I think we need to move those __promote_{2,3} using templates for atan2, fmod,
pow, copysign, fdim, fmax, fmin, hypot, nextafter, remainder, remquo and fma
later, because right now we have the overloads with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109532
--- Comment #7 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:d8a656d5b6246457e84934bc35115c134bc38def
commit r14-932-gd8a656d5b6246457e84934bc35115c134bc38def
Author: Jonathan Wakely
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109883
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100052
--- Comment #14 from seurer at gcc dot gnu.org ---
The failures occur erratically so one clean run doesn't mean much. Scanning
the test results mailing list I see failures for this just today in trunk.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98202
--- Comment #5 from Jonathan Wakely ---
Q can't be used with -std=c++NN strict modes, as noted in bug 87274
limits:2085: error: unable to find numeric literal operator 'operator""Q'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109890
Bug ID: 109890
Summary: vector's constructor doesn't start object lifetimes
during constant evaluation
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109532
--- Comment #8 from Jonathan Wakely ---
I've updated the docs to make this clear.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109811
JuzheZhong changed:
What|Removed |Added
CC||juzhe.zhong at rivai dot ai
--- Comment #7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109811
--- Comment #8 from Jan Hubicka ---
Created attachment 55101
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55101&action=edit
hottest loop
jpegxl build machinery adds -fno-vectorize and -fno-slp-vectorize to clang
flags. Adding -fno-tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109890
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109811
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109891
Bug ID: 109891
Summary: Null pointer special handling in ostream's operator <<
for C-strings
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109883
Jakub Jelinek changed:
What|Removed |Added
Attachment #55100|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109891
--- Comment #1 from Jonathan Wakely ---
Adding more UB to the library doesn't seem wise.
We could make it abort in debug mode, instead of setting badbit, but I don't
think we should just make it UB.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109891
--- Comment #2 from Jonathan Wakely ---
--- a/libstdc++-v3/include/bits/ostream.tcc
+++ b/libstdc++-v3/include/bits/ostream.tcc
@@ -306,6 +306,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
basic_ostream<_CharT, _Traits>&
operator<<(basic_ostre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109892
Bug ID: 109892
Summary: SLP failure with explicit fma
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109684
Mianzhi Wang changed:
What|Removed |Added
Attachment #54964|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97340
Patrick Palka changed:
What|Removed |Added
Keywords||rejects-valid
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46906
--- Comment #13 from Jonathan Wakely ---
This seems related to https://cplusplus.github.io/LWG/issue2366 and the changes
I'm proposing there.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109858
--- Comment #10 from Segher Boessenkool ---
(In reply to Hongtao.liu from comment #8)
> (In reply to Segher Boessenkool from comment #7)
> > > The patch will still use GENERAL_REGS when hard_regno_mode_ok for mode and
> > > GENERAL_REGS(which is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109885
--- Comment #1 from Andrew Pinski ---
Just FYI, GCC does better on aarch64 with sum.
GCC:
ldp q29, q30, [x0]
moviv31.4s, 0x1
fcmeq v29.4s, v29.4s, 0
fcmeq v30.4s, v30.4s, 0
and v31.16b, v31
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109849
Jan Hubicka changed:
What|Removed |Added
Blocks||109811
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109811
--- Comment #10 from Jan Hubicka ---
Actually vectorization hurts on both compilers and bit more with clang.
It seems that all important loops are hand vectorized and since register
pressure is a problem, vectorizing other loops causes enough of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106900
--- Comment #6 from CVS Commits ---
The trunk branch has been updated by Andrew Pinski :
https://gcc.gnu.org/g:f65af1eeef670f2c249b1896726ef57bbf65fe2f
commit r14-937-gf65af1eeef670f2c249b1896726ef57bbf65fe2f
Author: Andrew Pinski
Date: Tue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109570
--- Comment #5 from Christophe Lyon ---
Not sure how to update/fix the testcases though?
Since they get the declaration of fclose from stdio.h, we'd need to make
dg-error conditional to the glibc version in use, which seems unpractical.
Should
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109889
--- Comment #5 from Tulio Magno Quites Machado Filho ---
(In reply to Jonathan Wakely from comment #3)
> I wonder if we have a static destructor ordering problem.
I'm afraid the issue is happening earlier, when these iterators are being
initial
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106900
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |FIXED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456
Bug 56456 depends on bug 106900, which changed state.
Bug 106900 Summary: Regression after memchr optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106900
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109889
--- Comment #6 from Tulio Magno Quites Machado Filho ---
Let me elaborate my previous comment...
When initializing the object at 0x100414c8, one of its members points to an
address in the stack (0x7fffe8f8).
All these functions return and wh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109891
--- Comment #3 from Michel Morin ---
>From the safety point of view, I agree with you. But, at the same time, I
thought that detectable UB (with the help of sanitizers) is useful than silent
bug.
How about `throw`ing as in std::string's constr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109891
--- Comment #4 from Andrew Pinski ---
IIRC this was to added to be similar to glibc's nullptr handling for %s:
printf("xyza %s\n", nullptr);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109570
--- Comment #6 from Xi Ruoyao ---
(In reply to Christophe Lyon from comment #5)
> Not sure how to update/fix the testcases though?
> Since they get the declaration of fclose from stdio.h, we'd need to make
> dg-error conditional to the glibc ver
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109893
Bug ID: 109893
Summary: [14 Regression] Missed Dead Code Elimination when
using __builtin_unreachable since
r14-160-gf828503eeb79ad1f1ada6db7deccc5abcc2f3ca3
Product: gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109893
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109892
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109885
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90663
Andrew Pinski changed:
What|Removed |Added
Status|ASSIGNED|NEW
Assignee|pinskia at gcc do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109889
--- Comment #7 from Jonathan Wakely ---
When the function returns the iterator's destructor should detach itself from
the sequence's list of iterators, so that it doesn't outlive the stack frame
containing the iterator.
The commit that caused t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109889
--- Comment #8 from Jonathan Wakely ---
With -std=c++14 there's no crash, with -std=c++17, so that confirms it's
something related to copy elision.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109889
--- Comment #9 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #8)
> With -std=c++14 there's no crash, with -std=c++17,
Should have said "only with -std=c++17" (and later, of course).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109889
--- Comment #10 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #9)
> Should have said "only with -std=c++17" (and later, of course).
Actually, that's wrong, *only* with C++17, not earlier *or* later.
So the further changes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109894
Bug ID: 109894
Summary: WriteInt in the ISO libraries should not emit the '+'
when writing positive values
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Sever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109894
Gaius Mulley changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109894
Gaius Mulley changed:
What|Removed |Added
CC||gaius at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109894
Gaius Mulley changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109865
GARY.WHITE at ColoState dot edu changed:
What|Removed |Added
Resolution|--- |FIXED
Sta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109891
--- Comment #5 from Jonathan Wakely ---
(In reply to Michel Morin from comment #3)
> From the safety point of view, I agree with you. But, at the same time, I
> thought that detectable UB (with the help of sanitizers) is useful than
> silent bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109865
Andrew Pinski changed:
What|Removed |Added
Resolution|FIXED |INVALID
--- Comment #17 from Andrew Pin
1 - 100 of 199 matches
Mail list logo
