[Bug target/44685] internal compiler error: in final_scan_insn, at final.c:2650 while compiling program with complex types

[Bug target/44685] internal compiler error: in final_scan_insn, at final.c:2650 while compiling program with complex types

[dcb314 at hotmail dot com]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 18873 bytes --]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44685

David Binderman <dcb314 at hotmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dcb314 at hotmail dot com

--- Comment #2 from David Binderman <dcb314 at hotmail dot com> ---
I am getting something similar on blackfin
when building linux kernel

arch/blackfin/kernel/setup.c: In function ‘setup_arch’:
arch/blackfin/kernel/setup.c:1110:1: error: could not split insn
 }
 ^
(jump_insn:TI 1747 1218 1222 126 (parallel [
            (set (pc)
                (if_then_else (ne (reg:SI 16 I0 [945])
                        (const_int 1 [0x1]))
                    (label_ref 1219)
                    (pc)))
            (set (reg:SI 16 I0 [945])
                (plus:SI (reg:SI 16 I0 [945])
                    (const_int -1 [0xffffffffffffffff])))
            (unspec [
                    (const_int 0 [0])
                ] 10)
            (clobber (reg:SI 0 R0))
        ]) arch/blackfin/kernel/setup.c:400 96 {loop_end}
     (expr_list:REG_UNUSED (reg:SI 0 R0)
        (int_list:REG_BR_PROB 9550 (nil)))
 -> 1219)
arch/blackfin/kernel/setup.c:1110:1: internal compiler error: in
final_scan_insn, at final.c:2952
>From gcc-bugs-return-466042-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Nov 08 11:15:49 2014
Return-Path: <gcc-bugs-return-466042-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 17445 invoked by alias); 8 Nov 2014 11:15:49 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 17407 invoked by uid 48); 8 Nov 2014 11:15:46 -0000
From: "manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug other/346] gcc install clobbers files that it shouldn't touch
Date: Sat, 08 Nov 2014 11:15:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: other
X-Bugzilla-Version: 2.95
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: manu at gcc dot gnu.org
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status cc resolution
Message-ID: <bug-346-4-5MPidgo9pG@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-346-4@http.gcc.gnu.org/bugzilla/>
References: <bug-346-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-11/txt/msg00514.txt.bz2
Content-length: 797

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=346

Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |manu at gcc dot gnu.org
         Resolution|---                         |FIXED

--- Comment #10 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
I'll go ahead and close this as everything originally reported seems to have
been fixed. If there are further issues, a new bug should be opened with a
clear list of files clobbered. The most recent duplicate about this was about
-V not working and that got fixed.
>From gcc-bugs-return-466043-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Nov 08 11:25:24 2014
Return-Path: <gcc-bugs-return-466043-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 20889 invoked by alias); 8 Nov 2014 11:25:24 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 20858 invoked by uid 48); 8 Nov 2014 11:25:20 -0000
From: "manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/54780] G++ does not find precompiled headers in some cases
Date: Sat, 08 Nov 2014 11:25:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 4.7.2
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: manu at gcc dot gnu.org
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status cc resolution
Message-ID: <bug-54780-4-i179Y9OlzF@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-54780-4@http.gcc.gnu.org/bugzilla/>
References: <bug-54780-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-11/txt/msg00515.txt.bz2
Content-length: 559

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54780

Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
                 CC|                            |manu at gcc dot gnu.org
         Resolution|---                         |INVALID

--- Comment #6 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
Thus, not a bug then, no?
>From gcc-bugs-return-466044-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Nov 08 12:14:55 2014
Return-Path: <gcc-bugs-return-466044-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 9889 invoked by alias); 8 Nov 2014 12:14:55 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 9803 invoked by uid 48); 8 Nov 2014 12:14:50 -0000
From: "manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/63748] [4.9/5 Regression] wrong may be used uninitialized warning (abnormal edges)
Date: Sat, 08 Nov 2014 12:14:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: tree-optimization
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: manu at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.9.3
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cc dependson short_desc
Message-ID: <bug-63748-4-fhkFcGtmM3@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63748-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63748-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-11/txt/msg00516.txt.bz2
Content-length: 6679

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63748

Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |manu at gcc dot gnu.org
         Depends on|                            |24639
            Summary|[4.9/5 Regression] may be   |[4.9/5 Regression] wrong
                   |used uninitialized warning  |may be used uninitialized
                   |on variable definition with |warning (abnormal edges)
                   |initializer                 |

--- Comment #5 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Ulrich Weigand from comment #4)
> Huh?  No matter what, "buf" is in fact never used uninitialized in this
> function, and that should be trivial to see; the only use of "buf" occurs in
> line 17 immediately after the definition of "buf" in line 16, whether any
> longjmp is ever called or not.
> 
> Also, if any of the gotos in this function is removed, the warning
> disappears.  The problem seems to be related to some call-graph
> optimizations (note that the if (noside) check is partially redundant).

The problem arises because we create PHI nodes with default definitions of buf
for the basic block created by the gotos. For example:

;;   basic block 6, loop depth 0, count 0, freq 0, maybe hot
;;    prev block 5, next block 7, flags: (NEW, REACHABLE)
;;    pred:       3 (ABNORMAL)
;;                8 (ABNORMAL)
;;   starting at line -1
  # argvec_2(ab) = PHI <[test.c:9:9] argvec_13(ab)(3), argvec_3(ab)(8)>
  # buf_5(ab) = PHI <buf_18(D)(ab)(3), buf_6(ab)(8)>
  # .MEM_9(ab) = PHI <.MEM_16(ab)(3), .MEM_25(ab)(8)>
  # .MEM_20(ab) = VDEF <.MEM_9(ab)>
  # USE = anything
  # CLB = anything
  ABNORMAL_DISPATCHER (0);
;;    succ:       5 (ABNORMAL)

and no subsequent optimization is able to realize that those PHI nodes are
never used or to remove the edges as unreachable.

I think this is some issue with how the call-graph is built. A simplified
version of 015t.ssa:

test (intD.6 opD.1753, intD.6 nosideD.1754)
{
;;   basic block 2, loop depth 0, count 0, freq 0, maybe hot
;;    pred:       ENTRY (FALLTHRU)
;;   starting at line 9
  [test.c:11:6] if (op_14(D) != 0)
    goto <bb 3>;
  else
    goto <bb 10>;

;;   basic block 3, loop depth 0, count 0, freq 0, maybe hot
;;    pred:       2 (TRUE_VALUE)
;;   starting at line 13
  [test.c:13:16] # .MEM_16(ab) = VDEF <.MEM_15(D)>
  _17 = alloc_jmp_bufD.1750 ();
;;    succ:       4 (FALLTHRU)
;;                6 (ABNORMAL)

;;   basic block 4, loop depth 0, count 0, freq 0, maybe hot
;;    pred:       3 (FALLTHRU)
;;   starting at line 13, discriminator 1
  [test.c:13:16] buf_19 = _17;
;;    succ:       5 (FALLTHRU)

;;   basic block 5, loop depth 0, count 0, freq 0, maybe hot
;;    pred:       4 (FALLTHRU)
;;                6 (ABNORMAL)
;;   starting at line 14
  # buf_4(ab) = PHI <[test.c:13:16] buf_19(4), buf_5(ab)(6)>
  setjmpD.1749 (buf_4(ab));
  [test.c:16:10] if (noside_22(D) != 0)
    goto <bb 11> (nosideret);
  else
    goto <bb 7> (do_call_it);
;;    succ:       11 (TRUE_VALUE)
;;                7 (FALSE_VALUE)

;;   basic block 6, loop depth 0, count 0, freq 0, maybe hot
;;    pred:       3 (ABNORMAL)
;;                8 (ABNORMAL)
;;   starting at line -1
  # buf_5(ab) = PHI <buf_18(D)(ab)(3), buf_6(ab)(8)>
  ABNORMAL_DISPATCHER (0);
;;    succ:       5 (ABNORMAL)

;;   basic block 7, loop depth 0, count 0, freq 0, maybe hot
;;    pred:       5 (FALSE_VALUE)
;;                10 (FALLTHRU)
;;   starting at line 21
  # buf_6(ab) = PHI <buf_4(ab)(5), buf_18(D)(ab)(10)>
do_call_itL.2:
  [test.c:21:10] if (noside_22(D) != 0)
    goto <bb 11> (nosideret);
  else
    goto <bb 8>;
;;    succ:       11 (TRUE_VALUE)
;;                8 (FALSE_VALUE)

;;   basic block 8, loop depth 0, count 0, freq 0, maybe hot
;;    pred:       7 (FALSE_VALUE)
;;   starting at line 24
  _26 = fooD.1752 (argvec_3(ab));
;;    succ:       9 (FALLTHRU)
;;                6 (ABNORMAL)

;;   basic block 9, loop depth 0, count 0, freq 0, maybe hot
;;    pred:       8 (FALLTHRU)
;;   starting at line 24, discriminator 1
  [test.c:24:14] _27 = _26;
  [test.c:24:14] goto <bb 12>;
;;    succ:       12 (FALLTHRU)

;;   basic block 10, loop depth 0, count 0, freq 0, maybe hot
;;    pred:       2 (FALSE_VALUE)
;;   starting at line 27
  argvec_24 = allocaD.858 (1);
  [test.c:28:3] goto <bb 7> (do_call_it);
;;    succ:       7 (FALLTHRU)

;;   basic block 11, loop depth 0, count 0, freq 0, maybe hot
;;    pred:       5 (TRUE_VALUE)
;;                7 (TRUE_VALUE)
;;   starting at line 31
nosideretL.5:
  [test.c:31:10] _28 = 1;
;;    succ:       12 (FALLTHRU)

;;   basic block 12, loop depth 0, count 0, freq 0, maybe hot
;;    pred:       9 (FALLTHRU)
;;                11 (FALLTHRU)
;;   starting at line -1
  # _7 = PHI <[test.c:24:14] _27(9), [test.c:31:10] _28(11)>
  return _7;
;;    succ:       EXIT

}

which is more or less:


test (intD.6 opD.1753, intD.6 nosideD.1754)
{
bb1:
 if (op_14(D) != 0)
 {
     try {
         _17 = alloc_jmp_bufD.1750 (); 
         [test.c:13:16] buf_19 = _17;
         goto bb5;
     } catch {
         goto bb6;
     }
 } else {
      argvec_24 = allocaD.858 (1);
      [test.c:28:3] goto do_call_it;
  }

bb5:
  # buf_4(ab) = PHI <[test.c:13:16] buf_19(bb1), buf_5(ab)(6)>
  setjmpD.1749 (buf_4(ab));
  [test.c:16:10] if (noside_22(D) != 0)
    goto nosideret;
  else
    goto do_call_it;

bb6:
  # buf_5(ab) = PHI <buf_18(D)(ab)(bb1), buf_6(ab)(bb8)>
  ABNORMAL_DISPATCHER (0);
  goto bb5:

do_call_it:
  # buf_6(ab) = PHI <buf_4(ab)(5), buf_18(D)(ab)(10)>
  [test.c:21:10] if (noside_22(D) != 0)
    goto nosideret;
  else
    goto bb8;

bb8:
  try {
        [test.c:24:14] _7 = fooD.1752 (argvec_3(ab));
        [test.c:24:14] goto bb12;
  } catch { 
    goto bb6; 
  }

nosideret:
  [test.c:31:10] _7 = 1;
bb12:
  return _7;

}

Thus, it is clear that buf can be used uninitialized if the abnormal edge is
taken (represented by the first try-catch). Now, I don't have any idea why
there is an abnormal edge there. I guess this is what Andrew was explaining
about alloc_jmp_buf.

If it is indeed needed, then there may be a missing optimization later (someone
else would need to compare the -fdump-tree-all-all files when removing one of
the gotos).

Perhaps, as a work-around, the uninit pass could ignore default definitions
that come from abnormal edges, but I'm not sure if this will cause some false
negatives.
>From gcc-bugs-return-466045-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Nov 08 12:17:12 2014
Return-Path: <gcc-bugs-return-466045-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 11026 invoked by alias); 8 Nov 2014 12:17:12 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 11003 invoked by uid 48); 8 Nov 2014 12:17:09 -0000
From: "charles at karney dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libstdc++/63780] New: std::remquo returns wrong quotient
Date: Sat, 08 Nov 2014 12:17:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: libstdc++
X-Bugzilla-Version: 4.8.3
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: charles at karney dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter attachments.created
Message-ID: <bug-63780-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-11/txt/msg00517.txt.bz2
Content-length: 2170

https://gcc.gnu.org/bugzilla/show_bug.cgi?idc780

            Bug ID: 63780
           Summary: std::remquo returns wrong quotient
           Product: gcc
           Version: 4.8.3
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: charles at karney dot com

Created attachment 33921
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id3921&actioníit
intermediate output from compiler

This code:

#include <cmath>
#include <iostream>

int main() {
  int n;
  double x = 3419, m = 360;
  double y = std::remainder(x, m);
  double z = std::remquo(x, m, &n);
  std::cout << "result " << y << " " << z << " " << n << "\n";
}

compiled with

g++ --std=c++11 -O0 -o remquo-bug remquo-bug.cpp && ./remquo-bug

produces

result 179 539 8

The correct output is produced by -O1

result 179 179 9

Here is the output from g++ -v

Using built-in specs.
COLLECT_GCC=/usr/bin/g++
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.8.3/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-linker-build-id --with-linker-hash-style=gnu
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin
--enable-initfini-array --enable-java-awt=gtk --disable-dssi
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --enable-java-maintainer-mode
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib
--with-isl=/builddir/build/BUILD/gcc-4.8.3-20140911/obj-x86_64-redhat-linux/isl-install
--with-cloog=/builddir/build/BUILD/gcc-4.8.3-20140911/obj-x86_64-redhat-linux/cloog-install
--with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
gcc version 4.8.3 20140911 (Red Hat 4.8.3-7) (GCC)

Output from -save-temps attached

[Bug target/44685] internal compiler error: in final_scan_insn, at final.c:2650 while compiling program with complex types

[dcb314 at hotmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44685

--- Comment #3 from David Binderman <dcb314 at hotmail dot com> ---
(In reply to David Binderman from comment #2)
> I am getting something similar on blackfin
> when building linux kernel

> arch/blackfin/kernel/setup.c:1110:1: internal compiler error: in
> final_scan_insn, at final.c:2952

Still getting it a few months later, with a gcc 492 cross compiler.

[Bug target/44685] internal compiler error: in final_scan_insn, at final.c:2650 while compiling program with complex types

[dcb314 at hotmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44685

--- Comment #4 from David Binderman <dcb314 at hotmail dot com> ---
Created attachment 35317
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35317&action=edit
C source code

Source code from the linux kernel, which demonstrates the
problem when cross compiled on AMD for blackfin.

[Bug target/44685] internal compiler error: in final_scan_insn, at final.c:2650 while compiling program with complex types

[raj dot khem at gmail dot com]

------- Comment #1 from raj dot khem at gmail dot com  2010-06-27 07:11 -------
Created an attachment (id=21013)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21013&action=view)
testcase


-- 


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