[Bug tree-optimization/60206] New: IVOPT has no idea of inline asm

[Bug tree-optimization/60206] New: IVOPT has no idea of inline asm

[wmi at google dot com]

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

            Bug ID: 60206
           Summary: IVOPT has no idea of inline asm
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: wmi at google dot com
                CC: rguenth at gcc dot gnu.org, shenhan at google dot com
              Host: i386
            Target: i386

Created attachment 32141
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32141&action=edit
Testcase

This bug is found in google branch but I think the same problem also exists on
trunk (but not exposed).

For the testcase 1.c attached (1.c is extracted from libgcc/soft-fp/divtf3.c),
use trunk compiler gcc-r202164 (Target: x86_64-unknown-linux-gnu) + the patch
r204497 could expose the problem.

The command:
gcc -v -O2 -fno-omit-frame-pointer -fpic -c -S -m32 1.c

The error:
./1.c: In function ‘__divtf3’:
./1.c:64:1194: error: ‘asm’ operand has impossible constraints

The inline asm in error message is as follow:
do {
 __asm__ (
"sub{l} {%11,%3|%3,%11}\n\t"
"sbb{l} {%9,%2|%2,%9}\n\t"
"sbb{l} {%7,%1|%1,%7}\n\t"
"sbb{l} {%5,%0|%0,%5}"
: "=r" ((USItype) (A_f[3])), "=&r" ((USItype) (A_f[2])), "=&r" ((USItype)
(A_f[1])), "=&r" ((USItype) (A_f[0])) : "0" ((USItype) (B_f[2])), "g"
((USItype) (A_f[2])), "1" ((USItype) (B_f[1])), "g" ((USItype) (A_f[1])), "2"
((USItype) (B_f[0])), "g" ((USItype) (A_f[0])), "3" ((USItype) (0)), "g"
((USItype) (_n_f[_i])));
} while ()

Because -fno-omit-frame-pointer is turned on and the command line uses -fpic,
there are only 5 registers for register allocation.

Before IVOPT,
%0, %1, %2, %3 require 4 registers. The index variable i of _n_f[_i] requires
another register. So 5 registers are used up here.

After IVOPT, MEM reference _n_f[_i] is converted to MEM[base: _874, index:
ivtmp.22_821, offset: 0B]. base and index require 2 registers, Now 6 registers
are required, so LRA cannot find enough registers to allocate.

trunk compiler doesn't expose the problem because of patch r202165. With patch
r202165, IVOPT doesn't change _n_f[_i] in inline asm above. But it just hided
the problem.

Should IVOPT care about the constraints in inline-asm and restrict its
optimization in some case?
>From gcc-bugs-return-443613-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Feb 14 22:02:13 2014
Return-Path: <gcc-bugs-return-443613-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 7939 invoked by alias); 14 Feb 2014 22:02: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 7853 invoked by uid 48); 14 Feb 2014 22:02:08 -0000
From: "hjl.tools at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/60207] New: Wrong TFmode check in construct_container
Date: Fri, 14 Feb 2014 22:02:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: hjl.tools at gmail 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 cc
Message-ID: <bug-60207-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-02/txt/msg01370.txt.bz2
Content-length: 3461

http://gcc.gnu.org/bugzilla/show_bug.cgi?id`207

            Bug ID: 60207
           Summary: Wrong TFmode check in construct_container
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: hjl.tools at gmail dot com
                CC: hubicka at ucw dot cz, rth at gcc dot gnu.org, ubizjak at gmail dot com

r73099:

commit e07e720e6332466eef5d5f0ad7687523ddbfc644
Author: hubicka <hubicka@138bc75d-0d04-0410-961f-82ee72b054a4>
Date:   Thu Oct 30 21:01:16 2003 +0000

      * real.c (encode_ieee_extended): Initialize whole array.
      * reg-stack.c (move_for_stack_reg0: Use always XFmode.
      * i386-modes.def: Change definitions of TFmode and XFmode.
      * i386.c (classify_argument): Rename TFmodes to XFmodes; add new TFmode
co
de.
      (construct_container): Allow constructing of TFmode integer containers.
      (ix86_return_in_memory):  XFmode is not returned in memory.
      (init_ext_80387_constants): Always use XFmode.
      (print_operand): Likewise.
      (ix86_prepare_fp_compare_regs): Likewise.
      (split_to_parts): Deal with TFmode.
      (split_long_move): Simplify.
      (ix86_init_mmx_sse_builtins): Add __float80, __float128.
      (ix86_memory_move_cost): Do not confuse TFmode.
      * i386.h (LONG_DOUBLE_TYPE_SIZE): Set to 96.
      (IS_STACK_MODE): TFmode is not stack mode.
      (HARD_REGNO_NREGS, CLASS_MAX_NREGS): Deal nicely with XFmode.
      (VALID_SSE_REG_MODE): Allow TFmode.
      (VALID_FP_MODE_P): Disallow TFmode.

passed TFmode in integer registers:

+    case TFmode:
+      classes[0] = X86_64_INTEGER_CLASS;
+      classes[1] = X86_64_INTEGER_CLASS;
+      return 2;

   if (n == 2 && class[0] == X86_64_INTEGER_CLASS
       && class[1] == X86_64_INTEGER_CLASS
-      && (mode == CDImode || mode == TImode)
+      && (mode == CDImode || mode == TImode || mode == TFmode)
       && intreg[0] + 1 == intreg[1])
     return gen_rtx_REG (mode, intreg[0]);

But it was changed later to pass TFmode in SSE register:

commit fabb8546e54830051300c70ddcd8a6fce3b7d790
Author: rth <rth@138bc75d-0d04-0410-961f-82ee72b054a4>
Date:   Fri Jul 9 22:35:35 2004 +0000

            * config/i386/i386.c (classify_argument): Treat V1xx modes the same
as
            their base modes. CTImode, TCmode, and XCmode must be passed in
memory.
            TFmode (__float128) must be is an SSE/SSEUP pair. V2SImode,
V4HImode,
            and V8QI are class SSE. All sufficiently small remaining vector
modes
            must be passed in one or two integer registers.
            (ix86_libcall_value): TFmode must be returned in xmm0, XCmode must
be
            returned in memory.
            (bdesc_2arg, ix86_init_mmx_sse_builtins): __builtin_ia32_pmuludq
and
            __builtin_ia32_pmuludq128 have non-uniform argument and return
types
            and must thus be handled explicitly.
            * config/i386/i386.md (*movdi_1_rex64): Add cases for moving
between
            MMX and XMM regs.
            (movv8qi_internal, movv4hi_internal, movv2si_internal,
            movv2sf_internal): Permit moving between MMX and XMM registers
(since
            MMX areguments and return values are passed in XMM registers).
            (sse2_umulsidi3): Correct type and mode.

But we didn't remove mode == TFmode check in construct_container.

[Bug tree-optimization/60206] IVOPT has no idea of inline asm

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
I think the real issue __FP_FRAC_SUB_4 needs to be fixed not to use inline-asm
but normal C code.  The normal C code should be able to produce as good as the
inline-asm code now too.

[Bug tree-optimization/60206] IVOPT has no idea of inline asm

[wmi at google dot com]

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

--- Comment #2 from wmi at google dot com ---
This is a way to fix the problem. libgcc/soft-fp/op-4.h has provided a C
version of __FP_FRAC_SUB_4, but now it is overrided by the inline asm version
in config/i386/32/sfp-machine.h.

But the inline asm looks legal right? Isn't it compiler's responsiblity to keep
the inline asm constraints always satisfiable?

[Bug tree-optimization/60206] IVOPT has no idea of inline asm

[joseph at codesourcery dot com]

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

--- Comment #3 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
On Fri, 14 Feb 2014, pinskia at gcc dot gnu.org wrote:

> I think the real issue __FP_FRAC_SUB_4 needs to be fixed not to use inline-asm
> but normal C code.  The normal C code should be able to produce as good as the
> inline-asm code now too.

Does GCC do a good job of detecting add-with-carry and 
subtract-with-borrow patterns (i.e. detecting the comparison that 
corresponds to the carry flag and its use in a subsequent operation)?

(The Clang __builtin_addc* / __builtin_subc* functions might also be a 
useful addition for this sort of purpose.)

[Bug tree-optimization/60206] IVOPT has no idea of inline asm

[wmi at google dot com]

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

--- Comment #4 from wmi at google dot com ---

> On Fri, 14 Feb 2014, pinskia at gcc dot gnu.org wrote:
> 
> > I think the real issue __FP_FRAC_SUB_4 needs to be fixed not to use inline-asm
> > but normal C code.  The normal C code should be able to produce as good as the
> > inline-asm code now too.
> 
> Does GCC do a good job of detecting add-with-carry and 
> subtract-with-borrow patterns (i.e. detecting the comparison that 
> corresponds to the carry flag and its use in a subsequent operation)?

I remember at least the expansion of builtin_strlen could generate
sub-with-borrow and it works well, so I think rtl passes could handle
add-with-carry/subtract-with-borrow.

[Bug tree-optimization/60206] IVOPT has no idea of inline asm

[rguenther at suse dot de]

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

--- Comment #5 from rguenther at suse dot de <rguenther at suse dot de> ---
On Fri, 14 Feb 2014, wmi at google dot com wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60206
> 
>             Bug ID: 60206
>            Summary: IVOPT has no idea of inline asm
>            Product: gcc
>            Version: 4.9.0
>             Status: UNCONFIRMED
>           Severity: normal
>           Priority: P3
>          Component: tree-optimization
>           Assignee: unassigned at gcc dot gnu.org
>           Reporter: wmi at google dot com
>                 CC: rguenth at gcc dot gnu.org, shenhan at google dot com
>               Host: i386
>             Target: i386
> 
> Created attachment 32141
>   --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32141&action=edit
> Testcase
> 
> This bug is found in google branch but I think the same problem also exists on
> trunk (but not exposed).
> 
> For the testcase 1.c attached (1.c is extracted from libgcc/soft-fp/divtf3.c),
> use trunk compiler gcc-r202164 (Target: x86_64-unknown-linux-gnu) + the patch
> r204497 could expose the problem.
> 
> The command:
> gcc -v -O2 -fno-omit-frame-pointer -fpic -c -S -m32 1.c
> 
> The error:
> ./1.c: In function ‘__divtf3’:
> ./1.c:64:1194: error: ‘asm’ operand has impossible constraints
> 
> The inline asm in error message is as follow:
> do {
>  __asm__ (
> "sub{l} {%11,%3|%3,%11}\n\t"
> "sbb{l} {%9,%2|%2,%9}\n\t"
> "sbb{l} {%7,%1|%1,%7}\n\t"
> "sbb{l} {%5,%0|%0,%5}"
> : "=r" ((USItype) (A_f[3])), "=&r" ((USItype) (A_f[2])), "=&r" ((USItype)
> (A_f[1])), "=&r" ((USItype) (A_f[0])) : "0" ((USItype) (B_f[2])), "g"
> ((USItype) (A_f[2])), "1" ((USItype) (B_f[1])), "g" ((USItype) (A_f[1])), "2"
> ((USItype) (B_f[0])), "g" ((USItype) (A_f[0])), "3" ((USItype) (0)), "g"
> ((USItype) (_n_f[_i])));
> } while ()
> 
> Because -fno-omit-frame-pointer is turned on and the command line uses -fpic,
> there are only 5 registers for register allocation.
> 
> Before IVOPT,
> %0, %1, %2, %3 require 4 registers. The index variable i of _n_f[_i] requires
> another register. So 5 registers are used up here.
> 
> After IVOPT, MEM reference _n_f[_i] is converted to MEM[base: _874, index:
> ivtmp.22_821, offset: 0B]. base and index require 2 registers, Now 6 registers
> are required, so LRA cannot find enough registers to allocate.
> 
> trunk compiler doesn't expose the problem because of patch r202165. With patch
> r202165, IVOPT doesn't change _n_f[_i] in inline asm above. But it just hided
> the problem.
> 
> Should IVOPT care about the constraints in inline-asm and restrict its
> optimization in some case?

It's true that ASMs are not in any way special cased - it may be worth
trying if distinguishing address-uses and other uses may be worth it.
It's only a cost thing, of course.  In general find_interesting_uses_stmt
may need some modernization.
>From gcc-bugs-return-443890-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Feb 17 09:59:03 2014
Return-Path: <gcc-bugs-return-443890-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 7389 invoked by alias); 17 Feb 2014 09:59:03 -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 7349 invoked by uid 48); 17 Feb 2014 09:58:59 -0000
From: "joey.ye at arm dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/60172] ARM performance regression from trunk@207239
Date: Mon, 17 Feb 2014 09:59: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: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: joey.ye at arm dot com
X-Bugzilla-Status: WAITING
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:
Message-ID: <bug-60172-4-xLjPz6oXED@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-60172-4@http.gcc.gnu.org/bugzilla/>
References: <bug-60172-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-02/txt/msg01647.txt.bz2
Content-length: 1141

http://gcc.gnu.org/bugzilla/show_bug.cgi?id`172

--- Comment #8 from Joey Ye <joey.ye at arm dot com> ---
Here is tree dump and diff of 133t.forwprop4
  <bb 2>:
  Int_Index_4 = Int_1_Par_Val_3(D) + 5;
  Int_Loc.0_5 = (unsigned int) Int_Index_4;
  _6 = Int_Loc.0_5 * 4;
  _8 = Arr_1_Par_Ref_7(D) + _6;
  *_8 = Int_2_Par_Val_10(D);
  _13 = _6 + 4;
  _14 = Arr_1_Par_Ref_7(D) + _13;
  *_14 = Int_2_Par_Val_10(D);
  _17 = _6 + 60;
  _18 = Arr_1_Par_Ref_7(D) + _17;
  *_18 = Int_Index_4;
  pretmp_20 = Int_Loc.0_5 * 100;
  pretmp_2 = Arr_2_Par_Ref_22(D) + pretmp_20;
  _42 = (sizetype) Int_1_Par_Val_3(D);
  _41 = _42 * 4;
-  _40 = pretmp_2 + _41; // good
+  _12 = _41 + pretmp_20; // bad
+  _40 = Arr_2_Par_Ref_22(D) + _12;  // bad
  MEM[(int[25] *)_40 + 20B] = Int_Index_4;
  MEM[(int[25] *)_40 + 24B] = Int_Index_4;
  _29 = MEM[(int[25] *)_40 + 16B];
  _30 = _29 + 1;
  MEM[(int[25] *)_40 + 16B] = _30;
  _32 = pretmp_20 + 1000;
  _33 = Arr_2_Par_Ref_22(D) + _32;
  _34 = *_8;
-  _51 = _33 + _41;  // good
+  _16 = _41 + _32;  // bad
+  _51 = Arr_2_Par_Ref_22(D) + _16;  // bad

  MEM[(int[25] *)_51 + 20B] = _34;
  Int_Glob = 5;
  return;

[Bug tree-optimization/60206] IVOPT has no idea of inline asm

[wmi at google dot com]

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

--- Comment #6 from wmi at google dot com ---
Created attachment 32328
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32328&action=edit
2.c

[Bug tree-optimization/60206] IVOPT has no idea of inline asm

[wmi at google dot com]

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

--- Comment #7 from wmi at google dot com ---
After looking into the problem more, I found IVOPT may not be the root cause.
Even if IVOPT create a memory operand using two registers, if only the
following optimizations doesn't propagate the memory operand to an asm_operand,
the problem will not happen. 

So I created another smallcase 2.c for which gcc at the head of trunk will
report the same error. -fno-ivopts will not help here.

gcc -v
Target: x86_64-unknown-linux-gnu
Configured with: ../src/configure
--prefix=/usr/local/google/home/wmi/workarea/gcc-r208410/build/install
Thread model: posix
gcc version 4.9.0 20140307 (experimental) (GCC)

gcc -O2 -fno-omit-frame-pointer -m32 -S 2.c

2.c: In function ‘foo’:
2.c:25:1: error: ‘asm’ operand has impossible constraints
 __asm__ (
 ^

The problem will disappear after I use -fno-tree-ter and -fdisable-rtl-combine.
These two phases could propagate a memory reference using a register into an
asm operand with constraint "g", which make the registers used in asm stmt
increase. 

For TER, TER of loads into input arguments is allowed. For combine,
insn_invalid_p() will only check whether an asm operand will satisfy its
constraint. However, neither TER nor combine check whether the propagation
could make the registers in asm stmt exceed available register number.
>From gcc-bugs-return-445974-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Mar 10 21:05:24 2014
Return-Path: <gcc-bugs-return-445974-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 10199 invoked by alias); 10 Mar 2014 21:05:23 -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 10167 invoked by uid 48); 10 Mar 2014 21:05:19 -0000
From: "marekrusinowski at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/60493] New: g++ throws segmentation fault on simple code
Date: Mon, 10 Mar 2014 21:05:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 4.8.2
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: marekrusinowski at gmail 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-60493-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-03/txt/msg00843.txt.bz2
Content-length: 1507

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

            Bug ID: 60493
           Summary: g++ throws segmentation fault on simple code
           Product: gcc
           Version: 4.8.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: marekrusinowski at gmail dot com

Created attachment 32329
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32329&action=edit
Preprocessed source

This simple incorrect code (works here to: http://ideone.com/QPwEPO):


  #include <iterator>

  template <class T>
  class Splay {
    public:
      class iterator;
  };

  template <class T, class D>
  class Splay<T>::iterator : std::iterator<std::forward_iterator_tag, D> {
  };

  Splay<int>::iterator it;


Crashes g++ with output:


  gcc_segfault.cpp: In instantiation of ‘class Splay<int>::iterator’:
  gcc_segfault.cpp:13:22:   required from here
  gcc_segfault.cpp:10:17: internal compiler error: Segmentation fault
   class Splay<T>::iterator : std::iterator<std::forward_iterator_tag, D> {
                   ^
  Please submit a full bug report,
  with preprocessed source if appropriate.
  See <file:///usr/share/doc/gcc-4.8/README.Bugs> for instructions.
  Preprocessed source stored into /tmp/ccud4lbz.out file, please attach this to
your bugreport.


Proccessed source (/tmp/ccud4lbz.out) in attachment.
g++ version: "g++ (Debian 4.8.2-16) 4.8.2"
>From gcc-bugs-return-445975-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Mar 10 21:07:42 2014
Return-Path: <gcc-bugs-return-445975-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 13146 invoked by alias); 10 Mar 2014 21:07:41 -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 13078 invoked by uid 55); 10 Mar 2014 21:07:35 -0000
From: "jason at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/60367] Default argument object is not getting constructed
Date: Mon, 10 Mar 2014 21:07: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: unknown
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jason at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: jason at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-60367-4-mnLk31fwyA@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-60367-4@http.gcc.gnu.org/bugzilla/>
References: <bug-60367-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-03/txt/msg00844.txt.bz2
Content-length: 467

http://gcc.gnu.org/bugzilla/show_bug.cgi?id`367

--- Comment #8 from Jason Merrill <jason at gcc dot gnu.org> ---
Author: jason
Date: Mon Mar 10 21:06:59 2014
New Revision: 208465

URL: http://gcc.gnu.org/viewcvs?rev 8465&root=gcc&view=rev
Log:
    PR c++/60367
    * call.c (convert_default_arg): Remove special handling for
    CONSTRUCTOR.

Added:
    trunk/gcc/testsuite/g++.dg/overload/defarg8.C
Modified:
    trunk/gcc/cp/ChangeLog
    trunk/gcc/cp/call.c

[Bug tree-optimization/60206] IVOPT has no idea of inline asm

[olegendo at gcc dot gnu.org]

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

Oleg Endo <olegendo at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |olegendo at gcc dot gnu.org

--- Comment #8 from Oleg Endo <olegendo at gcc dot gnu.org> ---
(In reply to joseph@codesourcery.com from comment #3)
> On Fri, 14 Feb 2014, pinskia at gcc dot gnu.org wrote:
> 
> > I think the real issue __FP_FRAC_SUB_4 needs to be fixed not to use inline-asm
> > but normal C code.  The normal C code should be able to produce as good as the
> > inline-asm code now too.
> 
> Does GCC do a good job of detecting add-with-carry and 
> subtract-with-borrow patterns (i.e. detecting the comparison that 
> corresponds to the carry flag and its use in a subsequent operation)?

This can be done with combine patterns, although there are some limitations and
it has to be done for each target individually.  See also PR 54236, in
particular comment 6.