[Bug debug/37022] [4.4 regression] internal compiler error: in compute_barrier_args_size

[andreast at gcc dot gnu dot org]

--- Comment #14 from andreast at gcc dot gnu dot org  2008-12-27 20:51 
---
The original failures, closure_fn* have gone. So I didn't follow.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37022

[Bug debug/37022] [4.4 regression] internal compiler error: in compute_barrier_args_size

[pinskia at gcc dot gnu dot org]

--- Comment #13 from pinskia at gcc dot gnu dot org  2008-12-27 14:58 
---
Any news on this bug, it is one of the last P1s for 4.4?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37022

[Bug debug/37022] [4.4 regression] internal compiler error: in compute_barrier_args_size

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P1


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37022

[Bug debug/37022] [4.4 regression] internal compiler error: in compute_barrier_args_size

[jakub at gcc dot gnu dot org]

--- Comment #12 from jakub at gcc dot gnu dot org  2008-08-13 08:54 ---
After more thinking, I'm not convinced even debuggers need it when frame
pointer is present (as Jan just told me, gdb ignores DW_CFA_GNU_args_size
altogether anyway).  The current sp comes up just from unwinding through a
lower frame,
and the next sp value will be read from fp.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37022

[Bug debug/37022] [4.4 regression] internal compiler error: in compute_barrier_args_size

[xuepeng dot guo at intel dot com]

--- Comment #11 from xuepeng dot guo at intel dot com  2008-08-12 02:11 
---
(In reply to comment #9)
> The darwin -m64 failures are then the same problem, cross-jumping of noreturn
> calls between different level of stack depths.
> I've been wrong about DW_CFA_GNU_args_size being useless for cfa.reg !=
> STACK_POINTER_REGNUM, while such directives won't ever be used by the libgcc
> unwinder, they might be used by debuggers to set correct value of stack
> pointer,
> and therefore such directives aren't useless and so we should avoid
> crossjumping
> in that case.  Not sure how to detect that in crossjumping code though.

You are right. IMHO this is exactly the reason.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37022

[Bug debug/37022] [4.4 regression] internal compiler error: in compute_barrier_args_size

[xuepeng dot guo at intel dot com]

--- Comment #10 from xuepeng dot guo at intel dot com  2008-08-12 02:07 
---
(In reply to comment #7)
> Sorry, I can't reproduce the first issue with a x86_64-linux -> i?86-darwin
> cross on the provided preprocessed testcase, tried many different
> -march=/-mtune=
> options as well as -f{,no-}asynchronous-unwind-tables.  What tuning do you 
> use?
>  What preferred stack size?
> The later C testcase I can reproduce, but here the testcase has a frame 
> pointer
> (insn/f 38 37 39 pr37022.c:4 (set (reg/f:SI 6 bp)
> (reg/f:SI 7 sp)) 47 {*movsi_1} (nil))
> so I must say I don't understand at all why we generate any
> DW_CFA_GNU_args_size
> directives.  

I am not clear of you but this rtl is necessary for our stack realign proposal.
During we designed and implemented the stack realign proposal we didn't intend
to affect the existing way that DW_CFA_GNU_args_szie works. 

>I believe the unwinder won't use them anyway, as in
> uw_install_context_1
> if (!_Unwind_GetGRPtr (current, __builtin_dwarf_sp_column ()))
> the condition is false (sp is saved in bp).  For the -fno-a-u-t we check
> cfa.reg:
The unwinder will restore sp by DW_CFA_def_cfa_expression as shown below:
080483a8 :
 80483a8:   8d 4c 24 04 lea0x4(%esp),%ecx
 80483ac:   83 e4 f0and$0xfff0,%esp
 80483af:   ff 71 fcpushl  -0x4(%ecx)
 80483b2:   55  push   %ebp
 80483b3:   89 e5   mov%esp,%ebp
 80483b5:   51  push   %ecx
 80483b6:   83 ec 04sub$0x4,%esp

0018 0024 001c FDE cie= pc=080483a8..080483d8
  DW_CFA_advance_loc: 4 to 080483ac
  DW_CFA_def_cfa: r1 (ecx) ofs 0
  DW_CFA_advance_loc: 9 to 080483b5
  DW_CFA_expression: r5 (ebp) (DW_OP_breg5: 0)
  DW_CFA_advance_loc: 1 to 080483b6
  DW_CFA_def_cfa_expression (DW_OP_breg5: -4; DW_OP_deref) <<< restore sp
  DW_CFA_advance_loc: 12 to 080483c2
  DW_CFA_GNU_args_size: 32
  DW_CFA_advance_loc: 22 to 080483d8
  DW_CFA_GNU_args_size: 0
  DW_CFA_nop


> if (!flag_asynchronous_unwind_tables && cfa.reg != STACK_POINTER_REGNUM)
> but not so for the -fa-u-t case.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37022

[Bug debug/37022] [4.4 regression] internal compiler error: in compute_barrier_args_size

[jakub at gcc dot gnu dot org]

--- Comment #9 from jakub at gcc dot gnu dot org  2008-08-11 20:17 ---
The darwin -m64 failures are then the same problem, cross-jumping of noreturn
calls between different level of stack depths.
I've been wrong about DW_CFA_GNU_args_size being useless for cfa.reg !=
STACK_POINTER_REGNUM, while such directives won't ever be used by the libgcc
unwinder, they might be used by debuggers to set correct value of stack
pointer,
and therefore such directives aren't useless and so we should avoid
crossjumping
in that case.  Not sure how to detect that in crossjumping code though.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37022

[Bug debug/37022] [4.4 regression] internal compiler error: in compute_barrier_args_size

[andreast at gcc dot gnu dot org]

--- Comment #8 from andreast at gcc dot gnu dot org  2008-08-11 18:12 
---
When I opened the PR I had set the target to x86_64-apple-darwin9.

It does not happen under ix86-apple-darwin9.

My config for gcc looks like this:

[deuterium:gcc/head/objdir-x86_64] andreast% ./gcc/xgcc -v
Using built-in specs.
Target: x86_64-apple-darwin9
Configured with: /Volumes/development/gcc/head/gcc/configure
--prefix=/Volumes/development/gcc/head/testbin-x86_64
--build=x86_64-apple-darwin9 --target=x86_64-apple-darwin9 --disable-static
--disable-multilib --with-gmp=/usr/local/x86_64 --with-mpfr=/usr/local/x86_64
--enable-languages=c,c++,fortran,java,objc,obj-c++ --enable-java-awt=xlib
Thread model: posix
gcc version 4.4.0 20080810 (experimental) [trunk revision 138933] (GCC)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37022

[Bug debug/37022] [4.4 regression] internal compiler error: in compute_barrier_args_size

[jakub at gcc dot gnu dot org]

--- Comment #7 from jakub at gcc dot gnu dot org  2008-08-11 12:09 ---
Sorry, I can't reproduce the first issue with a x86_64-linux -> i?86-darwin
cross on the provided preprocessed testcase, tried many different
-march=/-mtune=
options as well as -f{,no-}asynchronous-unwind-tables.  What tuning do you use?
 What preferred stack size?

The later C testcase I can reproduce, but here the testcase has a frame pointer
(insn/f 38 37 39 pr37022.c:4 (set (reg/f:SI 6 bp)
(reg/f:SI 7 sp)) 47 {*movsi_1} (nil))
so I must say I don't understand at all why we generate any
DW_CFA_GNU_args_size
directives.  I believe the unwinder won't use them anyway, as in
uw_install_context_1
if (!_Unwind_GetGRPtr (current, __builtin_dwarf_sp_column ()))
the condition is false (sp is saved in bp).  For the -fno-a-u-t we check
cfa.reg:
if (!flag_asynchronous_unwind_tables && cfa.reg != STACK_POINTER_REGNUM)
but not so for the -fa-u-t case.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||jason at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37022

[Bug debug/37022] [4.4 regression] internal compiler error: in compute_barrier_args_size

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|normal  |blocker
   Keywords||ice-on-valid-code
   Target Milestone|--- |4.4.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37022

[Bug debug/37022] [4.4 regression] internal compiler error: in compute_barrier_args_size

[andreast at gcc dot gnu dot org]

-- 

andreast at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-08-06 20:29:34
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37022

[Bug debug/37022] [4.4 regression] internal compiler error: in compute_barrier_args_size

[hjl dot tools at gmail dot com]

--- Comment #6 from hjl dot tools at gmail dot com  2008-08-06 13:51 ---
>From Xuepeng:

__attribute__((noinline, used))
void
foo (int a, ...)
{
  va_list arg;
  char *p;
  int size;

  va_start (arg, a);
  size = va_arg (arg, int);

  if (size != 2)
/*A*/ abort ();

  p = (char *) __builtin_alloca (size + 1);

  va_end (arg);

  if (v < 0)
/*B*/   abort ();  
}

This bug is caused by label optimization. Function compute_barrier_args_size
intends to walk the whole function rtl and compute args_size on BARRIERS. When
it reached the first if statement (size != 2), it will compute the destination
of this if statement, the destination was supposed to be at /*A*/ and then set
barrier_args_size[/*A*/]=cur_args_size. Unfortunately the destination /*A*/ was
optimized to /*B*/, so the actual result is barrier_args_size[/*B*/] was set to
cur_args_size. And at this point the cur_args_size was still zero, so the
barrier_args_size[/*B*/]=0. 

The __builtin_alloca will adjust stack pointer and make cur_args_size=32. 

The function compute_barrier_args_size continued and reached label /*B*/.
According to the author's comment that barrier_args_size[/*B*/] != -1 means
that the insns starting with this label have been already scanned or are in the
worklist, so the author thought barrier_args_size[/*B*/] should be
cur_args_size which is 32 now. But in fact the insns starting with this label
havn't been scanned, the barrier_args_size[/*B*/] was set to 0 just because of
label optimization. So the assert (barrier_args_size[/*B*/]== cur_args_size)
was generated.

If change label /*A*/ to something like v=0 rather than abort (), there will be
no compiler errors.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37022

[Bug debug/37022] [4.4 regression] internal compiler error: in compute_barrier_args_size

[hjl dot tools at gmail dot com]

--- Comment #5 from hjl dot tools at gmail dot com  2008-08-06 13:32 ---
(In reply to comment #3)
> Created an attachment (id=16031)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16031&action=view) [edit]
> A smaller case.
> 
> [EMAIL PROTECTED] stackalign]$ /home/xguo2/app/stack-internal/bin/g++ -m32 
> -Os 
> -fasynchronous-unwind-tables -mpreferred-stack-boundary=4 a1.C
> a1.C: In function ‘void foo(int, ...)’:
> a1.C:27: internal compiler error: in compute_barrier_args_size, at
> dwarf2out.c:1289
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See  for instructions.

It also fails at C:

bash-3.2$ ./xgcc -B./ /tmp/a1.c -m32 -S -Os  -fasynchronous-unwind-tables
/tmp/a1.c: In function ‘foo’:
/tmp/a1.c:27: internal compiler error: in compute_barrier_args_size, at
dwarf2out.c:1319
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37022

[Bug debug/37022] [4.4 regression] internal compiler error: in compute_barrier_args_size

[hjl dot tools at gmail dot com]

--- Comment #4 from hjl dot tools at gmail dot com  2008-08-06 13:30 ---
The new testcase

http://gcc.gnu.org/bugzilla/attachment.cgi?id=16031&action=view

also fails on Linux/ia32 and revision 138427 is the cause.


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 CC||hjl dot tools at gmail dot
   ||com, Joey dot ye at intel
   ||dot com, xuepeng dot guo at
   ||intel dot com
  GCC build triplet|x86_64-apple-darwin9|
   GCC host triplet|x86_64-apple-darwin9|
 GCC target triplet|x86_64-apple-darwin9|
Summary|libffi test suite failures  |[4.4 regression] internal
   ||compiler error: in
   ||compute_barrier_args_size


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37022