https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97898
Richard Biener changed:
What|Removed |Added
Component|c |middle-end
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97897
Richard Biener changed:
What|Removed |Added
Component|c |tree-optimization
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97896
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |11.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97895
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97579
--- Comment #8 from Richard Biener ---
(In reply to Jakub Jelinek from comment #7)
> Actually still ICEs.
Yes, it was just a fix for the ISEL logic which was broken, not yet a fix for
the actual testcase.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97901
Bug ID: 97901
Summary: ICE at -Os: verify_gimple failed
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93176
Alan Modra changed:
What|Removed |Added
URL|https://gcc.gnu.org/piperma |https://gcc.gnu.org/piperma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97891
--- Comment #3 from Hongtao.liu ---
This problem is very similar to the one pass_rpad deals with.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97900
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97900
Marek Polacek changed:
What|Removed |Added
Priority|P3 |P2
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97900
--- Comment #2 from Marek Polacek ---
Confirmed. Started with r266055.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97899
--- Comment #8 from Marek Polacek ---
Reduced even more:
// PR c++/97899
template
int fn()
{
return 1;
}
template
void bar() {
const int i = int{fn()};
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91029
--- Comment #8 from Bruno Haible ---
> what is the reason to require that b >= 0 in all of this?
In the 1990ies there were portability problems with a%b, b < 0. ANSI C said
that the result was machine-dependent if a < 0 or b < 0. Fortunately the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89197
Marek Polacek changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97900
--- Comment #1 from Jonathan Strobl ---
Created attachment 49593
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49593&action=edit
gcc -v and crash output
Attaching the output seems to have failed last time. Here it is.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97900
Bug ID: 97900
Summary: g++ crashes when instantiating a templated function
with a template-type vector parameter
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89197
Marek Polacek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89197
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97899
--- Comment #7 from Florin Iucha ---
Cool, thank you!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97899
--- Comment #6 from Marek Polacek ---
Reduced:
// PR c++/97899
template
T fn(T a)
{
return a;
}
template
struct C {
void bar() {
int d = 42;
const int i = int{fn(d)};
}
};
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97899
--- Comment #5 from Florin Iucha ---
Curious, were you able to reduce it further, or just bisected it?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97899
--- Comment #4 from Marek Polacek ---
Started with r11-4959.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97899
--- Comment #3 from Florin Iucha ---
gcc version 11.0.0 20201108 (previous snapshot) is compiling fine.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97899
Marek Polacek changed:
What|Removed |Added
Last reconfirmed||2020-11-19
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97899
--- Comment #1 from Florin Iucha ---
Created attachment 49590
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49590&action=edit
pre-processed source file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97899
Bug ID: 97899
Summary: internal compiler error: in split_nonconstant_init_1,
at cp/typeck2.c:626
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97817
--- Comment #5 from Martin Sebor ---
I agree that the text of the warning could be improved. I'm hoping to make
changes along the lines you suggest for GCC 12 (it's too late for GCC 11),
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97847
--- Comment #4 from Segher Boessenkool ---
This was caused (or exposed) by e3b3b59683c1:
commit e3b3b59683c1e7d31a9d313dd97394abebf644be
Author: Vladimir N. Makarov
Date: Fri Nov 13 12:45:59 2020 -0500
[PATCH] Implementation of asm goto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97861
Martin Sebor changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97879
Martin Sebor changed:
What|Removed |Added
Keywords||patch
--- Comment #4 from Martin Sebor -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91029
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85811
--- Comment #10 from CVS Commits ---
The master branch has been updated by Jeff Law :
https://gcc.gnu.org/g:1be4878116a2be82552bd59c3c1c9adcac3d106b
commit r11-5152-g1be4878116a2be82552bd59c3c1c9adcac3d106b
Author: Roger Sayle
Date: Wed Nov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97888
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97896
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|WAITING |NEW
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91029
--- Comment #6 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:71c9d2b088c9d409a1bd3b50523ac4623a5bf1b4
commit r11-5150-g71c9d2b088c9d409a1bd3b50523ac4623a5bf1b4
Author: Jakub Jelinek
Date: We
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97888
--- Comment #6 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:71c9d2b088c9d409a1bd3b50523ac4623a5bf1b4
commit r11-5150-g71c9d2b088c9d409a1bd3b50523ac4623a5bf1b4
Author: Jakub Jelinek
Date: We
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97847
--- Comment #3 from Segher Boessenkool ---
I can now reproduce it, with a compiler built yesterday (previous was a
few days older), and -O0.
Confirmed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97893
David Malcolm changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97893
--- Comment #1 from CVS Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:f3f312b535f57b5773953746f6ad0d890ce09b88
commit r11-5148-gf3f312b535f57b5773953746f6ad0d890ce09b88
Author: David Malcolm
Date: We
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729
--- Comment #16 from abebeos at lazaridis dot com ---
I've updated the bounty, and you can follow the work here:
https://github.com/abebeos/avr-gnu
Whenever something relevant happens, I'll report it here.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97873
--- Comment #7 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #4)
> So then either we should expand the SWI48x mode abs for !TARGET_EXPAND_ABS
> into
> a pre-reload define_insn_and_split with abs that we'd split almost like
> smax,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96671
--- Comment #4 from CVS Commits ---
The master branch has been updated by Jeff Law :
https://gcc.gnu.org/g:f44e6091627372bd8fc4e72874a003643b021dca
commit r11-5146-gf44e6091627372bd8fc4e72874a003643b021dca
Author: Eugene Rozenfeld
Date: Wed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97865
--- Comment #15 from Iain Sandoe ---
(In reply to Jürgen Reuter from comment #14)
> If there is a git branch or so, I could also test it on my system with our
> code whether this works as expected.
Here you go - this is config.{sub, guess}, libt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85315
--- Comment #15 from rguenther at suse dot de ---
On November 18, 2020 3:55:44 PM GMT+01:00, amacleod at redhat dot com
wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85315
>
>--- Comment #12 from Andrew Macleod ---
>Maybe I'm a little de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97873
--- Comment #6 from Uroš Bizjak ---
The attached patch generates:
movl%edi, %eax
negl%eax
cmovs %edi, %eax
ret
The patch changes CC mode of NEG instruction to CCGOCmode, which is the same
mode as the mo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
--- Comment #40 from Jim Wilson ---
If you look at riscv.opt you will see that the -mshorten-memrefs option sets
the variable riscv_mshorten_memrefs. If you grep for that, you will see that
it is used in riscv_address_cost in riscv.c. I believe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97873
--- Comment #5 from Uroš Bizjak ---
Created attachment 49588
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49588&action=edit
Proposed patch
Attached patch introduces relevant peephole2 pattern (and fixes some other
issues).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93176
--- Comment #5 from Peter Bergner ---
Alan, didn't one of your recent patches fix this particular bug? So can we
mark this as fixed?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97884
--- Comment #11 from Andreas Schwab ---
2147483648 does not fit in 32 bits.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97896
Dominique d'Humieres changed:
What|Removed |Added
Last reconfirmed||2020-11-18
Status|UNC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97879
Martin Sebor changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97884
--- Comment #10 from s.baur...@tu-berlin.de ---
(In reply to Jonathan Wakely from comment #9)
> (In reply to s.bauroth from comment #7)
> > > The type of an integer constant is the first of the corresponding list
> > > in which its value can be re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97860
--- Comment #7 from Martin Sebor ---
What I mean is that unless error_mark_node necessarily implies (and guarantees)
the bound is a constant zero (as opposed to a similarly "broken" VLA bound),
simply bailing is safer than skipping it. I have no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97876
--- Comment #4 from Jonathan Wakely ---
Github's poor life choices should not be our problem ;-)
If clang-8 doesn't ship and doesn't work with GCC's ,
I would interpret that as you can't test with clang-8.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97880
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97884
--- Comment #9 from Jonathan Wakely ---
(In reply to s.bauroth from comment #7)
> > The type of an integer constant is the first of the corresponding list
> > in which its value can be represented.
> These kind of sentences make me think gcc's be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97884
--- Comment #8 from Jakub Jelinek ---
If you design your own programming language, you can define it whatever way you
want, but for C and C++ it is well defined how the compiler must behave in
these cases, that -2147483648 are two separate tokens
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96377
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Resolution|FIXED |---
Status|RES
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97884
--- Comment #7 from s.baur...@tu-berlin.de ---
I do understand that +2147483648 is not an int. I am aware of how the 2s
complement works. It seems to me the reason for INT_MIN being '(-2147483647 -
1)' instead of the mathematically equivalent '-21
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97506
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97523
--- Comment #1 from Marek Polacek ---
Better test:
// PR c++/97523
// { dg-do compile }
struct T {
explicit T();
T(int);
};
void
fn (int n)
{
new T[1]();
new T[2]();
new T[3]();
new T[n]();
#if __cpp_aggregate_paren_init
new T[](
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97895
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
Last recon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97860
--- Comment #6 from Jakub Jelinek ---
As I said, [0] is not a VLA bound.
And we don't record anything for constant bounds (even if they are in the
middle).
So perhaps:
/* array_type_nelts assumes the middle-end TYPE_DOMAINs, while
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97898
Bug ID: 97898
Summary: ICE in outermost_invariant_loop, at
tree-ssa-loop-im.c:431
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Prio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97884
--- Comment #6 from Jonathan Wakely ---
The C standard says "The type of an integer constant is the first of the
corresponding list in which its value can be represented." The corresponding
list for decimal constants with no suffix is int, long i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97897
Bug ID: 97897
Summary: ICE tree check: expected ssa_name, have integer_cst in
compute_optimized_partition_bases, at
tree-ssa-coalesce.c:1638
Product: gcc
Version:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97896
Bug ID: 97896
Summary: [11 Regression] ICE in gfc_trans_assignment_1, at
fortran/trans-expr.c:11156
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: nor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97860
--- Comment #5 from Martin Sebor ---
Actually, I missed that your patch just skips over the error node. That will
leave the attribute spec out of sync with the argument (it contains a '$' for
each VLA bound). Rather than continuing to the next
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97895
Bug ID: 97895
Summary: [11 Regression] ICE in do_auto_deduction, at
cp/pt.c:29255
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Prio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97894
Bug ID: 97894
Summary: gcc/attr-fnspec.h: 8 * function could be const ?
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97884
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97884
--- Comment #4 from s.baur...@tu-berlin.de ---
I am aware of the warning, I disagree with it's content. INT_MIN is an int, not
a long long int. I understand why it is processed as a long long int
internally, but that should not be visible from the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97893
Bug ID: 97893
Summary: Analyzer should only use CWE 690 when null ptr is from
a function return
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97528
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=97528
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97884
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85315
--- Comment #14 from Martin Sebor ---
Andrew, we discussed the same idea for built-in functions at Couldron. For
instance, in:
void f (const char *s, int n)
{
char a[8];
memcpy (a, s, n); // n must be in [0, 8]
if (n < 0 ||
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97532
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97860
--- Comment #4 from Jakub Jelinek ---
(In reply to Martin Sebor from comment #3)
> I was going to commit the following but I'll leave it to you.
>
> diff --git a/gcc/c/c-decl.c b/gcc/c/c-decl.c
> index d348e39c27a..95cf9e4cb00 100644
> --- a/gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97860
--- Comment #3 from Martin Sebor ---
I was going to commit the following but I'll leave it to you.
diff --git a/gcc/c/c-decl.c b/gcc/c/c-decl.c
index d348e39c27a..95cf9e4cb00 100644
--- a/gcc/c/c-decl.c
+++ b/gcc/c/c-decl.c
@@ -5775,6 +5775,10 @
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97882
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22326
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97870
--- Comment #3 from CVS Commits ---
The master branch has been updated by Vladimir Makarov :
https://gcc.gnu.org/g:2f2709e691148160e4f88090eaf48d3e4915b0e4
commit r11-5131-g2f2709e691148160e4f88090eaf48d3e4915b0e4
Author: Vladimir N. Makarov
D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85315
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97887
Uroš Bizjak changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95192
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85315
--- Comment #12 from Andrew Macleod ---
Maybe I'm a little dense.
if we are presuming that
&x + (a + b)
implies a + b == 0, then we also should assume that
&x + a implies a == 0
and if we can make those assumptions, then
&x + 1 is garb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97891
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2020-11-18
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97892
Richard Biener changed:
What|Removed |Added
Summary|ICE in tree check: expected |[10/11 Regression] ICE in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96377
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97579
--- Comment #7 from Jakub Jelinek ---
Actually still ICEs.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97579
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97673
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97860
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97887
--- Comment #6 from Richard Biener ---
So likely caused by g:f359611b363490b48a7ce0fd021f7e47d8816eb0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97887
--- Comment #5 from Uroš Bizjak ---
> > This should have the following insn constraint:
> >
> > "TARGET_80387 && !(SSE_FLOAT_MODE_P (mode) && TARGET_SSE_MATH)"
> >
> > to hide it from combine in cases where relevant SSE mode is available.
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97887
--- Comment #4 from Richard Biener ---
(In reply to Uroš Bizjak from comment #3)
> (In reply to Richard Biener from comment #2)
> > combine first makes recog pick negsf2_i387_1:
>
> This should have the following insn constraint:
>
> "TARGET_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97862
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97873
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97832
--- Comment #9 from Richard Biener ---
There's then also a permute optimization left on the plate:
t.c:16:3: note: node 0x3a19590 (max_nunits=4, refcnt=2)
t.c:16:3: note: stmt 0 _153 = f11_im_76 * x1_im_142;
t.c:16:3: note: stm
1 - 100 of 165 matches
Mail list logo
