On 12/14/2015 03:20 PM, Richard Biener wrote:
But there must be a reason statics/externals are expected and handled in all the
callers (and the function).
At the time this was written (git rev 60d031234), expand_one_var looked
very different. It called a subroutine expand_one_static_var which
On Mon, Dec 14, 2015 at 1:09 PM, Bernd Schmidt wrote:
> On 12/14/2015 10:07 AM, Richard Biener wrote:
>
>> Note that we also record alignment to make sure we can spill to properly
>> aligned stack slots.
>
>
>> I don't see why we don't need to do that for used statics/externs. That
>> is
>> are y
On 12/14/2015 10:07 AM, Richard Biener wrote:
Note that we also record alignment to make sure we can spill to properly
aligned stack slots.
I don't see why we don't need to do that for used statics/externs. That is
are you sure we never need to spill a var of their type?
Why would they be
>>> On 14.12.15 at 10:07, wrote:
> Note that we also record alignment to make sure we can spill to properly
> aligned stack slots.
>
> I don't see why we don't need to do that for used statics/externs. That is
> are you sure we never need to spill a var of their type?
No, I'm not, but note that
On Mon, Dec 14, 2015 at 9:44 AM, Jan Beulich wrote:
On 14.12.15 at 09:35, wrote:
>> On Fri, Dec 11, 2015 at 2:54 PM, Bernd Schmidt wrote:
>>> On 12/11/2015 02:48 PM, Jan Beulich wrote:
Function (or more narrow) scope static variables (as well as others not
placed on the stack
>>> On 14.12.15 at 09:35, wrote:
> On Fri, Dec 11, 2015 at 2:54 PM, Bernd Schmidt wrote:
>> On 12/11/2015 02:48 PM, Jan Beulich wrote:
>>>
>>> Function (or more narrow) scope static variables (as well as others not
>>> placed on the stack) should also not have any effect on the stack
>>> alignmen
On Fri, Dec 11, 2015 at 2:54 PM, Bernd Schmidt wrote:
> On 12/11/2015 02:48 PM, Jan Beulich wrote:
>>
>> Function (or more narrow) scope static variables (as well as others not
>> placed on the stack) should also not have any effect on the stack
>> alignment. I noticed the issue first with Linux'e
On 12/11/2015 02:48 PM, Jan Beulich wrote:
Function (or more narrow) scope static variables (as well as others not
placed on the stack) should also not have any effect on the stack
alignment. I noticed the issue first with Linux'es dynamic_pr_debug()
construct using an 8-byte aligned sub-file-sco
; (s) : "0" (&x));
+
+ return n ? test(n - 1, x) : (x ^ p);
+}
+
+int main (int argc, char *argv[] __attribute__((unused)))
+{
+ unsigned int x = test(argc, 0);
+
+ x |= test(argc + 1, 0);
+ x |= test(argc + 2, 0);
+
+ return !(x & (ALIGNMENT - 1));
+}
avoid alignment o
On 12/10/2015 05:07 PM, Jan Beulich wrote:
If not reaching
if (TREE_CODE (origvar) == SSA_NAME)
{
gcc_assert (TREE_CODE (var) != VAR_DECL
|| (!DECL_EXTERNAL (var)
&& !DECL_HAS_VALUE_EXPR_P (var)
&& !TREE_STATIC (var)
>>> On 10.12.15 at 14:53, wrote:
> On 12/10/2015 01:38 PM, Jan Beulich wrote:
>> --- 2015-12-09/gcc/cfgexpand.c
>> +++ 2015-12-09/gcc/cfgexpand.c
>> @@ -1544,12 +1544,15 @@ static HOST_WIDE_INT
>> expand_one_var (tree var, bool toplevel, bool really_expand)
>> {
>> unsigned int align = BIT
On 12/10/2015 01:38 PM, Jan Beulich wrote:
* cfgexpand.c (expand_one_var): Exclude static and external
variables when adjusting stack alignment related state.
gcc/testsuite/
2015-12-10 Jan Beulich
* gcc.c-torture/execute/stkalign.c: New.
--- 2015-12-09/gcc/cfgexpand
ENT);
+ asm ("" : "=g" (x), "+m" (s) : "0" (&x));
+
+ return n ? test(n - 1, x) : (x ^ p);
+}
+
+int main (int argc, char *argv[] __attribute__((unused)))
+{
+ unsigned int x = test(argc, 0);
+
+ x |= test(argc + 1, 0);
+ x |= test(argc + 2, 0);
+
+ re
On Fri, Oct 24, 2014 at 4:57 PM, Jan Beulich wrote:
> Function (or more narrow) scope static variables (as well as others not
> placed on the stack) should also not have any effect on the stack
> alignment. I noticed the issue first with Linux'es dynamic_pr_debug()
> construct using an 8-byte alig
On 10/24/14 04:12, Jan Beulich wrote:
On 24.10.14 at 11:52, wrote:
On Fri, Oct 24, 2014 at 11:18 AM, Jakub Jelinek wrote:
On Fri, Oct 24, 2014 at 11:10:08AM +0200, Richard Biener wrote:
For something in static storage, this seems OK. However, I think a hard
register variable ought to be lef
bute__((__aligned__(ALIGNMENT))) c; } s;
+ unsigned x;
+
+ assert(__alignof__(s) == ALIGNMENT);
+ asm ("" : "=g" (x), "+m" (s) : "0" (&x));
+
+ return n ? test(n - 1, x) : (x ^ p);
+}
+
+int main (int argc, char *argv[] __attribute__((unused)))
+{
On Fri, Oct 24, 2014 at 12:12 PM, Jan Beulich wrote:
On 24.10.14 at 11:52, wrote:
>> On Fri, Oct 24, 2014 at 11:18 AM, Jakub Jelinek wrote:
>>> On Fri, Oct 24, 2014 at 11:10:08AM +0200, Richard Biener wrote:
>> For something in static storage, this seems OK. However, I think a hard
>>
>>> On 24.10.14 at 11:52, wrote:
> On Fri, Oct 24, 2014 at 11:18 AM, Jakub Jelinek wrote:
>> On Fri, Oct 24, 2014 at 11:10:08AM +0200, Richard Biener wrote:
>>> >> For something in static storage, this seems OK. However, I think a hard
>>> >> register variable ought to be left alone -- even if w
On Fri, Oct 24, 2014 at 11:18 AM, Jakub Jelinek wrote:
> On Fri, Oct 24, 2014 at 11:10:08AM +0200, Richard Biener wrote:
>> >> For something in static storage, this seems OK. However, I think a hard
>> >> register variable ought to be left alone -- even if we can't spill it to
>> >> a stack slot
On Fri, Oct 24, 2014 at 11:10:08AM +0200, Richard Biener wrote:
> >> For something in static storage, this seems OK. However, I think a hard
> >> register variable ought to be left alone -- even if we can't spill it to
> >> a stack slot today, there's a reasonable chance we might add that
> >> cap
>>> On 24.10.14 at 11:10, wrote:
> On Fri, Oct 24, 2014 at 11:01 AM, Jan Beulich wrote:
> On 23.10.14 at 20:13, wrote:
>>> On 10/23/14 01:09, Jan Beulich wrote:
>>> On 23.10.14 at 08:50, wrote:
> On Thu, Oct 23, 2014 at 07:30:27AM +0100, Jan Beulich wrote:
>> Function (or more n
On Fri, Oct 24, 2014 at 11:01 AM, Jan Beulich wrote:
On 23.10.14 at 20:13, wrote:
>> On 10/23/14 01:09, Jan Beulich wrote:
>> On 23.10.14 at 08:50, wrote:
On Thu, Oct 23, 2014 at 07:30:27AM +0100, Jan Beulich wrote:
> Function (or more narrow) scope static variables (as well as
>>> On 23.10.14 at 20:13, wrote:
> On 10/23/14 01:09, Jan Beulich wrote:
> On 23.10.14 at 08:50, wrote:
>>> On Thu, Oct 23, 2014 at 07:30:27AM +0100, Jan Beulich wrote:
Function (or more narrow) scope static variables (as well as others not
placed on the stack) should also not have
On 10/23/14 01:09, Jan Beulich wrote:
On 23.10.14 at 08:50, wrote:
On Thu, Oct 23, 2014 at 07:30:27AM +0100, Jan Beulich wrote:
Function (or more narrow) scope static variables (as well as others not
placed on the stack) should also not have any effect on the stack
alignment. I noticed the iss
>>> On 23.10.14 at 08:50, wrote:
> On Thu, Oct 23, 2014 at 07:30:27AM +0100, Jan Beulich wrote:
>> Function (or more narrow) scope static variables (as well as others not
>> placed on the stack) should also not have any effect on the stack
>> alignment. I noticed the issue first with Linux'es dyna
On Thu, Oct 23, 2014 at 07:30:27AM +0100, Jan Beulich wrote:
> Function (or more narrow) scope static variables (as well as others not
> placed on the stack) should also not have any effect on the stack
> alignment. I noticed the issue first with Linux'es dynamic_pr_debug()
> construct using an 8-b
ned__(ALIGNMENT))) c; } s;
+ unsigned x;
+
+ assert(__alignof__(s) == ALIGNMENT);
+ asm ("" : "=g" (x), "+m" (s) : "0" (&x));
+
+ return n ? test(n - 1, x) : (x ^ p);
+}
+
+int main (int argc, char *argv[] __attribute__((unused)))
+{
+ unsigned int x =
27 matches
Mail list logo
