[Bug go/60874] New: FAIL: go.test/test/recover.go execution

[Bug go/60874] New: FAIL: go.test/test/recover.go execution

[ubizjak at gmail dot com]

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

            Bug ID: 60874
           Summary: FAIL: go.test/test/recover.go execution
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: go
          Assignee: ian at airs dot com
          Reporter: ubizjak at gmail dot com

The test fails [1] on alpha-linux-gnu (and other non-x86 processors) because
reflect.MakeFunc and other functions from reflect/makefunc.go are not
implemented for non-x86 architecture.

There was a suggestion to use libffi closures for this functionality [2], which
could solve this problem in a generic way.

[1] http://gcc.gnu.org/ml/gcc-testresults/2014-03/msg00790.html
[1] http://gcc.gnu.org/ml/gcc-patches/2013-09/msg02048.html

[Bug go/60874] FAIL: go.test/test/recover.go execution

[ubizjak at gmail dot com]

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

--- Comment #1 from Uroš Bizjak <ubizjak at gmail dot com> ---
Patch that extends libgo to use libffi closures is at [1].

[1] https://gcc.gnu.org/ml/gcc-patches/2014-07/msg01355.html
>From gcc-bugs-return-456788-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sun Jul 20 08:33:42 2014
Return-Path: <gcc-bugs-return-456788-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 26864 invoked by alias); 20 Jul 2014 08:33:39 -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 26540 invoked by uid 48); 20 Jul 2014 08:33:20 -0000
From: "dominiq at lps dot ens.fr" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/51864] [OOP] ALLOCATE with polymorphic array constructor as SOURCEDate: Sun, 20 Jul 2014 08:33:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: fortran
X-Bugzilla-Version: 4.7.0
X-Bugzilla-Keywords: ice-on-valid-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: dominiq at lps dot ens.fr
X-Bugzilla-Status: NEW
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 cf_reconfirmed_on everconfirmed
Message-ID: <bug-51864-4-OSaZTJawgK@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-51864-4@http.gcc.gnu.org/bugzilla/>
References: <bug-51864-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-07/txt/msg01379.txt.bz2
Content-length: 1404

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

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2014-07-20
     Ever confirmed|0                           |1

--- Comment #2 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
Compiling the code in comment 0 still gives an ICE with gfortran 4.10.0 r212833
(the same ICE as for pr53653):

pr51864.f90: In function 'MAIN__':
pr51864.f90:12:0: internal compiler error: in gfc_conv_array_constructor_expr,
at fortran/trans-expr.c:5668
 allocate(c(8), source=[ a, b ])
 ^

I also get the same ICE with the following code

  call pr53876
end

subroutine pr53876
  IMPLICIT NONE
  TYPE :: individual
    integer :: icomp ! Add an extra component to test offset
    REAL, DIMENSION(:), ALLOCATABLE :: genes
  END TYPE
  CLASS(individual), DIMENSION(:), ALLOCATABLE :: indv, indv1
  allocate (indv(2), source = [individual(1, [99,999]), &
                               individual(2, [999,9999])])
  allocate (indv1(2), source = [indv])
END

If I understand correctly comment 1, this code should be valid. Replacing
'[indv]' with '[indv(1),indv(2)]' does not fix the ICE, but replacing it with
'imdv' does.

[Bug go/60874] FAIL: go.test/test/recover.go execution

[ian at airs dot com]

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

Ian Lance Taylor <ian at airs dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2014-07-20
     Ever confirmed|0                           |1

--- Comment #2 from Ian Lance Taylor <ian at airs dot com> ---
The patch is committed so this bug may be fixed.  I haven't tested it on Alpha,
though.

[Bug go/60874] FAIL: go.test/test/recover.go execution

[ubizjak at gmail dot com]

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

Uroš Bizjak <ubizjak at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |NEW

--- Comment #3 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to Ian Lance Taylor from comment #2)
> The patch is committed so this bug may be fixed.  I haven't tested it on
> Alpha, though.

The testcase recover.go doesn't fail outright with not-implemented error.
However, tests test11reflect2, test13reflect2 and test14reflect2 currently
fail.
>From gcc-bugs-return-456862-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Jul 21 13:01:55 2014
Return-Path: <gcc-bugs-return-456862-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 32466 invoked by alias); 21 Jul 2014 13:01:54 -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 32416 invoked by uid 48); 21 Jul 2014 13:01:49 -0000
From: "redi at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/61867] gcc can't detect obviously false test
Date: Mon, 21 Jul 2014 13:01: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.9.1
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: redi at gcc dot gnu.org
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:
Message-ID: <bug-61867-4-k7e477inug@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-61867-4@http.gcc.gnu.org/bugzilla/>
References: <bug-61867-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-07/txt/msg01453.txt.bz2
Content-length: 241

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

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
I'm pretty sure gcc does detect it and optimizes appropriately, it just doesn't
warn (because it's not a static analyzer)

[Bug go/60874] FAIL: go.test/test/recover.go execution

[ubizjak at gmail dot com]

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

--- Comment #4 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to Uroš Bizjak from comment #3)
> (In reply to Ian Lance Taylor from comment #2)
> > The patch is committed so this bug may be fixed.  I haven't tested it on
> > Alpha, though.
> 
> The testcase recover.go doesn't fail outright with not-implemented error.
> However, tests test11reflect2, test13reflect2 and test14reflect2 currently
> fail.

The problem with test11reflect2 was due to unhandled FFI_TYPE_VOID case in
ffi_closure_osf_inner, fixed by following patch:

--cut here-
Index: src/alpha/ffi.c
===================================================================
--- src/alpha/ffi.c     (revision 212882)
+++ src/alpha/ffi.c     (working copy)
@@ -237,6 +237,7 @@ ffi_closure_osf_inner(ffi_closure *closure, void *

       switch (arg_types[i]->type)
        {
+       case FFI_TYPE_VOID:
        case FFI_TYPE_SINT8:
        case FFI_TYPE_UINT8:
        case FFI_TYPE_SINT16:
--cut here--

It looks that test13reflect2 and test14reflect2 tests fail on non-split stack
targets, since everything works OK with slightly modified testcase:

--cut here--
Index: testsuite/go.test/test/recover.go
===================================================================
--- testsuite/go.test/test/recover.go   (revision 212882)
+++ testsuite/go.test/test/recover.go   (working copy)
@@ -432,7 +432,7 @@
 }

 // enormous receiver, so wrapper splits stack to call M
-type T5 [8192]byte
+type T5 [2048]byte

 func (T5) M() {
        mustRecoverBody(doubleRecover(), recover(), recover(), 13)
@@ -459,12 +459,12 @@
 // enormous receiver + enormous method frame, so wrapper splits stack to call
M,
 // and then M splits stack to allocate its frame.
 // recover must look back two frames to find the panic.
-type T6 [8192]byte
+type T6 [2048]byte

 var global byte

 func (T6) M() {
-       var x [8192]byte
+       var x [2048]byte
        x[0] = 1
        x[1] = 2
        for i := range x {
--cut here--

It looks that the later problem points to a generic problem with non
split-stack targets.
>From gcc-bugs-return-456868-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Jul 21 14:59:12 2014
Return-Path: <gcc-bugs-return-456868-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 15115 invoked by alias); 21 Jul 2014 14:59:11 -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 14875 invoked by uid 48); 21 Jul 2014 14:59:03 -0000
From: "ubizjak at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug go/60874] FAIL: go.test/test/recover.go execution
Date: Mon, 21 Jul 2014 14:59:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: go
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: ubizjak at gmail dot com
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: ian at airs dot com
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-60874-4-aFwYa6cYYV@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-60874-4@http.gcc.gnu.org/bugzilla/>
References: <bug-60874-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-07/txt/msg01459.txt.bz2
Content-length: 205

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

--- Comment #5 from Uroš Bizjak <ubizjak at gmail dot com> ---
I forgot to tell that reflect test from libgo testsuite now passes:

PASS: reflect
>From gcc-bugs-return-456869-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Jul 21 15:33:53 2014
Return-Path: <gcc-bugs-return-456869-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 22447 invoked by alias); 21 Jul 2014 15:33:51 -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 22359 invoked by uid 48); 21 Jul 2014 15:33:45 -0000
From: "ubizjak at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug go/61871] New: FAIL: regexp from libgo testsuite on non-split stack targets
Date: Mon, 21 Jul 2014 15:33:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: go
X-Bugzilla-Version: 4.10.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: ubizjak at gmail dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: ian at airs dot com
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-61871-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-07/txt/msg01460.txt.bz2
Content-length: 1136

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

            Bug ID: 61871
           Summary: FAIL: regexp from libgo testsuite on non-split stack
                    targets
           Product: gcc
           Version: 4.10.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: go
          Assignee: ian at airs dot com
          Reporter: ubizjak at gmail dot com
                CC: cmang at google dot com

regexp test from libgo testsuite FAILs on alpha (non-split stack target) due to
too demanding testcase, even with 8G of RAM.

Applying the following testsuite patch, test passes without problems.

--cut here--
Index: go/regexp/all_test.go
==================================================================--- go/regexp/all_test.go       (revision 212885)
+++ go/regexp/all_test.go       (working copy)
@@ -475,7 +475,7 @@

 // This ran out of stack before issue 7608 was fixed.
 func TestOnePassCutoff(t *testing.T) {
-       MustCompile(`^(?:x{1,1000}){1,1000}$`)
+//     MustCompile(`^(?:x{1,1000}){1,1000}$`)
 }

 func BenchmarkLiteral(b *testing.B) {
--cut here--

[Bug go/60874] FAIL: go.test/test/recover.go execution

[ian at airs dot com]

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

--- Comment #6 from Ian Lance Taylor <ian at airs dot com> ---
I don't know why making the types smaller in comment #4 makes any difference. 
On a system that does not use split stacks, the runtime will allocate a 2M
stack for each goroutine (see StackMin in libgo/runtime/proc.c).  That is
clearly more than large enough to hold a 8192 byte value.  The comments in the
test about splitting the stack only apply to systems that support stack
splitting.

This will need more investigation by somebody with access to an Alpha.  I guess
one simple first step would be to verify that USING_SPLIT_STACK and
LINKER_SUPPORTS_SPLIT_STACK are both 0 in the file TARGET/libgo/config.h.

[Bug go/60874] FAIL: go.test/test/recover.go execution

[ubizjak at gmail dot com]

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

--- Comment #7 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to Ian Lance Taylor from comment #6)
> I don't know why making the types smaller in comment #4 makes any
> difference.  On a system that does not use split stacks, the runtime will
> allocate a 2M stack for each goroutine (see StackMin in
> libgo/runtime/proc.c).  That is clearly more than large enough to hold a
> 8192 byte value.  The comments in the test about splitting the stack only
> apply to systems that support stack splitting.
> 
> This will need more investigation by somebody with access to an Alpha.  I
> guess one simple first step would be to verify that USING_SPLIT_STACK and
> LINKER_SUPPORTS_SPLIT_STACK are both 0 in the file TARGET/libgo/config.h.

I can verify that they are undefined.

Maybe the effects of split stack can be ruled out on x86 by forcing it to use
libffi closures with non-split stack configuration?
>From gcc-bugs-return-457804-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Aug 05 14:23:06 2014
Return-Path: <gcc-bugs-return-457804-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 30048 invoked by alias); 5 Aug 2014 14:23:05 -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 29993 invoked by uid 55); 5 Aug 2014 14:23:00 -0000
From: "rguenther at suse dot de" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/62018] FAIL: gcc.dg/torture/ftrapv-1.c * execution test on x86_64-apple-darwin13
Date: Tue, 05 Aug 2014 14:23:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: middle-end
X-Bugzilla-Version: 4.10.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenther at suse dot de
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-62018-4-RSMh3QKh4m@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-62018-4@http.gcc.gnu.org/bugzilla/>
References: <bug-62018-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-08/txt/msg00301.txt.bz2
Content-length: 511

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

--- Comment #3 from rguenther at suse dot de <rguenther at suse dot de> ---
On Tue, 5 Aug 2014, dominiq at lps dot ens.fr wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?idb018
>
> --- Comment #2 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> > Can you please investigate a bit yourself?  The test relies on fork()/wait()
> > to work and properly return the exit status of the forked process.
>
> Where should I start?

With a debugger?

[Bug go/60874] FAIL: go.test/test/recover.go execution

[ubizjak at gmail dot com]

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

--- Comment #8 from Uroš Bizjak <ubizjak at gmail dot com> ---
After lots of debugging...

The problem is with the label that is passed as an argument to
__go_set_defer_retaddr. In function main.$thunk0, in _.179r.cse1 dump, we have:

...

(insn 7 3 8 2 (set (reg:DI 84)
        (high:DI (label_ref:DI 47))) rr.go:57 236 {*movdi}
     (insn_list:REG_LABEL_OPERAND 47 (nil)))
(insn 8 7 9 2 (set (reg:DI 83)
        (lo_sum:DI (reg:DI 84)
            (label_ref:DI 47))) rr.go:57 230 {*movdi_er_low_l}
     (insn_list:REG_LABEL_OPERAND 47 (expr_list:REG_EQUAL (label_ref:DI 47)
            (nil))))
(insn 9 8 10 2 (set (reg:DI 16 $16)
        (reg:DI 83)) rr.go:57 236 {*movdi}
     (nil))
(call_insn 10 9 11 2 (parallel [
            (set (reg:DI 0 $0)
                (call (mem:DI (symbol_ref:DI ("__go_set_defer_retaddr") [flags
0x41]  <function_decl 0x2000066a900 __go_set_defer_retaddr>) [0
__go_set_defer_retaddr S8 A64])
                    (const_int 0 [0])))
            (use (reg:DI 29 $29))
            (clobber (reg:DI 26 $26))
        ]) rr.go:57 357 {*call_value_osf_1_er}
     (expr_list:REG_CALL_DECL (symbol_ref:DI ("__go_set_defer_retaddr") [flags
0x41]  <function_decl 0x2000066a900 __go_set_defer_retaddr>)
        (nil))
    (expr_list:DI (use (reg:DI 16 $16))
        (nil)))

...

(call_insn 46 45 47 5 (parallel [
            (call (mem:DI (reg/f:DI 80 [ D.1014 ]) [0 *_42 S8 A64])
                (const_int 4048 [0xfd0]))
            (use (reg:DI 29 $29))
            (clobber (reg:DI 26 $26))
        ]) rr.go:57 210 {*call_osf_1_er}
     (expr_list:REG_DEAD (reg/f:DI 80 [ D.1014 ])
        (expr_list:REG_DEAD (reg:DI 21 $21)
            (expr_list:REG_DEAD (reg:DI 20 $20)
                (expr_list:REG_DEAD (reg:DI 19 $19)
                    (expr_list:REG_DEAD (reg:DI 18 $18)
                        (expr_list:REG_DEAD (reg:DI 17 $17)
                            (expr_list:REG_DEAD (reg:DI 16 $16)
                                (expr_list:REG_CALL_DECL (nil)
                                    (nil)))))))))
    (expr_list (use (reg:DI 21 $21))
        (expr_list (use (reg:DI 20 $20))
            (expr_list (use (reg:DI 19 $19))
                (expr_list (use (reg:DI 18 $18))
                    (expr_list (use (reg:DI 17 $17))
                        (expr_list (use (reg:DI 16 $16))
                            (expr_list:BLK (use (mem:BLK (reg/f:DI 30 $30) [0 
S4048 A64]))
                                (nil)))))))))
;;  succ:       6 [100.0%]  (FALLTHRU)
;; lr  out       15 [$15] 26 [$26] 29 [$29] 30 [$30] 31 [AP] 63 [FP]
;; live  out     15 [$15] 29 [$29] 30 [$30] 31 [AP] 63 [FP]

;; basic block 6, loop depth 0, count 0, freq 10000, maybe hot
;;  prev block 5, next block 7, flags: (REACHABLE, RTL, MODIFIED)
;;  pred:       2 [39.0%]
;;              5 [100.0%]  (FALLTHRU)
;; bb 6 artificial_defs: { }
;; bb 6 artificial_uses: { u-1(15){ }u-1(29){ }u-1(30){ }u-1(31){ }u-1(63){ }}
;; lr  in        15 [$15] 26 [$26] 29 [$29] 30 [$30] 31 [AP] 63 [FP]
;; lr  use       15 [$15] 29 [$29] 30 [$30] 31 [AP] 63 [FP]
;; lr  def       81
;; live  in      15 [$15] 29 [$29] 30 [$30] 31 [AP] 63 [FP]
;; live  gen     81
;; live  kill
(code_label/s 47 46 48 6 2 ("retaddr") [5 uses])
(note 48 47 49 6 [bb 6] NOTE_INSN_BASIC_BLOCK)
(insn 49 48 52 6 (set (reg:DI 81 [ <retval> ])
        (const_int 0 [0])) rr.go:57 236 {*movdi}
     (nil))

 succ:       8 [100.0%]  (FALLTHRU)

Unfortunatelly, this is not a robust approach, since in a follow-up
_.180r.fwprop1 pass (insn 49) propagates to function return value, leaving:

(code_label/s 47 46 48 6 2 ("retaddr") [5 uses])
(note 48 47 52 6 [bb 6] NOTE_INSN_BASIC_BLOCK)
;;  succ:       8 [100.0%]  (FALLTHRU)

The following 181r.cprop pass removes the label (also updates passed argument
to __go_set_defer_retaddr in (insn 7) and (insn 8)) and merges bb after a thunk
call:

(insn 7 3 8 2 (set (reg/f:DI 84)
        (high:DI (label_ref:DI [47 deleted]))) rr.go:57 236 {*movdi}
     (insn_list:REG_LABEL_OPERAND 47 (nil)))
(insn 8 7 9 2 (set (reg/f:DI 83)
        (lo_sum:DI (reg/f:DI 84)
            (label_ref:DI [47 deleted]))) rr.go:57 230 {*movdi_er_low_l}
     (expr_list:REG_DEAD (reg/f:DI 84)
        (insn_list:REG_LABEL_OPERAND 47 (expr_list:REG_EQUAL (label_ref:DI [47
deleted])
                (nil)))))

...

(call_insn 46 45 47 5 (parallel [
            (call (mem:DI (reg/f:DI 80 [ D.1014 ]) [0 *_42 S8 A64])
                (const_int 4048 [0xfd0]))
            (use (reg:DI 29 $29))
            (clobber (reg:DI 26 $26))
        ]) rr.go:57 210 {*call_osf_1_er}
     (expr_list:REG_DEAD (reg/f:DI 80 [ D.1014 ])
        (expr_list:REG_DEAD (reg:DI 21 $21)
            (expr_list:REG_DEAD (reg:DI 20 $20)
                (expr_list:REG_DEAD (reg:DI 19 $19)
                    (expr_list:REG_DEAD (reg:DI 18 $18)
                        (expr_list:REG_DEAD (reg:DI 17 $17)
                            (expr_list:REG_DEAD (reg:DI 16 $16)
                                (expr_list:REG_CALL_DECL (nil)
                                    (nil)))))))))
    (expr_list (use (reg:DI 21 $21))
        (expr_list (use (reg:DI 20 $20))
            (expr_list (use (reg:DI 19 $19))
                (expr_list (use (reg:DI 18 $18))
                    (expr_list (use (reg:DI 17 $17))
                        (expr_list (use (reg:DI 16 $16))
                            (expr_list:BLK (use (mem:BLK (reg/f:DI 30 $30) [0 
S4048 A64]))
                                (nil)))))))))
(note/s 47 46 52 5 ("retaddr") NOTE_INSN_DELETED_LABEL 2)
;;  succ:       8 [100.0%]  (FALLTHRU)

The missing label is substituted with a reference to some nearby label,
resulting in:

[+]     ldah $16,$L8($29)               !gprelhigh
        stq $26,4048($30)
        stq $9,4056($30)
[+]     lda $16,$L8($16)                !gprellow
        jsr $26,($27),__go_set_defer_retaddr            !lituse_jsr!22
...
$L10:
$L8:
        ldq $27,memcpy($29)             !literal!12
        lda $17,56($9)
        mov $30,$16
        lda $18,4048($31)
        jsr $26,($27),memcpy            !lituse_jsr!12
...
[++]    jsr $26,($27),0
        ldah $29,0($26)         !gpdisp!24
        lda $29,0($29)          !gpdisp!24
$L11:
        mov $31,$0


The [+] marks wrong label load and [++] marks thunk call. $L8 is an unrelated
label that gets loaded as an argument to __go_set_defer_retaddr.

Since $L8 is "far" away from thunk call, this fails the test in
__go_can_recover (runtime/go-recover.c):

  dret = (const char *) d->__retaddr;
  if (ret <= dret && ret + 16 >= dret)
    return 1;

Manually changing $L8 to $L11 in the call to __go_set_defer_retaddr (in an
assembly) results in a successful test.
>From gcc-bugs-return-457869-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Aug 06 13:00:36 2014
Return-Path: <gcc-bugs-return-457869-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 12678 invoked by alias); 6 Aug 2014 13:00:36 -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 12616 invoked by uid 48); 6 Aug 2014 13:00:29 -0000
From: "doko at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/62035] [4.9 Regresion] wrong code building libapache-mod-perl with -O1, works with -O1 -fno-tree-dse
Date: Wed, 06 Aug 2014 13:00: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: wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: doko at gcc dot gnu.org
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:
Message-ID: <bug-62035-4-gzVESarqGx@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-62035-4@http.gcc.gnu.org/bugzilla/>
References: <bug-62035-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-08/txt/msg00366.txt.bz2
Content-length: 157

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

--- Comment #1 from Matthias Klose <doko at gcc dot gnu.org> ---
seen with r213518 on the trunk as well

[Bug go/60874] FAIL: go.test/test/recover.go execution

[ubizjak at gmail dot com]

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

--- Comment #9 from Uroš Bizjak <ubizjak at gmail dot com> ---
To illustrate unreliable approach, please compile following test:

--cut here--
extern void foo (void *);

int test(void)
{
  __label__ bla;

  foo (&&bla);
 bla:
  return 0;
}
--cut here--

gcc -O2:

test:
.L2:
        pushl   %ebp
        movl    %esp, %ebp
        subl    $8, %esp
        movl    $.L2, (%esp)
        call    foo
        xorl    %eax, %eax
        leave
        ret

The passed argument doesn't represent return address.
>From gcc-bugs-return-457871-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Aug 06 13:11:31 2014
Return-Path: <gcc-bugs-return-457871-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 18464 invoked by alias); 6 Aug 2014 13:11:31 -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 18441 invoked by uid 48); 6 Aug 2014 13:11:28 -0000
From: "ktkachov at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/61749] arm_neon.h "_lane" and "_n" intrinsics can cause ICEs
Date: Wed, 06 Aug 2014 13:11:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 4.8.4
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: ktkachov at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: jgreenhalgh at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-61749-4-bMIzIDjcEH@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-61749-4@http.gcc.gnu.org/bugzilla/>
References: <bug-61749-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-08/txt/msg00368.txt.bz2
Content-length: 819

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

--- Comment #3 from ktkachov at gcc dot gnu.org ---
vqdmlal_lane_s16 expects an immediate/literal lane number as the fourth
argument and the builtin expansion code in aarch64-builtins.c is actually
equipped to error out when given a variable (in the SIMD_ARG_CONSTANT case of
aarch64_simd_expand_args).

However the type qualifiers for vqdmlal_lane_s16 are the QUADOP qualifiers
which don't enforce qualifier_immediate on the builtin, thus falling into the
SIMD_ARG_COPY_TO_REG and later on failing the CONST_INT_P assert when
processing the lane numbers.

If I give qualifier_immediate to the 4th argument I get a more helpful:
error: incompatible type for argument 4, expected 'const int'
message but the compiler still tries to proceed and ends up ICEing anyway.

[Bug go/60874] FAIL: go.test/test/recover.go execution

[schwab@linux-m68k.org]

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

--- Comment #10 from Andreas Schwab <schwab@linux-m68k.org> ---
If you never use goto *exp in the same function the value of &&label is
undefined.

[Bug go/60874] FAIL: go.test/test/recover.go execution

[ubizjak at gmail dot com]

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

--- Comment #11 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to Andreas Schwab from comment #10)
> If you never use goto *exp in the same function the value of &&label is
> undefined.

I did try adding goto bla: just before label, but never managed to get
something around return address. Care to post and example, please?
>From gcc-bugs-return-457874-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Aug 06 13:31:58 2014
Return-Path: <gcc-bugs-return-457874-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 1837 invoked by alias); 6 Aug 2014 13:31:58 -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 1800 invoked by uid 48); 6 Aug 2014 13:31:55 -0000
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/62035] [4.9/4.10 Regresion] wrong code building libapache-mod-perl with -O1, works with -O1 -fno-tree-dse
Date: Wed, 06 Aug 2014 13:31: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: wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenth at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.9.2
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: target_milestone
Message-ID: <bug-62035-4-LElgxy3Vdf@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-62035-4@http.gcc.gnu.org/bugzilla/>
References: <bug-62035-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-08/txt/msg00371.txt.bz2
Content-length: 294

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.9.2

[Bug go/60874] FAIL: go.test/test/recover.go execution

[ian at airs dot com]

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

--- Comment #12 from Ian Lance Taylor <ian at airs dot com> ---
Thanks for the analysis.  See also PR 60406.

Dominik sent me a patch for 60406 but 1) he has no copyright assignment; 2) I
think that his patch does not work for SJLJ exceptions.

[Bug go/60874] FAIL: go.test/test/recover.go execution

[ubizjak at gmail dot com]

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

Uroš Bizjak <ubizjak at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED
   Target Milestone|---                         |4.10.0

--- Comment #13 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to Ian Lance Taylor from comment #12)
> Thanks for the analysis.  See also PR 60406.
> 
> Dominik sent me a patch for 60406 but 1) he has no copyright assignment; 2)
> I think that his patch does not work for SJLJ exceptions.

Actually, this remaining problem is the same as PR60406.

The original problem is fixed.
>From gcc-bugs-return-457882-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Aug 06 14:19:58 2014
Return-Path: <gcc-bugs-return-457882-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 27504 invoked by alias); 6 Aug 2014 14:19:58 -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 27475 invoked by uid 48); 6 Aug 2014 14:19:54 -0000
From: "ubizjak at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug go/60406] reflect.go:test13reflect2 test failure
Date: Wed, 06 Aug 2014 14:19:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: go
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: ubizjak at gmail dot com
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: ian at airs dot com
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status cf_reconfirmed_on cc everconfirmed
Message-ID: <bug-60406-4-VkFAClZb4P@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-60406-4@http.gcc.gnu.org/bugzilla/>
References: <bug-60406-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-08/txt/msg00379.txt.bz2
Content-length: 672

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

Uroš Bizjak <ubizjak at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2014-08-06
                 CC|                            |ubizjak at gmail dot com
     Ever confirmed|0                           |1

--- Comment #1 from Uroš Bizjak <ubizjak at gmail dot com> ---
This problem also happens on alpha, please see analysis at [1].

[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60874#c8
>From gcc-bugs-return-457883-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Aug 06 14:39:29 2014
Return-Path: <gcc-bugs-return-457883-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 12355 invoked by alias); 6 Aug 2014 14:39:27 -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 12271 invoked by uid 48); 6 Aug 2014 14:39:16 -0000
From: "jgreenhalgh at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug regression/61510] [4.10 Regression]: 20_util/scoped_allocator/requirements/explicit_instantiation.cc and tr1/6_containers/tuple/requirements/explicit_instantiation.cc
Date: Wed, 06 Aug 2014 14:39:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: regression
X-Bugzilla-Version: 4.10.0
X-Bugzilla-Keywords: ice-on-valid-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jgreenhalgh at gcc dot gnu.org
X-Bugzilla-Status: WAITING
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.10.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cf_gcctarget bug_status
Message-ID: <bug-61510-4-Jjbm4AJqhK@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-61510-4@http.gcc.gnu.org/bugzilla/>
References: <bug-61510-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-08/txt/msg00380.txt.bz2
Content-length: 576

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

jgreenhalgh at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|cris-axis-elf,              |cris-axis-elf,
                   |arm-none-eabi,              |
                   |aarch64-none-elf            |
             Status|NEW                         |WAITING

--- Comment #7 from jgreenhalgh at gcc dot gnu.org ---
This is now fixed on aarch64 and arm. Hans, do you still see it on cris?

[Bug go/60874] FAIL: go.test/test/recover.go execution

[ubizjak at gmail dot com]

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

Uroš Bizjak <ubizjak at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.10.0                      |4.9.2
>From gcc-bugs-return-457910-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Aug 06 17:26:34 2014
Return-Path: <gcc-bugs-return-457910-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 7304 invoked by alias); 6 Aug 2014 17:26:33 -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 6221 invoked by uid 48); 6 Aug 2014 17:26:20 -0000
From: "glisse at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libstdc++/62039] New: concept checking for std::prev
Date: Wed, 06 Aug 2014 17:26: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.10.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: enhancement
X-Bugzilla-Who: glisse at gcc dot gnu.org
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
Message-ID: <bug-62039-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-08/txt/msg00407.txt.bz2
Content-length: 836

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

            Bug ID: 62039
           Summary: concept checking for std::prev
           Product: gcc
           Version: 4.10.0
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P3
         Component: libstdc++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: glisse at gcc dot gnu.org

Hello,

std::prev forwards to advance without any concept checking, and advance then
doesn't mind if the iterator is a forward iterator. I have seen several posts
on stackoverflow where people complained that the compiler didn't tell them how
silly their code was, and it would have been nice to be able to say: look, it
does if you ask nicely with -D_GLIBCXX_CONCEPT_CHECKS. Yes, I know those are
deprecated, feel free to close immediatly.