http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59084
Bug ID: 59084
Summary: Sub-optimal vector moves in AVX2 vectorized loop for
unaligned loads.
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59078
--- Comment #2 from Povilas Kanapickas ---
This would be very surprising, as a major use case for this instruction set
feature would be eliminated. Unfortunately autoincrements are not mentioned
anywhere in ARM documentation. However, I think a re
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59081
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47346
Jonathan Wakely changed:
What|Removed |Added
CC||romain.geissler at gmail dot
com
--- C
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59081
--- Comment #2 from Romain Geissler ---
It looks similar to http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41437 but in my
case I used a second class, not a function.
This issue is exactly like the one reported in
http://gcc.gnu.org/bugzilla/show_bu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59075
--- Comment #6 from Alexander Timin ---
(In reply to Tom Tromey from comment #2)
It has been compiled only with -g option.
What do you mean by "see gdb session"? I don't understand. What should I do?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59081
--- Comment #1 from Jonathan Wakely ---
Please check whether this is a duplicate of any of the "Depends on" bugs for PR
59002
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59075
--- Comment #4 from Alexander Timin ---
Created attachment 31196
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31196&action=edit
compiled executable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59075
--- Comment #5 from Alexander Timin ---
Created attachment 31197
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31197&action=edit
source code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59075
--- Comment #3 from Alexander Timin ---
Created attachment 31195
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31195&action=edit
compiled dwarf file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59083
--- Comment #2 from Jeffrey A. Law ---
I need a compilable/complete testcase.
If a program is faulting with -fisolate-erroneous-paths, then that program is
faulty in one way or another. It's dereferencing a null pointer, pass a null
argument in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59078
--- Comment #1 from Andrew Pinski ---
Note the use of autoincrement here might actually be slower due to dependent
between instructions.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59054
--- Comment #2 from Michael Meissner ---
Author: meissner
Date: Mon Nov 11 22:27:03 2013
New Revision: 204689
URL: http://gcc.gnu.org/viewcvs?rev=204689&root=gcc&view=rev
Log:
Apply patches for PR 59054
Added:
branches/ibm/gcc-4_9-meissner/g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59083
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59083
Bug ID: 59083
Summary: -fisolate-erroneous-paths produces illegal instruction
with enabled -fprofile-generate
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Sev
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59079
bert hubert changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59025
--- Comment #6 from Jakub Jelinek ---
If I remember well, there was one spot where it could result in swapped order
of commutative operation's operand at the tree level, plus of course if
RA/scheduling is affected by SSA_NAME_VERSION of the tempor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59025
--- Comment #5 from Pat Haugen ---
Well, it looks to be an interaction amongst 3 files from the benchmark. All 3
have to be compiled with r203979 compiler for the benchmark to fail (others are
compiled with r203978). I captured assembler output fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59009
Mikael Pettersson changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
--- Comme
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59082
Bug ID: 59082
Summary: [4.7/4.8/4.9 Regression] ICE with duplicate (virtual)
base
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Prio
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59081
Bug ID: 59081
Summary: GCC should forbid using a private member datatype in
template class
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59080
Bug ID: 59080
Summary: [4.9 Regression] [c++11] ICE with array of auto
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c+
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59079
Bug ID: 59079
Summary: a lambda with a parameter that depends on
vector<>::value_type typedef leads to compiler error
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47642
--- Comment #24 from Uroš Bizjak ---
Fixed?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58853
Uroš Bizjak changed:
What|Removed |Added
Target||x86
Status|ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57734
Paolo Carlini changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58853
--- Comment #12 from uros at gcc dot gnu.org ---
Author: uros
Date: Mon Nov 11 20:02:19 2013
New Revision: 204685
URL: http://gcc.gnu.org/viewcvs?rev=204685&root=gcc&view=rev
Log:
PR target/58853
* config/i386/x86-tune.def
(X86_TUNE_MI
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59050
Cong Hou changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58752
--- Comment #7 from Richard Smith ---
(In reply to Daniel Krügler from comment #6)
> (In reply to Richard Smith from comment #4)
> Richard, could you please explain what precisely you meant with:
>
> "Deducing #1 from #2 gives T=const U, which re
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
Bug 53947 depends on bug 58508, which changed state.
Bug 58508 Summary: [Missed-Optimization] Redundant vector load of "actual" loop
invariant in loop body.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58508
What|Removed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58508
Cong Hou changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59065
Harald Anlauf changed:
What|Removed |Added
CC||anlauf at gmx dot de
--- Comment #6 from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59050
--- Comment #4 from congh at gcc dot gnu.org ---
Author: congh
Date: Mon Nov 11 19:03:39 2013
New Revision: 204683
URL: http://gcc.gnu.org/viewcvs?rev=204683&root=gcc&view=rev
Log:
2013-11-11 Cong Hou
PR tree-optimization/59050
* tree-
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59049
--- Comment #9 from Jorn Wolfgang Rennecke ---
Author: amylaar
Date: Mon Nov 11 18:57:25 2013
New Revision: 204682
URL: http://gcc.gnu.org/viewcvs?rev=204682&root=gcc&view=rev
Log:
PR middle-end/59049
* expmed.c (emit_store_flag):
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56902
Cong Hou changed:
What|Removed |Added
CC||congh at google dot com
--- Comment #1 from Co
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59075
--- Comment #2 from Tom Tromey ---
(In reply to Jonathan Wakely from comment #1)
> Tom, do you know why this would be true on OS X?
Offhand I do not know. I think there are a few things that
could help us find out, though.
One would be to see t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678
--- Comment #23 from Nick Maclaren ---
(In reply to Vincent Lefèvre from comment #21)
>
> > Richard Biener's approach to the default is the one that matches the C
> > standard and Vincent Lefèvre is mistaken.
>
> No, I'm correct.
>
> > Defining
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48474
--- Comment #4 from Mike Stump ---
patches to the gcc-patches list get lost and ignored. Bugzilla is forever.
Looks like I chose wisely.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58853
--- Comment #11 from Jan Hubicka ---
> I'll prepare a patch (including HJ's fix) and change option to
> X86_TUNE_MISALIGNED_MOVE_STRING_PRO_EPILOGUES with corresponding
> TARGET_MISALIGNED_MOVE_STRING_PRO_EPILOGUES (and will fix some grammatical
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58853
--- Comment #10 from Uroš Bizjak ---
(In reply to Jan Hubicka from comment #9)
> > > What confuses me is why TARGET_MISALIGNED_MOVE_STRING_PROLOGUES seems to
> > > be
> > > true
> > > given that
> > >
> > > DEF_TUNE (TARGET_MISALIGNED_MOVE_STRIN
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58853
--- Comment #9 from Jan Hubicka ---
> > What confuses me is why TARGET_MISALIGNED_MOVE_STRING_PROLOGUES seems to be
> > true
> > given that
> >
> > DEF_TUNE (TARGET_MISALIGNED_MOVE_STRING_PROLOGUES,
> > "misaligned_move_string_prologues
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58853
--- Comment #8 from Uroš Bizjak ---
(In reply to Jan Hubicka from comment #7)
> Yes, we can add this, too, for correctness with manual changes to tunning
> flags
> (so the patch is approved).
> What confuses me is why TARGET_MISALIGNED_MOVE_STRIN
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59078
Bug ID: 59078
Summary: autoincrement feature of NEON store instructions is
not used
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58853
--- Comment #7 from Jan Hubicka ---
> diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
> index 53e04c4..dd8d943 100644
> --- a/gcc/config/i386/i386.c
> +++ b/gcc/config/i386/i386.c
> @@ -23766,6 +23766,7 @@ ix86_expand_set_or_movmem (r
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678
--- Comment #22 from joseph at codesourcery dot com ---
On Mon, 11 Nov 2013, nmm1 at cam dot ac.uk wrote:
> There are also very strong grounds for not wanting IEEE 754 support by
> default, anyway, because of the performance impact and because a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49661
--- Comment #3 from joseph at codesourcery dot com ---
libiberty is a C library. I don't consider that relevant to any code not
actually part of libiberty.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59058
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Known to work|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59064
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |4.9.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59063
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |4.9.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59071
Richard Biener changed:
What|Removed |Added
Keywords||rejects-valid
Target|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58937
Yury Gribov changed:
What|Removed |Added
CC||samsonov at google dot com
--- Comment #4 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59073
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment #2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59077
Bug ID: 59077
Summary: ipa-pure-const.c (better_state): comment and code
mistmatch
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Pri
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678
--- Comment #21 from Vincent Lefèvre ---
(In reply to Nick Maclaren from comment #20)
> Richard Biener's approach to the default is the one that matches the C
> standard and Vincent Lefèvre is mistaken.
No, I'm correct.
> Defining it to be 'off'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54562
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54562
--- Comment #5 from Jonathan Wakely ---
Author: redi
Date: Mon Nov 11 13:33:48 2013
New Revision: 204672
URL: http://gcc.gnu.org/viewcvs?rev=204672&root=gcc&view=rev
Log:
PR libstdc++/54562
* include/std/mutex (__timed_mutex_impl::__clock
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47756
--- Comment #6 from Olaf van der Spek ---
Hi Jonathan,
The difference between < > and " " is implementation defined. AFAIK GCC only
searches the include path with < > and first searches relative to the current
file with " ". So the standard can't
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58931
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58822
--- Comment #25 from Michi Henning ---
(In reply to Jonathan Wakely from comment #24)
> (In reply to Michi Henning from comment #20)
> > I'm pretty sure that I'm not using anything in shared_ptr that's outside the
> > standard, and the standard wa
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58822
--- Comment #24 from Jonathan Wakely ---
(In reply to Michi Henning from comment #20)
> I'm pretty sure that I'm not using anything in shared_ptr that's outside the
> standard, and the standard way to get access to shared_ptr is to include
> . If
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59056
--- Comment #3 from Jonathan Wakely ---
Similar (but not identical) to PR 58752
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52015
Jonathan Wakely changed:
What|Removed |Added
CC||chun-fu.yang at hp dot com
--- Comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59076
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Component|c++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59063
--- Comment #15 from Evgeniy Stepanov ---
(In reply to Yury Gribov from comment #13)
> (In reply to Evgeniy Stepanov from comment #11)
> > (In reply to Yury Gribov from comment #4)
> > > Evgeniy, what about a warning in GetRealFunctionAddress if r
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59049
--- Comment #8 from Jorn Wolfgang Rennecke ---
(In reply to Richard Biener from comment #7)
> That is, sth like
>
> Index: gcc/tree-ssa-ter.c
> ===
> --- gcc/tree-ssa-ter.c (revisio
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59049
--- Comment #7 from Richard Biener ---
That is, sth like
Index: gcc/tree-ssa-ter.c
===
--- gcc/tree-ssa-ter.c (revision 204664)
+++ gcc/tree-ssa-ter.c (working copy)
@@ -438,6 +439
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59063
--- Comment #14 from Yury Gribov ---
(In reply to Yury Gribov from comment #12)
> Makes sense. Attaching new patch.
Forgot to mention - tested on x64_64.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59049
--- Comment #6 from Richard Biener ---
We have
:
# iftmp.2_1 = PHI <"foo"(2), "bar"(3)>
_10 = 3;
_34 = g.5_8 != 1;
_35 = _10 != 3;
in .optimized, as fold-all-builtins manages to produce that from
:
# iftmp.2_1 = PHI <"foo"(3), "ba
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59063
--- Comment #13 from Yury Gribov ---
(In reply to Evgeniy Stepanov from comment #11)
> (In reply to Yury Gribov from comment #4)
> > Evgeniy, what about a warning in GetRealFunctionAddress if real symbol is
> > NULL?
>
> Warning sounds like a goo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59063
Yury Gribov changed:
What|Removed |Added
Attachment #31192|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57680
Kai Tietz changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59049
Jorn Wolfgang Rennecke changed:
What|Removed |Added
Keywords||patch
--- Comment #5 from Jorn W
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58970
--- Comment #30 from Jan Smets ---
Thanks!
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58854
--- Comment #8 from Ramana Radhakrishnan ---
Author: ramana
Date: Mon Nov 11 09:38:14 2013
New Revision: 204665
URL: http://gcc.gnu.org/viewcvs?rev=204665&root=gcc&view=rev
Log:
Backport fix for PR target/58854
2013-11-11 Ramana Radhakrishnan
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58854
Ramana Radhakrishnan changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678
Nick Maclaren changed:
What|Removed |Added
CC||nmm1 at cam dot ac.uk
--- Comment #20 fro
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38047
Richard Biener changed:
What|Removed |Added
Last reconfirmed|2008-11-07 11:26:14 |2011-11-10 10:26:14
Known to fail|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58028
Richard Biener changed:
What|Removed |Added
CC|rguenther at suse dot de |rguenth at gcc dot
gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59065
--- Comment #5 from Vittorio Zecca ---
I do not think SIZE should be used to detect an undefined array
pointer, but a size of zero
warns the code that the array is mostly unusable and that perhaps
something is wrong,
while a nonzero size is tellin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42970
--- Comment #2 from Richard Biener ---
Consider LTO. Note that the issue is that while we remove assignments to
unused variables from calls at the caller side we never remove a never used
return value from a return statement. This keeps the comp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56853
--- Comment #6 from g ---
In my case i could fix it by reinstalling gmp.
for macports you would have todo:
port -f uninstall gmp
port install -s gmp
81 matches
Mail list logo
