http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57834
Tobias Burnus changed:
What|Removed |Added
Keywords||rejects-valid
Status|UNCONFIR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16093
Manuel López-Ibáñez changed:
What|Removed |Added
Severity|normal |enhancement
--- Comment #5 from Man
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57835
Bug ID: 57835
Summary: variable tracking produces weird const
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57807
--- Comment #3 from jleahy+gcc at gmail dot com ---
I'll test this on Monday and get back to you.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19448
Paolo Carlini changed:
What|Removed |Added
CC|gcc-bugs at gcc dot gnu.org|
--- Comment #16 from Paolo Carlin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16093
Paolo Carlini changed:
What|Removed |Added
CC|gcc-bugs at gcc dot gnu.org|manu at gcc dot gnu.org
--- Commen
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57807
--- Comment #2 from Uroš Bizjak ---
jleahly, can you please test proposed patch with -masm=intel a bit?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57807
Uroš Bizjak changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57833
Harald Anlauf changed:
What|Removed |Added
CC||anlauf at gmx dot de
--- Comment #1 from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57834
Bug ID: 57834
Summary: C_F_POINTER regression(-std): accepts only explicit-
and assumed-size arrays for FPTR when SHAPE is present
Product: gcc
Version: 4.9.0
Status: UNCO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57833
Bug ID: 57833
Summary: MOVE_ALLOC's TO actual argument cannot be used in
subsequent ALLOCATE statement
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57832
--- Comment #1 from Olivier Langlois ---
Created attachment 30466
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30466&action=edit
original c file
very macro heavy loop unrolling sha-256 code hand optimized code (I have peaked
into the resul
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57832
Bug ID: 57832
Summary: compiling sha-256 code (xz 5.0.5) generates false
warnings when using -march=native on Atom CPU
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57831
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57830
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3 f
(this->*&B::f)();
--
$ g++-4.9 -v
Using built-in specs.
COLLECT_GCC=g++-4.9
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --prefix=/usr/local --program-suf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57773
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14263
Paolo Carlini changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|gcc-bugs at g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57830
--- Comment #2 from Jorn Wolfgang Rennecke ---
Created attachment 30464
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30464&action=edit
strlenopt-10.c optimized dump file from -Os compilation
This is expanded not into a single, but multiple
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57830
Andrew Pinski changed:
What|Removed |Added
Component|tree-optimization |target
--- Comment #1 from Andrew Pinski
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748
Andrew Pinski changed:
What|Removed |Added
Component|tree-optimization |middle-end
Target Milestone|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51253
Paolo Carlini changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57829
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57829
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
Target Milesto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57776
Rainer Orth changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57796
--- Comment #4 from Yuri Rumyantsev ---
(In reply to Jakub Jelinek from comment #3)
> By tuning I've meant the vectorizer cost model. If the desirability of
> gathers vs. no vectorization at all doesn't depend only on the insns in the
> loop, but
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57655
Uroš Bizjak changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57829
Marc Glisse changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57796
--- Comment #3 from Jakub Jelinek ---
By tuning I've meant the vectorizer cost model. If the desirability of gathers
vs. no vectorization at all doesn't depend only on the insns in the loop, but
also on how many iterations the loop has, then perh
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51253
Akim Demaille changed:
What|Removed |Added
CC||akim.demaille at gmail dot com
--- Commen
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57796
Yuri Rumyantsev changed:
What|Removed |Added
CC||ysrumyan at gmail dot com
--- Comment #
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748
Ramana Radhakrishnan changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57829
Mikael Pettersson changed:
What|Removed |Added
CC||mikpe at it dot uu.se
--- Comment #1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57830
Bug ID: 57830
Summary: fold_builtin_memory_op expands memcpy without regard
to -Os
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Pri
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57829
Bug ID: 57829
Summary: Wrong constant folding
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56801
--- Comment #2 from Patrick Marlier ---
This seems to be solved in 4.7.3 (I cannot reproduce).
Mike, do you confirm that?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57757
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57645
Paolo Carlini changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53414
roodh changed:
What|Removed |Added
CC||siddharoodh.d at gmail dot com
--- Comment #2 fro
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57779
--- Comment #3 from Paolo Carlini ---
Even if our implementation doesn't misbehave in those cases, a DEBUG_PEDASSERT
could be in order (like we do in, eg, basic_string::operator[])
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57827
Paolo Carlini changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57827
Paolo Carlini changed:
What|Removed |Added
Blocks||55004
--- Comment #1 from Paolo Carlini
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57828
Bug ID: 57828
Summary: linker error: undefined reference to '.LLSTxxx'
Product: gcc
Version: 4.7.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53356
--- Comment #13 from tormen ---
Small update:
The problem for me was seemingly caused by the fact that I was compiling on a
tmpfs RAM disk.
When I moved the compilation to a fixed disk, the below error vanished.
Maybe that can be of help to som
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29776
--- Comment #19 from Jakub Jelinek ---
Also, perhaps expand_builtin_unop for the int bitops builtin
(ffs/parity/popcount/clz/ctz/clrsb) optabs, if target returned by expand_unop
is wider than target_mode, perhaps we could set SUBREG_PROMOTED_VAR_P
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29776
--- Comment #18 from Jakub Jelinek ---
Or yet another option is just to always use [0, prec] VR for CLZ (and lower it
for defined range, as the patch does right now), i.e. for CLZ
change maxi = prec - 1; to maxi = prec; and drop if (maxi == prec)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29776
--- Comment #17 from Jakub Jelinek ---
Unfortunately looking at longlong.h, the header on some targets uses
__builtin_clz* or __builtin_ctz* even with defining COUNT_LEADING_ZEROS_0 to
some value (e.g. on alpha, arm, avr, coldfire, mips).
libgcc i
47 matches
Mail list logo