* [Bug target/65729] [5 Regression] ICE (in prohibited_class_reg_set_mode_p, at lra-constraints.c) on arm-linux-gnueabihf
2015-04-10 3:03 [Bug target/65729] New: [5 Regression] ICE (segfault) on arm-linux-gnueabihf doko at gcc dot gnu.org
@ 2015-04-10 7:07 ` jakub at gcc dot gnu.org
2015-04-10 7:47 ` rguenth at gcc dot gnu.org
` (10 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: jakub at gcc dot gnu.org @ 2015-04-10 7:07 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65729
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2015-04-10
CC| |jakub at gcc dot gnu.org,
| |vmakarov at gcc dot gnu.org
Target Milestone|--- |5.0
Ever confirmed|0 |1
--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Seems -march=armv7-a -mfloat-abi=hard -O2 is needed to trigger it.
Reduced testcase:
double
foo (void)
{
double x = 0.0;
asm volatile ("" : "+gw" (x));
return x;
}
Already ICEd back in February on the trunk (don't have older snapshots), and
4.9.0 20140401 doesn't ICE.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug target/65729] [5 Regression] ICE (in prohibited_class_reg_set_mode_p, at lra-constraints.c) on arm-linux-gnueabihf
2015-04-10 3:03 [Bug target/65729] New: [5 Regression] ICE (segfault) on arm-linux-gnueabihf doko at gcc dot gnu.org
2015-04-10 7:07 ` [Bug target/65729] [5 Regression] ICE (in prohibited_class_reg_set_mode_p, at lra-constraints.c) " jakub at gcc dot gnu.org
@ 2015-04-10 7:47 ` rguenth at gcc dot gnu.org
2015-04-10 9:04 ` jakub at gcc dot gnu.org
` (9 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: rguenth at gcc dot gnu.org @ 2015-04-10 7:47 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65729
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |ra
Priority|P3 |P1
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug target/65729] [5 Regression] ICE (in prohibited_class_reg_set_mode_p, at lra-constraints.c) on arm-linux-gnueabihf
2015-04-10 3:03 [Bug target/65729] New: [5 Regression] ICE (segfault) on arm-linux-gnueabihf doko at gcc dot gnu.org
2015-04-10 7:07 ` [Bug target/65729] [5 Regression] ICE (in prohibited_class_reg_set_mode_p, at lra-constraints.c) " jakub at gcc dot gnu.org
2015-04-10 7:47 ` rguenth at gcc dot gnu.org
@ 2015-04-10 9:04 ` jakub at gcc dot gnu.org
2015-04-10 9:20 ` ktkachov at gcc dot gnu.org
` (8 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: jakub at gcc dot gnu.org @ 2015-04-10 9:04 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65729
--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Seems the ICE or successful compilation aren't the only thing gcc used to
produce here:
old - r218687 ok
r218688 - r218759 error: inconsistent operand constraints in an ‘asm’
r218760 - r220293 ok
r220294 - latest internal compiler error: in prohibited_class_reg_set_mode_p,
at lra-constraints.c
>From gcc-bugs-return-483260-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Apr 10 09:04:20 2015
Return-Path: <gcc-bugs-return-483260-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 110008 invoked by alias); 10 Apr 2015 09:04:19 -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 107718 invoked by uid 48); 10 Apr 2015 09:04:15 -0000
From: "mpolacek at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/65727] [4.8/4.9/5 Regression] Segfault With Decltype In Lambda Expression Used To Initialize Static Class Member
Date: Fri, 10 Apr 2015 09:04: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.8.2
X-Bugzilla-Keywords: ice-on-valid-code
X-Bugzilla-Severity: major
X-Bugzilla-Who: mpolacek at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.8.5
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-65727-4-kjxR0i1rkJ@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-65727-4@http.gcc.gnu.org/bugzilla/>
References: <bug-65727-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: 2015-04/txt/msg00812.txt.bz2
Content-length: 1435
https://gcc.gnu.org/bugzilla/show_bug.cgi?ide727
--- Comment #2 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Here, we're trying to build_x_indirect_ref for a NULL pointer, that is bad.
The reason is that here
787 /* In a lambda, need to go through 'this' capture. */
788 tree lam = CLASSTYPE_LAMBDA_EXPR (current_class_type);
789 tree cap = lambda_expr_this_capture (lam, add_capture_p);
790 if (cap != error_mark_node)
791 object = build_x_indirect_ref (EXPR_LOCATION (object), cap,
792 RO_NULL, tf_warning_or_error);
lambda_expr_this_capture returns NULL: it's looking for 'this', but doesn't
find it.
The fix in r215478 [1] dealt with not finding 'this' by checking for
error_mark, but perhaps we should also check whether the capture is non-NULL:
--- a/gcc/cp/lambda.c
+++ b/gcc/cp/lambda.c
@@ -787,7 +787,7 @@ maybe_resolve_dummy (tree object, bool add_capture_p)
/* In a lambda, need to go through 'this' capture. */
tree lam = CLASSTYPE_LAMBDA_EXPR (current_class_type);
tree cap = lambda_expr_this_capture (lam, add_capture_p);
- if (cap != error_mark_node)
+ if (cap && cap != error_mark_node)
object = build_x_indirect_ref (EXPR_LOCATION (object), cap,
RO_NULL, tf_warning_or_error);
}
[1] https://gcc.gnu.org/ml/gcc-patches/2014-09/msg01878.html
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug target/65729] [5 Regression] ICE (in prohibited_class_reg_set_mode_p, at lra-constraints.c) on arm-linux-gnueabihf
2015-04-10 3:03 [Bug target/65729] New: [5 Regression] ICE (segfault) on arm-linux-gnueabihf doko at gcc dot gnu.org
` (2 preceding siblings ...)
2015-04-10 9:04 ` jakub at gcc dot gnu.org
@ 2015-04-10 9:20 ` ktkachov at gcc dot gnu.org
2015-04-10 15:49 ` vmakarov at gcc dot gnu.org
` (7 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: ktkachov at gcc dot gnu.org @ 2015-04-10 9:20 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65729
ktkachov at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |ktkachov at gcc dot gnu.org
--- Comment #3 from ktkachov at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #1)
> Seems -march=armv7-a -mfloat-abi=hard -O2 is needed to trigger it.
-mfpu=vfpv3-d16 is also needed
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug target/65729] [5 Regression] ICE (in prohibited_class_reg_set_mode_p, at lra-constraints.c) on arm-linux-gnueabihf
2015-04-10 3:03 [Bug target/65729] New: [5 Regression] ICE (segfault) on arm-linux-gnueabihf doko at gcc dot gnu.org
` (3 preceding siblings ...)
2015-04-10 9:20 ` ktkachov at gcc dot gnu.org
@ 2015-04-10 15:49 ` vmakarov at gcc dot gnu.org
2015-04-10 15:53 ` jakub at gcc dot gnu.org
` (6 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: vmakarov at gcc dot gnu.org @ 2015-04-10 15:49 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65729
--- Comment #5 from Vladimir Makarov <vmakarov at gcc dot gnu.org> ---
(In reply to Yvan Roux from comment #4)
> For me the assertion in prohibited_class_reg_set_mode_p is not right, it
> checks that set is a subset of reg_class_contents[rclass] and my
> understanding is that it should be the opposite:
>
> lra_assert (hard_reg_set_subset_p (reg_class_contents[rclass],set));
>
> With this modification the test is fixed (full validation is ongoing).
>
> Do I miss something Vlad ?
After some investigation done, I believe you are right, Yvan.
this_alternative_set is always not smaller than contents of this_alternative as
we use reg_class_subunion. So you can submit your patch with swapping
arguments in the assert call, of course after testing on x86-64 at least. I am
approving the patch. If you don't respond it in a few hours, I'll do it
myself. Thanks.
By the way, it is a bad practice for RA not define classes which are union of
classes can be used for the same operand. In this case, we could use
GENERAL_REGS or VFP_LO_REGS but only VFP_LO_REGS will be used only as it is a
result of reg_class_subunion[GENERAL_REGS][VFP_LO_REGS]. But fixing it is not
a task for GCC-5.0 as we are at the very end of creation of a new release.
Fixing RA bugs has a big chance introducing new ones until it is stabilized.
This is a situation what we actually see now.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug target/65729] [5 Regression] ICE (in prohibited_class_reg_set_mode_p, at lra-constraints.c) on arm-linux-gnueabihf
2015-04-10 3:03 [Bug target/65729] New: [5 Regression] ICE (segfault) on arm-linux-gnueabihf doko at gcc dot gnu.org
` (4 preceding siblings ...)
2015-04-10 15:49 ` vmakarov at gcc dot gnu.org
@ 2015-04-10 15:53 ` jakub at gcc dot gnu.org
2015-04-10 16:03 ` yroux at gcc dot gnu.org
` (5 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: jakub at gcc dot gnu.org @ 2015-04-10 15:53 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65729
--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Vladimir Makarov from comment #5)
> (In reply to Yvan Roux from comment #4)
> > For me the assertion in prohibited_class_reg_set_mode_p is not right, it
> > checks that set is a subset of reg_class_contents[rclass] and my
> > understanding is that it should be the opposite:
> >
> > lra_assert (hard_reg_set_subset_p (reg_class_contents[rclass],set));
> >
> > With this modification the test is fixed (full validation is ongoing).
> >
> > Do I miss something Vlad ?
>
> After some investigation done, I believe you are right, Yvan.
> this_alternative_set is always not smaller than contents of this_alternative
> as we use reg_class_subunion. So you can submit your patch with swapping
> arguments in the assert call, of course after testing on x86-64 at least. I
> am approving the patch. If you don't respond it in a few hours, I'll do it
> myself. Thanks.
>
> By the way, it is a bad practice for RA not define classes which are union
> of classes can be used for the same operand. In this case, we could use
> GENERAL_REGS or VFP_LO_REGS but only VFP_LO_REGS will be used only as it is
> a result of reg_class_subunion[GENERAL_REGS][VFP_LO_REGS]. But fixing it is
> not a task for GCC-5.0 as we are at the very end of creation of a new
> release. Fixing RA bugs has a big chance introducing new ones until it is
> stabilized. This is a situation what we actually see now.
So, could we perhaps just comment out the lra_assert for GCC 5.1 release, then
when stage1 reopens test the other order and if it works everywhere, after a
few weeks backport that to the branch? Not that it is very important, because
the release will be --enable-checking=release for most users and thus the
assert will be ignored anyway.
Just commenting out the assert means that no further testing is needed on it
right now, the patch would be obvious...
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug target/65729] [5 Regression] ICE (in prohibited_class_reg_set_mode_p, at lra-constraints.c) on arm-linux-gnueabihf
2015-04-10 3:03 [Bug target/65729] New: [5 Regression] ICE (segfault) on arm-linux-gnueabihf doko at gcc dot gnu.org
` (5 preceding siblings ...)
2015-04-10 15:53 ` jakub at gcc dot gnu.org
@ 2015-04-10 16:03 ` yroux at gcc dot gnu.org
2015-04-10 16:06 ` vmakarov at gcc dot gnu.org
` (4 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: yroux at gcc dot gnu.org @ 2015-04-10 16:03 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65729
--- Comment #7 from Yvan Roux <yroux at gcc dot gnu.org> ---
k, my validation is ok. I'll be off during ~3h and will submit it when I'm back
(or the assertion commenting patch) if it's better for 5.1
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug target/65729] [5 Regression] ICE (in prohibited_class_reg_set_mode_p, at lra-constraints.c) on arm-linux-gnueabihf
2015-04-10 3:03 [Bug target/65729] New: [5 Regression] ICE (segfault) on arm-linux-gnueabihf doko at gcc dot gnu.org
` (6 preceding siblings ...)
2015-04-10 16:03 ` yroux at gcc dot gnu.org
@ 2015-04-10 16:06 ` vmakarov at gcc dot gnu.org
2015-04-10 16:08 ` [Bug target/65729] [5/6 " jakub at gcc dot gnu.org
` (3 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: vmakarov at gcc dot gnu.org @ 2015-04-10 16:06 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65729
--- Comment #8 from Vladimir Makarov <vmakarov at gcc dot gnu.org> ---
Author: vmakarov
Date: Fri Apr 10 16:05:26 2015
New Revision: 221975
URL: https://gcc.gnu.org/viewcvs?rev=221975&root=gcc&view=rev
Log:
2015-04-10 Vladimir Makarov <vmakarov@redhat.com>
PR target/65729
* lra-constraints.c (prohibited_class_reg_set_mode_p): Comment the
assert.
Modified:
trunk/gcc/ChangeLog
trunk/gcc/lra-constraints.c
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug target/65729] [5/6 Regression] ICE (in prohibited_class_reg_set_mode_p, at lra-constraints.c) on arm-linux-gnueabihf
2015-04-10 3:03 [Bug target/65729] New: [5 Regression] ICE (segfault) on arm-linux-gnueabihf doko at gcc dot gnu.org
` (7 preceding siblings ...)
2015-04-10 16:06 ` vmakarov at gcc dot gnu.org
@ 2015-04-10 16:08 ` jakub at gcc dot gnu.org
2015-04-10 16:13 ` [Bug target/65729] [5 " vmakarov at gcc dot gnu.org
` (2 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: jakub at gcc dot gnu.org @ 2015-04-10 16:08 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65729
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Priority|P1 |P3
Target Milestone|5.0 |6.0
Summary|[5 Regression] ICE (in |[5/6 Regression] ICE (in
|prohibited_class_reg_set_mo |prohibited_class_reg_set_mo
|de_p, at lra-constraints.c) |de_p, at lra-constraints.c)
|on arm-linux-gnueabihf |on arm-linux-gnueabihf
--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
No longer a GCC 5.1 blocker with the assert commented out.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug target/65729] [5 Regression] ICE (in prohibited_class_reg_set_mode_p, at lra-constraints.c) on arm-linux-gnueabihf
2015-04-10 3:03 [Bug target/65729] New: [5 Regression] ICE (segfault) on arm-linux-gnueabihf doko at gcc dot gnu.org
` (8 preceding siblings ...)
2015-04-10 16:08 ` [Bug target/65729] [5/6 " jakub at gcc dot gnu.org
@ 2015-04-10 16:13 ` vmakarov at gcc dot gnu.org
2015-04-10 16:43 ` [Bug target/65729] [5/6 " jakub at gcc dot gnu.org
2015-04-15 13:07 ` yroux at gcc dot gnu.org
11 siblings, 0 replies; 13+ messages in thread
From: vmakarov at gcc dot gnu.org @ 2015-04-10 16:13 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65729
Vladimir Makarov <vmakarov at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Priority|P3 |P1
Target Milestone|6.0 |5.0
Summary|[5/6 Regression] ICE (in |[5 Regression] ICE (in
|prohibited_class_reg_set_mo |prohibited_class_reg_set_mo
|de_p, at lra-constraints.c) |de_p, at lra-constraints.c)
|on arm-linux-gnueabihf |on arm-linux-gnueabihf
--- Comment #10 from Vladimir Makarov <vmakarov at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #6)
> (In reply to Vladimir Makarov from comment #5)
> > (In reply to Yvan Roux from comment #4)
> > > For me the assertion in prohibited_class_reg_set_mode_p is not right, it
> > > checks that set is a subset of reg_class_contents[rclass] and my
> > > understanding is that it should be the opposite:
> > >
> > > lra_assert (hard_reg_set_subset_p (reg_class_contents[rclass],set));
> > >
> > > With this modification the test is fixed (full validation is ongoing).
> > >
> > > Do I miss something Vlad ?
> >
> > After some investigation done, I believe you are right, Yvan.
> > this_alternative_set is always not smaller than contents of this_alternative
> > as we use reg_class_subunion. So you can submit your patch with swapping
> > arguments in the assert call, of course after testing on x86-64 at least. I
> > am approving the patch. If you don't respond it in a few hours, I'll do it
> > myself. Thanks.
> >
> > By the way, it is a bad practice for RA not define classes which are union
> > of classes can be used for the same operand. In this case, we could use
> > GENERAL_REGS or VFP_LO_REGS but only VFP_LO_REGS will be used only as it is
> > a result of reg_class_subunion[GENERAL_REGS][VFP_LO_REGS]. But fixing it is
> > not a task for GCC-5.0 as we are at the very end of creation of a new
> > release. Fixing RA bugs has a big chance introducing new ones until it is
> > stabilized. This is a situation what we actually see now.
>
> So, could we perhaps just comment out the lra_assert for GCC 5.1 release,
> then when stage1 reopens test the other order and if it works everywhere,
> after a few weeks backport that to the branch? Not that it is very
> important, because the release will be --enable-checking=release for most
> users and thus the assert will be ignored anyway.
> Just commenting out the assert means that no further testing is needed on it
> right now, the patch would be obvious...
OK. I'll do it. As I understand
(In reply to Yvan Roux from comment #7)
> k, my validation is ok. I'll be off during ~3h and will submit it when I'm
> back (or the assertion commenting patch) if it's better for 5.1
I've just commented the assert. We will fix it for 5.1.
So, Jakub, I did what you asked as it is important for your work on release
candidate.
Although I'd like to work on PR65710 but I am not sure it will be fixed soon as
it is a performance bug now and will take at least a few days to fix it. So
the PR65710 is also work for 5.1.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug target/65729] [5/6 Regression] ICE (in prohibited_class_reg_set_mode_p, at lra-constraints.c) on arm-linux-gnueabihf
2015-04-10 3:03 [Bug target/65729] New: [5 Regression] ICE (segfault) on arm-linux-gnueabihf doko at gcc dot gnu.org
` (9 preceding siblings ...)
2015-04-10 16:13 ` [Bug target/65729] [5 " vmakarov at gcc dot gnu.org
@ 2015-04-10 16:43 ` jakub at gcc dot gnu.org
2015-04-15 13:07 ` yroux at gcc dot gnu.org
11 siblings, 0 replies; 13+ messages in thread
From: jakub at gcc dot gnu.org @ 2015-04-10 16:43 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65729
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|5.0 |6.0
Summary|[5 Regression] ICE (in |[5/6 Regression] ICE (in
|prohibited_class_reg_set_mo |prohibited_class_reg_set_mo
|de_p, at lra-constraints.c) |de_p, at lra-constraints.c)
|on arm-linux-gnueabihf |on arm-linux-gnueabihf
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug target/65729] [5/6 Regression] ICE (in prohibited_class_reg_set_mode_p, at lra-constraints.c) on arm-linux-gnueabihf
2015-04-10 3:03 [Bug target/65729] New: [5 Regression] ICE (segfault) on arm-linux-gnueabihf doko at gcc dot gnu.org
` (10 preceding siblings ...)
2015-04-10 16:43 ` [Bug target/65729] [5/6 " jakub at gcc dot gnu.org
@ 2015-04-15 13:07 ` yroux at gcc dot gnu.org
11 siblings, 0 replies; 13+ messages in thread
From: yroux at gcc dot gnu.org @ 2015-04-15 13:07 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65729
Yvan Roux <yroux at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |FIXED
Assignee|unassigned at gcc dot gnu.org |yroux at gcc dot gnu.org
--- Comment #12 from Yvan Roux <yroux at gcc dot gnu.org> ---
Now fixed.
^ permalink raw reply [flat|nested] 13+ messages in thread