http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409
--- Comment #6 from H.J. Lu ---
Starting program:
/export/project/git/gcc-regression/spec/2000/spec/benchspec/CINT2000/253.perlbmk/run/0002/../0002/perlbmk_peak.lto
-I./lib diffmail.pl 2 550 15 24 23 100 > /dev/null
Program received signa
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59403
--- Comment #2 from Boaz Ben-Zvi ---
(In reply to Richard Biener from comment #1)
> Are you using precompiled headers?
Our project builds some *.gch files for later use; I don't think that the
compilation that failed was using any precompiled he
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59415
--- Comment #1 from Tobias Burnus ---
It fails in
575 verify_bb_vtables (basic_block bb)
...
589 if (gimple_code (stmt) == GIMPLE_CALL)
590 {
591 tree fncall = gimple_call_fn (stmt);
592 if (T
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59385
--- Comment #5 from Sriraman Tallam ---
The root-cause is because floating point expression contraction is default
disabled in ISO C unless specified explicitly. So, adding -ffp-contract=fast
solves the problem.
Details:
The problem is in functi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58657
--- Comment #2 from Kazumoto Kojima ---
Native TLS support is a mixture of supports in compiler, assembler&linker
and libc. Unfortunately current native SH TLS support of linker and libc
is only for little-endian. Binutils can work with luck. G
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59415
Bug ID: 59415
Summary: ICE segfault in verify_bb_vtables for g++ -S
-fvtable-verify=std -fsanitize=null
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Keywords:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409
--- Comment #5 from H.J. Lu ---
(In reply to H.J. Lu from comment #4)
> Should it consider both *first_niters and scalar_loop_iters?
Something like this
diff --git a/gcc/tree-vect-loop-manip.c b/gcc/tree-vect-loop-manip.c
index 380fd22..3f85cc1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58518
Volker Reichelt changed:
What|Removed |Added
Status|NEW |RESOLVED
Known to work|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59044
Volker Reichelt changed:
What|Removed |Added
CC||reichelt at gcc dot gnu.org
--- Comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409
--- Comment #4 from H.J. Lu ---
Should it consider both *first_niters and scalar_loop_iters?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409
--- Comment #3 from H.J. Lu ---
slpeel_tree_peel_loop_to_edge has comments:
The first guard is:
if (FIRST_NITERS == 0) then skip the first loop,
and go directly to the second loop.
This is removed by r205730.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59385
--- Comment #4 from Sriraman Tallam ---
The "widening_mult" has the answer. This pass converts this gimple sequence
double _31;
double _33;
double _36;
double _37;
_31 = *a_4;
_33 = *b_6;
_34 = _33 * _31;
_36 = *c_8;
_37 = _34
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409
--- Comment #2 from H.J. Lu ---
Revert
--
diff --git a/gcc/tree-vect-loop-manip.c b/gcc/tree-vect-loop-manip.c
index f2fdc99..380fd22 100644
--- a/gcc/tree-vect-loop-manip.c
+++ b/gcc/tree-vect-loop-manip.c
@@ -1061,7 +1061,6 @@ slpeel_tree_peel_
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59092
Andrew Pinski changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59092
--- Comment #2 from Andrew Pinski ---
Author: pinskia
Date: Fri Dec 6 21:08:33 2013
New Revision: 205763
URL: http://gcc.gnu.org/viewcvs?rev=205763&root=gcc&view=rev
Log:
2013-12-06 Andrew Pinski
PR target/59092
* config/aarch64/aarc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59388
Jakub Jelinek changed:
What|Removed |Added
Known to work||4.8.3, 4.9.0
Summary|[4.7/4.8/
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59388
--- Comment #7 from Jakub Jelinek ---
Author: jakub
Date: Fri Dec 6 21:06:13 2013
New Revision: 205762
URL: http://gcc.gnu.org/viewcvs?rev=205762&root=gcc&view=rev
Log:
PR tree-optimization/59388
* tree-ssa-reassoc.c (update_range_test):
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59388
--- Comment #6 from Jakub Jelinek ---
Author: jakub
Date: Fri Dec 6 21:00:49 2013
New Revision: 205761
URL: http://gcc.gnu.org/viewcvs?rev=205761&root=gcc&view=rev
Log:
PR tree-optimization/59388
* tree-ssa-reassoc.c (update_range_test):
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59078
Oleg Endo changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50749
Oleg Endo changed:
What|Removed |Added
CC||tir5c3 at yahoo dot co.uk
--- Comment #17 fro
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59399
--- Comment #5 from Marek Polacek ---
Ah, I knew it was promotion. Perhaps we don't want to enable that for
integer-overflow instrumentation...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58348
ctice at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58348
--- Comment #5 from Andris Pavenis ---
It was short term bug as ENABLE_VTABLE_VERIFY was removed from
libvtv/configure.ac and libvtv/Makefile.am at first and left
in libvtv/testsuite/Makefile.am. It was removed from last place
4 days later. So th
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59399
--- Comment #4 from Andrew Pinski ---
(In reply to Marek Polacek from comment #3)
> Why get_rtx_for_ssa_name returns different rtx for the same SSA_NAME?
Because of the PROMOTE_MODE macro. From docs:
/* Define this macro if it is advisable to ho
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58314
Oleg Endo changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50751
--- Comment #33 from Oleg Endo ---
Author: olegendo
Date: Fri Dec 6 19:34:23 2013
New Revision: 205759
URL: http://gcc.gnu.org/viewcvs?rev=205759&root=gcc&view=rev
Log:
Backport from mainline
2013-11-26 Oleg Endo
PR target/58314
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58314
--- Comment #19 from Oleg Endo ---
Author: olegendo
Date: Fri Dec 6 19:34:23 2013
New Revision: 205759
URL: http://gcc.gnu.org/viewcvs?rev=205759&root=gcc&view=rev
Log:
Backport from mainline
2013-11-26 Oleg Endo
PR target/58314
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58348
ctice at gcc dot gnu.org changed:
What|Removed |Added
CC||ctice at gcc dot gnu.org
--- Co
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59399
--- Comment #3 from Marek Polacek ---
On both x86_64 and ppc64, we have this identical SSA_NAME:
unit size
align 32 symtab 0 alias set -1 canonical type 0x7fb5a65a4690 precision
32 min max
pointer_to_this >
visited
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59043
--- Comment #2 from mrs at gcc dot gnu.org ---
Author: mrs
Date: Fri Dec 6 19:26:26 2013
New Revision: 205758
URL: http://gcc.gnu.org/viewcvs?rev=205758&root=gcc&view=rev
Log:
2013-12-06 Dominique d'Humieres
PR testsuite/59043
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58721
--- Comment #12 from Dominique d'Humieres ---
> The inlining of perdida also happens with --param large-function-insns=10.
> perhaps it indicates we shoud bump this parameter up little bit.
The threshold is ~6000 (exactly 5941), i.e. more tha
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59414
Bug ID: 59414
Summary: Class array pointers: compile error on valid code
(Different ranks in pointer assignment)
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59408
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59408
--- Comment #1 from ian at gcc dot gnu.org ---
Author: ian
Date: Fri Dec 6 18:26:27 2013
New Revision: 205756
URL: http://gcc.gnu.org/viewcvs?rev=205756&root=gcc&view=rev
Log:
PR go/59408
runtime: Don't require g != m->g0 in sema notesleep.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58721
--- Comment #11 from Jan Hubicka ---
The inlining of perdida also happens with --param large-function-insns=10.
perhaps it indicates we shoud bump this parameter up little bit.
The reason why inlining order changed is iztaccihuatl that calls
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410
--- Comment #24 from H.J. Lu ---
(In reply to Kostya Serebryany from comment #22)
> > That is true. The kernel change was made to fix:
> >
> > https://bugzilla.kernel.org/show_bug.cgi?id=36372
>
> Could you please explain the situation?
> What
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410
--- Comment #23 from H.J. Lu ---
I opened:
https://bugzilla.kernel.org/show_bug.cgi?id=66721
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410
--- Comment #22 from Kostya Serebryany ---
> That is true. The kernel change was made to fix:
>
> https://bugzilla.kernel.org/show_bug.cgi?id=36372
Could you please explain the situation?
What was fixed and in which kernel?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410
--- Comment #21 from H.J. Lu ---
(In reply to Kostya Serebryany from comment #20)
> > >
> > > # readelf -lW a.out
> >
> > Your address must be sensible. Otherwise kernel will ignore it.
> > Please try "-Ttext-segment 0x8500".
>
> How i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
-unknown-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/usr/local/gcc-trunk
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 4.9.0 20131206 (experimental) [trunk revision 205734] (GCC)
$
$ gcc-trunk -O1 small.c; a.out
7
$ gcc-trunk -O2 small.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59412
Bug ID: 59412
Summary: __fixunsdfDI triggers wrong inexact exceptions
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: l
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59388
--- Comment #5 from Jakub Jelinek ---
Created attachment 31393
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31393&action=edit
gcc48-pr59388.patch
Untested 4.8.x patch.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59388
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410
--- Comment #20 from Kostya Serebryany ---
> >
> > # readelf -lW a.out
>
> Your address must be sensible. Otherwise kernel will ignore it.
> Please try "-Ttext-segment 0x8500".
How is 0x8500 censible if it's beyond the address
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59405
Uroš Bizjak changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410
--- Comment #19 from H.J. Lu ---
(In reply to H.J. Lu from comment #18)
> (In reply to Kostya Serebryany from comment #16)
> > > Kernel is free to load PIE at ANY address it wants. But
> > > you can specify where to load PIE via a linker switch
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410
--- Comment #18 from H.J. Lu ---
(In reply to Kostya Serebryany from comment #16)
> > Kernel is free to load PIE at ANY address it wants. But
> > you can specify where to load PIE via a linker switch
> >
> > -Ttext-segment 0x8500
> >
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58251
--- Comment #10 from Markus Trippelsdorf ---
(In reply to David Kredba from comment #8)
> Going to attach ii file gzipped.
>
> What can I do next please?
You can now further reduce the single testfile by following the
"Simple ICE reduction" sec
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59405
--- Comment #9 from uros at gcc dot gnu.org ---
Author: uros
Date: Fri Dec 6 17:16:52 2013
New Revision: 205753
URL: http://gcc.gnu.org/viewcvs?rev=205753&root=gcc&view=rev
Log:
PR target/59405
* config/i386/i386.c (type_natural_mode): Pr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410
--- Comment #17 from Kostya Serebryany ---
> already, but don't remember where exactly.
Please let's move the discussion about non-PIE here:
https://code.google.com/p/thread-sanitizer/issues/detail?id=5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410
--- Comment #16 from Kostya Serebryany ---
> Kernel is free to load PIE at ANY address it wants. But
> you can specify where to load PIE via a linker switch
>
> -Ttext-segment 0x8500
>
> to tell kernel to load PIE to a specific address.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410
--- Comment #15 from Jakub Jelinek ---
What I mean, unlike asan where the shadow memory shift and base is part of the
ABI, in tsan, while performance sensitive, the MemToShadow is still library
implementation detail. So, I think it shouldn't be t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410
--- Comment #14 from H.J. Lu ---
(In reply to Kostya Serebryany from comment #11)
> > 4000-5000 r-xp 08:11 34221424
> > /export/build/gnu/gcc-x32/build-x86_64-linux/gcc/testsuite/atomic_stack.exe
>
> So,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58251
--- Comment #9 from David Kredba ---
Created attachment 31391
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31391&action=edit
Preprocessed source file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58251
--- Comment #8 from David Kredba ---
Thank you Richard.
This fails as before:
kig-4.11.4_build # /usr/bin/x86_64-pc-linux-gnu-g++ -save-temps -fPIC -O2 -ggdb
-pipe -march=native -mtune=native -flto=4 -fuse-linker-plugin
-Wnon-virtual-dtor -Wno-l
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410
--- Comment #13 from Dmitry Vyukov ---
And what if you enable randomization?
> Have any attempt for saner tsan shadow memory mapping be done in the last
> year?
No, there were no such attempts.
But, yes, it would be nice if tsan supports no-ASR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410
--- Comment #12 from H.J. Lu ---
For some reason, tsan tests aren't run on 6GB machine.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410
--- Comment #11 from Kostya Serebryany ---
> 4000-5000 r-xp 08:11 34221424
> /export/build/gnu/gcc-x32/build-x86_64-linux/gcc/testsuite/atomic_stack.exe
So, the executable is loaded into 4000, wh
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56807
--- Comment #8 from Andrew Church ---
Yes, by replacing "0 - allocate" with "allocate" it seems to work fine. Sorry
for not trying it out myself earlier.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410
--- Comment #10 from H.J. Lu ---
(In reply to Kostya Serebryany from comment #3)
> (In reply to H.J. Lu from comment #0)
> > On a Linux/x86-64 machine with 4GB RAM, I got failures like:
> >
> > FAIL: c-c++-common/tsan/atomic_stack.c -O0 output
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410
--- Comment #9 from Kostya Serebryany ---
(In reply to H.J. Lu from comment #6)
> I got those failures on this machine:
Admittedly, I never ran tsan tests on a 4Gb machine.
Does clang's tsan also fail there?
Can you show /proc/self/maps of the f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410
Kostya Serebryany changed:
What|Removed |Added
Status|NEW |UNCONFIRMED
Last reconfirmed|2013-1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410
--- Comment #7 from H.J. Lu ---
On failed machine:
[hjl@gnu-ivb-1 ~]$ ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unli
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59411
Bug ID: 59411
Summary: Problem with TYPE(C_PTR) constant initialization
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410
--- Comment #5 from Jakub Jelinek ---
Have any attempt for saner tsan shadow memory mapping be done in the last year?
I mean, there were some PRs or mailing list threads about it being worth to
support also non-PIE executables etc., understandably
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410
--- Comment #4 from Kostya Serebryany ---
(In reply to Dmitry Vyukov from comment #2)
> It seems that this kernel has ASLR disabled, so kernel maps libraries at
> 0x55. Tsan does not support this ATM.
BTW, the situation with tsan's shadow became w
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410
--- Comment #3 from Kostya Serebryany ---
(In reply to H.J. Lu from comment #0)
> On a Linux/x86-64 machine with 4GB RAM, I got failures like:
>
> FAIL: c-c++-common/tsan/atomic_stack.c -O0 output pattern test, is FATAL:
> ThreadSanitizer can n
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410
--- Comment #2 from Dmitry Vyukov ---
It seems that this kernel has ASLR disabled, so kernel maps libraries at 0x55.
Tsan does not support this ATM.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410
--- Comment #1 from Jakub Jelinek ---
BTW, the tsan.exp tests don't seem to be as cheap as was claimed during the
patch submission, I'd prefer to at least throttle the torture options down to
say -O0 and -O2 rather than so many different variants
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410
Bug ID: 59410
Summary: Some tsan tests fail with 4GB RAM
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58721
--- Comment #10 from Jan Hubicka ---
OK,
seems that the problem is with Fortran generating internally __builtin_expect
to control various construct. I would make a lot more sense to use
GIMPLE_PREDICT for those cases. With GIMPLE_PREDICT one can
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59091
Ramana Radhakrishnan changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59406
--- Comment #2 from g1pi at libero dot it ---
(In reply to Jonathan Wakely from comment #1)
> We're not really making any non-critical changes to TR1 code now.
Yet std::_Fnv_hash_bytes in non-TR1 code has the same problem (lines 116 and
161 of svn
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58477
--- Comment #5 from Jan Hubicka ---
I am testing
Index: ../gcc/cgraphclones.c
===
--- ../gcc/cgraphclones.c (revision 205737)
+++ ../gcc/cgraphclones.c (working copy)
@@ -
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58721
Jan Hubicka changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59409
Bug ID: 59409
Summary: [4.9 Regression] 253.perlbmk in SPEC CPU 2K is
miscompiled
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Prio
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474
--- Comment #76 from Richard Biener ---
There are a lot of calls with fnspec, almost all constraints look like
D.12770.0+16 = allalltmp
D.12770.64+128 = allalltmp
D.12770.192+64 = allalltmp
callarg = &READONLY
callarg = *callarg
callarg = callarg
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59330
--- Comment #5 from Richard Biener ---
Author: rguenth
Date: Fri Dec 6 14:14:34 2013
New Revision: 205741
URL: http://gcc.gnu.org/viewcvs?rev=205741&root=gcc&view=rev
Log:
2013-12-06 Richard Biener
Backport from mainline
2013-11-29
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59334
--- Comment #5 from Richard Biener ---
Author: rguenth
Date: Fri Dec 6 14:14:34 2013
New Revision: 205741
URL: http://gcc.gnu.org/viewcvs?rev=205741&root=gcc&view=rev
Log:
2013-12-06 Richard Biener
Backport from mainline
2013-11-29
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59408
Rainer Orth changed:
What|Removed |Added
Target Milestone|--- |4.9.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59408
Bug ID: 59408
Summary: [4.9 regression] Many Go tests FAIL with notesleep not
on g0
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Pr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474
--- Comment #75 from Richard Biener ---
On trunk with the reduced testcase and -O2 (no -g):
ipa inlining heuristics : 9.85 ( 5%) usr 0.00 ( 0%) sys 9.93 ( 5%) wall
1448 kB ( 0%) ggc
tree PTA: 161.26 (78%) usr 0.30 (45
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56807
--- Comment #7 from Kai Tietz ---
duh. Yes, of course the '0 -' is wrong. We want to address backward.
Does the patch with this change fixes your issue?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59407
Bug ID: 59407
Summary: gcc.target/i386/pr58218.c FAILs with Sun as
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59407
Rainer Orth changed:
What|Removed |Added
Target Milestone|--- |4.9.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58017
--- Comment #1 from Oleg Endo ---
(In reply to Oleg Endo from comment #0)
>
> especially if the compared reg is dead after the comparison.
... and the constant is not shared with any other insn
and the comparison is not in a (tight) loop.
i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38134
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|NEW
Assignee|rguenth at gcc do
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59406
--- Comment #1 from Jonathan Wakely ---
We're not really making any non-critical changes to TR1 code now.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59343
Oleg Endo changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59058
Richard Biener changed:
What|Removed |Added
Known to work||4.9.0
Summary|[4.7/4.8/4.9 Re
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58137
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |4.8.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59288
--- Comment #6 from Richard Biener ---
Author: rguenth
Date: Fri Dec 6 12:39:32 2013
New Revision: 205739
URL: http://gcc.gnu.org/viewcvs?rev=205739&root=gcc&view=rev
Log:
2013-12-06 Richard Biener
Backport from mainline
2013-11-27
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59164
--- Comment #6 from Richard Biener ---
Author: rguenth
Date: Fri Dec 6 12:39:32 2013
New Revision: 205739
URL: http://gcc.gnu.org/viewcvs?rev=205739&root=gcc&view=rev
Log:
2013-12-06 Richard Biener
Backport from mainline
2013-11-27
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58137
--- Comment #8 from Richard Biener ---
Author: rguenth
Date: Fri Dec 6 12:39:32 2013
New Revision: 205739
URL: http://gcc.gnu.org/viewcvs?rev=205739&root=gcc&view=rev
Log:
2013-12-06 Richard Biener
Backport from mainline
2013-11-27
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59405
--- Comment #8 from Uroš Bizjak ---
(In reply to Yukhin Kirill from comment #5)
> I see. So, it seems like a limitation to passing vectors as arguments in
> 32-bit mode. We may implement something similar to `vzerroupper'
> autogeneration or simpl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59405
--- Comment #7 from Uroš Bizjak ---
(In reply to H.J. Lu from comment #6)
> I think this is a dup of PR48397.
No, this one happens due to missing interdependencies between x87 and MMX
registers. We could make all MMX instructions dependant on st(
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58359
--- Comment #12 from Anatoly Sinyavin ---
Does it mean that my solution is not accepted?
If it's so I am going to think about two approaches
- vectorizer should ignore that path (Richard Biener 2013-09-09 08:22:53
UTC)
- replacing the GI
1 - 100 of 128 matches
Mail list logo
