https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108245
Andrew Pinski changed:
What|Removed |Added
CC||lyubomir.filipov at amusnet
dot co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108302
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108302
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2023-01-06
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105656
Andrew Pinski changed:
What|Removed |Added
Keywords||internal-improvement
Last reconfirmed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108312
Bug ID: 108312
Summary: NULL definition in system.h is no longer needed any
more
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: internal-improvement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108311
Bug ID: 108311
Summary: system.h defines va_copy but we require C++11 compiler
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: internal-improvement
Severity: no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108300
Andrew Pinski changed:
What|Removed |Added
Component|bootstrap |middle-end
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100825
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108303
--- Comment #2 from Andrew Pinski ---
(In reply to Jonathan Wakely from comment #1)
> Currently we don't mangle requirements, so the foos all mangle the same and
> actually instantiating #1 will break, but for now we can test that they're
> cons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108309
--- Comment #4 from Andrew Pinski ---
(In reply to tim blechmann from comment #3)
> > That is a conditionally supported construct in C++. clang does not support
> > it but GCC does.
> >
> > GCC does warn with -Wconditionally-supported
>
> in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108306
--- Comment #4 from Andrew Pinski ---
The documentation now has:
Note that sanitizers tend to increase the rate of false positive
warnings, most notably those around @option{-Wmaybe-uninitialized}.
We recommend against combining @option{-Werror}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108309
--- Comment #3 from tim blechmann ---
> That is a conditionally supported construct in C++. clang does not support it
> but GCC does.
>
> GCC does warn with -Wconditionally-supported
interesting. i may have to reduce it manually rather than
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108308
Andrew Pinski changed:
What|Removed |Added
Version|unknown |13.0
Summary|wrong code at -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108309
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |12.3
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108294
Gaius Mulley changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108310
Eric Gallager changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102824
--- Comment #6 from Eric Gallager ---
@marxin is this something you checked during the sphinx conversion and
reversion at all?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103210
--- Comment #5 from Eric Gallager ---
Downstream version of this issue:
https://github.com/cooljeanius/apple-gdb-1824/issues/9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108310
Eric Gallager changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108310
Bug ID: 108310
Summary: Some warnings that -Wtraditional-conversion causes to
be emitted aren't actually controlled by it
Product: gcc
Version: 12.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108309
--- Comment #1 from tim blechmann ---
Created attachment 54200
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54200&action=edit
reduced test case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108309
Bug ID: 108309
Summary: ICE in in cxx_eval_component_reference, at
cp/constexpr.cc:4136
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108225
--- Comment #14 from Jonathan Wakely ---
And it isn't specific to Canadian cross compilation either. It happens for any
build with the latest mingw-w64 headers, both native and cross. And that has
nothing to do with std::mutex, which is the subj
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108225
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108225
--- Comment #12 from cqwrteur ---
(In reply to cqwrteur from comment #11)
> The problem is that it breaks gcc build too. GCC won't build any more due to
> macro pollution of __FILE__
x86_64-w64-mingw32/artifacts/hostbuild/x86_64-w64-mingw32/gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108225
cqwrteur changed:
What|Removed |Added
Status|RESOLVED|NEW
Resolution|WONTFIX
ecking=yes --prefix=/local/suz-local/software/local/gcc-trunk
--enable-sanitizers --enable-languages=c,c++ --disable-werror --enable-multilib
--with-system-zlib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 13.0.0 20230105 (experimental) [master r13-5035-g4413365616e] (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108307
Bug ID: 108307
Summary: ICE compiling .S file with
-fdiagnostics-format=sarif-file
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: diagnostic, ice-on-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77691
John David Anglin changed:
What|Removed |Added
Last reconfirmed|2016-09-22 00:00:00 |2023-1-5
--- Comment #53 from John D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108306
Kees Cook changed:
What|Removed |Added
Attachment #54198|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108261
--- Comment #6 from Iain Sandoe ---
and another datum (on x86_64linux):
$ ../gcc-13-0-0p/bin/gm2
/home/iains/gcc-master/src-patched/gcc/testsuite/gm2/coroutines/pim/run/pass/testiotransfer.mod
-flibs=cor,iso,pim -o tio -O
$ LD_LIBRARY_PATH=../
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108306
--- Comment #2 from Kees Cook ---
Ugh, sorry. The PoC is bad -- the bounds check isn't present. Let me try to get
a another PoC.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108306
Kees Cook changed:
What|Removed |Added
CC||arnd at linaro dot org,
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108306
Bug ID: 108306
Summary: false-positive -Warray-bounds warning emitted with
-fsanitize=shift
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108292
Roger Sayle changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108292
--- Comment #14 from Roger Sayle ---
Created attachment 54197
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54197&action=edit
Related optimizations to ix86_expand_int_movcc.
Just for the record, here is a related patch that I was working
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108297
--- Comment #3 from Ian Lance Taylor ---
Created attachment 54196
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54196&action=edit
Potential patch
Does this patch fix the problem for you? Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108305
Bug ID: 108305
Summary: FAIL: 27_io/basic_ofstream/open/char/noreplace.cc
execution test
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108292
--- Comment #13 from H.J. Lu ---
I also got
$ cat foo.i
extern void foo (float *);
extern int x;
int
mouse_frame_side(void) {
float mouseloc;
foo (&mouseloc);
return mouseloc > x ? 1 : 2;
}
$ gcc -march=alderlake -Ofast -S foo.i
during R
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108292
--- Comment #12 from CVS Commits ---
The master branch has been updated by Roger Sayle :
https://gcc.gnu.org/g:9e6ac747ac5cff9e3f58421cdd9f03538e48ed07
commit r13-5038-g9e6ac747ac5cff9e3f58421cdd9f03538e48ed07
Author: Roger Sayle
Date: Thu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108297
--- Comment #2 from dave.anglin at bell dot net ---
On 2023-01-05 2:23 p.m., ian at airs dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108297
>
> Ian Lance Taylor changed:
>
> What|Removed |Add
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108292
--- Comment #11 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #10)
> (In reply to Roger Sayle from comment #8)
> > Here's my proposed patch (or something close to it, it's still bootstrapping
> > and regression testing). The goal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108275
Patrick Palka changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot
gnu.org
Tar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108297
Ian Lance Taylor changed:
What|Removed |Added
CC||ian at airs dot com
--- Comment #1 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108275
--- Comment #2 from CVS Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:12b0d35ec52375da5652d2b8da74083ab700b9d7
commit r13-5037-g12b0d35ec52375da5652d2b8da74083ab700b9d7
Author: Patrick Palka
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108292
--- Comment #10 from Jakub Jelinek ---
(In reply to Roger Sayle from comment #8)
> Created attachment 54195 [details]
> Roger's proposed patch
>
> Here's my proposed patch (or something close to it, it's still bootstrapping
> and regression tes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108292
--- Comment #9 from Roger Sayle ---
Another way to avoid the SCALAR_FLOAT_MODE_P problem is:
/* Add a REG_EQUAL note to allow condition to be shared. */
rtx note = gen_rtx_fmt_ee (orig_code, mode, op0, op1);
/* TMP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108304
Bug ID: 108304
Summary: FAIL: 20_util/from_chars/4.cc execution test
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108292
--- Comment #8 from Roger Sayle ---
Created attachment 54195
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54195&action=edit
Roger's proposed patch
Here's my proposed patch (or something close to it, it's still bootstrapping
and regressi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108288
--- Comment #8 from Simon Marchi ---
I tested with just patching my /usr/include, and it looks like it works fine,
I'm able to run a program under my GDB. Removing the fix, I get back the hang.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108303
Jonathan Wakely changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108288
--- Comment #7 from Jonathan Wakely ---
__gnu_debug::_Safe_iterator_base::_M_detach in debug.cc isn't affected by the
patch though.
The fix is to the post-inc and post-dec members, so only the code that calls
those needs to be recompiled.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108288
--- Comment #6 from Simon Marchi ---
Because some code trying to acquire the lock (see frame #7 in my backtrace) is
in debug.cc, I thought it would maybe need to be changed too? But I don't
really understand any of this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108292
--- Comment #7 from Jakub Jelinek ---
Or for now don't add any REG_EQUAL note if op0 has scalar floating point
mode...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108292
--- Comment #6 from Jakub Jelinek ---
So I wonder about:
--- gcc/config/i386/i386-expand.cc.jj 2023-01-04 10:45:49.978883731 +0100
+++ gcc/config/i386/i386-expand.cc 2023-01-05 18:22:40.228518935 +0100
@@ -3271,10 +3271,12 @@ ix86_expand_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108303
Bug ID: 108303
Summary: lookup failes with requires clause on non-template
friend function of a class template
Product: gcc
Version: 13.0
Status: UNCONFIRMED
S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108288
--- Comment #5 from Jonathan Wakely ---
The patch doesn't change libstdc++.so, it only changes the headers.
You don't even need to rebuild GCC. You could just put a patched copy of
safe_iterator.h in /tmp/x/debug and then compile with -I/tmp/x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108292
--- Comment #5 from Jakub Jelinek ---
Though, it seems the REG_EQUAL note is also wrong on the cmov10.c testcase
which went with the commit (again, exact opposite).
Seems we have multiple cases where this REG_EQUAL note is newly added.
One is x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108292
Roger Sayle changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |roger at
nextmovesoftware dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108298
--- Comment #5 from Segher Boessenkool ---
This is not x86-specific. Like on powerpc64 we get
addi 3,3,3 # 11 [c=4 l=4] *addsi3/1
extsw 3,3# 17 [c=4 l=4] extendsidi2/1
blr # 25 [c=4 l=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108182
--- Comment #5 from Iain Sandoe ---
(In reply to Gaius Mulley from comment #4)
> Created attachment 54184 [details]
> Potential fix for target multilib_dir handling -m and -f.
>
> Work in progress.
1. (I think) the string you need is "multilib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107631
Iain Sandoe changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107631
--- Comment #4 from CVS Commits ---
The master branch has been updated by Iain D Sandoe :
https://gcc.gnu.org/g:4413365616e8c6024d1ff4e23309e5012ee33b9f
commit r13-5035-g4413365616e8c6024d1ff4e23309e5012ee33b9f
Author: Iain Sandoe
Date: Wed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108288
--- Comment #4 from Simon Marchi ---
Thanks for looking into this so quickly. I'll try to test the patch against my
use case, but I might need some guidance. I know how to build gcc and install
it in some non-default prefix. But then, do I ne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108110
--- Comment #16 from Martin Jambor ---
I have posted the sorting patch to the mailing list:
https://gcc.gnu.org/pipermail/gcc-patches/2023-January/609459.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108293
--- Comment #3 from Jose E. Marchesi ---
(In reply to Jakub Jelinek from comment #2)
> Another thing is that at least for all SFmode constant one could use mov
> instead of lddw.
For this I guess we could expand the "I" constraint to cover cons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103784
--- Comment #8 from Surya Kumari Jangala ---
Using -O3 with gcc13, I got (with the test in comment 2):
For P8:
cmpwi 0,3,2
bgt 0,.L3
subfic 4,4,9
srdi 3,4,63
xori 3,3,0x1
rldicl 3,3,0,63
b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108212
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108290
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108290
--- Comment #2 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:e2eab3c4edb6aa9a93f982c4554cd756000934ca
commit r13-5033-ge2eab3c4edb6aa9a93f982c4554cd756000934ca
Author: Jonathan Wakely
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108212
--- Comment #1 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:80ff207da6d8784e227eb93f75c4ac5a300c8420
commit r13-5034-g80ff207da6d8784e227eb93f75c4ac5a300c8420
Author: Jonathan Wakely
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108130
Martin Jambor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108299
--- Comment #9 from Andrea Griffini ---
I agree that comment 0 is wrong and was based on a text that I thought was
taken from the standard but apparently was not (cppreference.com). Sorry for
the noise.
I think that if the dynamic initializatio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108299
--- Comment #8 from Jonathan Wakely ---
FWIW the current wording in the standard was introduced by
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0250r3.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108299
--- Comment #7 from Jonathan Wakely ---
Comment 0 seems wrong to me, there is no requirement that flag is initialized
if not odr-used, and if it is initialized, it doesn't have to happen before the
printf statement.
I agree that the standard sa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108302
Bug ID: 108302
Summary: void fn (uint8_t auto... args); leads to internal
compiler error: Segmentation fault
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108299
Jakub Jelinek changed:
What|Removed |Added
CC||jason at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105010
Segher Boessenkool changed:
What|Removed |Added
Last reconfirmed||2023-01-05
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108292
Jakub Jelinek changed:
What|Removed |Added
CC||sayle at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108298
--- Comment #4 from Segher Boessenkool ---
But please use PR33053 for that, or open a new PR? Let's keep this one
for just this actual bug :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108299
--- Comment #5 from Andrea Griffini ---
So you are saying that the standard forgot to add "that requires dynamic
initialization" and that this is the intention?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108299
--- Comment #4 from Jakub Jelinek ---
flag2 doesn't have dynamic initialization, if you add dynamic initialization to
it, you'll see that flag is constructed before flag2 and that happens before it
is referenced in the current thread (after the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108288
--- Comment #3 from Jonathan Wakely ---
This was my reproducer, although it doesn't deadlock without the hack to use a
single mutex for all objects.
#define _GLIBCXX_DEBUG 1
#include
int main()
{
std::vector v{1,2,3};
auto i = v.begin();
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108288
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108299
--- Comment #3 from Andrea Griffini ---
Thread storage duration is different from static storage duration.
The text I found on the topic is different from the one you are linking,
but even in this version (that is indeed more permissive) it's e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108288
--- Comment #1 from Jonathan Wakely ---
I've tried to reproduce this, but it depends on the addresses of the
_Safe_iterator objects that get created, because they'll use different mutexes
unless their addresses collide in the hash function.
Wou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108288
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2023-01-05
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108290
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|--- |13.0
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108292
--- Comment #2 from Jakub Jelinek ---
The assembly difference is
- movl$1, x+20(%rip)
+ movl$-6, x+20(%rip)
Now, that is the correct value to be stored into x[5] by the
__builtin_sub_overflow (0, 6, &x[5]);
statement, but eac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105010
--- Comment #21 from Piotr Kubaj ---
I'm not sure whether it will help, but the issue only affects building 32-bit
multilib libraries on powerpc64. That is, building a full 32-bit gcc for
powerpc works just fine.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108221
--- Comment #3 from Jonathan Wakely ---
I have a workaround for this, but bootstrap still fails for me at:
/tmp/ccC7KXoL.s: Assembler messages:
/tmp/ccC7KXoL.s:82719: Error: value of 0001254e too large for field of 2 bytes
at 0002
make[6]:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107884
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2023-01-05
Status|UNCONFI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108301
Bug ID: 108301
Summary: GCC Static Analyzer evaluates "__analyzer_eval((!(((0
!= b[0]) == p_9) && p_9)))" to be TRUE in the true
branch of "if 0 != b[0]) == p_9) && p_9))"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108292
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108292
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108293
--- Comment #2 from Jakub Jelinek ---
Another thing is that at least for all SFmode constant one could use mov
instead of lddw.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108300
--- Comment #2 from LIU Hao ---
(In reply to Jonathan Wakely from comment #1)
> (In reply to LIU Hao from comment #0)
> > 791 | #define abort() fancy_abort (__FILE__, __LINE__, __FUNCTION__)
>
> The C++ standard says this is undefined.
>
> W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108293
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108221
--- Comment #2 from Jonathan Wakely ---
This is a pre-existing problem that std::to_chars for floating-point types
doesn't work on these targets. Until I started to use std::format in
std/c++20/tzdb.cc the library wasn't using that, so the missi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108265
--- Comment #4 from Jonathan Wakely ---
and for 12.3
1 - 100 of 141 matches
Mail list logo
