--- Comment #27 from jamborm at gcc dot gnu dot org 2010-07-21 17:21
---
Fixed.
--
jamborm at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNE
--- Comment #26 from jamborm at gcc dot gnu dot org 2010-07-21 14:17
---
Subject: Bug 44900
Author: jamborm
Date: Wed Jul 21 14:17:11 2010
New Revision: 162375
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162375
Log:
2010-07-21 Martin Jambor
PR tree-optimization/4
--- Comment #25 from jamborm at gcc dot gnu dot org 2010-07-21 13:57
---
Subject: Bug 44900
Author: jamborm
Date: Wed Jul 21 13:57:12 2010
New Revision: 162374
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162374
Log:
2010-07-21 Martin Jambor
PR tree-optimization/4
--- Comment #24 from jamborm at gcc dot gnu dot org 2010-07-20 13:34
---
I posted a proposed fix to the mailing list:
http://gcc.gnu.org/ml/gcc-patches/2010-07/msg01570.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44900
--
jamborm at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jamborm at gcc dot gnu dot
|dot org
--- Comment #23 from yottui at yahoo dot co dot jp 2010-07-15 03:45 ---
(In reply to comment #22)
> Please file that as a different bug.
May I enter comment #15 as a new bug to Bugzilla?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44900
--- Comment #22 from pinskia at gcc dot gnu dot org 2010-07-14 16:50
---
(In reply to comment #21)
> Even if it did not voilate aliasing rules, the IR looks good:
The expansion looks incorrect though:
(insn 39 38 40 t.cc:55 (set (reg:DI 107)
(vec_select:DI (reg:V2DI 79 [ D.4999
--- Comment #21 from pinskia at gcc dot gnu dot org 2010-07-14 16:44
---
(In reply to comment #20)
> (In reply to comment #15)
> > I found the similar case with gcc 4.4.4 of MacPorts and gcc 4.4.0 of MinGW.
> I think the code in comment #15 is invalid and voilates C/C++ aliasing rules.
--- Comment #20 from pinskia at gcc dot gnu dot org 2010-07-14 16:41
---
(In reply to comment #15)
> I found the similar case with gcc 4.4.4 of MacPorts and gcc 4.4.0 of MinGW.
I think the code in comment #15 is invalid and voilates C/C++ aliasing rules.
--
http://gcc.gnu.org/bugzi
--- Comment #19 from hjl dot tools at gmail dot com 2010-07-14 15:52
---
(In reply to comment #15)
> I found the similar case with gcc 4.4.4 of MacPorts and gcc 4.4.0 of MinGW.
>
> -- begin testcase --
> // g++ -O -msse2 test.cpp
> typedef long long __m128i __attribute__ ((__vector_siz
--- Comment #18 from sezeroz at gmail dot com 2010-07-14 14:05 ---
(In reply to comment #15)
> I found the similar case with gcc 4.4.4 of MacPorts and gcc 4.4.0 of MinGW.
>
This case fails with 4.4 on i686-linux too, printing 16, 16, 14, 14 instead of
16, 15, 14, 13 which 4.3 does.
-
--- Comment #17 from sezeroz at gmail dot com 2010-07-14 14:02 ---
(In reply to comment #16)
> This is also the wrong result with MinGW gcc 3.4.5.
> I'm expecting that all component of v will be 2500.
>
> 4.4.4 of MacPorts, 4.5.0 of MacPorts, 4.4.0 of MinGW and 4.5.0-1 of MinGW were
> w
--- Comment #16 from yottui at yahoo dot co dot jp 2010-07-14 12:24 ---
This is also the wrong result with MinGW gcc 3.4.5.
I'm expecting that all component of v will be 2500.
4.4.4 of MacPorts, 4.5.0 of MacPorts, 4.4.0 of MinGW and 4.5.0-1 of MinGW were
worked fine.
This time, I did n
--- Comment #15 from yottui at yahoo dot co dot jp 2010-07-14 09:22 ---
I found the similar case with gcc 4.4.4 of MacPorts and gcc 4.4.0 of MinGW.
-- begin testcase --
// g++ -O -msse2 test.cpp
typedef long long __m128i __attribute__ ((__vector_size__ (16),
__may_alias__));
struct vec
--- Comment #14 from rguenth at gcc dot gnu dot org 2010-07-12 07:54
---
It indeed works with the 4.5.0 release which makes it a blocker for 4.5.1.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from hjl dot tools at gmail dot com 2010-07-12 02:03
---
If you replace
---
vec2 a;
a = vec2::load(p);
---
with
---
vec2 a = vec2::load(p);
---
the testcase will pass.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44900
--- Comment #12 from hjl dot tools at gmail dot com 2010-07-12 01:05
---
It is caused by revision 158826. On trunk, it
is fixed/hidden by revision 158732:
http://gcc.gnu.org/ml/gcc-cvs/2010-04/msg00839.html
--
hjl dot tools at gmail dot com changed:
What|Removed
--- Comment #11 from hjl dot tools at gmail dot com 2010-07-11 23:35
---
It is very likely caused by revision 158826:
http://gcc.gnu.org/ml/gcc-cvs/2010-04/msg00933.html
I will verify it and find out which checkin on trunk
fixes/hides this bug.
--
http://gcc.gnu.org/bugzilla/show
--- Comment #10 from yottui at yahoo dot co dot jp 2010-07-11 23:11 ---
Please use '-m32' if host is x64.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44900
--- Comment #9 from pinskia at gcc dot gnu dot org 2010-07-11 22:47 ---
Works with:
GNU C++ (GCC) version 4.5.0 20100401 (experimental) [trunk revision 157933]
(x86_64-unknown-linux-gnu)
compiled by GNU C version 4.5.0 20100401 (experimental) [trunk revision
157933], GMP version
--- Comment #8 from rguenth at gcc dot gnu dot org 2010-07-11 21:59 ---
Hm? I checked 4.5.0 and it was broken as well, so someone should double-check
(I can't at the moment).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44900
--- Comment #7 from hjl dot tools at gmail dot com 2010-07-11 20:59 ---
It works with gcc 4.5.0. It is a 4.5.1 regression.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
-
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-07-11 12:48 ---
Confirmed, caused by SRA, maybe latent on the trunk.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
23 matches
Mail list logo
