Hi,
Consider code:
int foo(char *t, char *v, int w)
{
int i;
for (i = 1; i != w; ++i)
{
int x = i 2;
v[x + 4] = t[x + 4];
}
return 0;
}
Compile it to x86 (I used both gcc 4.7.2 and gcc 4.8.1) with options:
gcc -O2 -m32 -S test.c
You will see loop, formed like:
.L5:
leal 0(,%eax,4), %edx
Hum, I can't change gcc branch because I'm tighted to gnat 7.1.2 based on gcc
4.7.3 (I saw that LRA was merged in 4.8). I will use a workaround for the
moment (i.e. disable wide offset MEM on conditional moves).
Does someone know if gnat frontend will rebase on 4.8 soon :) ? (or maybe LRA
will
Eric Botcazou ebotca...@adacore.com writes:
Well, I think making the simplify-rtx code conditional on the target
would be the wrong way to go. If we really can't live with it being
unconditional then I think we should revert it. But like I say I think
it would be better to make combine
On 06-Dec-13 01:34 AM, Maxim Kuvyrkov wrote:
On 6/12/2013, at 8:44 am, shmeel gutl shmeelg...@shmuelhome.mine.nu wrote:
On 05-Dec-13 02:39 AM, Maxim Kuvyrkov wrote:
Dependency type plays a role for estimating costs and latencies between
instructions (which affects performance), but using
On Fri, Dec 6, 2013 at 12:41 AM, BELBACHIR Selim
selim.belbac...@fr.thalesgroup.com wrote:
Hum, I can't change gcc branch because I'm tighted to gnat 7.1.2 based on gcc
4.7.3 (I saw that LRA was merged in 4.8). I will use a workaround for the
moment (i.e. disable wide offset MEM on
On 06/12/13 09:30, Konstantin Vladimirov wrote:
Hi,
Consider code:
int foo(char *t, char *v, int w)
{
int i;
for (i = 1; i != w; ++i)
{
int x = i 2;
v[x + 4] = t[x + 4];
}
return 0;
}
Compile it to x86 (I used both gcc 4.7.2 and gcc 4.8.1) with options:
gcc -O2 -m32 -S
Any gnat official release ? Maybe gnat 7.2 beta is based on 4.8, I'll try to
get this one.
-Message d'origine-
De : Andrew Pinski [mailto:pins...@gmail.com]
Envoyé : vendredi 6 décembre 2013 09:54
À : BELBACHIR Selim
Cc : Jeff Law; gcc@gcc.gnu.org
Objet : Re: Controling reloads of
Hi,
Example from x86 code was only for ease of reproduction. I am pretty
sure, this is architecture-independent issue. Say on ARM:
.L2:
mov ip, r3, asl #2
add ip, ip, #4
add r3, r3, #1
ldrb r4, [r0, ip] @ zero_extendqisi2
cmp r3, r2
strb r4, [r1, ip]
bne .L2
May be improved to:
.L2:
add r3,
On Fri, Dec 6, 2013 at 5:47 AM, Trevor Saunders tsaund...@mozilla.com wrote:
On Mon, Dec 02, 2013 at 12:16:18PM +0100, Richard Biener wrote:
On Sun, Dec 1, 2013 at 12:30 PM, Toon Moene t...@moene.org wrote:
http://gcc.gnu.org/ml/gcc-testresults/2013-12/msg1.html
FAILED: Bootstrap
On Fri, Dec 6, 2013 at 9:42 AM, Richard Sandiford
rdsandif...@googlemail.com wrote:
Eric Botcazou ebotca...@adacore.com writes:
Well, I think making the simplify-rtx code conditional on the target
would be the wrong way to go. If we really can't live with it being
unconditional then I think
On Fri, Dec 06, 2013 at 12:30:54PM +0400, Konstantin Vladimirov wrote:
Consider code:
int foo(char *t, char *v, int w)
{
int i;
for (i = 1; i != w; ++i)
{
int x = i 2;
v[x + 4] = t[x + 4];
}
return 0;
}
This is either job of ivopts pass, dunno why it doesn't consider
turning
On Fri, Dec 6, 2013 at 9:30 AM, Konstantin Vladimirov
konstantin.vladimi...@gmail.com wrote:
Hi,
Consider code:
int foo(char *t, char *v, int w)
{
int i;
for (i = 1; i != w; ++i)
{
int x = i 2;
v[x + 4] = t[x + 4];
}
return 0;
}
Compile it to x86 (I used both gcc 4.7.2 and gcc
Hi,
nothing changes if everything is unsigned and we are guaranteed to not
raise UB on overflow:
unsigned foo(unsigned char *t, unsigned char *v, unsigned w)
{
unsigned i;
for (i = 1; i != w; ++i)
{
unsigned x = i 2;
v[x + 4] = t[x + 4];
}
return 0;
}
yields:
.L5:
leal 0(,%eax,4), %edx
addl
On Fri, Dec 6, 2013 at 11:19 AM, Konstantin Vladimirov
konstantin.vladimi...@gmail.com wrote:
Hi,
nothing changes if everything is unsigned and we are guaranteed to not
raise UB on overflow:
unsigned foo(unsigned char *t, unsigned char *v, unsigned w)
{
unsigned i;
for (i = 1; i != w;
Hi all,
We are re-targeting the gcc 4.8.1 to the 16 bit core ,where word =int
= short = pointer= 16 , char = 8 bit and long =32 bit.
We model the above requirement as
#define BITS_PER_UNIT 8
#define BITS_PER_WORD 16
#define UNITS_PER_WORD 2
#define POINTER_SIZE
Hi All ,
The below sample caught my attention i.e
int a ;
unsigned int b;
int func()
{
return a =b;
}
the compiler didn't warn me about the signed mismatch in the above case.
where as
int *a ;
unsigned int *b;
int func()
{
a =b;
return *a;
}
compiler warns me as
warning: pointer targets in
On Fri, Dec 6, 2013 at 2:25 AM, Richard Biener
richard.guent...@gmail.com wrote:
On Fri, Dec 6, 2013 at 11:19 AM, Konstantin Vladimirov
konstantin.vladimi...@gmail.com wrote:
Hi,
nothing changes if everything is unsigned and we are guaranteed to not
raise UB on overflow:
unsigned
On Wed, 4 Dec 2013, Vidya Praveen wrote:
Hi Richi,
Apologies for the late response. I was on vacation.
On Mon, Oct 14, 2013 at 09:04:58AM +0100, Richard Biener wrote:
void
foo (int *__restrict__ a,
int *__restrict__ b,
int c)
{
int i;
for (i = 0; i
Umesh Kalappa umesh.kalap...@gmail.com writes:
Tried to compile the below sample by retargeted compiler
int a =10;
int b =10;
int func()
{
return a+ b;
}
the compiler is stating that the a and b are global with short type(HI
mode) of size 2 bytes.
Yeah, HImode sounds right in
On Fri, 6 Dec 2013, Konstantin Vladimirov wrote:
Consider code:
int foo(char *t, char *v, int w)
{
int i;
for (i = 1; i != w; ++i)
{
int x = i 2;
A side note, but something too few people seem to be aware of: writing
i2 can pessimize code compared to i*4 (and it is never faster). That is
Hi,
Richard, I tried to add LSHIFT_EXPR case to tree-scalar-evolution.c
and now it yields code like (x86 again):
.L5:
movzbl 4(%esi,%eax,4), %edx
movb %dl, 4(%ebx,%eax,4)
addl $1, %eax
cmpl %ecx, %eax
jne .L5
So, excessive lea is gone. It is great, thank you so much. But I
wonder what else can
I am pleased to announce that the GCC Steering Committee has
appointed Oleg Endo as co-maintainer of the SH port.
Please join me in congratulating Oleg on his new role.
Oleg, please update your listing in the MAINTAINERS file.
Happy hacking!
David
On Fri, Dec 6, 2013 at 2:52 PM, Konstantin Vladimirov
konstantin.vladimi...@gmail.com wrote:
Hi,
Richard, I tried to add LSHIFT_EXPR case to tree-scalar-evolution.c
and now it yields code like (x86 again):
.L5:
movzbl 4(%esi,%eax,4), %edx
movb %dl, 4(%ebx,%eax,4)
addl $1, %eax
cmpl %ecx,
On 12/06/2013 10:41 AM, Umesh Kalappa wrote:
I’m bit confused or i'm missing something here .
The first of these is implementation-defined behaviour, and the second
is (potentially) undefined behaviour.
This is more of a generic C question than a GCC question.
Andrew.
On Dec 6, 2013, at 5:40 AM, Umesh Kalappa umesh.kalap...@gmail.com wrote:
Hi all,
We are re-targeting the gcc 4.8.1 to the 16 bit core ,where word =int
= short = pointer= 16 , char = 8 bit and long =32 bit.
We model the above requirement as
#define BITS_PER_UNIT 8
On Fri, Dec 06, 2013 at 10:47:00AM +0100, Richard Biener wrote:
On Fri, Dec 6, 2013 at 5:47 AM, Trevor Saunders tsaund...@mozilla.com wrote:
On Mon, Dec 02, 2013 at 12:16:18PM +0100, Richard Biener wrote:
On Sun, Dec 1, 2013 at 12:30 PM, Toon Moene t...@moene.org wrote:
On Fri, 2013-12-06 at 09:05 -0500, David Edelsohn wrote:
I am pleased to announce that the GCC Steering Committee has
appointed Oleg Endo as co-maintainer of the SH port.
Please join me in congratulating Oleg on his new role.
Oleg, please update your listing in the MAINTAINERS
On 12/06/13 07:17, Richard Biener wrote:
On Fri, Dec 6, 2013 at 2:52 PM, Konstantin Vladimirov
konstantin.vladimi...@gmail.com wrote:
Hi,
Richard, I tried to add LSHIFT_EXPR case to tree-scalar-evolution.c
and now it yields code like (x86 again):
.L5:
movzbl 4(%esi,%eax,4), %edx
movb %dl,
On 12/5/2013, 9:35 AM, Tejas Belagod wrote:
Vladimir Makarov wrote:
On 12/4/2013, 6:15 AM, Tejas Belagod wrote:
Hi,
I'm trying to relax CANNOT_CHANGE_MODE_CLASS for aarch64 to allow all
mode changes on FP_REGS as aarch64 does not have register-packing, but
I'm running into an LRA ICE. A test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061
--- Comment #41 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
---
(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)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50351
--- Comment #7 from xunxun xunxun1982 at gmail dot com ---
(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.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59058
--- Comment #13 from Richard Biener rguenth at gcc dot gnu.org ---
Author: rguenth
Date: Fri Dec 6 09:23:07 2013
New Revision: 205730
URL: http://gcc.gnu.org/viewcvs?rev=205730root=gccview=rev
Log:
2013-12-06 Richard Biener rguent...@suse.de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59317
Robert Suchanek robert.suchanek at imgtec dot com changed:
What|Removed |Added
Status|UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58721
--- Comment #8 from Dominique d'Humieres dominiq at lps dot ens.fr ---
... 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59403
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58251
--- Comment #7 from Richard Biener rguenth at gcc dot gnu.org ---
(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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59395
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P4
Target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51244
--- Comment #73 from Oleg Endo olegendo at gcc dot gnu.org ---
Author: olegendo
Date: Fri Dec 6 10:46:53 2013
New Revision: 205734
URL: http://gcc.gnu.org/viewcvs?rev=205734root=gccview=rev
Log:
PR target/51244
PR target/59343
*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59343
--- Comment #9 from Oleg Endo olegendo at gcc dot gnu.org ---
Author: olegendo
Date: Fri Dec 6 10:46:53 2013
New Revision: 205734
URL: http://gcc.gnu.org/viewcvs?rev=205734root=gccview=rev
Log:
PR target/51244
PR target/59343
*
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:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59405
--- Comment #1 from Uroš Bizjak ubizjak at gmail dot com ---
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 aivchenk at gmail dot com changed:
What|Removed |Added
CC||aivchenk at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59405
--- Comment #2 from Yukhin Kirill kirill.yukhin at intel dot com ---
Created attachment 31389
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31389action=edit
Testcase
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59405
--- Comment #3 from Yukhin Kirill kirill.yukhin at intel dot com ---
(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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59188
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
Status|NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59226
--- Comment #5 from Markus Trippelsdorf octoploid at yandex dot com ---
(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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59405
--- Comment #4 from Uroš Bizjak ubizjak at gmail dot com ---
(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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59402
H.J. Lu hjl.tools at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58585
Markus Trippelsdorf octoploid at yandex dot com changed:
What|Removed |Added
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59402
--- Comment #3 from Kostya Serebryany kcc at gcc dot gnu.org ---
(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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59316
--- Comment #17 from Eric Botcazou ebotcazou at gcc dot gnu.org ---
Author: ebotcazou
Date: Fri Dec 6 11:31:56 2013
New Revision: 205735
URL: http://gcc.gnu.org/viewcvs?rev=205735root=gccview=rev
Log:
PR target/59316
*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59316
Eric Botcazou ebotcazou at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59402
--- Comment #4 from H.J. Lu hjl.tools at gmail dot com ---
(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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59405
--- Comment #5 from Yukhin Kirill kirill.yukhin at intel dot com ---
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
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 hjl.tools at gmail dot com ---
I think this is a dup of PR48397.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58359
--- Comment #12 from Anatoly Sinyavin a.sinyavin at samsung dot com ---
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59405
--- Comment #7 from Uroš Bizjak ubizjak at gmail dot com ---
(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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59405
--- Comment #8 from Uroš Bizjak ubizjak at gmail dot com ---
(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'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59164
--- Comment #6 from Richard Biener rguenth at gcc dot gnu.org ---
Author: rguenth
Date: Fri Dec 6 12:39:32 2013
New Revision: 205739
URL: http://gcc.gnu.org/viewcvs?rev=205739root=gccview=rev
Log:
2013-12-06 Richard Biener rguent...@suse.de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58137
--- Comment #8 from Richard Biener rguenth at gcc dot gnu.org ---
Author: rguenth
Date: Fri Dec 6 12:39:32 2013
New Revision: 205739
URL: http://gcc.gnu.org/viewcvs?rev=205739root=gccview=rev
Log:
2013-12-06 Richard Biener rguent...@suse.de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59288
--- Comment #6 from Richard Biener rguenth at gcc dot gnu.org ---
Author: rguenth
Date: Fri Dec 6 12:39:32 2013
New Revision: 205739
URL: http://gcc.gnu.org/viewcvs?rev=205739root=gccview=rev
Log:
2013-12-06 Richard Biener rguent...@suse.de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58137
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |4.8.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59058
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Known to work||4.9.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59343
Oleg Endo olegendo at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59406
--- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org ---
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 rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58017
--- Comment #1 from Oleg Endo olegendo at gcc dot gnu.org ---
(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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59407
Rainer Orth ro at gcc dot gnu.org 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:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56807
--- Comment #7 from Kai Tietz ktietz at gcc dot gnu.org ---
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 rguenth at gcc dot gnu.org ---
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:
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59408
Rainer Orth ro at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |4.9.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59334
--- Comment #5 from Richard Biener rguenth at gcc dot gnu.org ---
Author: rguenth
Date: Fri Dec 6 14:14:34 2013
New Revision: 205741
URL: http://gcc.gnu.org/viewcvs?rev=205741root=gccview=rev
Log:
2013-12-06 Richard Biener rguent...@suse.de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59330
--- Comment #5 from Richard Biener rguenth at gcc dot gnu.org ---
Author: rguenth
Date: Fri Dec 6 14:14:34 2013
New Revision: 205741
URL: http://gcc.gnu.org/viewcvs?rev=205741root=gccview=rev
Log:
2013-12-06 Richard Biener rguent...@suse.de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474
--- Comment #76 from Richard Biener rguenth at gcc dot gnu.org ---
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 =
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58721
Jan Hubicka hubicka at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58477
--- Comment #5 from Jan Hubicka hubicka at gcc dot gnu.org ---
I am testing
Index: ../gcc/cgraphclones.c
===
--- ../gcc/cgraphclones.c (revision 205737)
+++
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59091
Ramana Radhakrishnan ramana at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58721
--- Comment #10 from Jan Hubicka hubicka at gcc dot gnu.org ---
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.
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 jakub at gcc dot gnu.org ---
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410
--- Comment #2 from Dmitry Vyukov dvyukov at google dot com ---
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 kcc at gcc dot gnu.org ---
(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:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410
--- Comment #4 from Kostya Serebryany kcc at gcc dot gnu.org ---
(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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410
--- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org ---
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
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:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410
H.J. Lu hjl.tools at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410
--- Comment #7 from H.J. Lu hjl.tools at gmail dot com ---
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410
Kostya Serebryany kcc at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410
--- Comment #9 from Kostya Serebryany kcc at gcc dot gnu.org ---
(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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410
--- Comment #10 from H.J. Lu hjl.tools at gmail dot com ---
(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:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56807
--- Comment #8 from Andrew Church achurch+gcc at achurch dot org ---
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 hjl.tools at gmail dot com ---
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 kcc at gcc dot gnu.org ---
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410
--- Comment #13 from Dmitry Vyukov dvyukov at google dot com ---
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
1 - 100 of 305 matches
Mail list logo
