https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
--- Comment #17 from Martin Uecker ---
Am Freitag, dem 03.03.2023 um 23:18 + schrieb isanbard at gmail dot com:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
>
> --- Comment #16 from Bill Wendling ---
> (In reply to Martin Uecker f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109007
--- Comment #3 from bugreporter66 at gmail dot com ---
Thanks, I will try to find out and be more specific where exactly it leaks.
It was my first attempt at reducing the code that would fit into 1MB
attachment.
Checked g++ 10.4 today, it works
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109004
--- Comment #1 from bugreporter66 at gmail dot com ---
Checked g++ 10.4 today, it works as it should.
11.3 and 12.1 were tested to show the issue so far.
The command line for building:
powerpc64le-linux-gnu-g++ -O2 -static test.cpp -o test_p64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109018
--- Comment #6 from qingzhe huang ---
I agree "Note g can be still found after the declaration via argument dependent
lookup."
Can we view this issue from a different angle? The real work of parsing should
be started at "template function defin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109018
Andrew Pinski changed:
What|Removed |Added
Resolution|FIXED |INVALID
--- Comment #5 from Andrew Pins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109018
qingzhe huang changed:
What|Removed |Added
Resolution|INVALID |FIXED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108982
Hans-Peter Nilsson changed:
What|Removed |Added
CC||hp at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109011
--- Comment #6 from Jakub Jelinek ---
Oh, and optabs.cc expands ctz using clz as (bitsize-1) - .CLZ(x & -x) which is
one fewer operations if andn isn't supported, on the other side is undefined at
zero (so could be used for __builtin_ctz but not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108994
--- Comment #12 from Tom Stellard ---
https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=6e80a1d164d1f9 is the first bad
commit.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109019
Thomas Koenig changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109019
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109019
Bug ID: 109019
Summary: Failure to optimize b + c -1
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: rtl-optimiz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109016
--- Comment #1 from CVS Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:df0184906a7b86a497c038766366904a20b5601e
commit r13-6467-gdf0184906a7b86a497c038766366904a20b5601e
Author: David Malcolm
Date: F
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
--- Comment #16 from Bill Wendling ---
(In reply to Martin Uecker from comment #15)
> Am Freitag, dem 03.03.2023 um 20:27 + schrieb isanbard at gmail dot com:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
> >
> > --- Comment #14 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108988
--- Comment #8 from David Malcolm ---
(In reply to Jakub Jelinek from comment #6)
> Fixed.
Thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109018
--- Comment #3 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #1)
> template
> decltype(g(T())) h()
> return g(T());}
Typo in my example missing {
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109018
--- Comment #2 from Andrew Pinski ---
Also from that page:
> If multiple declarations of the same template differ in the result of name
> lookup, the first such declaration is used
That is GCC gets that part correct even while clang and MSVC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109018
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107565
--- Comment #7 from CVS Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:56572a08ec4a0fc1a7802d3737cd7f7cc9089c4b
commit r13-6466-g56572a08ec4a0fc1a7802d3737cd7f7cc9089c4b
Author: David Malcolm
Date: F
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109014
--- Comment #2 from CVS Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:56572a08ec4a0fc1a7802d3737cd7f7cc9089c4b
commit r13-6466-g56572a08ec4a0fc1a7802d3737cd7f7cc9089c4b
Author: David Malcolm
Date: F
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109018
Bug ID: 109018
Summary: decltype of dependent expressions lookup should be
done only when doing template function definition
Product: gcc
Version: 13.0
Status: UNCONFIR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108988
--- Comment #7 from CVS Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:d3ef73867e3f70a343ad5aa4e00b270be85fa572
commit r13-6465-gd3ef73867e3f70a343ad5aa4e00b270be85fa572
Author: David Malcolm
Date: F
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42566
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108315
--- Comment #17 from Segher Boessenkool ---
What makes you think we need to tell the user to do something? There is
nothing that needs to be done as far as I can see? /confused
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
--- Comment #15 from Martin Uecker ---
Am Freitag, dem 03.03.2023 um 20:27 + schrieb isanbard at gmail dot com:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
>
> --- Comment #14 from Bill Wendling ---
> (In reply to Martin Uecker f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101118
Iain Sandoe changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108871
--- Comment #8 from Jonny Grant ---
Another test case.
https://godbolt.org/z/qss7jj51x
I noticed when not using -fanalyzer gcc still warns about __builtin_puts being
passed NULL. However gcc doesn't warn about my own function with attribute
n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109017
Bug ID: 109017
Summary: ICE on unexpanded pack from C++20
explicit-template-parameter lambda syntax
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109011
--- Comment #5 from Jakub Jelinek ---
And to answer myself, as x86 has vplzcnt* just for 32-bit and 64-bit elts with
-mavx512cd (perhaps -mavx512vl also depending on vecsize), there is also 8-bit
and 16-bit element vector popcount (guarded by di
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109011
--- Comment #4 from Jakub Jelinek ---
Hacker's Delight has also a variant for popcount, either .POPCOUNT ((x - 1) &
~x)
or bitsize - .POPCOUNT (x | -x), though a question is if there are any targets
which have vector popcount and don't have vect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108975
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
--- Comment #14 from Bill Wendling ---
(In reply to Martin Uecker from comment #9)
> > > Considering that the GNU extensions is rarely used, one could consider
> > > redefining the meaning of
> > >
> > > int n = 1;
> > > struct {
> > > int n;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109007
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109011
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108315
Alexander Monakov changed:
What|Removed |Added
Resolution|INVALID |---
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109011
Andrew Pinski changed:
What|Removed |Added
Blocks||53947
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109011
--- Comment #1 from Andrew Pinski ---
On aarch64, both get vectorized.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108763
ibuclaw at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |WONTFIX
Status|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108763
--- Comment #7 from CVS Commits ---
The master branch has been updated by Iain Buclaw :
https://gcc.gnu.org/g:1f83aee5864129c4147a95c1a4e35d37c7eb7e59
commit r13-6463-g1f83aee5864129c4147a95c1a4e35d37c7eb7e59
Author: Iain Buclaw
Date: Fri M
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104852
Alexandre Oliva changed:
What|Removed |Added
CC||aoliva at gcc dot gnu.org
A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108315
--- Comment #15 from Segher Boessenkool ---
(In reply to Alexander Monakov from comment #14)
> Are you guys really sure you want to blame the user here,
I apologise if this hasn't been a nice experience for you.
I'm not blaming anyone, least o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101118
--- Comment #11 from Iain Sandoe ---
(In reply to Iain Sandoe from comment #10)
> Hmm... maybe I am being too hasty here.
>
> If the coroutine has a definition in a header, then the coroutine frame type
> _should_ be the same for each instance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101118
--- Comment #10 from Iain Sandoe ---
Hmm... maybe I am being too hasty here.
If the coroutine has a definition in a header, then the coroutine frame type
_should_ be the same for each instance of it. So maybe this is actually
reporting a genui
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109016
Bug ID: 109016
Summary: Analyzer doesn't know about OMP builtins
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: openmp
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104852
--- Comment #8 from CVS Commits ---
The master branch has been updated by Alexandre Oliva :
https://gcc.gnu.org/g:21edd841611a97442a6b95e8ec7e91ff8fd3a451
commit r13-6461-g21edd841611a97442a6b95e8ec7e91ff8fd3a451
Author: Alexandre Oliva
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52590
--- Comment #7 from CVS Commits ---
The master branch has been updated by Alexandre Oliva :
https://gcc.gnu.org/g:21edd841611a97442a6b95e8ec7e91ff8fd3a451
commit r13-6461-g21edd841611a97442a6b95e8ec7e91ff8fd3a451
Author: Alexandre Oliva
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95989
--- Comment #23 from CVS Commits ---
The master branch has been updated by Alexandre Oliva :
https://gcc.gnu.org/g:21edd841611a97442a6b95e8ec7e91ff8fd3a451
commit r13-6461-g21edd841611a97442a6b95e8ec7e91ff8fd3a451
Author: Alexandre Oliva
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51534
--- Comment #6 from CVS Commits ---
The master branch has been updated by Alexandre Oliva :
https://gcc.gnu.org/g:cc9cc5a9a5fb0c16532a16b87fbd155037a7ed89
commit r13-6457-gcc9cc5a9a5fb0c16532a16b87fbd155037a7ed89
Author: Alexandre Oliva
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104882
--- Comment #6 from CVS Commits ---
The master branch has been updated by Alexandre Oliva :
https://gcc.gnu.org/g:220008eafaaed7433b1c18e394279391e885a138
commit r13-6455-g220008eafaaed7433b1c18e394279391e885a138
Author: Alexandre Oliva
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109015
Bug ID: 109015
Summary: Analyzer doesn't know about atomic builtins
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: anal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108994
--- Comment #11 from Tom Stellard ---
(In reply to Jakub Jelinek from comment #10)
> I'd start with verification if it is really libgcc, so don't recompile the
> app, just try it against GCC 12.2.1 libgcc vs. 13.0.1.
I confirmed it's libgcc. O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109014
--- Comment #1 from David Malcolm ---
I believe the issue here is that:
* display_properties partially initializes the "found" buffer, writing a -1
terminator at the end of the initialized part at:
fv[m] = -1;
* display_properties then ca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108996
--- Comment #7 from Andrew Pinski ---
(In reply to Ulrich Weigand from comment #4)
> (In reply to Jakub Jelinek from comment #3)
> > What is done on other arches?
>
> That depends on the platform ABI. On some arches, including x86/x86_64 and
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109007
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109014
Bug ID: 109014
Summary: -Wanalyzer-use-of-uninitialized-value seen in
pcre2-10.42's pcre2test.c
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108315
--- Comment #14 from Alexander Monakov ---
Are you guys really sure you want to blame the user here, considering that all
linkers, including the BFD linker, initially misinterpreted the ABI the same
way?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109006
--- Comment #3 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:59a576f274b9093fd4b25eb6be556b40c2424478
commit r13-6454-g59a576f274b9093fd4b25eb6be556b40c2424478
Author: Jonathan Wakely
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109013
--- Comment #2 from Jakub Jelinek ---
Even the dominating case could be valid.
E.g. if the body does
#pragma omp ordered
foo ();
bar ();
#pragma omp ordered
baz ();
where bar () calls exit (0);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108315
--- Comment #13 from Segher Boessenkool ---
(In reply to Alexander Monakov from comment #10)
> (In reply to Rui Ueyama from comment #9)
> > I'm the maintainer of the mold linker. I didn't implement that POWER10 ABI
> > because I didn't have an a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109013
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101118
--- Comment #9 from Iain Sandoe ---
(In reply to Jan Hubicka from comment #8)
> >
> > the synthesised functions (actor, destroy) are intended to be TU-local.
> > the ramp function is what remains of the user's original function after the
> > co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108887
--- Comment #5 from Jan Hubicka ---
> Perhaps, but shouldn't we also unlink_from_assembler_name_hash (node, false);?
> I think the point of the current removal is that we've discovered the mangling
> alias clashes with some other symbol.
cgraph_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101118
--- Comment #8 from Jan Hubicka ---
>
> the synthesised functions (actor, destroy) are intended to be TU-local.
> the ramp function is what remains of the user's original function after the
> coroutine body is outlined - so that has the origina
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109013
Bug ID: 109013
Summary: [OpenMP] Diagnose if multiple 'omp ordered' appear in
a loop body
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: diagnostic,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109006
--- Comment #2 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:ce1c99f1ccd7b1229a4f8531d6b6de6cf571a9ef
commit r13-6453-gce1c99f1ccd7b1229a4f8531d6b6de6cf571a9ef
Author: Jonathan Wakely
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109009
--- Comment #1 from Segher Boessenkool ---
This is very target-specific. Could you please attach a test case (with any
significant compiler flags as well, and specific target mentioned, etc.) that
shows the problem?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108998
Patrick Palka changed:
What|Removed |Added
Summary|[12/13 Regression] ICE in |[12 Regression] ICE in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108998
--- Comment #5 from CVS Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:341e6cd8d603a334fd34657a6b454176be1c6437
commit r13-6452-g341e6cd8d603a334fd34657a6b454176be1c6437
Author: Patrick Palka
Date: F
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107939
Marek Polacek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109012
Bug ID: 109012
Summary: Repeated error messages when using -std=c++23
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101118
--- Comment #7 from Iain Sandoe ---
(In reply to Jan Hubicka from comment #6)
from me there has been no progress on anything co-routines related, for a while
- I of not have any resources to work on it.
> I am not really expert on coroutines.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108887
--- Comment #4 from Jakub Jelinek ---
Perhaps, but shouldn't we also unlink_from_assembler_name_hash (node, false);?
I think the point of the current removal is that we've discovered the mangling
alias clashes with some other symbol.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101118
--- Comment #6 from Jan Hubicka ---
I am not really expert on coroutines. But this seems to be a type (not a
declaration we globalize during LTO) generated internally by the front-end.
The name __D.9984.3.4 looks like it has a global counter in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106896
--- Comment #10 from Jan Hubicka ---
The problem the assert is trying to solve is that local counters are all
frequencies relative to the entry block count, while IPA counters are absolute
values within the whole program. So comparing them mixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101118
--- Comment #5 from John Drouhard ---
Has there been any progress toward resolution for this? We've been trying to
use coroutines in our project but we require LTO for performance reasons, so
this is holding us back.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108996
--- Comment #6 from Mark Wielaard ---
(In reply to Jakub Jelinek from comment #5)
> So, I wonder if we just shouldn't ask for a DWARF 6 extension here, have
> some way for the compiler to specify DW_AT_location for the return value.
There is ht
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108887
--- Comment #3 from Jan Hubicka ---
We don't really have way to mark nodes for removal. I am not 100% sure I
understand what the code does, but removing random nodes from cgraph in hook
invoked from mangling seems dangerous, since we invoke DEC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108986
Jakub Jelinek changed:
What|Removed |Added
Summary|[11/12/13 Regression] |[11/12 Regression]
|I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108998
Patrick Palka changed:
What|Removed |Added
Summary|[13 Regression] ICE in |[12/13 Regression] ICE in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108986
--- Comment #5 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:1b0e3f8ca369f63d3e1a8e1c268d93530035503a
commit r13-6450-g1b0e3f8ca369f63d3e1a8e1c268d93530035503a
Author: Jakub Jelinek
Date: F
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108141
--- Comment #7 from Vladimir Makarov ---
(In reply to Jakub Jelinek from comment #6)
> The change has been reverted, so this is no longer a regression.
Just for the info. The patch I reverted resulted in wrong calculation of
pressure classes (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108999
Vladimir Makarov changed:
What|Removed |Added
CC||vmakarov at gcc dot gnu.org
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109011
Bug ID: 109011
Summary: missed optimization in presence of __builtin_ctz
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Componen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109008
--- Comment #12 from Jakub Jelinek ---
(In reply to Richard Biener from comment #11)
I think before we code something on the compiler side, it might be better
to play just with C testcases.
Quite naive
#include
__attribute__((noipa)) void
e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109010
--- Comment #1 from Richard Biener ---
I've tried to attach the full build log but it's too large even compressed.
Instead I placed it at https://gcc.opensuse.org/CPU2017.449.log.xz but it
might take a day or so for it to appear.
Not all leaks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109001
Patrick Palka changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107461
Patrick Palka changed:
What|Removed |Added
CC||headch at gmail dot com
--- Comment #16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108998
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=109010
Bug ID: 109010
Summary: Fortran frontend memory leaks building SPEC CPU 2017
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109009
Bug ID: 109009
Summary: Shrink Wrap missed opportunity
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimizati
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108924
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108923
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108996
Jakub Jelinek changed:
What|Removed |Added
CC||mark at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109008
--- Comment #11 from Richard Biener ---
I think for the reverse op I'd naiively try to compute the result as we do now
and then extend the range by one ulp of the input range with the largest
magnitude.
Does real_nextafter (0.0) result in a den
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109008
--- Comment #10 from Jakub Jelinek ---
So, can't we say compute what we compute right now for the reverse operation
and then call some helper function which will try to extended that range a
little bit in both directions by performing frange_ari
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108996
--- Comment #4 from Ulrich Weigand ---
(In reply to Jakub Jelinek from comment #3)
> What is done on other arches?
That depends on the platform ABI. On some arches, including x86/x86_64 and
arm/aarch64, the ABI requires the generated code relo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109008
--- Comment #9 from Richard Biener ---
(In reply to Richard Biener from comment #8)
> We basically have to consider an input range [a, b] as [a - x, b + y]
> with the largest positive x and y so that correctly rounding the value
> yields a and b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109008
--- Comment #8 from Richard Biener ---
We basically have to consider an input range [a, b] as [a - x, b + y]
with the largest positive x and y so that correctly rounding the value
yields a and b again.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109008
--- Comment #7 from Richard Biener ---
(In reply to Jakub Jelinek from comment #6)
> Note, the ulps frange_arithmetic are ulps of the result, result is in this
> case 0.0,
> so 1ulp is the smallest subnormal number.
> That is something completel
1 - 100 of 142 matches
Mail list logo
