https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71723
Thomas Koenig changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89213
--- Comment #3 from Michael Meissner ---
The vector shift sequence does not appear in Spec 2006 CPU compiled for power9.
The vector shift sequence does appear 4 times in the 602_gcc_s benchmark, and
once in the 683_imagick_s benchmark.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89211
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89212
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89214
Richard Biener changed:
What|Removed |Added
Keywords||ice-checking
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89217
Richard Biener changed:
What|Removed |Added
Keywords||error-recovery,
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58142
--- Comment #10 from Ev Drikos ---
(In reply to Jonathan Wakely from comment #9)
> ...
I'm not sure either. But I've confirmed in macOS (10.13) the following simple
hack.
If the routine that initialises the Emulated TLS created two keys and the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89219
Bug ID: 89219
Summary: [gfortran 7.3] compiler throws internal compiler
error: segmentation fault
Product: gcc
Version: 7.3.0
Status: UNCONFIRMED
Severity: norm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89210
--- Comment #2 from Jakub Jelinek ---
Author: jakub
Date: Wed Feb 6 09:16:19 2019
New Revision: 268573
URL: https://gcc.gnu.org/viewcvs?rev=268573&root=gcc&view=rev
Log:
PR middle-end/89210
* fold-const-call.c (fold_const_vec_co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89211
--- Comment #4 from Jakub Jelinek ---
Author: jakub
Date: Wed Feb 6 09:17:55 2019
New Revision: 268574
URL: https://gcc.gnu.org/viewcvs?rev=268574&root=gcc&view=rev
Log:
PR c/89211
* c-parser.c (c_parser_declaration_or_fndef): D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89210
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89211
Jakub Jelinek changed:
What|Removed |Added
Summary|[8/9 Regression] ICE in |[8 Regression] ICE in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89219
--- Comment #1 from Richard Biener ---
Works for me with FSF 7.3.0 on x86_64-linux.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89220
Bug ID: 89220
Summary: Inconsistent behaviour of class template type
deduction
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priori
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84201
--- Comment #6 from Richard Biener ---
If Martins bisection to power.fppized.o is correct you can bisect the loop
via the vect_loop or vect_slp debug counters (or first try with just
-fno-tree-{loop,slp}-vectorize to narrow down to loop vs. BB ve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88074
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|NEW
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89220
--- Comment #1 from Matt A ---
// ... but this compiles again
auto z = ((Foo(123)))(0);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89219
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89220
--- Comment #2 from Jonathan Wakely ---
(In reply to Matt A from comment #0)
> Interestingly with "-std=c++1y" both x and y fail to compile, which is at
> least consistent (even if I'm not sure it's correct...)
It's correct. -std=c++1y is a syno
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87709
Jonathan Wakely changed:
What|Removed |Added
CC||matt at ookypooky dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89220
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88415
--- Comment #5 from Richard Biener ---
For backport depends on some earlier change.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88415
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89221
Bug ID: 89221
Summary: --enable-frame-pointer does not work as intended
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89182
--- Comment #3 from Richard Biener ---
Author: rguenth
Date: Wed Feb 6 11:18:33 2019
New Revision: 268575
URL: https://gcc.gnu.org/viewcvs?rev=268575&root=gcc&view=rev
Log:
2019-02-06 Richard Biener
PR tree-optimization/89182
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89182
Richard Biener changed:
What|Removed |Added
Known to work||9.0
Summary|[8/9 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89154
--- Comment #4 from Segher Boessenkool ---
The r1 adjustment is establishing the stack frame. It needs to precede all
stack accesses (not just those by the prologue saves!) We could separately
wrap it, if that would help? You can then get mult
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89222
Bug ID: 89222
Summary: [7.x regression] ARM thumb-2 misoptimisation of func
ptr call with -O2 or -Os
Product: gcc
Version: 7.3.0
Status: UNCONFIRMED
Severity: n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89222
--- Comment #1 from Jonathan Larmour ---
Created attachment 45617
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45617&action=edit
Assembler file generated by GCC when compiled with -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89213
--- Comment #4 from Segher Boessenkool ---
You could just do
xxspltib xx,sh
vsrad 2,2,xx
(only the low 6 bits of the shift count are looked at, for 64-bit shifts,
in all vector insns).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84075
Marc Schmitt changed:
What|Removed |Added
CC||schmitt.marc at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84075
--- Comment #6 from Marc Schmitt ---
Created attachment 45618
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45618&action=edit
Reduced test case with eigen-only dependency
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84075
--- Comment #7 from Marc Schmitt ---
Created attachment 45619
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45619&action=edit
Preprocessed test case with eigen-only dependency
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89223
Bug ID: 89223
Summary: internal compiler error: in int_cst_value, at
tree.c:11226
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Prior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89224
Bug ID: 89224
Summary: subscript of NEON intrinsic discards const
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89135
--- Comment #6 from Richard Biener ---
Author: rguenth
Date: Wed Feb 6 12:56:02 2019
New Revision: 268578
URL: https://gcc.gnu.org/viewcvs?rev=268578&root=gcc&view=rev
Log:
2019-02-06 Richard Biener
Backport from mainline
20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88903
--- Comment #8 from Richard Biener ---
Author: rguenth
Date: Wed Feb 6 12:56:02 2019
New Revision: 268578
URL: https://gcc.gnu.org/viewcvs?rev=268578&root=gcc&view=rev
Log:
2019-02-06 Richard Biener
Backport from mainline
20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89213
--- Comment #5 from Michael Meissner ---
Sure I could use XXSPLTIB all of the time if I limit the optimization to ISA
3.0 (power9). I was trying to add optimization for shift counts for 1..15 on
ISA 2.07 (power8) as well, hence using VSPLTISW fo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89215
--- Comment #1 from Jakub Jelinek ---
Seems to be upstream bug, also in asan etc., Demangle(name) in there doesn't
really differentiate between cases where it allocated the memory or just
returned the passed in string or did something else.
E.g.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84075
Christoph Hertzberg changed:
What|Removed |Added
CC||chtz at informatik dot
uni-bremen.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71302
David Malcolm changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88749
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at mengyan1223 dot wang
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89225
Bug ID: 89225
Summary: [9 Regression] LRA hang on ppc64le compiling glibc
starting with r268404
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89225
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89223
David Malcolm changed:
What|Removed |Added
Keywords||ice-on-valid-code
Status|UNC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89215
--- Comment #2 from Jakub Jelinek ---
E.g. the LLVM demangler even documents that leak:
const char *DemangleCXXABI(const char *name) {
// FIXME: __cxa_demangle aggressively insists on allocating memory.
// There's not much we can do about tha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89158
--- Comment #8 from Marek Polacek ---
Author: mpolacek
Date: Wed Feb 6 15:26:24 2019
New Revision: 268580
URL: https://gcc.gnu.org/viewcvs?rev=268580&root=gcc&view=rev
Log:
PR c++/89158 - by-value capture of constexpr variable broken.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89158
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89199
boger at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P2
Severity|normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88983
--- Comment #7 from Marek Polacek ---
Author: mpolacek
Date: Wed Feb 6 15:29:14 2019
New Revision: 268581
URL: https://gcc.gnu.org/viewcvs?rev=268581&root=gcc&view=rev
Log:
PR c++/88983 - ICE with switch in constexpr function.
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88983
Marek Polacek changed:
What|Removed |Added
Summary|[7/8 Regression] ICE in |[7 Regression] ICE in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89119
--- Comment #9 from Marek Polacek ---
Author: mpolacek
Date: Wed Feb 6 15:33:18 2019
New Revision: 268582
URL: https://gcc.gnu.org/viewcvs?rev=268582&root=gcc&view=rev
Log:
PR c++/89119 - ICE with value-initialization in template.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89223
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89119
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89024
--- Comment #9 from Marek Polacek ---
Author: mpolacek
Date: Wed Feb 6 15:36:20 2019
New Revision: 268583
URL: https://gcc.gnu.org/viewcvs?rev=268583&root=gcc&view=rev
Log:
PR c++/89024 - ICE with incomplete enum type.
* call.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89024
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88983
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84251
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
--- Comment #10 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89223
--- Comment #3 from Jakub Jelinek ---
Started with r210113.
int_cst_value changed there:
/* Make sure the sign-extended value will fit in a HOST_WIDE_INT. */
- gcc_assert (TREE_INT_CST_HIGH (x) == 0
- || TREE_INT_CST_HIGH (x) ==
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89223
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P2
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89225
--- Comment #1 from Vladimir Makarov ---
It seems my latest patch for PR87246 caused this:
https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=268404
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89223
--- Comment #4 from Jakub Jelinek ---
I guess either we should lower ARRAY_REF indexes with precisions higher than
pointer precision to that smaller precision early (during gimplification
e.g.?), though not really sure what effect would that have
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89223
Jakub Jelinek changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88856
--- Comment #22 from Jakub Jelinek ---
What we could do there is remove the first of those two splitters, remove the
&& !dead_or_set_p (insn, operands[1])
test from the second, and add peephole2 that would transform
(set (access part 1) (subre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88856
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89123
--- Comment #10 from rdapp at linux dot ibm.com ---
Created attachment 45621
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45621&action=edit
Tentative patch for libgo on s390x
I didn't manage to make much progress with analyzing the remain
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89213
--- Comment #6 from Segher Boessenkool ---
For 32-bit or smaller shifts you can use vspltisb always, or vspltis[hw] if
you prefer.
If generating code for ISA 2.07 (Power8) you don't have xxspltib but you do
have vsld/vsrd/vsrad/vrld, hrm. You s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84201
--- Comment #7 from Steve Ellcey ---
(In reply to Richard Biener from comment #6)
> If Martins bisection to power.fppized.o is correct you can bisect the loop
> via the vect_loop or vect_slp debug counters (or first try with just
> -fno-tree-{loo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89195
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
Wilco changed:
What|Removed |Added
CC||wilco at gcc dot gnu.org
--- Comment #8 from Wil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89102
--- Comment #3 from Jonathan Wakely ---
Author: redi
Date: Wed Feb 6 17:25:26 2019
New Revision: 268586
URL: https://gcc.gnu.org/viewcvs?rev=268586&root=gcc&view=rev
Log:
PR libstdc++/89102 fix common_type<> and common_type specializations
Thi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88596
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89217
--- Comment #4 from Marek Polacek ---
Some sort of modification happens twice for the RANGE_FOR_EXPR. Originally we
have
{*((struct S *) this)->r}
which should be turned to
TARGET_EXPR r}>
but we now reprocess this again and get bogus
TARGET_EXP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89222
--- Comment #2 from Jakub Jelinek ---
Not confirming since it is unclear even on what OS you are using this and what
to look for (I don't see r5 set close to start of main etc.). That said, if
hal_setjmp works similarly to setjmp, but you don't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88049
--- Comment #4 from Jason Merrill ---
(In reply to Jan Hubicka from comment #3)
> > > We ICE on the fact that _ZTV1aIN12_GLOBAL__N_11fEE which is vtable for
> > > anonymous namespace type but it has EXTERNAL flag set.
> > >
> > > Jason, why this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84251
--- Comment #11 from Jeffrey A. Law ---
Oh, DOM is too early, it's expansion that exposes the redundancies. Seems
like CSE ought to be able to pick this up though.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89222
--- Comment #3 from Jonathan Larmour ---
Thanks for the quick reply.
(In reply to Jakub Jelinek from comment #2)
> Not confirming since it is unclear even on what OS you are using this
It's an embedded OS, so from your point of view, it's essen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87451
--- Comment #14 from Rainer Orth ---
Author: ro
Date: Wed Feb 6 18:54:16 2019
New Revision: 268588
URL: https://gcc.gnu.org/viewcvs?rev=268588&root=gcc&view=rev
Log:
Fix gcc.dg/debug/dwarf2/inline5.c with Solaris as (PR debug/87451)
PR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89222
Andrew Pinski changed:
What|Removed |Added
Keywords||wrong-code
--- Comment #4 from Andrew Pi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89226
Bug ID: 89226
Summary: codegen for copying a 512-bit object fails to use avx
instructions
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89102
--- Comment #4 from Jonathan Wakely ---
Minimal fix committed to trunk, with a complete fix posted to
https://gcc.gnu.org/ml/gcc-patches/2019-02/msg00346.html for stage 1.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89102
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|9.0 |8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71302
--- Comment #4 from David Malcolm ---
Author: dmalcolm
Date: Wed Feb 6 19:44:52 2019
New Revision: 268589
URL: https://gcc.gnu.org/viewcvs?rev=268589&root=gcc&view=rev
Log:
Fix locations in conversion_null_warnings (PR c++/71302)
PR c++/71302
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71302
David Malcolm changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89227
Bug ID: 89227
Summary: gotools test cmd/go fails with link error "call lacks
nop, can't restore toc; recompile with -fPIC"
Product: gcc
Version: 9.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89226
--- Comment #1 from Marc Glisse ---
The optimized dump for copy1 looks like
*to_2(D) = *from_3(D);
so we get essentially memcpy, while copy2 has
_4 = MEM[(const struct foo512 &)from_3(D)].a;
MEM[(struct foo512 *)to_2(D)].a = _4;
_5 = M
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89227
--- Comment #1 from Ian Lance Taylor ---
Same as https://golang.org/issue/29046?
I would bet that this has something to do with the fact that testenv.HasLink is
inlinable. Something is wrong with the way that the frontend is passing the
inlinab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89226
--- Comment #2 from Jakub Jelinek ---
That is because in copy1 it is a normal memcpy expansion.
And, the generic move_by_pieces case is done in preference to target specific
one. In i386.h we have:
/* Max number of bytes we can move from memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71860
--- Comment #6 from Thomas Koenig ---
Author: tkoenig
Date: Wed Feb 6 20:34:42 2019
New Revision: 268590
URL: https://gcc.gnu.org/viewcvs?rev=268590&root=gcc&view=rev
Log:
2019-02-06 Thomas Koenig
PR fortran/71860
* gfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89226
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71860
Thomas Koenig changed:
What|Removed |Added
Keywords|ice-on-invalid-code |
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89226
--- Comment #4 from Jakub Jelinek ---
Maybe i386.c would need its own ix86_use_by_pieces_infrastructure_p target hook
if the default wouldn't do the right thing with this. Maybe we'll need to
split STORE_MAX_PIECES into separately overridable CL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89199
--- Comment #2 from ian at gcc dot gnu.org ---
Author: ian
Date: Wed Feb 6 20:46:00 2019
New Revision: 268591
URL: https://gcc.gnu.org/viewcvs?rev=268591&root=gcc&view=rev
Log:
PR go/89199
sync/atomic: use strong form of atomic_comp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89199
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89164
Jonathan Wakely changed:
What|Removed |Added
Keywords||patch
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89227
boger at gcc dot gnu.org changed:
What|Removed |Added
CC||seurer at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88919
--- Comment #5 from seurer at gcc dot gnu.org ---
Note that the change was backported to gcc 8 (r268578) and the test case fails
there now the same way.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89226
--- Comment #5 from H.J. Lu ---
(In reply to Jakub Jelinek from comment #3)
> Seems most of the *by_pieces code actually uses widest_int_mode_for_size
> which already handles even the wider modes as long as they have a mov
> instruction. With th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78063
Tom de Vries changed:
What|Removed |Added
CC||vries at gcc dot gnu.org
--- Comment #4 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86020
Bill Schmidt changed:
What|Removed |Added
Known to work||9.0
--- Comment #10 from Bill Schmidt --
1 - 100 of 126 matches
Mail list logo