https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64972
--- Comment #2 from Rainer Emrich ---
Issue exists for target x86_64-w64-mingw32 too.
By the way, this is a regression.
At the moment gcc doesn't build for the *-w64-mingw32 targets.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60851
--- Comment #15 from uros at gcc dot gnu.org ---
Author: uros
Date: Tue Mar 24 07:12:03 2015
New Revision: 221617
URL: https://gcc.gnu.org/viewcvs?rev=221617&root=gcc&view=rev
Log:
PR rtl-optimization/60851
* recog.c (constrain_operands):
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65533
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65533
--- Comment #3 from Jakub Jelinek ---
Working on a patch...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64972
Kai Tietz changed:
What|Removed |Added
Known to work||4.9.3
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64972
Kai Tietz changed:
What|Removed |Added
Target Milestone|--- |5.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60851
Uroš Bizjak changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64972
--- Comment #4 from Jakub Jelinek ---
And the suggested fix is just to cast to unsigned long and use %ld or %lx
instead of %zd and %zx. I can't test it on these targets, so it is better if
somebody with M$ access writes and tests the patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65516
--- Comment #10 from David Kredba ---
Thank you, it works.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65533
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P1
Component|middle-end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65533
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65167
ienkovich at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65527
ienkovich at gcc dot gnu.org changed:
What|Removed |Added
CC||ienkovich at gcc dot gnu.or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65531
ienkovich at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65533
--- Comment #5 from Richard Biener ---
(In reply to Jakub Jelinek from comment #4)
> Created attachment 35120 [details]
> gcc5-pr65533.patch
>
> Untested fix.
Hmm, looks basically ok, though doing
vect_free_slp_tree (child);
from the cleanu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65533
--- Comment #6 from Richard Biener ---
Looks like a latent issue on the branch(es) btw.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65536
Manuel López-Ibáñez changed:
What|Removed |Added
CC||dodji at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65533
--- Comment #7 from Jakub Jelinek ---
(In reply to Richard Biener from comment #5)
> Hmm, looks basically ok, though doing
>
> vect_free_slp_tree (child);
>
> from the cleanup before
>
> /* If the SLP build for operand zero failed and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62234
Manuel López-Ibáñez changed:
What|Removed |Added
Blocks||61913
--- Comment #2 from Manuel L
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65537
Bug ID: 65537
Summary: [5 Regression]: --with-build-config=bootstrap-lto
fails on CentOS 5.11
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65533
--- Comment #8 from rguenther at suse dot de ---
On Tue, 24 Mar 2015, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65533
>
> --- Comment #7 from Jakub Jelinek ---
> (In reply to Richard Biener from comment #5)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65538
Bug ID: 65538
Summary: [5 Regression] Memory leak of ipa_node_params_sum
elements
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Prior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65538
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|--- |5.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65537
Markus Trippelsdorf changed:
What|Removed |Added
CC||trippels at gcc dot gnu.org
--- Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65519
--- Comment #8 from Richard Biener ---
Created attachment 35121
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35121&action=edit
patch
gimple-fold works like fold - it tries to re-simplify what you feed it, but
only
the outermost level (so
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65524
Arnaud Charlet changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65537
--- Comment #2 from Uroš Bizjak ---
(In reply to Markus Trippelsdorf from comment #1)
> Update your binutils?
Not an option on a production system ...
> Or maybe the minimal binutils version for LTO bootstrap should be mentioned
> on changes.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65517
--- Comment #4 from Richard Biener ---
Author: rguenth
Date: Tue Mar 24 09:31:48 2015
New Revision: 221619
URL: https://gcc.gnu.org/viewcvs?rev=221619&root=gcc&view=rev
Log:
2015-03-24 Richard Biener
PR middle-end/65517
* tree-cfg.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65517
Markus Trippelsdorf changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65517
--- Comment #6 from Richard Biener ---
(In reply to Markus Trippelsdorf from comment #5)
> Fixed.
> BTW the testcase has DOS line-endings.
Yes, cut&pasting from firefox adds those for some very stupid reason (and I
can't figure out how to "fix"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64952
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
CC||ktkachov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65519
Eric Botcazou changed:
What|Removed |Added
Attachment #35101|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65519
--- Comment #9 from Eric Botcazou ---
> gimple-fold works like fold - it tries to re-simplify what you feed it, but
> only the outermost level (so it doesn't really recurse). Still I think this
> bug needs changing code-generation like with the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65519
--- Comment #11 from Eric Botcazou ---
> I always forget how to force SJLJ EH on x86_64-linux for ada so I didn't
> manage to reproduce the issue or check if the patch fixes it ...
Yes, it does.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65519
--- Comment #12 from Richard Biener ---
(In reply to Eric Botcazou from comment #11)
> > I always forget how to force SJLJ EH on x86_64-linux for ada so I didn't
> > manage to reproduce the issue or check if the patch fixes it ...
>
> Yes, it do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65052
--- Comment #4 from Nick Clifton ---
Created attachment 35123
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35123&action=edit
Disable the generation of real_jump insns
This patch works around the problem by disabling the generation of the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65519
--- Comment #13 from Eric Botcazou ---
> I'll add
>
> Index: gcc/testsuite/gnat.dg/opt48.adb
> ===
> --- gcc/testsuite/gnat.dg/opt48.adb (revision 0)
> +++ gcc/testsuite/gnat.dg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65536
--- Comment #2 from Richard Biener ---
The main issue with LTO is that it re-creates a combined linemap but in (most
of the time) quite awkward ordering (simply registering random-ordered
file:line:column entries by switching files/lines "appropr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65536
Richard Biener changed:
What|Removed |Added
Summary|[5 regression] LTO line |LTO line number information
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64952
--- Comment #9 from Dominique d'Humieres ---
Duplicate of pr65532?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65515
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65512
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65525
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65525
--- Comment #2 from Richard Biener ---
Run till exit from #0 0x012bf93a in build2_stat (code=MEM_REF,
tt=, arg0=,
arg1=)
at /space/rguenther/src/svn/trunk/gcc/tree.c:4385
0x006f8b40 in build_over_call (cand=0x24f7aa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65512
--- Comment #7 from Peter VARGA ---
Due the fact some frameworks do NOT support gcc 5.0 yet I would like to know if
this bug is going to be fixed in a 4.9.X version or not.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34503
Steven Bosscher changed:
What|Removed |Added
CC||thomas.preudhomme at arm dot
com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65519
--- Comment #14 from rguenther at suse dot de ---
On Tue, 24 Mar 2015, ebotcazou at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65519
>
> --- Comment #13 from Eric Botcazou ---
> > I'll add
> >
> > Index: gcc/testsui
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65513
--- Comment #4 from Paolo Carlini ---
I'm adding the reduced testcase and closing the bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65525
--- Comment #3 from Richard Biener ---
Ah, and that was me:
2011-08-12 Richard Guenther
* call.c (build_over_call): Instead of memcpy use an
assignment of two MEM_REFs.
which implements memcpy as *(char[n])ptr1 = *(char[n])ptr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65513
--- Comment #5 from paolo at gcc dot gnu.org ---
Author: paolo
Date: Tue Mar 24 10:24:33 2015
New Revision: 221620
URL: https://gcc.gnu.org/viewcvs?rev=221620&root=gcc&view=rev
Log:
2015-03-24 Paolo Carlini
PR c++/65513
* g++.dg/cpp0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65513
Paolo Carlini changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65538
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64787
--- Comment #4 from vehre at gcc dot gnu.org ---
Author: vehre
Date: Tue Mar 24 10:28:48 2015
New Revision: 221621
URL: https://gcc.gnu.org/viewcvs?rev=221621&root=gcc&view=rev
Log:
gcc/fortran/ChangeLog
2015-03-24 Andre Vehreschild
PR f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63230
--- Comment #6 from vehre at gcc dot gnu.org ---
Author: vehre
Date: Tue Mar 24 10:28:48 2015
New Revision: 221621
URL: https://gcc.gnu.org/viewcvs?rev=221621&root=gcc&view=rev
Log:
gcc/fortran/ChangeLog
2015-03-24 Andre Vehreschild
PR f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57456
--- Comment #6 from vehre at gcc dot gnu.org ---
Author: vehre
Date: Tue Mar 24 10:28:48 2015
New Revision: 221621
URL: https://gcc.gnu.org/viewcvs?rev=221621&root=gcc&view=rev
Log:
gcc/fortran/ChangeLog
2015-03-24 Andre Vehreschild
PR f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65537
--- Comment #3 from Richard Biener ---
Well, simply add a config/bootstrap-lto-fat.mk?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65537
Richard Biener changed:
What|Removed |Added
Keywords||documentation
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48181
Steven Bosscher changed:
What|Removed |Added
Summary|[4.8/4.9/5 Regression] |[4.8/4.9 Regression] wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59978
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65538
--- Comment #2 from Martin Liška ---
(In reply to Jakub Jelinek from comment #0)
> Seen recently in valgrind output (e.g. on the pr65533.c testcase):
>
> ==19246== 216 (48 direct, 168 indirect) bytes in 1 blocks are definitely
> lost in loss rec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64952
--- Comment #10 from Mikael Morin ---
(In reply to Dominique d'Humieres from comment #9)
> Duplicate of pr65532?
Rather cause of pr65532. Only comment #8 is a duplicate.
(In reply to Mikael Morin from comment #7)
> (In reply to paul.richard.t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59988
--- Comment #5 from Paolo Carlini ---
I'm adding a testcase and closing the bug. By the way, both current EDG and
clang agree with GCC.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64972
--- Comment #5 from Rainer Emrich ---
(In reply to Jakub Jelinek from comment #4)
> And the suggested fix is just to cast to unsigned long and use %ld or %lx
> instead of %zd and %zx. I can't test it on these targets, so it is better
> if somebo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65533
--- Comment #9 from Jakub Jelinek ---
Author: jakub
Date: Tue Mar 24 10:45:09 2015
New Revision: 221622
URL: https://gcc.gnu.org/viewcvs?rev=221622&root=gcc&view=rev
Log:
PR tree-optimization/65533
* tree-vect-slp.c (vect_build_slp_tree)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59988
--- Comment #6 from paolo at gcc dot gnu.org ---
Author: paolo
Date: Tue Mar 24 10:50:36 2015
New Revision: 221623
URL: https://gcc.gnu.org/viewcvs?rev=221623&root=gcc&view=rev
Log:
2015-03-24 Paolo Carlini
PR c++/59988
* g++.dg/cpp0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64972
--- Comment #6 from Jakub Jelinek ---
(In reply to Rainer Emrich from comment #5)
> (In reply to Jakub Jelinek from comment #4)
> > And the suggested fix is just to cast to unsigned long and use %ld or %lx
> > instead of %zd and %zx. I can't tes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59988
--- Comment #8 from paolo at gcc dot gnu.org ---
Author: paolo
Date: Tue Mar 24 10:51:38 2015
New Revision: 221624
URL: https://gcc.gnu.org/viewcvs?rev=221624&root=gcc&view=rev
Log:
2015-03-24 Paolo Carlini
PR c++/59988
* g++.dg/cpp0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59988
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65537
--- Comment #4 from Markus Trippelsdorf ---
Or something like:
diff --git a/config/bootstrap-lto.mk b/config/bootstrap-lto.mk
index 9e065e1d85a0..5e93ee848727 100644
--- a/config/bootstrap-lto.mk
+++ b/config/bootstrap-lto.mk
@@ -1,5 +1,10 @@
#
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65532
--- Comment #4 from Mikael Morin ---
With r221586, procedure d1mach is resolved more than once.
At the first time resolve_values is called, the problematic variables (diver,
large, etc) have a NULL sym->value, which is set afterwards in resolve_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60067
--- Comment #1 from Paolo Carlini ---
This is fixed in 4.9.1, I'm adding the testcase and closing the bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65533
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64972
--- Comment #7 from Rainer Emrich ---
Ok, here's the additional issue in oacc-parallel.c.
libtool: compile:
/opt/devel/SCRATCH/tmp.UotBZukqBt/gcc-5.0.0/gcc-5.0.0/./gcc/xgcc
-B/opt/devel/SCRATCH/tmp.UotBZukqBt/gcc-5.0.0/gcc-5.0.0/./gcc/
-L/opt/d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65537
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65531
ienkovich at gcc dot gnu.org changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64972
--- Comment #8 from Rainer Emrich ---
I'm testing the following on x86_64-w64-mingw32 at the moment.
Index: oacc-parallel.c
===
--- oacc-parallel.c (Revision 221607)
+++ oacc-pa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60067
--- Comment #2 from paolo at gcc dot gnu.org ---
Author: paolo
Date: Tue Mar 24 11:42:11 2015
New Revision: 221625
URL: https://gcc.gnu.org/viewcvs?rev=221625&root=gcc&view=rev
Log:
2015-03-24 Paolo Carlini
PR c++/60067
* g++.dg/temp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60067
--- Comment #3 from paolo at gcc dot gnu.org ---
Author: paolo
Date: Tue Mar 24 11:42:26 2015
New Revision: 221626
URL: https://gcc.gnu.org/viewcvs?rev=221626&root=gcc&view=rev
Log:
2015-03-24 Paolo Carlini
PR c++/60067
* g++.dg/temp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60067
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64715
--- Comment #15 from Richard Biener ---
(In reply to Jakub Jelinek from comment #14)
> Created attachment 35073 [details]
> WIP patch
>
> So, on top of what you've committed, here is my unfinished attempt to
> disable for __bos undesirable trans
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55901
--- Comment #15 from vehre at gcc dot gnu.org ---
Author: vehre
Date: Tue Mar 24 11:47:45 2015
New Revision: 221627
URL: https://gcc.gnu.org/viewcvs?rev=221627&root=gcc&view=rev
Log:
2015-03-24 Andre Vehreschild
PR fortran/55901
* tra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58194
Paolo Carlini changed:
What|Removed |Added
Status|SUSPENDED |NEW
--- Comment #2 from Paolo Carlini -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64715
--- Comment #16 from Richard Biener ---
Ok, so disabling the forwprop breaks testcases like gcc.dg/tree-ssa/alias-21.c:
:
*r_2(D) = 0;
_4 = r_2(D) + 4;
*_4 = 1;
_6 = *r_2(D);
return _6;
SCCVN isn't able to disambiguate *r_2(D) again
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65537
--- Comment #6 from Uroš Bizjak ---
I'm testing the following patch:
--cut here--
Index: config/bootstrap-lto-noplugin.mk
===
--- config/bootstrap-lto-noplugin.mk(revision 0)
++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65536
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65536
--- Comment #5 from Manuel López-Ibáñez ---
(In reply to Richard Biener from comment #2)
> The main issue with LTO is that it re-creates a combined linemap but in (most
> of the time) quite awkward ordering (simply registering random-ordered
> fi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65519
--- Comment #15 from Richard Biener ---
Patch needs adjustments, re-testing.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65536
--- Comment #6 from Manuel López-Ibáñez ---
(In reply to Jan Hubicka from comment #0)
> One obvious thing is that linemap_line_start takes argument 3 to be max
> column hint, but we pass current_col that is not cool.
If I remember correctly, the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65515
--- Comment #7 from Jakub Jelinek ---
Created attachment 35124
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35124&action=edit
gcc5-pr65515.patch
Lightly tested fix. Basically, most of DFS::DFS_write_tree is now moved into a
loop in DFS:
ultilib-list=m32,m64
--disable-altivec --disable-fixed-point --enable-targets=all --disable-libgcj
--enable-libgomp --disable-libmudflap --disable-libssp --enable-lto
--with-cloog --disable-isl-version-check --enable-libsanitizer
Thread model: posix
gcc version 4.10.0-pre20150322 20150324 (experimen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64715
--- Comment #17 from Jakub Jelinek ---
In
*r_2(D) = 0;
_4 = r_2(D) + 4;
*_4 = 1;
_6 = *r_2(D);
there are no handled components, so there is no reason not to create
&MEM_REF[r_2, 4]. But it shouldn't be hard to construct similar testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65492
--- Comment #11 from Allan Jensen ---
Issues with slow cmov has been seen in several bug reports:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53346
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54073
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65515
--- Comment #8 from rguenther at suse dot de ---
On Tue, 24 Mar 2015, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65515
>
> --- Comment #7 from Jakub Jelinek ---
> Created attachment 35124
> --> https://gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64715
--- Comment #18 from rguenther at suse dot de ---
On Tue, 24 Mar 2015, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64715
>
> --- Comment #17 from Jakub Jelinek ---
> In
> *r_2(D) = 0;
> _4 = r_2(D) + 4;
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65539
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65498
--- Comment #7 from Marek Polacek ---
The problem appears to be that we're trying to use the body of the operator()
function after it's been released (release_function_body). Investigating
more...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65536
--- Comment #7 from Richard Biener ---
(In reply to Manuel López-Ibáñez from comment #5)
> (In reply to Richard Biener from comment #2)
> > The main issue with LTO is that it re-creates a combined linemap but in
> > (most
> > of the time) quite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58156
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53628
Paolo Carlini changed:
What|Removed |Added
Status|NEW |RESOLVED
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65532
Mikael Morin changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at
1 - 100 of 214 matches
Mail list logo