https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109349
Kito Cheng changed:
What|Removed |Added
CC||kito at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109029
--- Comment #7 from Hongtao.liu ---
(In reply to Hongtao.liu from comment #6)
> (In reply to Hongtao.liu from comment #5)
> > We need to support signbit2 for vector double/_Float16. Also similar
> > like popcnt, there's a mismatch of input and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109029
--- Comment #6 from Hongtao.liu ---
(In reply to Hongtao.liu from comment #5)
> We need to support signbit2 for vector double/_Float16. Also similar
> like popcnt, there's a mismatch of input and output between builtin and
> signbit_optab, it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109349
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109349
--- Comment #2 from Andrew Pinski ---
Also from reading the merge request, this really should just be in the gcc user
manual instead of just in the compiler.
Gcc's user manual should document what is supported.
It is how all other targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109349
--- Comment #1 from Andrew Pinski ---
Target options always start with -m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109349
Bug ID: 109349
Summary: Add --print-supported-extensions
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109029
--- Comment #5 from Hongtao.liu ---
We need to support signbit2 for vector double/_Float16. Also similar like
popcnt, there's a mismatch of input and output between builtin and
signbit_optab, it could be handled in vectorizer pattern match.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109029
--- Comment #4 from Hongtao.liu ---
Also found a document missing for signbitm2 in md.texi.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106069
--- Comment #37 from Xionghu Luo (luoxhu at gcc dot gnu.org) ---
https://gcc.gnu.org/pipermail/gcc-patches/2023-March/614932.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101047
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85048
--- Comment #11 from Hongtao.liu ---
Fixed in GCC13.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85048
--- Comment #10 from CVS Commits ---
The master branch has been updated by hongtao Liu :
https://gcc.gnu.org/g:fe42e7fe119159f7443dbe68189e52891dc0148e
commit r13-6951-gfe42e7fe119159f7443dbe68189e52891dc0148e
Author: liuhongt
Date: Thu Mar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109323
--- Comment #5 from Enrico Maria De Angelis ---
I've asked some feeback here
https://stackoverflow.com/questions/75891694/is-it-legal-for-a-coroutines-promise-type-to-lack-both-return-void-and-return-v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109323
--- Comment #4 from Enrico Maria De Angelis ---
The more I read the standard, specifically
http://eel.is/c++draft/dcl.fct.def.coroutine#6 and
http://eel.is/c++draft/stmt.return.coroutine, the more I'm convinced that it's
just fine that a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105452
--- Comment #6 from CVS Commits ---
The trunk branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:58df5350753c00f140c86e60ba5ce0cac686ec4b
commit r13-6949-g58df5350753c00f140c86e60ba5ce0cac686ec4b
Author: Jason Merrill
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105221
--- Comment #7 from CVS Commits ---
The trunk branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:85131af0603c0af2aa6b40de6cc929905f22bd50
commit r13-6948-g85131af0603c0af2aa6b40de6cc929905f22bd50
Author: Jason Merrill
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109334
--- Comment #1 from Martin Uecker ---
Created attachment 54796
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54796=edit
partial fix
Simply removing the condition based on internal_p would make it work for the
most important cases as in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109319
--- Comment #5 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:c016887c91a79d67b6a3c7e19b9219f5ab1e2a4d
commit r13-6946-gc016887c91a79d67b6a3c7e19b9219f5ab1e2a4d
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109322
--- Comment #11 from Steve Kargl ---
On Thu, Mar 30, 2023 at 07:21:21PM +, pinskia at gcc dot gnu.org wrote:
>
> For ILP32 (32bit x86) and LLP64IL32 (64bit Windows/mingw) targets, it will use
> c_long_long which is outputted wrong. Anyways
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109128
--- Comment #5 from Tobias Burnus ---
New idea for the lto-plugin.c:
Currently, as soon as a file pops up (as seemingly here for the common block in
libone.a), the file is claimed via claim_file_handler, which collects the file
names.
Later,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109347
--- Comment #9 from Andrew Pinski ---
Even for pre-LRA with reload in GCC 4.7.0:
t.c: In function ‘f’:
t.c:91:1: note: unable to find a register to spill in class ‘GR_REGS’
t.c:91:1: note: this is the insn:
(insn 33 32 34 2 (set (reg:DI 198)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109347
Andrew Pinski changed:
What|Removed |Added
Known to fail||7.3.0
--- Comment #8 from Andrew
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109347
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109347
Andrew Pinski changed:
What|Removed |Added
Attachment #54791|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109347
--- Comment #6 from Andrew Pinski ---
Oh if we add back the s0 case, it fails at -O1 and above too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109347
--- Comment #5 from Andrew Pinski ---
Created attachment 54794
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54794=edit
testcase for riscv32-elf
Here is a testcase which also fails for riscv32-elf. Note it only fails at -O0.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109347
--- Comment #4 from Andrew Pinski ---
Created attachment 54793
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54793=edit
Fixed up riscv64 testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109347
--- Comment #3 from Andrew Pinski ---
On the trunk I get:
t.c: In function ‘f’:
t.c:94:1: error: s0 cannot be used in ‘asm’ here
94 | }
| ^
First with the RISCV example.
After removing the s0 variable usage I still get the ICE.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109347
--- Comment #2 from Andrew Pinski ---
(In reply to Piggy NL from comment #0)
> The assertion was introduced in e3b3b59683c1.
r11-5002-ge3b3b59683c1e7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109322
--- Comment #10 from Andrew Pinski ---
(In reply to Steve Kargl from comment #9)
>
> If one instruments, write_decl() in dump-parse-tree.cc to
> dump the table of bind(c) types, one can see why you get
> what you get.
>
> % cat a.f90
> module
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109171
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||pault at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109348
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109128
--- Comment #4 from Tobias Burnus ---
Minor observations (unrelated to this bug but should be fixed. separately or
together):
- '@' file in lto-wrapper.cc's compile_offload_image's fork_execute call is
always the same. (Matters if there is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84779
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC|anlauf at gmx dot de |anlauf at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109322
--- Comment #9 from Steve Kargl ---
On Wed, Mar 29, 2023 at 07:42:08PM +, sgk at troutmask dot
apl.washington.edu wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109322
>
> --- Comment #3 from Steve Kargl ---
> On Wed, Mar 29, 2023
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109347
--- Comment #1 from Piggy NL ---
Created attachment 54792
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54792=edit
Reproduce for mips64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109348
Bug ID: 109348
Summary: Pointer initialization fails for target with
references
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109347
Bug ID: 109347
Summary: [lra] Spill failure for architecture without CC
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109279
--- Comment #14 from Vineet Gupta ---
(In reply to Andrew Pinski from comment #12)
> Here is something to look into:
> #define const1 0x0101010101010101ULL
> #define const0 const1
> unsigned long long f(unsigned long long occ, const unsigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109068
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109154
--- Comment #41 from CVS Commits ---
The master branch has been updated by Andrew Macleod :
https://gcc.gnu.org/g:429a7a88438cc80e7c58d9f63d44838089899b12
commit r13-6945-g429a7a88438cc80e7c58d9f63d44838089899b12
Author: Andrew MacLeod
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109231
--- Comment #31 from Jakub Jelinek ---
If the important side-effect is allocation of some GC memory, then perhaps
(assuming you also see just 5 initialize_cfun calls with 2xint, TFmode float,
uint and bool) testing hack might be:
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109323
--- Comment #3 from Enrico Maria De Angelis ---
However, I'm not entirely sure (not anymore now that I've read the standard
more carefully) that not having any of those two memebrs is an error.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84075
Patrick Palka changed:
What|Removed |Added
Target Milestone|--- |10.5
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109346
Bug ID: 109346
Summary: RFE add DW_AT_location to DW_TAG_subprogram
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109323
--- Comment #2 from Enrico Maria De Angelis ---
Created attachment 54790
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54790=edit
Attachment for report 109323
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104970
--- Comment #15 from Martin Uecker ---
Thanks.
I still wonder whether the original example should be added to the test suite?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102419
Patrick Palka changed:
What|Removed |Added
CC||cjdb.ns at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109337
Patrick Palka changed:
What|Removed |Added
Resolution|--- |DUPLICATE
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109338
Patrick Palka changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
See
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96464
Patrick Palka changed:
What|Removed |Added
See Also|https://gcc.gnu.org/bugzill |
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109303
Martin Jambor changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109327
Andrew Pinski changed:
What|Removed |Added
Summary|ICE on valid code at -O1|[13 Regression] ICE on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109231
--- Comment #30 from Jakub Jelinek ---
So, if I add the
--- a/gcc/tree-inline.cc
+++ b/gcc/tree-inline.cc
@@ -2787,6 +2787,7 @@ initialize_cfun (tree new_fndecl, tree callee_fndecl,
profile_count count)
/* Get clean struct function. */
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105644
Patrick Palka changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109137
--- Comment #22 from Jakub Jelinek ---
Sure. The point was to avoid regressions on the release branch because of so
big changes for the tunings which were supported before already.
So we might want both the LRA changes and perhaps zen1-3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109137
--- Comment #21 from Jan Hubicka ---
Zen 1-3 changes were intentional in the original tuning patch (it is also
briefly mentioned in the commit message). By allowing 256 bit AVX moves
instead of 64bit integer moves (or 128bit) we can move
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109128
--- Comment #3 from Tobias Burnus ---
My initial thought was to handle it via lto1. This works well if all relevant
files are compiled with "-flto" as then the callers of the offload functions,
the offload functions themselves are available,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105221
Jason Merrill changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105221
--- Comment #6 from Jason Merrill ---
Reduced:
void (*p)(int) = [](auto) noexcept {};
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109231
--- Comment #29 from Jakub Jelinek ---
So aggregate_value_p has some side-effects other than return value then? Ugh.
Anyway, my patch intention has been to avoid the relayouts.
So, just calling aggregate_value_p there or perhaps instead later
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109104
Kito Cheng changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109231
--- Comment #28 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #25 from Jakub Jelinek ---
> Anyway, as I said for the second version, it would be nice to also try
> subvariants:
> // relayout_decl (DECL_RESULT (new_fndecl));
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91645
Jakub Jelinek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85563
Richard Biener changed:
What|Removed |Added
CC||amacleod at redhat dot com,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91645
--- Comment #12 from Jakub Jelinek ---
WIP which still doesn't work:
--- gcc/value-query.cc.jj 2023-03-23 15:25:47.069740988 +0100
+++ gcc/value-query.cc 2023-03-30 14:56:58.809298424 +0200
@@ -230,9 +230,11 @@ range_query::get_tree_range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81958
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
--- Comment #8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109343
Andrew Pinski changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109345
Bug ID: 109345
Summary: class(*) variable that is a string array is not
handled correctly
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109344
--- Comment #5 from Xi Ruoyao ---
(In reply to albin from comment #4)
> Thanks for the info. If it was fixed three years ago how come it is still
> seen when using gcc (trunk) on Compiler Explorer? Is Compiler Explorer using
> an obsolete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109344
--- Comment #4 from albin ---
Thanks for the info. If it was fixed three years ago how come it is still seen
when using gcc (trunk) on Compiler Explorer? Is Compiler Explorer using an
obsolete glibc?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101834
--- Comment #12 from Jonathan Wakely ---
Patch submitted:
https://gcc.gnu.org/pipermail/gcc-patches/2023-March/614893.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107897
Jason Merrill changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108887
Jason Merrill changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109104
Martin Liška changed:
What|Removed |Added
Keywords|needs-bisection |
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101834
--- Comment #11 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #10)
> @@ -22,6 +22,7 @@ libexecdir := @libexecdir@
> target_noncanonical := @target_noncanonical@
> gcc_version := $(shell @get_gcc_base_ver@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101834
--- Comment #10 from Jonathan Wakely ---
This seems like an improvement ...
--- a/c++tools/Makefile.in
+++ b/c++tools/Makefile.in
@@ -22,6 +22,7 @@ libexecdir := @libexecdir@
target_noncanonical := @target_noncanonical@
gcc_version :=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91645
--- Comment #11 from Jakub Jelinek ---
(In reply to Aldy Hernandez from comment #9)
> It looks like what we want for this test is actually !isgreaterequal() not
> isless(), since we want to exclude the possibility of a NAN. Like this:
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101834
--- Comment #9 from Segher Boessenkool ---
(In reply to Segher Boessenkool from comment #8)
> (In reply to Jonathan Wakely from comment #6)
> > Also, after 'make clean' you can no longer do 'make all'
>
> Of course you cannot. Where do you
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101834
--- Comment #8 from Segher Boessenkool ---
(In reply to Jonathan Wakely from comment #6)
> Also, after 'make clean' you can no longer do 'make all'
Of course you cannot. Where do you see this?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101834
--- Comment #7 from Segher Boessenkool ---
Thank you for looking at this!
(In reply to Jonathan Wakely from comment #5)
> c++tools/Makefile.in has:
>
> mostlyclean::
> rm -f $(MAPPER.O)
>
> clean::
> rm -f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103559
--- Comment #11 from Jakub Jelinek ---
Actually, I was just misreading the tree dumps, we use hw insn for x u>= 0.0,
which
is UNGE_EXPR, so it is true if x is NAN or GE_EXPR, or as described in the
tree-call-cdce.cc comment:
y = sqrt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101834
--- Comment #6 from Jonathan Wakely ---
Also, after 'make clean' you can no longer do 'make all'
c++tools$ make clean all
# --enable-maintainer-mode to rebuild
/home/jwakely/src/gcc/gcc/c++tools/configure, or make MAINTAINER=touch
#
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101834
--- Comment #5 from Jonathan Wakely ---
c++tools/Makefile.in has:
mostlyclean::
rm -f $(MAPPER.O)
clean::
rm -f g++-mapper-server$(exeext)
distclean::
rm -f config.log config.status config.h
Should distclean have
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107897
--- Comment #7 from CVS Commits ---
The trunk branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:a23b33a1bdeff7bc2289d9ebb7cb7b7ec0a605f5
commit r13-6944-ga23b33a1bdeff7bc2289d9ebb7cb7b7ec0a605f5
Author: Jason Merrill
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108887
--- Comment #9 from CVS Commits ---
The trunk branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:a23b33a1bdeff7bc2289d9ebb7cb7b7ec0a605f5
commit r13-6944-ga23b33a1bdeff7bc2289d9ebb7cb7b7ec0a605f5
Author: Jason Merrill
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109344
Xi Ruoyao changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108640
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443
Bug 88443 depends on bug 107561, which changed state.
Bug 107561 Summary: [13 Regression] g++.dg/pr71488.C and
[g++.dg/warn/Warray-bounds-16.C -m32] regression due to -Wstringop-overflow
problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107561
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107561
--- Comment #25 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:04b0a7b1a6d9e0f3782888f1ebf187c26690038b
commit r13-6943-g04b0a7b1a6d9e0f3782888f1ebf187c26690038b
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109341
Jan Hubicka changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109344
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103035
Bug 103035 depends on bug 109342, which changed state.
Bug 109342 Summary: [13 Regression] Wrong code with -O2 since
r13-5348-gc29d85359add80
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109342
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109342
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109342
--- Comment #4 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:1d0ba4467dd9cad11eb9ff547442e3ce6292b892
commit r13-6942-g1d0ba4467dd9cad11eb9ff547442e3ce6292b892
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107943
Richard Biener changed:
What|Removed |Added
Last reconfirmed|2022-12-01 00:00:00 |2023-3-30
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101834
Segher Boessenkool changed:
What|Removed |Added
Last reconfirmed||2023-03-30
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103559
--- Comment #10 from Xi Ruoyao ---
(In reply to Jakub Jelinek from comment #9)
> isless (NAN, 0.0) should be false, no, so NAN shouldn't errno = EDOM for
> glibc.
Oh, I misunderstood your question.
1 - 100 of 132 matches
Mail list logo
