https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67324
Bug ID: 67324
Summary: Failures in Assignable concept's requires-expression
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: webrown.cpp at gmail dot com
Target Milestone: ---
Created attachment 36243
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36243&action=edit
Test for Assignable concept
Using g++-mp-6 (MacPorts gcc6 6-20150816_0) 6.0.0 20150816 (experimental), I
have been experimenting with the Assignable concept as defined in a very recent
draft of the Ranges proposal. I am experiencing several kinds of failures,
demonstrable via the attached self-contained program. I compile with options
-Og -std=c++1z plus a host of warning-enabling options.
Please note, in the Assignable concept definition, lines annotated #1 and #2.
Line #1 corresponds to the draft's definition; line #2 is a variant formulation
of that definition. There are no compilation diagnostics except as follows:
When line #1 is uncommented, all the affirmatively-phrased static_asserts fail.
When line #2 is uncommented instead, only the last static_assert (involving
struct F) fires.
I believe none of these asserts should fail in either case.
When I remove the entire requires expression and replace it with a
corresponding expression using the detection idiom (per N4502), none of the
static_asserts fail.
I have consulted with both Eric Niebler and Andrew Sutton re these
observations; they agree this is unexpected behavior. Eric commented that the
placeholder constraint in #1 "is only partially implemented in gcc." Andrew
commented, "I wonder if there's not a deeper bug. I plugged something similar
into origin and it broke completely unrelated test cases."
At the moment, this is a complete show-stopper for me.
