--- Comment #19 from hjl dot tools at gmail dot com 2010-09-17 20:24
---
It comes back with revision 164375:
http://gcc.gnu.org/ml/gcc-cvs/2010-09/msg00669.html
for PR 45678. On Linux/ia32, I got
FAIL: gcc.target/i386/incoming-9.c scan-assembler-not andl[\\t ]*\\$-16,[\\t
]*%esp
It
--- Comment #18 from jakub at gcc dot gnu dot org 2010-07-27 17:59 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #17 from jakub at gcc dot gnu dot org 2010-07-27 17:55 ---
Subject: Bug 44542
Author: jakub
Date: Tue Jul 27 17:54:32 2010
New Revision: 162582
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162582
Log:
PR target/44542
* cfgexpand.c (expand_one_stack_
--- Comment #16 from hjl dot tools at gmail dot com 2010-06-16 15:38
---
(In reply to comment #15)
> 2) even when get_decl_align_unit returns something small, the decl might still
> get a nicely aligned slot (say offset 64). If it is known at this point
> that virtual_stack_vars_rtx wi
--- Comment #15 from jakub at gcc dot gnu dot org 2010-06-16 14:57 ---
1) all the world isn't ix86/x86_64, this is generic code, so
MAX_SUPPORTED_STACK_ALIGNMENT is small on many targets
2) even when get_decl_align_unit returns something small, the decl might still
get a nicely aligned s
--- Comment #14 from hjl dot tools at gmail dot com 2010-06-16 14:36
---
The code in question is
offset -= frame_phase;
align = offset & -offset;
align *= BITS_PER_UNIT;
if (align == 0)
align = STACK_BOUNDARY;
else if (align > MAX_SUPPORTED_STACK_A
--- Comment #13 from jakub at gcc dot gnu dot org 2010-06-16 06:55 ---
This looks wrong. The code in expand_one_stack_var_at (before dynamic stack
realignment) made perfect sense, if we gave a bigger alignment to some variable
(e.g. automatic array), it is useful to tell the expanders t
--- Comment #12 from hjl dot tools at gmail dot com 2010-06-15 17:25
---
Created an attachment (id=20922)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20922&action=view)
A new patch
Fix typo and update comments.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44542
--- Comment #11 from hjl dot tools at gmail dot com 2010-06-15 17:20
---
Created an attachment (id=20921)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20921&action=view)
An updated patch
I don't see why expand_one_stack_var_at should compute alignment
when its callers know what
--- Comment #10 from hjl dot tools at gmail dot com 2010-06-15 17:13
---
Created an attachment (id=20920)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20920&action=view)
A patch to use alignment
If we already know the alignment we need, why not use it? Here is
a patch does it.
--- Comment #9 from jakub at gcc dot gnu dot org 2010-06-15 16:45 ---
Re: #c4 - !really_expand never occur when !optimize and for optimize they
are called IMHO way too early (during inlining etc.).
Re: #c8 - the testcases were meant for the given range of svn revs of trunk to
show the i
--- Comment #8 from hjl dot tools at gmail dot com 2010-06-15 15:39 ---
(In reply to comment #7)
> Jakub was not talking about crtl->stack_alignment_estimated becoming 256,
> but rather DECL_ALIGN of certain decls in expand_one_stack_var_at.
>
I set the breakpoint at expand_one_stack_v
--- Comment #7 from matz at gcc dot gnu dot org 2010-06-15 14:56 ---
Jakub was not talking about crtl->stack_alignment_estimated becoming 256,
but rather DECL_ALIGN of certain decls in expand_one_stack_var_at.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44542
--- Comment #6 from hjl dot tools at gmail dot com 2010-06-15 14:46 ---
I watched crtl->stack_alignment_estimated in gdb
with the testcase in comment #2. I didn't see it
set to 256.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44542
--- Comment #5 from matz at gcc dot gnu dot org 2010-06-15 13:50 ---
Oh, and yes, I agree that in expand_one_stack_var_at (only called when
really_expand == true) we should limit align to $something. I'm just not
sure what $something is. crtl->stack_alignment_estimated is not really it
--- Comment #4 from matz at gcc dot gnu dot org 2010-06-15 13:40 ---
Can you try to instead do the stack-estimation only when really_expand is
false? The issue is, we see all variables (or we _should_ see) exactly twice,
once for estimation, once for generating the DECL_RTL. The code w
--- Comment #3 from jakub at gcc dot gnu dot org 2010-06-15 12:53 ---
Created an attachment (id=20914)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20914&action=view)
gcc46-pr44542.patch
For the "don't use changed DECL_ALIGN for stack estimation after
expand_one_stack_var_at has
--- Comment #2 from jakub at gcc dot gnu dot org 2010-06-15 11:36 ---
I don't have any wrong-code testcases.
__attribute__((noinline, noclone)) void
f (long x)
{
long a, b, c, d;
asm ("");
__builtin_alloca (1);
}
int
main (void)
{
f (1234567890);
return 0;
}
shows the same is
--- Comment #1 from matz at gcc dot gnu dot org 2010-06-15 11:19 ---
We have a slightly problematic ordering issue here. Here's what I
think should be made the case:
DECL_ALIGN should not matter after expansion, we have MEM_ALIGN for that.
(and for calculating offsets from stack-ptr
19 matches
Mail list logo
