--- Comment #27 from sezeroz at gmail dot com 2010-09-18 20:51 ---
Are 4.4 and 4.5 going to be fixed?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45678
--- Comment #22 from rguenth at gcc dot gnu dot org 2010-09-17 09:00
---
Subject: Bug 45678
Author: rguenth
Date: Fri Sep 17 09:00:23 2010
New Revision: 164356
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164356
Log:
2010-09-17 Richard Guenther rguent...@suse.de
PR
--- Comment #23 from rguenth at gcc dot gnu dot org 2010-09-17 13:57
---
Subject: Bug 45678
Author: rguenth
Date: Fri Sep 17 13:57:04 2010
New Revision: 164369
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164369
Log:
2010-09-17 Richard Guenther rguent...@suse.de
PR
--- Comment #24 from hjl dot tools at gmail dot com 2010-09-17 16:35
---
Created an attachment (id=21821)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21821action=view)
A patch
The problem is we failed to update stack alignment when
we increase alignment of local variable. This
--- Comment #25 from hjl dot tools at gmail dot com 2010-09-17 17:26
---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2010-09/msg01425.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #26 from hjl at gcc dot gnu dot org 2010-09-17 17:49 ---
Subject: Bug 45678
Author: hjl
Date: Fri Sep 17 17:49:30 2010
New Revision: 164375
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164375
Log:
Update stack alignment when increasing local variable alignment.
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-09-16 10:17 ---
DECL_ALIGN of d is set to 128 (but appearantly it isn't ensured it'll end up
that way). DECL_ALIGN is adjusted here:
Old value = 32
New value = 128
expand_one_stack_var_at (decl=0x75ae90a0, offset=-16)
at
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-09-16 10:18 ---
Created an attachment (id=21809)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21809action=view)
patch to fix half STRICT_ALIGNMENT targets memcpy folding
Might need this patch to fix as well. i?86 / x86_64
--- Comment #5 from jakub at gcc dot gnu dot org 2010-09-16 10:40 ---
Re: #c4, shouldn't there be srcvar = NULL_TREE; somewhere for the
STRICT_ALIGNMENT non-aligned case?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45678
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-09-16 10:50 ---
Missing some else indeed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45678
--- Comment #7 from jakub at gcc dot gnu dot org 2010-09-16 11:57 ---
For the ix86/x86_64 alignment issue, I believe the problem here is that
max_align = MAX (crtl-max_used_stack_slot_alignment,
PREFERRED_STACK_BOUNDARY);
is fine for
--- Comment #8 from hjl dot tools at gmail dot com 2010-09-16 13:02 ---
This also failed:
---
typedef float V __attribute__ ((vector_size (16)));
V g;
float d[4] = { 4, 3, 2, 1 };
int
main ()
{
V e;
__builtin_memcpy (e, d, sizeof (d));
V f = { 5, 15, 25, 35 };
e = e * f;
g =
--- Comment #9 from hjl dot tools at gmail dot com 2010-09-16 13:05 ---
If __builtin_memcpy generates instructions which
require bigger alignment than alignments of
source or destination, it should increase the
alignment of source or destination.
--
--- Comment #10 from hjl dot tools at gmail dot com 2010-09-16 13:10
---
When __builtin_memcpy increases the alignment of source
or destination, it should update needed stack alignment if
source or destination is on stack.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45678
--- Comment #11 from hjl dot tools at gmail dot com 2010-09-16 13:21
---
This code:
if (TREE_CODE (srcvar) == ADDR_EXPR
var_decl_component_p (TREE_OPERAND (srcvar, 0))
tree_int_cst_equal (TYPE_SIZE_UNIT (srctype), len)
(!STRICT_ALIGNMENT
--- Comment #12 from hjl dot tools at gmail dot com 2010-09-16 13:32
---
(In reply to comment #4)
Created an attachment (id=21809)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21809action=view) [edit]
patch to fix half STRICT_ALIGNMENT targets memcpy folding
Might need this
--- Comment #13 from rguenth at gcc dot gnu dot org 2010-09-16 13:39
---
(In reply to comment #12)
(In reply to comment #4)
Created an attachment (id=21809)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21809action=view) [edit]
patch to fix half STRICT_ALIGNMENT targets
--- Comment #14 from jakub at gcc dot gnu dot org 2010-09-16 13:54 ---
The reason why cfgexpand does increase the alignment is that it believes that
the base slot will be at least PREFERRED_STACK_BOUNDARY bytes aligned, which is
true on all targets but i?86/x86-64, which apparently
--- Comment #15 from hjl dot tools at gmail dot com 2010-09-16 13:54
---
Created an attachment (id=21810)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21810action=view)
A patch
This patch adds HARD_ALIGNMENT_MODE_P and works for me.
--
--- Comment #16 from hjl dot tools at gmail dot com 2010-09-16 13:59
---
(In reply to comment #13)
With that patch the assignment generated from memcpy doesn't need more
that int alignment, but still cfgexpand.c sets DECL_ALIGN of the
decl to 128 so expand uses aligned
--- Comment #17 from jakub at gcc dot gnu dot org 2010-09-16 14:08 ---
That's true. But many expanders can make use of DECL_ALIGN information, e.g.
to choose faster code. If cfgexpand keeps doing what it does now, namely
bumping DECL_ALIGN of variables up to PREFERRED_STACK_BOUNDARY
--- Comment #18 from rguenth at gcc dot gnu dot org 2010-09-16 14:13
---
(In reply to comment #16)
(In reply to comment #13)
With that patch the assignment generated from memcpy doesn't need more
that int alignment, but still cfgexpand.c sets DECL_ALIGN of the
decl to 128 so
--- Comment #19 from hjl dot tools at gmail dot com 2010-09-16 14:17
---
(In reply to comment #17)
That's true. But many expanders can make use of DECL_ALIGN information, e.g.
to choose faster code. If cfgexpand keeps doing what it does now, namely
bumping DECL_ALIGN of variables
--- Comment #20 from rguenth at gcc dot gnu dot org 2010-09-16 14:22
---
The patch in comment #4 makes memcpy folding not lie about alignment.
cfgexpand still lies about alignment though.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45678
--- Comment #21 from hjl dot tools at gmail dot com 2010-09-16 14:30
---
(In reply to comment #20)
The patch in comment #4 makes memcpy folding not lie about alignment.
X86 only cares about alignment for vector modes.
Can we combine 2 patches into one?
cfgexpand still lies about
--- Comment #2 from jakub at gcc dot gnu dot org 2010-09-15 14:23 ---
Actually
typedef float V __attribute__ ((vector_size (16)));
V g;
int
main ()
{
float d[4] = { 4, 3, 2, 1 };
V e;
__builtin_memcpy (e, d, sizeof (d));
V f = { 5, 15, 25, 35 };
e = e * f;
g = e;
return
26 matches
Mail list logo
