https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78760
Eric Gallager changed:
What|Removed |Added
CC||dmalcolm at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81679
--- Comment #5 from Eric Gallager ---
(In reply to jos...@codesourcery.com from comment #4)
> On Wed, 2 Aug 2017, msebor at gcc dot gnu.org wrote:
>
> > If there is a concern that the attribute could be used on declarations in
> > existing code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87869
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83353
--- Comment #5 from joseph at codesourcery dot com ---
asin(sin(a)) is not safe (or at least not simple) because of arguments
outside [-pi/2, pi/2]. sin(asin(a)) is more appropriate with -ffast-math
because arguments outside [-1,1] are
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40503
--- Comment #10 from joseph at codesourcery dot com ---
I was not attempting to confirm that GCC had a particular bug.
In this case: as I said, no excess precision support is hooked up for
decimal floating point (i.e., whatever the back end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87872
Bug ID: 87872
Summary: debug list::splice should not call _M_transfer_from_if
on self-splices
Product: gcc
Version: 7.3.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
Bug ID: 87871
Summary: [9 Regression] testcases fail after r265398 on arm
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87678
--- Comment #9 from Segher Boessenkool ---
Ah. So you want this optimisation (which is currently done by LRA) to be done
by combine as well; it's not that the resulting assembler code for this
testcase
is worse than what you'd like to see. And
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87870
Bug ID: 87870
Summary: ppc64le generates poor code when loading constants
into TImode vars
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46020
--- Comment #14 from Thomas Koenig ---
Author: tkoenig
Date: Fri Nov 2 20:20:43 2018
New Revision: 265757
URL: https://gcc.gnu.org/viewcvs?rev=265757=gcc=rev
Log:
2018-11-02 Thomas Koenig
PR fortran/46020
* decl.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87678
--- Comment #8 from Uroš Bizjak ---
(In reply to Segher Boessenkool from comment #7)
> It's not clear to me what you would have liked it to do instead?
The loads from constant memory pools always have REG_EQUAL of a relevant
constant attached
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83656
--- Comment #5 from Martin Sebor ---
Revised patch that should resolve the autoconf concerns:
https://gcc.gnu.org/ml/gcc-patches/2018-11/msg00120.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47030
--- Comment #7 from marco atzeri ---
I am trying to update the draft patch of Tobias to gcc-7.3.0
the current gcc on cygwin.
The attached patch builds but does not solve the problem of
!GCC$ attributes dllexport :: /mydata/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47030
--- Comment #6 from marco atzeri ---
Created attachment 44949
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44949=edit
updated patch for 7.3.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87865
--- Comment #3 from Iain Buclaw ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #2)
> > --- Comment #1 from Iain Buclaw ---
> > This is part of the dmd frontend which as no interaction with gcc. So
> > gcc_unreachable() can't be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87869
--- Comment #1 from Nick Bowler ---
Er, I can't count, the unrolled loop is only ~four times the size.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87869
Bug ID: 87869
Summary: Unrolled loop leads to excessive code bloat with -Os
on ARC EM.
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16166
--- Comment #14 from Eric Gallager ---
This came up on the gcc-help mailing list here:
https://gcc.gnu.org/ml/gcc-help/2018-11/msg3.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87868
Bug ID: 87868
Summary: testsuite/c-c++-common/pr60101.c with -O3 and ubsan
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83173
--- Comment #11 from Mike Gulick ---
(In reply to Mike Gulick from comment #10)
> In hopes of seeing some progress on this bug, I will rebase the patches on
> the latest gcc master branch and re-test. I will also refactor the main
> patch to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87864
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #1 from Iain Buclaw ---
> Is there another way to get a section in earlier versions of Solaris?
What I initially did in LLVM's compiler-rt (which prompted the addition
of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87865
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #1 from Iain Buclaw ---
> This is part of the dmd frontend which as no interaction with gcc. So
> gcc_unreachable() can't be used here.
I see. However, if upstream dmc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87867
Bug ID: 87867
Summary: ICE on virtual destructor (-mlong-calls
-ffunction-sections) on arm-none-eabi
Product: gcc
Version: 8.2.1
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87864
--- Comment #1 from Iain Buclaw ---
Is there another way to get a section in earlier versions of Solaris?
The alternative is to support a vagary of methods in order to determine loaded
modules at runtime.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87678
--- Comment #7 from Segher Boessenkool ---
Hi Uros,
It's not clear to me what you would have liked it to do instead?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87865
--- Comment #1 from Iain Buclaw ---
This is part of the dmd frontend which as no interaction with gcc. So
gcc_unreachable() can't be used here.
Sounds like some independent compatibility layer is required here instead.
Hi Enrique,
Flu season is here, and the office is the perfect place for those germs to
spread like wildfire. The risks are nothing to sneeze at: according to the
Centers for Disease Control and Prevention, the flu alone costs U.S.
companies $10.4 billion per year.
Bringing Vanguard Cleaning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87678
--- Comment #6 from Uroš Bizjak ---
Here is a bit simpler testcase:
--cut here--
typedef float __v4sf __attribute__((__vector_size__ (16)));
__v4sf
foo (__v4sf x)
{
return x + (__v4sf){ 2.3f, 2.3f, 2.3f, 2.3f };
}
--cut here--
"cc1 -O2" on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87678
--- Comment #5 from Uroš Bizjak ---
(In reply to Segher Boessenkool from comment #4)
> It tries twice, first just the substitution, and then that modified with
> the REG_EQUAL. You know a mem is not often valid in the resulting insn,
> but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87861
--- Comment #3 from Andreas Schwab ---
http://gcc.gnu.org/ml/gcc-patches/2018-09/msg01052.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87678
--- Comment #4 from Segher Boessenkool ---
It tries twice, first just the substitution, and then that modified with
the REG_EQUAL. You know a mem is not often valid in the resulting insn,
but combine doesn't, and that is not the same thing as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81878
--- Comment #42 from Tamar Christina ---
Author: tnfchris
Date: Fri Nov 2 15:27:30 2018
New Revision: 265749
URL: https://gcc.gnu.org/viewcvs?rev=265749=gcc=rev
Log:
Fix mingw-w64 Ada native bootstrap (PR81878).
Due to the changes in PR81878
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70831
Jeffrey A. Law changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87861
--- Comment #2 from Marek Polacek ---
It's unlikely that this is caused by my latest patch implementing P0846R0, that
only triggers with C++2a.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87853
--- Comment #6 from Uroš Bizjak ---
(In reply to Terry Guo from comment #5)
> What about a fix like below? I tested with bootstrap and regression test,
> there is no problem.
LGTM.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87852
--- Comment #7 from Eric Botcazou ---
> Eric, you added partitions_for_undefined_values and IIRC that was just narrow
> scope enough to fix a specific issue but not generally address shortcomings
> within RTL?
Yes, it's only enabled for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87861
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87866
Rainer Orth changed:
What|Removed |Added
Target Milestone|--- |9.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87866
Bug ID: 87866
Summary: gdc fails to compile minimal test
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87865
Rainer Orth changed:
What|Removed |Added
Target Milestone|--- |9.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82501
Martin Liška changed:
What|Removed |Added
Target Milestone|9.0 |10.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87865
Bug ID: 87865
Summary: gdc doesn't build unless assert is marked noreturn
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87864
Rainer Orth changed:
What|Removed |Added
Target Milestone|--- |9.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87864
Bug ID: 87864
Summary: libdruntime doesn't link with /bin/ld before Solaris
11.4
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87862
--- Comment #2 from Jonathan Wakely ---
The relevant quote from the standard is:
If a template, a member template or a member of a class template is explicitly
specialized then that specialization shall be declared before the first use of
that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87853
--- Comment #5 from Terry Guo ---
Hi folks,
What about a fix like below? I tested with bootstrap and regression test, there
is no problem.
diff --git a/gcc/config/i386/emmintrin.h b/gcc/config/i386/emmintrin.h
index 7a6ff80..3c1f04b 100644
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87863
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |9.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87862
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87859
--- Comment #2 from Jakub Jelinek ---
Created attachment 44948
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44948=edit
gcc9-pr87859.patch
WIP patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87843
--- Comment #15 from Richard Biener ---
But the following fixes it:
diff --git a/gcc/alias.c b/gcc/alias.c
index 7963ece291a..4c88c0980d3 100644
--- a/gcc/alias.c
+++ b/gcc/alias.c
@@ -1235,14 +1235,14 @@ record_component_aliases (tree type)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87863
Bug ID: 87863
Summary: c-c++-common/gomp/gridify-{2,3}.c ICE
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: openmp
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87843
--- Comment #14 from Richard Biener ---
The following does _not_ fix it (but an assert that the alias-set is -1 does
trigger). We probably have to adjust all types the record parent is embedded
into as well for which there's no easy way.
Well.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87843
--- Comment #13 from Richard Biener ---
So the alias machinery disambiguates them at
static bool
indirect_refs_may_alias_p (tree ref1 ATTRIBUTE_UNUSED, tree base1,
poly_int64 offset1, poly_int64 max_size1,
...
/* Do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87843
--- Comment #12 from Richard Biener ---
OK, so in GCC 8 at least pointer-to-incomplete type gets the alias set of void
* and that conflicts with any other pointer. So that works.
Not sure what breaks here now...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87862
Bug ID: 87862
Summary: Different behavior with -O2 with template
specialization of virtual member function
Product: gcc
Version: 7.3.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87843
--- Comment #11 from Richard Biener ---
That said - we used to give all pointer types the same alias-set but you
somehow convinced yourself that not doing that is safe. Even when considering
pointer-to-complete and pointer-to-incomplete types.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87843
--- Comment #10 from Richard Biener ---
I can only see that v->locs might be affected by fld because the type of the
FIELD_DECL changes but the (alias) type of *p_11 remains the same. Thus
we have get_alias_set (ptr-to-incomplete) and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25844
--- Comment #21 from simon at pushface dot org ---
This bug was fixed in GCC 5 (5.2.0, x86_64-apple-darwin15) and is still fixed
up to GCC 9.0.0 20180927.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87843
--- Comment #9 from Jan Hubicka ---
Created attachment 44946
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44946=edit
reproducer
I am attaching the preprocessed file and will be away till 2pm.
What seems to be wrong is that we optimize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87860
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |9.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87861
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |9.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87859
Richard Biener changed:
What|Removed |Added
Keywords||wrong-code
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87843
--- Comment #8 from Richard Biener ---
(In reply to Jan Hubicka from comment #7)
> > If we have less MEM_REFs then we probably strip them because we think they
> > reference equal types.
> >
> > I think I already told you that given that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14557
--- Comment #23 from nsz at gcc dot gnu.org ---
(In reply to felix from comment #21)
> > va_list ap2;
> > va_copy(ap2, ap);
>
> > and then use , this always works.
>
> > the proposed macros are both broken and unnecessary.
>
> That's not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87852
--- Comment #6 from Richard Biener ---
And fwprop before that questionable code does
/* We used to have a def reaching a use that is _before_ the def,
with the def not dominating the use even though the use and def
are in the same
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87859
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87843
--- Comment #7 from Jan Hubicka ---
> If we have less MEM_REFs then we probably strip them because we think they
> reference equal types.
>
> I think I already told you that given that MEM_REFs use pointer types
> to carry alignment info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87852
Richard Biener changed:
What|Removed |Added
CC||aoliva at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87857
--- Comment #5 from Stas Sergeev ---
(In reply to Jakub Jelinek from comment #4)
> The reason you get an error is that the expression isn't constant, because
> it needs to emit the runtime diagnostics. Just fix the bug and get away
> with that?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87852
Richard Biener changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87861
Bug ID: 87861
Summary: [9 regression] ICE in
output_constructor_regular_field, at varasm.c:5165
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: build,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87678
--- Comment #3 from Uroš Bizjak ---
Another similar problem:
__m128
bar (__m128 x)
{
return x + _mm_set1_ps (2.3f);
}
gcc -O2 -msse2 creates following _combine dump:
--cut here--
Trying 6 -> 7:
6: r85:V4SF=[`*.LC0']
REG_EQUAL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70380
--- Comment #3 from Jonathan Wakely ---
Both Clang and EDG also reject the same two statements.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87855
--- Comment #4 from fiesh at zefix dot tv ---
Heh ok, you tricked me ;)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87855
--- Comment #3 from Ville Voutilainen ---
The fix is not quite right. I'll do a more intrusive one. Stay tuned.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87855
--- Comment #2 from fiesh at zefix dot tv ---
This fixes the problem. Thank you so much for your effort!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87857
--- Comment #4 from Jakub Jelinek ---
The reason you get an error is that the expression isn't constant, because it
needs to emit the runtime diagnostics. Just fix the bug and get away with
that? 1U<<31 will do.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87854
Richard Biener changed:
What|Removed |Added
Target||msp430, avr
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87852
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87851
Richard Biener changed:
What|Removed |Added
Priority|P3 |P4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64928
--- Comment #27 from Richard Biener ---
Btw, on trunk for the small testcase the main peak memory user is
Bitmaps LeakPeak
Times N searches Search iter Type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81486
Ted Lyngmo changed:
What|Removed |Added
CC||ted at lyncon dot se
--- Comment #3 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87860
Martin Liška changed:
What|Removed |Added
URL||https://reviews.llvm.org/D5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87849
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87848
Richard Biener changed:
What|Removed |Added
Keywords||ice-on-valid-code
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87843
--- Comment #6 from Richard Biener ---
If we have less MEM_REFs then we probably strip them because we think they
reference equal types.
I think I already told you that given that MEM_REFs use pointer types
to carry alignment info _those_ may
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87860
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87860
Bug ID: 87860
Summary: [9 Regression] libsanitizer build fails on
sparc64-linux-gnu
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87776
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87837
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87836
Richard Biener changed:
What|Removed |Added
Target||sparc
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87837
--- Comment #8 from Richard Biener ---
(In reply to Jakub Jelinek from comment #7)
> That is unfortunately too hard, because there are just too many places where
> the FEs can construct these.
> That said, having one macro like
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87859
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|--- |8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87859
Bug ID: 87859
Summary: [8/9 Regression] store-merging miscompilation of mesa
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87837
--- Comment #7 from Jakub Jelinek ---
That is unfortunately too hard, because there are just too many places where
the FEs can construct these.
That said, having one macro like TYPE_OVERFLOW_UNDEFINED that would combine
that and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87837
--- Comment #6 from Richard Biener ---
Just have to repeat that I very much dislike TYPE_OVERFLOW_SANITIZED being
sprinkled all over the place... just instrument before folding things?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83348
--- Comment #3 from Richard Biener ---
Well, as said in the comment there's room for improvements.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83353
--- Comment #4 from Richard Biener ---
So asin(sin(a)) would be a no-brainer but sin(asin(a)) needs to handle a being
outside of [-1,1].
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87827
--- Comment #2 from ibuclaw at gcc dot gnu.org ---
Author: ibuclaw
Date: Fri Nov 2 08:29:50 2018
New Revision: 265742
URL: https://gcc.gnu.org/viewcvs?rev=265742=gcc=rev
Log:
Fix libgphobos.spec in the wrong place with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83352
--- Comment #3 from Richard Biener ---
It's first canonicalized to
[local count: 1073741824]:
_4 = ABS_EXPR ;
_2 = __builtin_pow (_4, 3.125e-2);
and then expanded again to
[local count: 1073741824]:
_4 = ABS_EXPR ;
powroot_5 =
1 - 100 of 105 matches
Mail list logo
