[Bug debug/37022] New: libffi test suite failures

[Bug debug/37022] New: libffi test suite failures

[andreast at gcc dot gnu dot org]

FAIL: libffi.call/closure_fn1.c -Os (test for excess errors)
FAIL: libffi.call/closure_fn2.c -Os (test for excess errors)
FAIL: libffi.call/closure_fn6.c -Os (test for excess errors)
FAIL: libffi.call/cls_6_1_byte.c -Os (test for excess errors)
FAIL: libffi.call/cls_7_1_byte.c -Os (test for excess errors)

/Volumes/development/gcc/head/gcc/libffi/testsuite/libffi.call/closure_fn1.c:
In function 'main':^M
/Volumes/development/gcc/head/gcc/libffi/testsuite/libffi.call/closure_fn1.c:89:
internal compiler error: in compute_barrier_args_size, at dwarf2out.c:1279^M
Please submit a full bug report,^M
with preprocessed source if appropriate.^M
See <http://gcc.gnu.org/bugs.html> for instructions.^M

FAIL: libffi.call/closure_fn1.c -Os (test for excess errors)


Revision 138427 introduces these failures.


-- 
           Summary: libffi test suite failures
           Product: gcc
           Version: 4.4.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: debug
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: andreast at gcc dot gnu dot org
 GCC build triplet: x86_64-apple-darwin9
  GCC host triplet: x86_64-apple-darwin9
GCC target triplet: x86_64-apple-darwin9


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

[Bug debug/37022] libffi test suite failures

[andreast at gcc dot gnu dot org]

------- Comment #1 from andreast at gcc dot gnu dot org  2008-08-04 19:59 -------
Created an attachment (id=16016)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16016&action=view)
preprocessed source closure_fn1

Preprocessed source.


-- 


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

[Bug debug/37022] libffi test suite failures

[xuepeng dot guo at intel dot com]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2016 bytes --]



------- Comment #2 from xuepeng dot guo at intel dot com  2008-08-06 06:30 -------
Created an attachment (id=16030)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16030&action=view)
Testcase.

Hi, I got the similar failure on linux/x86 platform.

[xguo2@shgcc-10 minbuild]$
/home/xguo2/internal-source-tree/stack-internal/minbuild/gcc/testsuite/g++/../../g++
-B/home/xguo2/internal-source-tree/stack-internal/minbuild/gcc/testsuite/g++/../../
/home/xguo2/internal-source-tree/stack-internal/src/gcc/testsuite/g++.dg/torture/stackalign/async-unwind-1.C
 -nostdinc++
-I/home/xguo2/internal-source-tree/stack-internal/minbuild/x86_64-unknown-linux-gnu/32/libstdc++-v3/include/x86_64-unknown-linux-gnu
-I/home/xguo2/internal-source-tree/stack-internal/minbuild/x86_64-unknown-linux-gnu/32/libstdc++-v3/include
-I/home/xguo2/internal-source-tree/stack-internal/src/libstdc++-v3/libsupc++
-I/home/xguo2/internal-source-tree/stack-internal/src/libstdc++-v3/include/backward
-I/home/xguo2/internal-source-tree/stack-internal/src/libstdc++-v3/testsuite/util
-fmessage-length=0  -Os  -fasynchronous-unwind-tables
-mpreferred-stack-boundary=4   
-L/home/xguo2/internal-source-tree/stack-internal/minbuild/x86_64-unknown-linux-gnu/32/libstdc++-v3/src/.libs

-L/home/xguo2/internal-source-tree/stack-internal/minbuild/x86_64-unknown-linux-gnu/32/libstdc++-v3/src/.libs
-L/home/xguo2/internal-source-tree/stack-internal/minbuild/x86_64-unknown-linux-gnu/32/libiberty
 -lm   -m32 -o ./async-unwind-1.exe
/home/xguo2/internal-source-tree/stack-internal/src/gcc/testsuite/g++.dg/torture/stackalign/async-unwind-1.C:
In function ‘void foo(int, ...)’:
/home/xguo2/internal-source-tree/stack-internal/src/gcc/testsuite/g++.dg/torture/stackalign/async-unwind-1.C:74:
internal compiler error: in compute_barrier_args_size, at dwarf2out.c:1289
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.


-- 


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

[Bug debug/37022] libffi test suite failures

[xuepeng dot guo at intel dot com]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 659 bytes --]



------- Comment #3 from xuepeng dot guo at intel dot com  2008-08-06 06:38 -------
Created an attachment (id=16031)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16031&action=view)
A smaller case.

[xguo2@shgcc-10 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 <http://gcc.gnu.org/bugs.html> 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

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

[hjl dot tools at gmail dot com]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1055 bytes --]



------- 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.
> 
> [xguo2@shgcc-10 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 <http://gcc.gnu.org/bugs.html> 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 <http://gcc.gnu.org/bugs.html> 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 #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

[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|0000-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

[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

[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

[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 #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

[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 <foo>:
 80483a8:       8d 4c 24 04             lea    0x4(%esp),%ecx
 80483ac:       83 e4 f0                and    $0xfffffff0,%esp
 80483af:       ff 71 fc                pushl  -0x4(%ecx)
 80483b2:       55                      push   %ebp
 80483b3:       89 e5                   mov    %esp,%ebp
 80483b5:       51                      push   %ecx
 80483b6:       83 ec 04                sub    $0x4,%esp

00000018 00000024 0000001c FDE cie=00000000 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

[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

[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

[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

[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

[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] internal compiler error: in compute_barrier_args_size

[jakub at gcc dot gnu dot org]

------- Comment #15 from jakub at gcc dot gnu dot org  2009-01-13 17:18 -------
As the asserts aren't on the trunk, this isn't really a regression, we've been
emitting bogus unwind info in these cases (and many more than now) before as
well.


-- 

jakub at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[4.4 regression] internal   |internal compiler error: in
                   |compiler error: in          |compute_barrier_args_size
                   |compute_barrier_args_size   |


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

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

[amylaar at gcc dot gnu dot org]

------- Comment #16 from amylaar at gcc dot gnu dot org  2009-03-08 14:37 -------
(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.

It is a valid size optimization, so if the unwinder doesn't need the directive
to be always correct, we should do this optimization for -Os unless you also
specify -O1.  Optimization levels above -O1 are known to give imperfect debug
information.  And -O1 defaults to -fno-crossjumping .


-- 

amylaar at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |amylaar at gcc dot gnu dot
                   |                            |org


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

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

[jakub at gcc dot gnu dot org]

-- 

jakub at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.4.0                       |4.4.1


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

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

[jakub at gcc dot gnu dot org]

-- 

jakub at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.4.1                       |4.4.2


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

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

[jakub at gcc dot gnu dot org]

-- 

jakub at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.4.2                       |4.4.3


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

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

[jakub at gcc dot gnu dot org]

-- 

jakub at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.4.3                       |4.4.4


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

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

[ebotcazou at gcc dot gnu dot org]

------- Comment #17 from ebotcazou at gcc dot gnu dot org  2010-01-25 06:58 -------
Jakub, what to do with this PR?  It is still marked "blocker" although it seems
to have blocked nothing.


-- 

ebotcazou at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ebotcazou at gcc dot gnu dot
                   |                            |org


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

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

[jakub at gcc dot gnu dot org]

------- Comment #18 from jakub at gcc dot gnu dot org  2010-01-25 08:22 -------
It is no longer marged regression, so no longer release critical.
Anyway, the goal should be to reenable the asserts in dwarf2out.c and fix the
issues, because they really result in wrong unwind info.  Only the unwinder
uses it though (DW_CFA_GNU_args_size), so the question is if we can come up
with a testcase that actually misbehaves of it.
There are two known cases which triggered the assertions - one is alloca with
an argument that ends up to be constant in the end, and the other is
crossjumping of noreturn sequences with different stack push depth.


-- 

jakub at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|blocker                     |major
           Priority|P1                          |P2


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

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

[jakub at gcc dot gnu dot org]

-- 

jakub at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.4.4                       |4.4.5


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

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

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.4.5                       |4.4.6

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

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.4.6                       |4.4.7

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

[rguenth at gcc dot gnu.org]

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

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.4.7                       |---