* [Bug go/60874] FAIL: go.test/test/recover.go execution
2014-04-17 18:14 [Bug go/60874] New: FAIL: go.test/test/recover.go execution ubizjak at gmail dot com
@ 2014-07-20 8:27 ` ubizjak at gmail dot com
2014-07-20 9:12 ` ian at airs dot com
` (11 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: ubizjak at gmail dot com @ 2014-07-20 8:27 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug go/60874] FAIL: go.test/test/recover.go execution
2014-04-17 18:14 [Bug go/60874] New: FAIL: go.test/test/recover.go execution ubizjak at gmail dot com
2014-07-20 8:27 ` [Bug go/60874] " ubizjak at gmail dot com
@ 2014-07-20 9:12 ` ian at airs dot com
2014-07-21 12:31 ` ubizjak at gmail dot com
` (10 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: ian at airs dot com @ 2014-07-20 9:12 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug go/60874] FAIL: go.test/test/recover.go execution
2014-04-17 18:14 [Bug go/60874] New: FAIL: go.test/test/recover.go execution ubizjak at gmail dot com
2014-07-20 8:27 ` [Bug go/60874] " ubizjak at gmail dot com
2014-07-20 9:12 ` ian at airs dot com
@ 2014-07-21 12:31 ` ubizjak at gmail dot com
2014-07-21 14:35 ` ubizjak at gmail dot com
` (9 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: ubizjak at gmail dot com @ 2014-07-21 12:31 UTC (permalink / raw)
To: gcc-bugs
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)
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug go/60874] FAIL: go.test/test/recover.go execution
2014-04-17 18:14 [Bug go/60874] New: FAIL: go.test/test/recover.go execution ubizjak at gmail dot com
` (2 preceding siblings ...)
2014-07-21 12:31 ` ubizjak at gmail dot com
@ 2014-07-21 14:35 ` ubizjak at gmail dot com
2014-08-05 14:09 ` ian at airs dot com
` (8 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: ubizjak at gmail dot com @ 2014-07-21 14:35 UTC (permalink / raw)
To: gcc-bugs
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--
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug go/60874] FAIL: go.test/test/recover.go execution
2014-04-17 18:14 [Bug go/60874] New: FAIL: go.test/test/recover.go execution ubizjak at gmail dot com
` (3 preceding siblings ...)
2014-07-21 14:35 ` ubizjak at gmail dot com
@ 2014-08-05 14:09 ` ian at airs dot com
2014-08-05 14:14 ` ubizjak at gmail dot com
` (7 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: ian at airs dot com @ 2014-08-05 14:09 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug go/60874] FAIL: go.test/test/recover.go execution
2014-04-17 18:14 [Bug go/60874] New: FAIL: go.test/test/recover.go execution ubizjak at gmail dot com
` (4 preceding siblings ...)
2014-08-05 14:09 ` ian at airs dot com
@ 2014-08-05 14:14 ` ubizjak at gmail dot com
2014-08-06 13:00 ` ubizjak at gmail dot com
` (6 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: ubizjak at gmail dot com @ 2014-08-05 14:14 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug go/60874] FAIL: go.test/test/recover.go execution
2014-04-17 18:14 [Bug go/60874] New: FAIL: go.test/test/recover.go execution ubizjak at gmail dot com
` (5 preceding siblings ...)
2014-08-05 14:14 ` ubizjak at gmail dot com
@ 2014-08-06 13:00 ` ubizjak at gmail dot com
2014-08-06 13:03 ` ubizjak at gmail dot com
` (5 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: ubizjak at gmail dot com @ 2014-08-06 13:00 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug go/60874] FAIL: go.test/test/recover.go execution
2014-04-17 18:14 [Bug go/60874] New: FAIL: go.test/test/recover.go execution ubizjak at gmail dot com
` (6 preceding siblings ...)
2014-08-06 13:00 ` ubizjak at gmail dot com
@ 2014-08-06 13:03 ` ubizjak at gmail dot com
2014-08-06 13:12 ` schwab@linux-m68k.org
` (4 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: ubizjak at gmail dot com @ 2014-08-06 13:03 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug go/60874] FAIL: go.test/test/recover.go execution
2014-04-17 18:14 [Bug go/60874] New: FAIL: go.test/test/recover.go execution ubizjak at gmail dot com
` (7 preceding siblings ...)
2014-08-06 13:03 ` ubizjak at gmail dot com
@ 2014-08-06 13:12 ` schwab@linux-m68k.org
2014-08-06 13:27 ` ubizjak at gmail dot com
` (3 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: schwab@linux-m68k.org @ 2014-08-06 13:12 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug go/60874] FAIL: go.test/test/recover.go execution
2014-04-17 18:14 [Bug go/60874] New: FAIL: go.test/test/recover.go execution ubizjak at gmail dot com
` (8 preceding siblings ...)
2014-08-06 13:12 ` schwab@linux-m68k.org
@ 2014-08-06 13:27 ` ubizjak at gmail dot com
2014-08-06 13:56 ` ian at airs dot com
` (2 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: ubizjak at gmail dot com @ 2014-08-06 13:27 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug go/60874] FAIL: go.test/test/recover.go execution
2014-04-17 18:14 [Bug go/60874] New: FAIL: go.test/test/recover.go execution ubizjak at gmail dot com
` (9 preceding siblings ...)
2014-08-06 13:27 ` ubizjak at gmail dot com
@ 2014-08-06 13:56 ` ian at airs dot com
2014-08-06 14:17 ` ubizjak at gmail dot com
2014-08-06 17:16 ` ubizjak at gmail dot com
12 siblings, 0 replies; 14+ messages in thread
From: ian at airs dot com @ 2014-08-06 13:56 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug go/60874] FAIL: go.test/test/recover.go execution
2014-04-17 18:14 [Bug go/60874] New: FAIL: go.test/test/recover.go execution ubizjak at gmail dot com
` (10 preceding siblings ...)
2014-08-06 13:56 ` ian at airs dot com
@ 2014-08-06 14:17 ` ubizjak at gmail dot com
2014-08-06 17:16 ` ubizjak at gmail dot com
12 siblings, 0 replies; 14+ messages in thread
From: ubizjak at gmail dot com @ 2014-08-06 14:17 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug go/60874] FAIL: go.test/test/recover.go execution
2014-04-17 18:14 [Bug go/60874] New: FAIL: go.test/test/recover.go execution ubizjak at gmail dot com
` (11 preceding siblings ...)
2014-08-06 14:17 ` ubizjak at gmail dot com
@ 2014-08-06 17:16 ` ubizjak at gmail dot com
12 siblings, 0 replies; 14+ messages in thread
From: ubizjak at gmail dot com @ 2014-08-06 17:16 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 14+ messages in thread