https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84646
Richard Biener changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105480
Kewen Lin changed:
What|Removed |Added
CC||bergner at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84646
--- Comment #4 from Richard Biener ---
It's
edge
back_threader::maybe_register_path (back_threader_profitability &profit)
{
edge taken_edge = find_taken_edge (m_path);
if (taken_edge && taken_edge != UNREACHABLE_EDGE)
{
if (m_visi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95414
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107581
--- Comment #4 from Marc Poulhiès ---
You're correct, builtin_decl_explicit returns NULL.
As for the lib and fcode:
8186 {
8187enum built_in_function lib;
8188mode = get_builtin_sync_mode (fcode -
BUILT_IN_ATOM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107568
Sam James changed:
What|Removed |Added
CC||iains at gcc dot gnu.org
--- Comment #4 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105480
--- Comment #7 from Richard Biener ---
(In reply to Kewen Lin from comment #6)
> It's certainly an issue reported here, for one complete fix I did some more
> investigation how the option -ftrapping-math affects things, from what LLVM
> generate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105480
--- Comment #8 from Kewen Lin ---
(In reply to Richard Biener from comment #7)
> (In reply to Kewen Lin from comment #6)
> > Both fcmpu and fcmp would trap for sNaN, is it expected with the current GCC
> > implementation?
>
> But the key is -fs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84646
--- Comment #5 from Aldy Hernandez ---
(In reply to Richard Biener from comment #4)
> It's
>
> edge
> back_threader::maybe_register_path (back_threader_profitability &profit)
> {
> edge taken_edge = find_taken_edge (m_path);
>
> if (taken_e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107586
Bug ID: 107586
Summary: gcc trunk missed a stack-buffer-overflow
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitiz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107587
Bug ID: 107587
Summary: Explicit specializations of user-defined deduction
guides in unnamed namespaces trigger -Wunused-function
Product: gcc
Version: 12.2.0
Status: UN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90584
--- Comment #6 from Yibiao Yang ---
Hi, Richard Biener.
I updated gcc to the latest trunk version and also found that this bug seems
have been fixed in the following trunk version.
$ gcc --version
gcc (GCC) 13.0.0 20221107 (experimental)
I wa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90586
--- Comment #2 from Yibiao Yang ---
(In reply to Richard Biener from comment #1)
> The reason is that somehow the only stmt with line 9 prevailing is one
> not originally having it:
>
>:
> [t.c:11:14] D.1918 = 0;
> [t.c:11:14] // predict
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84646
--- Comment #6 from Richard Biener ---
I'm testing a patch removing the premature rejection of the cycle in the
backwards threader but will leave the cancellation code for now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107588
Bug ID: 107588
Summary: Tt
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107588
Rolex changed:
What|Removed |Added
CC||dieearget at heisei dot be
--- Comment #1 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90584
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90586
--- Comment #3 from Richard Biener ---
I think it is a genuine bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105480
--- Comment #9 from Richard Biener ---
(In reply to Kewen Lin from comment #8)
> (In reply to Richard Biener from comment #7)
> > (In reply to Kewen Lin from comment #6)
> > > Both fcmpu and fcmp would trap for sNaN, is it expected with the curr
ot affected).
Apparently the standard is a bit vague about this case. Grammar `const auto'
is accepted by LLVM [1]. Also, the corresponding GCC testcases (c2x-auto-1.c
and c2x-auto-2.c) use `const auto' (not `auto const').
Using version `13.0.0 20221109 (experimental)':
#
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107583
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2022-11-09
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107538
--- Comment #3 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #0)
> #define _GLIBCXX_ASSERTIONS
> #include
> #include
>
> int main()
> {
> double nan = std::numeric_limits::quiet_NaN();
> std::pow(10, std::complex(nan,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107585
Jakub Jelinek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
Last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99671
David Malcolm changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77432
David Malcolm changed:
What|Removed |Added
CC||dmalcolm at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107569
--- Comment #11 from Aldy Hernandez ---
(In reply to Andrew Macleod from comment #5)
> (In reply to Jakub Jelinek from comment #4)
> > The cdce case is something I've mentioned today:
> > https://gcc.gnu.org/pipermail/gcc-patches/2022-November/6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107569
--- Comment #12 from Aldy Hernandez ---
It looks like the code reading from the blob in SSA_NAME_RANGE_INFO and
populating an frange is always leaving the NAN bit toggled even if it wasn't in
the stored range.
Does this help?
diff --git a/gcc/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107569
--- Comment #13 from Aldy Hernandez ---
Created attachment 53861
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53861&action=edit
preprocessed testcase for comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107569
--- Comment #14 from Pilar Latiesa ---
I have tested the testcase in comment #1 with Clang, and I realized that Clang
trunk avoids the tailcall to sqrt even without any hint with
__builtin_unreachable: https://godbolt.org/z/5sb8bYcoq
Clang is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107569
--- Comment #15 from Jakub Jelinek ---
We don't have multiplication wired in frange, that is something we talked about
today on gcc-patches.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107590
Bug ID: 107590
Summary: __atomic_test_and_set broken on PowerPC
Product: gcc
Version: 11.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107591
Bug ID: 107591
Summary: range-op{,-float}.cc for x * x
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107569
--- Comment #16 from Jakub Jelinek ---
I've filed PR107591 for the lack of x * x range optimization.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107590
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2022-11-09
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107590
--- Comment #2 from Andrew Pinski ---
>Reason: 259 at address: 0x3109
Yes that does seem like an alignment disagreement.
I suspect the code is broken for allocation and it is allocating unaligned
structs.
Also inside gdb can you do the fo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107591
Aldy Hernandez changed:
What|Removed |Added
Last reconfirmed||2022-11-09
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107591
--- Comment #1 from Aldy Hernandez ---
pinskia is a god. How does he keep track of all these bugs, plus the cross
reference between them? I knew PR91645 was related, but it was specifically
something on my radar, not the 5 trillion bugs in pin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79365
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62139
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |13.0
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107591
--- Comment #2 from Jakub Jelinek ---
Perhaps before we try to map MULT_EXPR into some irange/frange op the usual
way,
while we still have access to gimple statement check if it is MULT_EXPR with
the same operands and use a different artificial
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78862
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78117
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |13.0
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55360
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78222
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |WONTFIX
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86772
Bug 86772 depends on bug 86808, which changed state.
Bug 86808 Summary: tilegx port needs updating for CVE-2017-5753
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86808
What|Removed |Added
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86809
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |WONTFIX
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86772
Bug 86772 depends on bug 86809, which changed state.
Bug 86809 Summary: tilepro port needs updating for CVE-2017-5753
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86809
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101926
Bug 101926 depends on bug 55360, which changed state.
Bug 55360 Summary: [TileGX] Passing structure by value on stack needlessly
writes to and reads from memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55360
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86808
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |13.0
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107591
--- Comment #3 from Andrew Pinski ---
(In reply to Aldy Hernandez from comment #1)
> pinskia is a god. How does he keep track of all these bugs, plus the cross
> reference between them? I knew PR91645 was related, but it was specifically
> som
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107591
--- Comment #5 from Aldy Hernandez ---
(In reply to Andrew Pinski from comment #3)
> (In reply to Aldy Hernandez from comment #1)
> > pinskia is a god. How does he keep track of all these bugs, plus the cross
> > reference between them? I knew
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107591
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107591
--- Comment #6 from Aldy Hernandez ---
(In reply to Jakub Jelinek from comment #2)
> Perhaps before we try to map MULT_EXPR into some irange/frange op the usual
> way,
> while we still have access to gimple statement check if it is MULT_EXPR wit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107590
--- Comment #3 from Sergey Fedorov ---
(In reply to Andrew Pinski from comment #2)
> >Reason: 259 at address: 0x3109
>
> Yes that does seem like an alignment disagreement.
>
> I suspect the code is broken for allocation and it is allocatin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107592
Bug ID: 107592
Summary: ICE: gdc segfault on label continue
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107581
--- Comment #5 from Marc Poulhiès ---
Created attachment 53862
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53862&action=edit
naive patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107581
--- Comment #6 from Marc Poulhiès ---
IIUC, the builtin for ADD_FETCH_4 is correctly defined (there's an entry with a
corresponding decl), but there's no builtin for FETCH_ADD_4.
When looking in go-gcc.cc, I see that only the ADD_FETCH is defin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101392
--- Comment #5 from Gaius Mulley ---
thanks for this excellent analysis. Here is a patch which will fix the passing
of binop.proc in M2GenGCC.c.
diff --git a/gcc/m2/gm2-gcc/m2expr.def b/gcc/m2/gm2-gcc/m2expr.def
index 8988c78d575..e622d31d09b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107591
--- Comment #7 from Jakub Jelinek ---
To answer my own question:
int
foo (int x)
{
return x + x;
}
int
bar (int x)
{
return x * x * x * x * x * x;
}
float
baz (float x)
{
return x + x;
}
float
qux (float x)
{
return x * x * x * x * x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107590
--- Comment #4 from Andrew Pinski ---
(In reply to Sergey Fedorov from comment #3)
> > Also inside gdb can you do the following:
> >
> > disassemble $pc-0x10 $pc+0x10
> > info registers
>
> I could try that tomorrow, provided an ancient GBD we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107591
--- Comment #8 from Jakub Jelinek ---
(In reply to Aldy Hernandez from comment #6)
> FYI, the range operators have a relation field, so it should be able to tell
> you that both operands are equal with VREL_EQ (?). You could use that to
> optim
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107590
--- Comment #5 from Iain Sandoe ---
I'm away from my usual sources of information but I'd suggest exploring the
possibility that someone has assumed that either the spinlock or a bool is
8bits; As far as my memory serves both are 32b on power d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100799
Surya Kumari Jangala changed:
What|Removed |Added
Status|ASSIGNED|WAITING
--- Comment #21 from Sur
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107593
Bug ID: 107593
Summary: ice with -Wduplicated-cond
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assigne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105586
Surya Kumari Jangala changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107590
--- Comment #6 from Andrew Pinski ---
(In reply to Iain Sandoe from comment #5)
> I'm away from my usual sources of information but I'd suggest exploring the
> possibility that someone has assumed that either the spinlock or a bool is
> 8bits; A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106123
--- Comment #3 from qinzhao at gcc dot gnu.org ---
the minimized testing case:
struct S { int t; int a; void foo (); };
void
S::foo ()
{
#pragma omp parallel
{
#pragma omp taskloop firstprivate (a)
for (int i = 0; i < a; i++)
t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107569
--- Comment #17 from CVS Commits ---
The master branch has been updated by Aldy Hernandez :
https://gcc.gnu.org/g:4eadbe80060ab6c45193a1a57fac84b035e1c328
commit r13-3860-g4eadbe80060ab6c45193a1a57fac84b035e1c328
Author: Aldy Hernandez
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105480
--- Comment #10 from joseph at codesourcery dot com ---
For scalar isnan see bug 66462. (The claim in bug 66462 comment 19 that
there was ever a working version of that patch ready to go in is
incorrect: November 2016 is older than June 2017.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107592
--- Comment #1 from Iain Buclaw ---
Generated function:
---
void foo (struct _param_0)
{
void label = <<< error >>>;
label:;
while (1)
{
{
struct thing;
thing = _param_0;
goto ;
}
goto ;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107591
--- Comment #9 from Andrew Macleod ---
(In reply to Jakub Jelinek from comment #8)
> (In reply to Aldy Hernandez from comment #6)
> > FYI, the range operators have a relation field, so it should be able to tell
> > you that both operands are equ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107591
--- Comment #10 from Jakub Jelinek ---
(In reply to Andrew Macleod from comment #9)
> you could also test whether op1_range contains + and/or - 0, as well as
> op2_range. VREL_EQ is a symbolic equality.. the ranges can still be
> distinct and i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107594
Bug ID: 107594
Summary: ICE in module_state, at cp/module.cc:3810
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107595
Bug ID: 107595
Summary: ICE in ix86_push_argument, at config/i386/i386.cc:4335
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Comp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107596
Bug ID: 107596
Summary: ICE in gfc_match_submodule, at fortran/module.cc:773
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107569
--- Comment #18 from Jakub Jelinek ---
Ok, just so that I don't just kibbitz/review frange stuff but also try to do
something, here is my so far untested attempt at normal multiplication
fold_range (not the x * x stuff discussed elsewhere):
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107591
--- Comment #11 from Andrew Macleod ---
(In reply to Jakub Jelinek from comment #10)
> (In reply to Andrew Macleod from comment #9)
> > you could also test whether op1_range contains + and/or - 0, as well as
> > op2_range. VREL_EQ is a symbolic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107591
--- Comment #12 from Jakub Jelinek ---
(In reply to Andrew Macleod from comment #11)
> no, I meant in addition to the VREL_EQ. so
> if (rel == VREL_EQ && op1_range != op2_range)
> then you know you have something like if (x == y) z=x*y
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107580
Jonathan Wakely changed:
What|Removed |Added
Keywords||ABI
Assignee|redi at gcc do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107597
Bug ID: 107597
Summary: LTO causes static inline variables to get a
non-uniqued global symbol
Product: gcc
Version: 8.4.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107591
--- Comment #13 from Andrew Macleod ---
(In reply to Jakub Jelinek from comment #12)
> (In reply to Andrew Macleod from comment #11)
> > no, I meant in addition to the VREL_EQ. so
> > if (rel == VREL_EQ && op1_range != op2_range)
> > th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107598
Bug ID: 107598
Summary: implicitly-defined copy/move assignment op not
constexpr
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107599
Bug ID: 107599
Summary: [13 regression]
c-c++-common/diagnostic-format-json-4.c fails after
r13-3853-g9c3bc557995463
Product: gcc
Version: 13.0
Statu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107599
Martin Liška changed:
What|Removed |Added
Ever confirmed|0 |1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107593
Marek Polacek changed:
What|Removed |Added
Target Milestone|--- |12.3
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107441
--- Comment #11 from CVS Commits ---
The master branch has been updated by Harald Anlauf :
https://gcc.gnu.org/g:e805adaa283129604a1fb305d0a1cf1e8a90c76e
commit r13-3863-ge805adaa283129604a1fb305d0a1cf1e8a90c76e
Author: Harald Anlauf
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107599
--- Comment #2 from CVS Commits ---
The master branch has been updated by Martin Liska :
https://gcc.gnu.org/g:f94c2eff6b0e000ee2feadedf354590958308760
commit r13-3864-gf94c2eff6b0e000ee2feadedf354590958308760
Author: Martin Liska
Date: Wed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107599
Martin Liška changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107559
--- Comment #2 from CVS Commits ---
The master branch has been updated by Harald Anlauf :
https://gcc.gnu.org/g:e505f7493bed1395d121d2f53137ec11706fa42e
commit r13-3865-ge505f7493bed1395d121d2f53137ec11706fa42e
Author: Harald Anlauf
Date: W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107559
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Target Milestone|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107591
--- Comment #14 from Jakub Jelinek ---
Incremental patch on top of the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107569#c18 patch which optimizes
the floating point x * x:
--- gcc/range-op-float.cc.jj2022-11-09 19:06:11.075716000 +0100
+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107591
--- Comment #15 from Jakub Jelinek ---
I've screwed up the real_value_negate calls, they need to assign the result.
Anyway, yet another option would be for cdce to ask the ranger if the sqrt
argument can be smaller than -0.0 (and only if it can
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94104
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107444
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Last reconfirmed||2022-11-09
Assigne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107595
H.J. Lu changed:
What|Removed |Added
Last reconfirmed||2022-11-09
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107596
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107591
--- Comment #16 from Andrew Macleod ---
(In reply to Jakub Jelinek from comment #15)
> I've screwed up the real_value_negate calls, they need to assign the result.
>
> Anyway, yet another option would be for cdce to ask the ranger if the sqrt
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99671
--- Comment #2 from David Malcolm ---
Created attachment 53863
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53863&action=edit
Implementation of this (not yet ported to Sphinx)
This patch implements the new warning; still uses texinfo rat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107595
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107595
kargl at gcc dot gnu.org changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #3 from kargl
1 - 100 of 121 matches
Mail list logo
