http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061
--- Comment #41 from Joost VandeVondele
---
(In reply to Kostya Serebryany from comment #40)
> Is there anything else left in this bug?
> If not, please close this one and open another for the next problem(s)
I'll close it as soon as libbacktra
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50351
--- Comment #7 from xunxun ---
(In reply to Kai Tietz from comment #6)
> I rechecked reported issue with current trunk-version and didn't saw this
> ICE anymore. Also with newer 4.7 version I can't reproduce issue.
>
> Could you please retest an
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59058
--- Comment #13 from Richard Biener ---
Author: rguenth
Date: Fri Dec 6 09:23:07 2013
New Revision: 205730
URL: http://gcc.gnu.org/viewcvs?rev=205730&root=gcc&view=rev
Log:
2013-12-06 Richard Biener
PR tree-optimization/59058
* tree-
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59317
Robert Suchanek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58721
--- Comment #8 from Dominique d'Humieres ---
> ... bug was introduced by r202567 ...
I have checked that and fixing it with r205586 restores the timing of r202566.
The reason why this is not seen on recent revisions is r203167 which introduces
ye
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59403
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58007
janus at gcc dot gnu.org changed:
What|Removed |Added
Known to work||4.6.4, 4.8.1
Summary
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58251
--- Comment #7 from Richard Biener ---
(In reply to David Kredba from comment #6)
> I "reduced" it to this:
>
> /usr/bin/x86_64-pc-linux-gnu-g++ -fPIC -O2 -ggdb -pipe -march=native
> -mtune=native -flto=4 -fuse-linker-plugin -Wnon-virtual-dtor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59395
Richard Biener changed:
What|Removed |Added
Priority|P3 |P4
Target Milestone|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51244
--- Comment #73 from Oleg Endo ---
Author: olegendo
Date: Fri Dec 6 10:46:53 2013
New Revision: 205734
URL: http://gcc.gnu.org/viewcvs?rev=205734&root=gcc&view=rev
Log:
PR target/51244
PR target/59343
* config/sh/sh.md (*cbranch_t):
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59343
--- Comment #9 from Oleg Endo ---
Author: olegendo
Date: Fri Dec 6 10:46:53 2013
New Revision: 205734
URL: http://gcc.gnu.org/viewcvs?rev=205734&root=gcc&view=rev
Log:
PR target/51244
PR target/59343
* config/sh/sh.md (*cbranch_t): C
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59405
Bug ID: 59405
Summary: Incorrect FP<->MMX transition during call/ret
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: targ
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59405
--- Comment #1 from Uroš Bizjak ---
There is no testcase attached, but you need to *manually* insert _mm_empty (==
emms) to switch from MMX to x87 state.
The compiler does not automatically insert emms for you.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59226
Alexander Ivchenko changed:
What|Removed |Added
CC||aivchenk at gmail dot com
--- Commen
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59405
--- Comment #2 from Yukhin Kirill ---
Created attachment 31389
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31389&action=edit
Testcase
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59405
--- Comment #3 from Yukhin Kirill ---
(In reply to Uroš Bizjak from comment #1)
> There is no testcase attached, but you need to *manually* insert _mm_empty
> (== emms) to switch from MMX to x87 state.
>
> The compiler does not automatically inse
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59188
Joost VandeVondele changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59226
--- Comment #5 from Markus Trippelsdorf ---
(In reply to Alexander Ivchenko from comment #4)
> This broke Android image build with trunk compiler (in addition to pr58585)..
Yes. Many C++ projects that use multiple inheritance don't compile ATM:
C
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59405
--- Comment #4 from Uroš Bizjak ---
(In reply to Yukhin Kirill from comment #3)
> (In reply to Uroš Bizjak from comment #1)
> > There is no testcase attached, but you need to *manually* insert _mm_empty
> > (== emms) to switch from MMX to x87 stat
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59402
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58585
Markus Trippelsdorf changed:
What|Removed |Added
CC||octoploid at yandex dot com
--- Com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59402
--- Comment #3 from Kostya Serebryany ---
(In reply to H.J. Lu from comment #2)
> (In reply to Kostya Serebryany from comment #1)
> > Thanks for the report, H.J. I'll try to respond properly on Monday (-ish).
>
> Can I check my patches into trunk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59316
--- Comment #17 from Eric Botcazou ---
Author: ebotcazou
Date: Fri Dec 6 11:31:56 2013
New Revision: 205735
URL: http://gcc.gnu.org/viewcvs?rev=205735&root=gcc&view=rev
Log:
PR target/59316
* config/sparc/sparc.h (SPARC_LOW_FE_EXCEPT_VAL
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59316
Eric Botcazou changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59402
--- Comment #4 from H.J. Lu ---
(In reply to Kostya Serebryany from comment #3)
> (In reply to H.J. Lu from comment #2)
> > (In reply to Kostya Serebryany from comment #1)
> > > Thanks for the report, H.J. I'll try to respond properly on Monday (-
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59405
--- Comment #5 from Yukhin Kirill ---
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
simply close the bug as `user misunderstanding.'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59406
Bug ID: 59406
Summary: functions labelled FNV-1a in tr1/functional_hash.h are
not FNV-1a
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: minor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59405
--- Comment #6 from H.J. Lu ---
I think this is a dup of PR48397.
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
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=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=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=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=58137
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |4.8.3
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=59343
Oleg Endo changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
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=38134
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|NEW
Assignee|rguenth at gcc do
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=59407
Rainer Orth changed:
What|Removed |Added
Target Milestone|--- |4.9.0
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=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=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=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=59408
Rainer Orth changed:
What|Removed |Added
Target Milestone|--- |4.9.0
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=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=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=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=58721
Jan Hubicka changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at g
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=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=59091
Ramana Radhakrishnan changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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=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=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
--- 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 #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 #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 #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=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
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
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
Kostya Serebryany changed:
What|Removed |Added
Status|NEW |UNCONFIRMED
Last reconfirmed|2013-1
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
--- 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=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 #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=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=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=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=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=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 #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 #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=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=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=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=59410
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
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
--- 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=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=59412
Bug ID: 59412
Summary: __fixunsdfDI triggers wrong inexact exceptions
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: l
-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=59409
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
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=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 #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 #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=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=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=59408
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
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=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=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=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
1 - 100 of 128 matches
Mail list logo
