--- Comment #13 from jvdelisle at gcc dot gnu dot org 2008-05-06 04:35
---
Janne, see discussion in comment #6
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-05-06 04:15 ---
Oh we don't handle VCE On the left hand side for many different reasons. One
is because if we set only part of the variable, we could get possible invalid
gimple as we are only setting part of a SSA_NAME. I am un-a
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-05-06 04:09 ---
So for &i[0], we don't convert it to VCE but the others we convert it but we
don't get to the point convert to VCE for the placement new case for some
reason ...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2008-05-06 04:02
---
Fixed on trunk, reopened PR34974
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2008-05-06 04:01
---
Subject: Bug 36131
Author: jvdelisle
Date: Tue May 6 04:00:38 2008
New Revision: 134973
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134973
Log:
2008-05-05 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #12 from jvdelisle at gcc dot gnu dot org 2008-05-06 04:01
---
Reverted patch which caused pr36131. Reopening this one.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-05-06 03:56 ---
(In reply to comment #2)
> FWIW, noticed on cris-elf as well, where additionally, for the record,
> gfortran.dg/transfer_assumed_size_1.f90 regressed. From gfortran.log:
I just checked on i686-darwin and there is n
--- Comment #13 from pinskia at gcc dot gnu dot org 2008-05-06 03:48
---
Subject: Bug 36141
Author: pinskia
Date: Tue May 6 03:47:29 2008
New Revision: 134972
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134972
Log:
2008-05-05 Andrew Pinski <[EMAIL PROTECTED]>
PR
--- Comment #12 from pinskia at gcc dot gnu dot org 2008-05-06 03:47
---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNE
--- Comment #1 from bkoz at gcc dot gnu dot org 2008-05-06 03:11 ---
These are all failures in "C" mode, and are due to running into C++ constructs
like the keyword "namespace."
--
bkoz at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2008-05-06 02:27
---
The regression occurs from r132512, the change to transfer.c
The test case from pr36142 is:
! { dg-do run }
! Adapted from fmt_t_6.f testcase for PR 34782
character a(6)
data a / 'a', 'b', 'c', 'd',
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2008-05-06 02:25
---
Regarding Janne's thoughts on fixing this problem. One of the features that
the stream alloc provides is the ability to grow the buffer size as needed. We
will have to rethink this problem as part of eliminating
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2008-05-06 01:43
---
I have confirmed this is a duplicate of pr36131. The regression occurs from
r132512, the change to transfer.c
*** This bug has been marked as a duplicate of 36131 ***
--
jvdelisle at gcc dot gnu dot org chan
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2008-05-06 01:43
---
*** Bug 36142 has been marked as a duplicate of this bug. ***
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #11 from hjl dot tools at gmail dot com 2008-05-06 01:13
---
(In reply to comment #10)
> (In reply to comment #8)
> > That is:
> > Index: gcc/gcc/tree-ssa-forwprop.c
> > ===
> > --- gcc/gcc/tree-ssa-forwprop.c (
--- Comment #2 from hp at gcc dot gnu dot org 2008-05-06 01:05 ---
FWIW, noticed on cris-elf as well, where additionally, for the record,
gfortran.dg/transfer_assumed_size_1.f90 regressed. From gfortran.log:
PASS: gfortran.dg/transfer_assumed_size_1.f90 -O2 (test for excess errors)
c
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2008-05-06 00:33
---
This is a regression and probably the same as PR36131. When I first saw this,
I was having dejavu. I knew we fixed this already once before.
--
jvdelisle at gcc dot gnu dot org changed:
What|
--- Comment #3 from hjl dot tools at gmail dot com 2008-05-06 00:30 ---
Fixed by revision 134966.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-05-05 23:32 ---
/tmp/ccdYPpfu.s:66: Error: invalid character '<' in mnemonic
/tmp/ccdYPpfu.s:70: Error: invalid character '<' in mnemonic
/tmp/ccdYPpfu.s:77: Error: invalid character '<' in mnemonic
/tmp/ccdYPpfu.s:81: Error: inval
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-05-05 23:31 ---
XPASS: gcc.dg/tree-ssa/ltrans-3.c scan-tree-dump-times ltrans "transformed
loop" 1
FAIL: gcc.dg/vect/vect-reduc-1short.c (test for excess errors)
WARNING: gcc.dg/vect/vect-reduc-1short.c compilation failed to produc
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36144
>From http://gcc.gnu.org/ml/gcc-testresults/2008-05/msg00391.html .
Between revision 134953 and 134958, they showed up.
The only revision which could have caused this is revision 134957.
http://gcc.gnu.org/ml/gcc-cvs/2008-05/msg00117.html
--
Summary: [4.4 Regression] gcc.dg/vect/ve
--- Comment #11 from hjl dot tools at gmail dot com 2008-05-05 22:49
---
An updated patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2008-05/msg00271.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35657
--- Comment #10 from hjl dot tools at gmail dot com 2008-05-05 22:30
---
(In reply to comment #8)
> That is:
> Index: gcc/gcc/tree-ssa-forwprop.c
> ===
> --- gcc/gcc/tree-ssa-forwprop.c (revision 134951)
> +++ gcc/gcc/tree-
--- Comment #3 from tromey at gcc dot gnu dot org 2008-05-05 22:27 ---
fold_binary sees both MAX_EXPRs and reassociates.
(I think this is why it works with intermediate variables.)
Then associate_trees creates a new MAX_EXPR, converting each
argument to unsigned:
return fold_build2 (
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-05-05 21:30 ---
Yes I saw this, this is because we are not creating a VIEW_CONVERT_EXPR for the
first indirect reference, I think it has something to do with the placement
new. I will look at it when I get home tonight.
--
pins
Revision 134947 caused
FAIL: g++.dg/tree-ssa/pr19637.C scan-tree-dump-times dom1 "return 1;" 3
on Linux/ia32 and Linux/Intel64.
--
Summary: [4.4 Regression]: FAIL: g++.dg/tree-ssa/pr19637.C
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
S
--- Comment #4 from jarygrove at yahoo dot com 2008-05-05 21:08 ---
Please close this bug, I synchronized the handshake thread and no longer
getting the exception
Never miss a thing. Make Yahoo your home p
--- Comment #9 from pinskia at gcc dot gnu dot org 2008-05-05 21:04 ---
A reduced testcase:
extern void ffi_closure_unix (void);
ffi_prep_closure_loc (void)
{
struct ia64_fd
{
unsigned long long code_pointer;
unsigned long long gp;
};
struct ffi_ia64_trampoline_struct
{
--- Comment #8 from pinskia at gcc dot gnu dot org 2008-05-05 20:50 ---
That is:
Index: gcc/gcc/tree-ssa-forwprop.c
===
--- gcc/gcc/tree-ssa-forwprop.c (revision 134951)
+++ gcc/gcc/tree-ssa-forwprop.c (working copy)
@@ -657
--- Comment #7 from pinskia at gcc dot gnu dot org 2008-05-05 20:49 ---
So we get:
VIEW_CONVERT_EXPR(ffi_closure_unix).code_pointer
Where we have a function_decl.
The easy fix is not to build a VCE for a function decl which I am testing right
now.
Thanks,
Andrew Pinski
--
pinski
Consider the following testcase:
! { dg-do run }
! Adapted from fmt_t_6.f testcase for PR 34782
character a(6)
data a / 'a', 'b', 'c', 'd', 'e', 'f' /
write(*,'(T20,A3, T1,A4, T5,A2, T7,A2, T9,A4, T17,A2)')
1 'a', 'b', 'c', 'd', 'e', 'f'
print *, 'should be'
--- Comment #6 from pinskia at gcc dot gnu dot org 2008-05-05 19:43 ---
> Can you try it with a cross compiler for Linux/ia64? You just need
> to build cc1, not the whole cross compiler
It was building right now.
-- Pinski
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36141
--- Comment #5 from hjl dot tools at gmail dot com 2008-05-05 19:35 ---
(In reply to comment #4)
> Note with the preprocessed source, I cannot reproduce this under
> powerpc64-linux-gnu which means ia64 is setting FUNCTION_TYPEs' TYPE_SIZE
> funny.
>
Can you try it with a cross compile
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-05-05 19:20 ---
Note with the preprocessed source, I cannot reproduce this under
powerpc64-linux-gnu which means ia64 is setting FUNCTION_TYPEs' TYPE_SIZE
funny.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36141
--- Comment #2 from tromey at gcc dot gnu dot org 2008-05-05 19:10 ---
test.c.t02.original says:
u = MAX_EXPR <(unsigned int) i, 1>;
... but this is wrong.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #3 from hjl dot tools at gmail dot com 2008-05-05 19:01 ---
Created an attachment (id=15582)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15582&action=view)
A testcase
[EMAIL PROTECTED] libffi]$ /export/build/gnu/gcc/build-ia64-linux/./gcc/xgcc
-B/export/build/gnu/gcc
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-05-05 19:00 ---
This libffi code is a bit weird really, we are looking into a function pointer
here.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36141
On Linux/ia64, gcc 4.4 revision 134951 failed with
/export/build/gnu/gcc/build-ia64-linux/./gcc/xgcc
-B/export/build/gnu/gcc/build-ia64-linux/./gcc/
-B/usr/gcc-4.4/ia64-unknown-linux-gnu/bin/
-B/usr/gcc-4.4/ia64-unknown-linux-gnu/lib/ -isystem
/usr/gcc-4.4/ia64-unknown-linux-gnu/include -isystem
/u
--- Comment #4 from tkoenig at gcc dot gnu dot org 2008-05-05 18:57 ---
The problem isn't specific to in_pack, it's the
fact that we don't initialize the array descriptor
correctly.
s2 shows
if (a != 0B)
{
{
integer(kind=4) D.638;
D.638 = a->dim[0].stride;
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-05-05 18:55 ---
Can you attach the preprocessed source? The source is very ia64 dependent.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36141
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36141
--- Comment #4 from tkoenig at gcc dot gnu dot org 2008-05-05 18:24 ---
(In reply to comment #3)
> One possibility is to allocate something for zero-sized arrays, e.g. one
> element. The array bounds ensure than that the program still knows that the
> size of the array is zero. The extr
The following programs produce a segfault when compiled with the 05/02/08
snapshot of gfortran 4.4.0 under MIPS Linux. I believe this is related to Bug
36139, even though these programs do not segfault under HPPA, and the programs
in Bug 36139 do not segfault in MIPS.
PROGRAM kmci
IMPLICIT LOGICAL
--- Comment #19 from pmaydell at chiark dot greenend dot org dot uk
2008-05-05 17:57 ---
Bug 35961 does suggest that we didn't quite get this patch right, though:
At top level:
cc1: error: unrecognized command line option "-Wno-long-double"
The deferred 'unrecognised -Wno*' output
--- Comment #4 from burnus at gcc dot gnu dot org 2008-05-05 17:05 ---
It would be nice if this could go into 4.3.1; its release was scheduled for
today, but it got delayed by three P1 regressions.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35997
The 05/02/08 snapshot of gfortran 4.4.0 produces a variety of bugs on different
platforms. The bug described here is specific to HPPA Linux.
The following subroutine segfaults when I type "gfortran -c mnbrak.f90":
SUBROUTINE mnbrak
IMPLICIT REAL(a-f)
PARAMETER(a=0.0)
f=func()
END SUBROUTINE mnbra
Hello.
At compiling gcc-4.3.0 with ../gcc-4.3.0/./configure prefix=/I get this
error:
--
...
checking whether the target asssembler upports thread-local storage... yes
updating cache ./config.cache
configure: creating ./config.status
config.status: creating Makefile
conf
--- Comment #18 from pinskia at gcc dot gnu dot org 2008-05-05 16:15
---
*** Bug 35961 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-05-05 16:15 ---
(In reply to comment #2)
> What was the reasoning behind this change in behavior?
See PR 28322.
*** This bug has been marked as a duplicate of 28322 ***
--
pinskia at gcc dot gnu dot org changed:
Wh
--- Comment #2 from tj at castaglia dot org 2008-05-05 16:11 ---
What was the reasoning behind this change in behavior? It violates the
principle of least surprise, and will cause problems for e.g. configure scripts
which use simple tests to determine whether the system's compiler accep
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36079
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35997
--- Comment #4 from jakub at gcc dot gnu dot org 2008-05-05 15:47 ---
Not really, as IEEE754 mandates turning sNaN into qNaN after raising the
exception. I have a fix in the works in omp-low.c (so far works for non-SSA
and not yet for -ftree-parallelize-loops) and that's middle-end.
-
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-05-05 15:40 ---
That sounds like a bug in the target back-ends for not storing exactly the
bit-wise for NaNs.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from jv244 at cam dot ac dot uk 2008-05-05 15:28 ---
right, it is actually new CP2K code since I checked 4.3. No regression thus.
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
--- Comment #3 from dot at dotat dot at 2008-05-05 14:52 ---
The code is executed when the function selog_on() returns true. The warning is
also inconsistent, which also points to an analysis bug.
--
dot at dotat dot at changed:
What|Removed |Added
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2008-05-05 14:49
---
I will have a look. Odd, I don't recall anything going near this recently.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
Gcc 4.4 revision 134946 has
FAIL: g++.dg/opt/pr30965.C scan-tree-dump-times optimized ";; Function" 2
I think it is caused by revision 134859:
http://gcc.gnu.org/ml/gcc-cvs/2008-05/msg00019.html
--
Summary: [4.4 Regression]: FAIL: g++.dg/opt/pr30965.C
Product: gcc
--- Comment #1 from otte at gnome dot org 2008-05-05 14:17 ---
Created an attachment (id=15581)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15581&action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36137
The attached program prints (unsigned) -1 as opposed to 1.
This doesn't happen if intermediate variables are used somewhere in the
process.
I tested gcc 3.4, 4.2.3 (on both x86 and x86-64) with -O0 and -O2, all ended up
with -1.
suncc printed 1.
--
Summary: gcc can't do math
+++ This bug was initially created as a clone of Bug #36133 +++
Hello,
The ASM code created by GCC 4.2.1 for 68k/Coldfire platform is not optimal.
Comparing ASM output created by GCC 2.9 with GCC 4.2,
the generated code got partially much worse with GCC 4.
One problem that was visible a lot was
+++ This bug was initially created as a clone of Bug #36133 +++
Hello,
The ASM code created by GCC 4.2.1 for 68k/Coldfire platform is not optimal.
Comparing ASM output created by GCC 2.9 with GCC 4.2,
the generated code got partially much worse with GCC 4.
One problem that was visible a lot was
+++ This bug was initially created as a clone of Bug #36133 +++
Hello,
The ASM code created by GCC 4.2.1 for 68k/Coldfire platform is not optimal.
Comparing ASM output created by GCC 2.9 with GCC 4.2,
the generated code got partially much worse with GCC 4.
One problem that was visible a lot was
--- Comment #2 from burnus at gcc dot gnu dot org 2008-05-05 13:46 ---
I have probably a too old gfortran 4.4.0 (namely 20080424), but it does not
crash here. I see the same valgrind output using gfortran 4.1, 4.2, 4.3 and
4.4.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36132
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu dot
|
Hello,
The ASM code created by GCC 4.2.1 for 68k/Coldfire platform is not optimal.
Comparing ASM output created by GCC 2.9 with GCC 4.2,
the generated code got partially much worse with GCC 4.
One problem that was visible in very many places was
that GCC created unnecessary TST instructions.
Pl
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Component|fortran |libfortran
--- Comment #1 from jv244 at cam dot ac dot uk 2008-05-05 13:25 ---
testcase:
MODULE M1
INTEGER, PARAMETER :: dp=KIND(0.0D0)
CONTAINS
SUBROUTINE S1(a)
REAL(dp), DIMENSION(45), INTENT(OUT), &
OPTIONAL :: a
IF (PRESENT(a)) a=0.0_dp
the following testcase, derived from CP2K, illustrates an issue with
_gfortran_internal_pack. In CP2K this causes crashes such as:
Operating system error: Cannot allocate memory
Memory allocation failed
while this testcase shows under valgrind:
> gfortran -g -O0 test.f90
> valgrind --tool=memch
--- Comment #2 from jv244 at cam dot ac dot uk 2008-05-05 13:11 ---
also happens if profiles are generated/used at -O2 instead of -O3
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36129
gfortran [trunk revision 134945] generates wrong output for the following
testcase (derived from CP2K) :
write(6,FMT='(T2,A,T10,A)') "23456789012345","ABC"
END
yields:
23456789012345ABC
instead of:
23456789ABC345
--
Summary: [4.4 Regression] wrong IO
Product: gcc
--- Comment #1 from jv244 at cam dot ac dot uk 2008-05-05 12:29 ---
at least a back trace, but I guess that is not very useful:
#0 internal_error (gmsgid=0xc34369 "verify_histograms failed") at
/data03/vondele/gcc_trunk/gcc/gcc/diagnostic.c:594
#1 0x008c949d in verify_histogra
"make check-parallel" makes the following regression tests with respect to the
atomics library fail:
FAIL: 29_atomics/atomic_flag/test_and_set/explicit.c (test for excess errors)
WARNING: 29_atomics/atomic_flag/test_and_set/explicit.c compilation failed to
produce executable
FAIL: 29_atomics/atomi
--- Comment #7 from ubizjak at gmail dot com 2008-05-05 10:53 ---
validate_unshare_change was introduced by:
2007-06-26 Jan Hubicka <[EMAIL PROTECTED]>
* fwprop.c (try_fwprop_subst): Use validate_unshare_change.
* postreload.c (reload_cse_simplify_set): Instead of cop
--- Comment #2 from jakub at gcc dot gnu dot org 2008-05-05 10:39 ---
This is nothing target specific though, on many targets reading a float or
double sNaN into a FPU register and storing back somewhere else leads to qNaN
being stored.
--
jakub at gcc dot gnu dot org changed:
--- Comment #154 from jv244 at cam dot ac dot uk 2008-05-05 10:31 ---
this PR remains meaningful, but indeed the component should be changed to
'other'
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
-
current CP2K CVS fails to compile with [trunk revision 134945]
/data03/vondele/clean/cp2k/src/../src/atomic_kind_types.F: In function
read_atomic_kind:
/data03/vondele/clean/cp2k/src/../src/atomic_kind_types.F:1158: error: Dead
histogram
IOR value ior:0.
__builtin_memset (&element_symbol[2]{lb:
--- Comment #6 from ubizjak at gmail dot com 2008-05-05 10:29 ---
This patch works for me:
Index: recog.c
===
--- recog.c (revision 134943)
+++ recog.c (working copy)
@@ -537,7 +537,8 @@ validate_replace_rtx_1 (rtx
--- Comment #19 from pinskia at gcc dot gnu dot org 2008-05-05 09:14
---
(In reply to comment #17)
> Comment #c16 doesn't make sense. Of course malloc(3) can't be changed to
> return
> alignment, that would break all programs out there, violate many standards,
> etc.
Right now malloc
--- Comment #18 from tim at klingt dot org 2008-05-05 09:09 ---
hm, if that code is broken, what about the following one on x86_64
(__sync_bool_compare_and_swap_16 requires an alignment of 16 byte)?
struct __attribute__((aligned(16))) foo_t
{
foo_t(int a = 0, int b = 0): a_(a), b_(b
--- Comment #17 from jakub at gcc dot gnu dot org 2008-05-05 08:53 ---
Comment #c16 doesn't make sense. Of course malloc(3) can't be changed to
return
alignment, that would break all programs out there, violate many standards,
etc.
There are posix_memalign and memalign, which work just
--- Comment #16 from pinskia at gcc dot gnu dot org 2008-05-05 07:50
---
malloc has the same issue really. And from what I heard last time, glibc does
not want to change malloc to return the alignment.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36054
--- Comment #13 from irar at gcc dot gnu dot org 2008-05-05 07:49 ---
Subject: Bug 36119
Author: irar
Date: Mon May 5 07:48:58 2008
New Revision: 134945
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134945
Log:
PR tree-optimization/36119
* tree-vect-transform.c
--- Comment #15 from pinskia at gcc dot gnu dot org 2008-05-05 07:49
---
See http://gcc.gnu.org/ml/gcc/2006-10/msg00166.html and a couple others about a
way to have an aligned operator new.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36054
--- Comment #12 from irar at gcc dot gnu dot org 2008-05-05 07:48 ---
Subject: Bug 36119
Author: irar
Date: Mon May 5 07:47:49 2008
New Revision: 134944
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134944
Log:
PR tree-optimization/36119
* tree-vect-transform.c
--- Comment #14 from Joey dot ye at intel dot com 2008-05-05 07:29 ---
HJ,
AVX will have the similar problem on x86_64, whose new only returns object
aligned at 16 bytes. Dynamically allocated __m256 won't be guaranteed at 32
bytes boundary.
--
http://gcc.gnu.org/bugzilla/show_bug
--- Comment #13 from Joey dot ye at intel dot com 2008-05-05 07:22 ---
It is helpful. Root cause is that memory allocated by new is only aligned to 8
bytes under i386. In your case, object Environment is allocated by new and its
constructor tried to use movdqa to initialize its members.
88 matches
Mail list logo
