https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70182
Bug ID: 70182
Summary: c++filt fails to demangle
_ZNSt17_Function_handlerIFSt4pairImjEjEZN5folly12addBe
nchmarkI3$_0EENSt9enable_ifIXeqsr5boost14function_type
s14fu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70146
--- Comment #4 from H.J. Lu ---
(In reply to Andy Lutomirski from comment #3)
> I think a similar optimization could be applied to default-visibility
> references as well. For example, gcc can generate things like this:
>
> call__x86.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70181
Bug ID: 70181
Summary: missing -Wtautological-compare for constant
expressions
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70180
Bug ID: 70180
Summary: missing -Wpointer-arith on NULL arithmetic cast to a
an object type
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: minor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70179
Bug ID: 70179
Summary: PPC64 ICE with -mabi=ieeelongdouble and long double
complex
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Prio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70146
--- Comment #3 from Andy Lutomirski ---
I think a similar optimization could be applied to default-visibility
references as well. For example, gcc can generate things like this:
call__x86.get_pc_thunk.ax
addl$_GLOBAL_OFF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70162
--- Comment #2 from Oleg Endo ---
(In reply to Oleg Endo from comment #1)
>
> I guess there are more cases like (*2) above, where constants are encoded in
> a larger format than necessary.
Looks like that indeed. For example:
void bleh (volat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70171
Seth LaForge changed:
What|Removed |Added
CC||sethml at ofb dot net
--- Comment #1 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70150
--- Comment #4 from H.J. Lu ---
(In reply to Jakub Jelinek from comment #3)
> But -fno-pic should turn off even the default -fpie or -fPIE (if you force
> it through configure option) and also make sure neither __PIC__ nor __PIE__
> macros are de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70168
Ulrich Weigand changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70168
--- Comment #5 from Ulrich Weigand ---
Author: uweigand
Date: Thu Mar 10 23:59:20 2016
New Revision: 234127
URL: https://gcc.gnu.org/viewcvs?rev=234127&root=gcc&view=rev
Log:
PR target/70168
* config/rs6000/rs6000.c (rs6000_expan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70168
--- Comment #4 from Ulrich Weigand ---
Author: uweigand
Date: Thu Mar 10 23:58:44 2016
New Revision: 234126
URL: https://gcc.gnu.org/viewcvs?rev=234126&root=gcc&view=rev
Log:
PR target/70168
* config/rs6000/rs6000.c (rs6000_expan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69602
Sérgio Basto changed:
What|Removed |Added
CC||sergio at serjux dot com
--- Comment #12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70150
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70150
--- Comment #2 from H.J. Lu ---
(In reply to H.J. Lu from comment #1)
> When GCC is configured with --enable-default-pie, -fno-pic doesn't
> turn off PIC:
>
> [hjl@gnu-6 gcc]$ ./xgcc -B./ -S x.c -fno-pic
> x.c:2:3: error: #error foo
> # error f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70177
--- Comment #3 from Jakub Jelinek ---
Perhaps better testcase (-O2 again):
int b[128];
void
foo (int i, int j)
{
int c, f, g, h;
for (g = 0; g < 64; g++)
for (h = g, f = 0; f <= i; f++, h++)
for (c = 0; c < j; c++)
b[h] =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70150
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70168
Ulrich Weigand changed:
What|Removed |Added
Status|NEW |ASSIGNED
URL|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70177
--- Comment #2 from Jakub Jelinek ---
Though, that expression looks weird, on the testcase it is clear that if i is
>= 0 (not -1!), then c must be 0, because otherwise the innermost loop must
invoke undefined behavior, and deriving anything about
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70121
--- Comment #3 from Patrick Palka ---
A candidate patch posted at:
https://gcc.gnu.org/ml/gcc-patches/2016-03/msg00669.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70177
Jakub Jelinek changed:
What|Removed |Added
Keywords||ice-on-valid-code
Status|UNC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70177
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70009
--- Comment #8 from cesar at gcc dot gnu.org ---
Author: cesar
Date: Thu Mar 10 22:50:40 2016
New Revision: 234124
URL: https://gcc.gnu.org/viewcvs?rev=234124&root=gcc&view=rev
Log:
libgomp/
PR testsuite/70009
* testsuite/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70178
Bug ID: 70178
Summary: Loop-invariant memory loads from std::string innards
are not hoisted
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Keywords: missed-optim
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70177
Bug ID: 70177
Summary: [6 Regression] ICE in extract_ops_from_tree starting
with r233660
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70173
--- Comment #1 from Andrew Pinski ---
Most people don't use distclean or build in the source directory. Most people
use a separate build directory and just wipe out that build directory.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70175
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38341
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70176
Bug ID: 70176
Summary: Regression with C++03 Issue cstdio
Product: gcc
Version: 5.3.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70159
--- Comment #9 from Sebastian Pop ---
Created attachment 37927
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37927&action=edit
patch for hoisting expressions
Updated the patch from PR23286 to hoist the redundant expressions:
:
inv_4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70175
Bug ID: 70175
Summary: Condition comparing two float numbers
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70164
Jeffrey A. Law changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 6.0.0 20160310 (experimental) [trunk revision 234104] (GCC)
$
$ gcc-trunk -O0 -c small.c
small.c: In function ‘fn1’:
small.c:9:8: warning: assignment makes integer from pointer without
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58306
--- Comment #10 from PeteVine ---
At least on ARM (gcc 4.9.3) it does work after a clean generate/use cycle.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70173
Bug ID: 70173
Summary: make distclean: leaves stage_final and
libcc1/compiler-name.h
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60760
Martin Sebor changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57955
--- Comment #16 from Eric Botcazou ---
> I tried implementing Jakub's suggestion to have CONSTANT_ALIGNMENT return
> 128 for large constructors. This doesn't fix the r201264 version of the
> test case, which still generates fairly horrid code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68654
Jeffrey A. Law changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64058
Jeffrey A. Law changed:
What|Removed |Added
CC||afomin.mailbox at gmail dot com
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70172
--- Comment #2 from Martin Sebor ---
I should add that the bogus "reinterpret_cast" error goes away when the address
of a non-array member is used instead, as in the test case below, even though
this modified test case is also invalid for the sam
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70121
Patrick Palka changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70172
Martin Sebor changed:
What|Removed |Added
Keywords||diagnostic
Blocks|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43640
Seth LaForge changed:
What|Removed |Added
CC||sethml at ofb dot net
--- Comment #3 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70172
Bug ID: 70172
Summary: incorrect reinterpret_cast from integer to pointer
error on invalid constexpr initialization
Product: gcc
Version: 6.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70171
Bug ID: 70171
Summary: Poor code generated when return struct using ternary
operator
Product: gcc
Version: 5.3.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70170
Bug ID: 70170
Summary: [6 regression] bogus not a constant expression error
comparing pointer to array to null
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Sev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70169
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70168
David Edelsohn changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 6.0.0 20160310 (experimental) [trunk revision 234104] (GCC)
$
$ gcc-trunk -O0 -c small.c
$
$ gcc-trunk -O1 -c small.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70168
--- Comment #1 from Ulrich Weigand ---
Created attachment 37925
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37925&action=edit
Patch to add retval vs. newval overlap check
This patch fixes the problem for me with the GCC 5 branch. Not f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70168
Bug ID: 70168
Summary: [5 Regression] Wrong code generation in
__sync_val_compare_and_swap on PowerPC
Product: gcc
Version: 5.4.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69614
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58306
--- Comment #9 from Artem S. Tashkinov ---
Tow more errors for the same sources:
threadpool.cpp: In member function ‘bool
ThreadPool::GetQueuedTask(ThreadPool::QueueEntry*)’:
threadpool.cpp:213:1: error: corrupted profile info: profile data is n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58306
Artem S. Tashkinov changed:
What|Removed |Added
Summary|error: corrupted value |Broken profiling for unrar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58306
Artem S. Tashkinov changed:
What|Removed |Added
Host||x86_64 i686
Version|5.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64058
--- Comment #17 from Jeffrey A. Law ---
The nice thing about looking at the conflict set sizes is it doesn't change the
computational complexity. After we've built the conflict graph we can walk the
coalesce pairs once and compute the size of th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58306
--- Comment #7 from Artem S. Tashkinov ---
Affects GCC 5.3.1 as well.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70167
Bug ID: 70167
Summary: Some const array prvalues are incorrectly treated as
lvalues
Product: gcc
Version: 5.3.0
Status: UNCONFIRMED
Severity: normal
P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69708
--- Comment #4 from Martin Jambor ---
I've posted one possible implementation of this feature to the mailing
list along with an explanation why it makes sense to actually do it
better and how :-)
https://gcc.gnu.org/ml/gcc-patches/2016-03/msg006
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70149
--- Comment #4 from Dominique d'Humieres ---
> Removing the gcc_assert allows the code to compile.
Confirmed, but it leads to wrong code: if I use the module with
use myptr_mod
print *, "'", char_data, "'", int_data
print *, "'", number_string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70127
--- Comment #15 from Martin Jambor ---
(In reply to Jakub Jelinek from comment #14)
> but if you keep the e = a[0]; assignment, I really don't understand the last
> two statements. The kept statement already copied them, the extra stores
> don't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70013
--- Comment #11 from Martin Jambor ---
(In reply to alalaw01 from comment #10)
> which is much saner. But I don't really understand why the PARM_DECL case
> that I'm adding to here is that way
SRA tries to avoid generating unnecessary aggregate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70044
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70044
Nick Clifton changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70001
Jakub Jelinek changed:
What|Removed |Added
Summary|[5/6 regression] Infinity |[5 Regression] Infinity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=7044
--- Comment #2 from Nick Clifton ---
Author: nickc
Date: Thu Mar 10 17:24:16 2016
New Revision: 234118
URL: https://gcc.gnu.org/viewcvs?rev=234118&root=gcc&view=rev
Log:
PR target/7044
* config/aarch64/aarch64.c
(aarch64_o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70001
--- Comment #9 from Jakub Jelinek ---
Author: jakub
Date: Thu Mar 10 17:23:06 2016
New Revision: 234117
URL: https://gcc.gnu.org/viewcvs?rev=234117&root=gcc&view=rev
Log:
PR c++/70001
* constexpr.c (cxx_eval_vec_init_1): For pre_
he following sentence in [1]
could be clarified further:
"Even with -fstrict-aliasing, type-punning is allowed, provided the memory is
accessed through the union type."
[1] https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#Type-punning
Tested with -O2 on gcc 4.7.2, 4.9.2 and 6.0.0 20160310.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70165
--- Comment #1 from vries at gcc dot gnu.org ---
Something like this would be helpful, but that's bash, and the script is sh:
...
index e9cb9f5..1d13056 100644
--- a/libjava/scripts/jar.in
+++ b/libjava/scripts/jar.in
@@ -386,6 +386,7 @@ while tes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70048
--- Comment #16 from Jiong Wang ---
(In reply to Richard Henderson from comment #13)
> Created attachment 37911 [details]
> aggressive patch
>
Cool! Thanks very much for experimenting this thoughtful new aggressive
direction.
But there is a pe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67681
--- Comment #8 from alalaw01 at gcc dot gnu.org ---
Indeed, the -DFOO=1 case vectorizes with -fno-tree-dominator-opts.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69589
Jan Hubicka changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67681
--- Comment #7 from alalaw01 at gcc dot gnu.org ---
Looking at where the peeling happens. In both -DFOO=0 and -DFOO=1 cases,
107.ch2 peels the inner loop header, so there is an i<=max test in the outer
loop before the inner loop. However, in the -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69589
--- Comment #19 from Jan Hubicka ---
Author: hubicka
Date: Thu Mar 10 16:11:14 2016
New Revision: 234115
URL: https://gcc.gnu.org/viewcvs?rev=234115&root=gcc&view=rev
Log:
PR lto/69589
* cgraph.c (cgraph_node::dump): Dump split_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70165
Bug ID: 70165
Summary: build failure in libgcj-6.0.0.jar
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: other
As
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69630
--- Comment #8 from Jan Hubicka ---
Author: hubicka
Date: Thu Mar 10 16:05:59 2016
New Revision: 234114
URL: https://gcc.gnu.org/viewcvs?rev=234114&root=gcc&view=rev
Log:
PR ipa/69630
* ipa-devirt.c (possible_polymorphic_call_tar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69630
Jan Hubicka changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56226
--- Comment #19 from Dave Johansen ---
(In reply to kargl from comment #18)
> (In reply to Dave Johansen from comment #17)
> > (In reply to kargl from comment #16)
> > > See the fortran@ mailinglist archive. Fritz posted a patch against
> > > 4.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69589
--- Comment #18 from Jan Hubicka ---
Author: hubicka
Date: Thu Mar 10 16:02:55 2016
New Revision: 234113
URL: https://gcc.gnu.org/viewcvs?rev=234113&root=gcc&view=rev
Log:
PR lto/69589
* tree.c (free_lang_data_in_decl): Clear vi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69589
--- Comment #17 from Jan Hubicka ---
Author: hubicka
Date: Thu Mar 10 16:02:00 2016
New Revision: 234112
URL: https://gcc.gnu.org/viewcvs?rev=234112&root=gcc&view=rev
Log:
PR lto/69589
* tree.c (need_assembler_name_p): Only recor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70127
--- Comment #14 from Jakub Jelinek ---
(In reply to Martin Jambor from comment #11)
> Well, e has size 64 bits and the replacements created for it have 32
> and 2 bits respectively and so in the simple SRA reprezentation of
> things, there are 30
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56226
--- Comment #18 from kargl at gcc dot gnu.org ---
(In reply to Dave Johansen from comment #17)
> (In reply to kargl from comment #16)
> > See the fortran@ mailinglist archive. Fritz posted a patch against
> > 4.8 branch.
>
> Are the patches that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56226
--- Comment #17 from Dave Johansen ---
(In reply to kargl from comment #16)
> See the fortran@ mailinglist archive. Fritz posted a patch against
> 4.8 branch.
Are the patches that were posted against 6.0?
> That patch will never be committed t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70153
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56226
--- Comment #16 from kargl at gcc dot gnu.org ---
(In reply to Dave Johansen from comment #14)
> Are the patches for 4.8 available or can they be made available? I would
> like to make a Software Collection (SCL) of version of 4.8 with these
> pat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70153
--- Comment #7 from Marek Polacek ---
Author: mpolacek
Date: Thu Mar 10 15:13:01 2016
New Revision: 234111
URL: https://gcc.gnu.org/viewcvs?rev=234111&root=gcc&view=rev
Log:
PR c++/70153
* cp-gimplify.c (cp_fold): Handle UNARY_PL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56226
--- Comment #15 from Dominique d'Humieres ---
> Are the patches for 4.8 available or can they be made available? I would like
> to make a Software Collection (SCL) of version of 4.8 with these patches so
> it could be used on RHEL 6/7 without hav
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56226
--- Comment #14 from Dave Johansen ---
Are the patches for 4.8 available or can they be made available? I would like
to make a Software Collection (SCL) of version of 4.8 with these patches so it
could be used on RHEL 6/7 without having to jump t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68695
--- Comment #22 from Jakub Jelinek ---
Going back to variants of the original testcase:
int
foo (int x, int y, int a)
{
int i = x;
int j = y;
#ifdef EX1
if (__builtin_expect (x > y, 1))
#elif defined EX0
if (__builtin_expect (x > y, 0))
#
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70029
Jan Hubicka changed:
What|Removed |Added
CC||jason at redhat dot com
--- Comment #5 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70160
--- Comment #7 from Jakub Jelinek ---
(In reply to Ilya Enkovich from comment #6)
> Thanks a lot for your analysis! When chain is built we scan all register
> definitions and their uses. Thus it includes all register definitions and
> uses. Un
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70113
--- Comment #3 from Christophe Lyon ---
Author: clyon
Date: Thu Mar 10 13:29:48 2016
New Revision: 234108
URL: https://gcc.gnu.org/viewcvs?rev=234108&root=gcc&view=rev
Log:
2016-03-10 Christophe Lyon
PR target/70113.
* config
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69630
Jan Hubicka changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69493
--- Comment #5 from Segher Boessenkool ---
Ah, needs -mlittle, not just -mabi=elfv2.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70048
--- Comment #15 from Wilco ---
(In reply to Richard Biener from comment #14)
> The regression in the original description looks severe enough to warrant
> some fixing even if regressing some other cases.
Agreed, I think the improvement from Rich
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70160
Ilya Enkovich changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69489
amker at gcc dot gnu.org changed:
What|Removed |Added
CC||amker at gcc dot gnu.org
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70139
--- Comment #3 from Viktor Ostashevskyi ---
Could be the same problem as in PR70145.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70113
--- Comment #2 from Christophe Lyon ---
(In reply to Christophe Lyon from comment #0)
> This is a follow-up to PR 633304.
I meant bug #63304
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70161
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
1 - 100 of 153 matches
Mail list logo
