Thanks for nice benchmarks. Vladimir.
Why is GCC code size so much bigger than LLVM? Does -Ofast have more unrolling
on GCC? It doesn't seem increasing code size help performance (164.gzip
197.parser)
Is there comparisons for O2? I guess that is more useful for typical
mobile/embedded
On 25 June 2014 10:26, Bingfeng Mei b...@broadcom.com wrote:
Why is GCC code size so much bigger than LLVM? Does -Ofast have more unrolling
on GCC? It doesn't seem increasing code size help performance (164.gzip
197.parser)
Is there comparisons for O2? I guess that is more useful for typical
On Wed, Jun 25, 2014 at 5:26 PM, Bingfeng Mei b...@broadcom.com wrote:
Thanks for nice benchmarks. Vladimir.
Why is GCC code size so much bigger than LLVM? Does -Ofast have more unrolling
On the contrary, I don't think rtl unrolling is enabled by default on
GCC with level O3/Ofast. There is no
On Wed, Jun 25, 2014 at 5:47 PM, Bin.Cheng amker.ch...@gmail.com wrote:
On Wed, Jun 25, 2014 at 5:26 PM, Bingfeng Mei b...@broadcom.com wrote:
Thanks for nice benchmarks. Vladimir.
Why is GCC code size so much bigger than LLVM? Does -Ofast have more
unrolling
On the contrary, I don't think
On Wed, Jun 25, 2014 at 11:53 AM, Bin.Cheng amker.ch...@gmail.com wrote:
On Wed, Jun 25, 2014 at 5:47 PM, Bin.Cheng amker.ch...@gmail.com wrote:
On Wed, Jun 25, 2014 at 5:26 PM, Bingfeng Mei b...@broadcom.com wrote:
Thanks for nice benchmarks. Vladimir.
Why is GCC code size so much bigger
Hello,
GCC provides its own version of stdatomic.h since GCC 4.9. Here we have:
#define atomic_load_explicit(PTR, MO) \
__extension__ \
({
On Wed, 25 Jun 2014, Sebastian Huber wrote:
I think the inheritance of the volatile qualifier via __typeof__
(*__atomic_load_ptr) is an implementation flaw.
See the comment in c_parser_typeof_specifier:
/* For use in macros such as those in stdatomic.h, remove
_Atomic and const
On 2014-06-25, 5:32 AM, Renato Golin wrote:
On 25 June 2014 10:26, Bingfeng Mei b...@broadcom.com wrote:
Why is GCC code size so much bigger than LLVM? Does -Ofast have more unrolling
on GCC? It doesn't seem increasing code size help performance (164.gzip
197.parser)
Is there comparisons for
On 2014-06-24, 10:57 AM, Ramana Radhakrishnan wrote:
The ball-park number you have probably won't change much.
I don't think Neon can improve score for SPECInt2000 significantly but
may be I am wrong.
It won't probably improve the overall score by a large amount but some
individual
On Wed, Jun 25, 2014 at 4:00 PM, Vladimir Makarov vmaka...@redhat.com wrote:
On 2014-06-25, 5:32 AM, Renato Golin wrote:
On 25 June 2014 10:26, Bingfeng Mei b...@broadcom.com wrote:
Why is GCC code size so much bigger than LLVM? Does -Ofast have more
unrolling
on GCC? It doesn't seem
On Wed, Jun 25, 2014 at 04:02:49PM +0200, Richard Biener wrote:
That might be a consequence of difference in aliasing I wrote about. I
looked at the code generated by LLVM and GCC of an interpreter and saw
bigger code generated by GCC too.
A sequence of bytecodes execution and each
Dear gcc contributors,
could you please answer a few questions about unit tests? Is it
possible to use them in gcc? Or maybe there is some analogue? I would
be very grateful for your comments.
--
Cheers, Roman Gareev
On 2014-06-25, 10:02 AM, Richard Biener wrote:
On Wed, Jun 25, 2014 at 4:00 PM, Vladimir Makarov vmaka...@redhat.com wrote:
On 2014-06-25, 5:32 AM, Renato Golin wrote:
On 25 June 2014 10:26, Bingfeng Mei b...@broadcom.com wrote:
Why is GCC code size so much bigger than LLVM? Does -Ofast
On Wed, 25 Jun 2014, Vladimir Makarov wrote:
Maybe. But in this case LLVM did a right thing. The variable addressing was
through a restrict pointer.
Ah, gcc implements (on purpose?) a weak version of restrict, where it only
considers that 2 restrict pointers don't alias, whereas all other
On 2014-06-25, 10:37 AM, Marc Glisse wrote:
On Wed, 25 Jun 2014, Vladimir Makarov wrote:
Maybe. But in this case LLVM did a right thing. The variable
addressing was through a restrict pointer.
Ah, gcc implements (on purpose?) a weak version of restrict, where it
only considers that 2
On 2014-06-25, 10:01 AM, Vladimir Makarov wrote:
On 2014-06-24, 10:57 AM, Ramana Radhakrishnan wrote:
I've tried this options too. As I guessed it resulted in GCC
improvement of eon only by 6% which improved overall score by less 0.5%.
No change for LLVM though. Eon is more fp benchmark
On 2014-06-25 15:25, Joseph S. Myers wrote:
On Wed, 25 Jun 2014, Sebastian Huber wrote:
I think the inheritance of the volatile qualifier via __typeof__
(*__atomic_load_ptr) is an implementation flaw.
See the comment in c_parser_typeof_specifier:
/* For use in macros such as those in
On Wed, 25 Jun 2014, Sebastian Huber wrote:
In case __auto_type discards const and volatile qualifiers, then shouldn't
this generate a warning (-Wconst-qual)
__auto_type __atomic_load_ptr = (PTR);
?
No. The discarding is for qualifiers on the type itself (remembering that
qualifiers on
Snapshot gcc-4.9-20140625 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.9-20140625/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.9 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61559
Eric Botcazou ebotcazou at gcc dot gnu.org changed:
What|Removed |Added
CC|ebotcazou at gcc dot gnu.org |
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57742
--- Comment #17 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
---
(In reply to Marc Glisse from comment #16)
Done. Joost, feel free to add your testcase from comment #3 if you want to
(I can't write a hello world in fortran so
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61597
--- Comment #6 from Adrien Hamelin adrien.hamelin+gcc at gmail dot com ---
I also wanted to say, my code may be not optimal or may be done in an easier
way or else (and if you have comments on it i'm ok with that), but what i think
what is the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61597
--- Comment #7 from Markus Trippelsdorf trippels at gcc dot gnu.org ---
Well, the default assumption, when someone posts a 77000 line preprocessed
program with strange runtime behavior, is that the program is buggy.
You have to convince us that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57742
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57742
--- Comment #19 from Marc Glisse glisse at gcc dot gnu.org ---
(In reply to Joost VandeVondele from comment #17)
Thanks Marc, I don't have write access, but I can try to dg-ify the testcase
from comment #3.. however, first test, it still seems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57742
--- Comment #20 from Marc Glisse glisse at gcc dot gnu.org ---
(In reply to Joost VandeVondele from comment #18)
The following now fails, so'll reopen this PR. It is at least related to
zeroing pvec twice in a row, and doesn seem to happen if I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60947
--- Comment #13 from amker at gcc dot gnu.org ---
OK, I compared generated assembly before/after revision 206552.
BEFORE)
@ frame_needed = 1, uses_anonymous_args = 0
movip, sp
stmfdsp!, {r4, r5, r6, r7, r8, r9, r10, fp, ip,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57742
--- Comment #21 from Marc Glisse glisse at gcc dot gnu.org ---
I am testing the following:
--- tree-ssa-strlen.c(revision 211967)
+++ tree-ssa-strlen.c(working copy)
@@ -1646,20 +1646,22 @@ handle_builtin_memset (gimple_stmt_itera
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60947
--- Comment #14 from amker at gcc dot gnu.org ---
Created attachment 33001
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33001action=edit
Dump of cunroll/ivopt/ira/reload passes after revision 206552 for the
preprocessed file.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61597
Adrien Hamelin adrien.hamelin+gcc at gmail dot com changed:
What|Removed |Added
Attachment #33000|0 |1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61602
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Keywords||lto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61598
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |4.10.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61595
--- Comment #2 from Richard Biener rguenth at gcc dot gnu.org ---
Hmm, does it work if you do
typedef int vint __attribute__((vector_size(16)));
and use vint in as the type for vr?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61597
Adrien Hamelin adrien.hamelin+gcc at gmail dot com changed:
What|Removed |Added
Attachment #33002|0 |1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61560
--- Comment #4 from Richard Biener rguenth at gcc dot gnu.org ---
Author: rguenth
Date: Wed Jun 25 08:37:37 2014
New Revision: 211970
URL: https://gcc.gnu.org/viewcvs?rev=211970root=gccview=rev
Log:
2014-06-25 Richard Biener rguent...@suse.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61560
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61588
Marek Polacek mpolacek at gcc dot gnu.org changed:
What|Removed |Added
CC||mpolacek at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58876
Bug 58876 depends on bug 61600, which changed state.
Bug 61600 Summary: #pragma GCC diagnostic pop leaves warnings enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61600
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59304
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
CC||redi at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61600
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61601
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61582
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Status|RESOLVED|NEW
Last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61597
--- Comment #10 from Jonathan Wakely redi at gcc dot gnu.org ---
Thank you - that test case is much more useful
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61595
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61597
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61597
--- Comment #12 from Jonathan Wakely redi at gcc dot gnu.org ---
(In reply to Jonathan Wakely from comment #11)
decltype(iter += i) is Iter so you return a reference to a temporary which
goes out of scope
Sorry, temporary is the wrong word - a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61603
Bug ID: 61603
Summary: ICE in gcc/gcc/toplev.c:337
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61558
Markus Trippelsdorf trippels at gcc dot gnu.org changed:
What|Removed |Added
CC||larsbj
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61603
Markus Trippelsdorf trippels at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61164
Ilya Palachev iliyapalachev at gmail dot com changed:
What|Removed |Added
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61231
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61420
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |4.8.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61459
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |4.8.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60718
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |4.8.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61500
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |4.9.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61488
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |4.9.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61499
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |4.9.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61500
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|4.9.1 |4.8.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61445
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Version|unknown |4.10.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61453
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |4.10.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61604
Bug ID: 61604
Summary: missing line numbers in a sanitizer backtrace from an
OMP region
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59193
Marek Polacek mpolacek at gcc dot gnu.org changed:
What|Removed |Added
Status|REOPENED|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61597
--- Comment #13 from Adrien Hamelin adrien.hamelin+gcc at gmail dot com ---
I'm sorry that i made you lose your time :-(
I thought that kind of code would trigger a warning though.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61294
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61231
Matthias Klose doko at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61595
--- Comment #4 from Sebastian Meyer gcc-bugzilla at mailhell dot seb7.de ---
Richard: The typdef gets optimized away very quickly, so I needed to trick
around a bit. But the array won't use the typedef anyway, the produced DWARF is
equal to what
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61605
Bug ID: 61605
Summary: Potential optimization: Keep unclobbered argument
registers live across function calls
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61606
Bug ID: 61606
Summary: About GCC install, testing step (mostly check...)
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61607
Bug ID: 61607
Summary: DOM missed jump threading and destroyed loops
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Keywords: missed-optimization, wrong-code
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61595
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61542
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61607
--- Comment #1 from Richard Biener rguenth at gcc dot gnu.org ---
Optimizing block #5
1 COND 1 = i_1 ge_expr R_6(D)
1 COND 0 = i_1 lt_expr R_6(D)
LKUP STMT inter0p_13 = PHI inter0p_2
inter0p_13 = PHI inter0p_2(4)
2 STMT inter0p_13 =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61566
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61607
--- Comment #2 from Richard Biener rguenth at gcc dot gnu.org ---
With the propagation limitation removed we get
Registering jump thread: (2, 4) incoming edge; (4, 5) joiner; (5, 7)
normal;
Cancelling jump thread: (2, 4) incoming edge;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61575
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61597
--- Comment #14 from Jonathan Wakely redi at gcc dot gnu.org ---
Yes, I can't convince gcc or clang to give a warning. Even address sanitizer
and undefined-behaviour sanitizer don't catch the problem.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57742
--- Comment #22 from Marc Glisse glisse at gcc dot gnu.org ---
Author: glisse
Date: Wed Jun 25 12:27:13 2014
New Revision: 211977
URL: https://gcc.gnu.org/viewcvs?rev=211977root=gccview=rev
Log:
2014-06-25 Marc Glisse marc.gli...@inria.fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57742
Marc Glisse glisse at gcc dot gnu.org changed:
What|Removed |Added
Status|REOPENED|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61542
Bill Schmidt wschmidt at gcc dot gnu.org changed:
What|Removed |Added
Summary|[4.8/4.9 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61607
--- Comment #3 from Richard Biener rguenth at gcc dot gnu.org ---
Like with
Index: gcc/tree-ssa-threadupdate.c
===
--- gcc/tree-ssa-threadupdate.c (revision 211969)
+++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61162
--- Comment #12 from Marek Polacek mpolacek at gcc dot gnu.org ---
Author: mpolacek
Date: Wed Jun 25 12:43:05 2014
New Revision: 211978
URL: https://gcc.gnu.org/viewcvs?rev=211978root=gccview=rev
Log:
PR c/61162
* c-parser.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61162
Marek Polacek mpolacek at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61608
Bug ID: 61608
Summary: [4.10 regression] FAIL: gcc.target/arm/epilog-1.c
scan-assembler tests
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61433
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61597
--- Comment #15 from Marc Glisse glisse at gcc dot gnu.org ---
If you can reduce the testcase to a manageable size, I'll see why
https://gcc.gnu.org/ml/gcc-patches/2014-06/msg01692.html is not enough (it
should be, with -fkeep-inline-functions,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61608
jgreenhalgh at gcc dot gnu.org changed:
What|Removed |Added
Target||arm*-none-*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61608
--- Comment #1 from Kai Tietz ktietz at gcc dot gnu.org ---
Does this issue get fixed by adding the peephole2 also at old place too?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61597
--- Comment #16 from Jonathan Wakely redi at gcc dot gnu.org ---
Marc:
struct Iter
{
Iter operator+=(int) { return *this; }
int operator*() { return i; }
int i;
};
Iter func(Iter iter, int n) {
return iter += n;
}
int main()
{
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61595
--- Comment #6 from Sebastian Meyer gcc-bugzilla at mailhell dot seb7.de ---
Ah, okay, thank you for the clarification, Jakub.
So this is indeed RESOLVED INVALID, sorry.
I am still sure I saw the example I gave, but can't seem to find it now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320
--- Comment #44 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot
Uni-Bielefeld.DE ---
--- Comment #43 from thopre01 at gcc dot gnu.org ---
Thanks. In the stage before the one that fails, could you add
-fdump-tree-all-details
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61608
--- Comment #2 from jgreenhalgh at gcc dot gnu.org ---
Yes, it does.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61609
Bug ID: 61609
Summary: running libraries compiled with different gcc versions
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61597
--- Comment #17 from Marc Glisse glisse at gcc dot gnu.org ---
(In reply to Jonathan Wakely from comment #16)
Marc:
struct Iter
{
Iter operator+=(int) { return *this; }
int operator*() { return i; }
int i;
};
Iter func(Iter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61409
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61608
--- Comment #3 from Kai Tietz ktietz at gcc dot gnu.org ---
Thanks for testing. I will sent a patch for it.
It seems after all that we need to run peephole2 pass twice.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61409
--- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org ---
I think what is important that if the other conditions besides mini_p != 0 are
not met, then control flow goes to basic blocks from which there is no path to
the bb with the use (in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61609
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61608
--- Comment #4 from Richard Biener rguenth at gcc dot gnu.org ---
(In reply to Kai Tietz from comment #3)
Thanks for testing. I will sent a patch for it.
It seems after all that we need to run peephole2 pass twice.
Bad for compile-time.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61608
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |4.10.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49132
--- Comment #8 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org ---
Author: paolo
Date: Wed Jun 25 14:27:35 2014
New Revision: 211981
URL: https://gcc.gnu.org/viewcvs?rev=211981root=gccview=rev
Log:
/cp
2014-06-25 Paolo Carlini
1 - 100 of 254 matches
Mail list logo
