[Bug c++/53000] New: Trinary operator does not behave as standardized

[Bug c++/53000] New: Trinary operator does not behave as standardized

[gcc-bugs at quasiparticle dot net]

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

             Bug #: 53000
           Summary: Trinary operator does not behave as standardized
    Classification: Unclassified
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: gcc-bugs@quasiparticle.net


The conditional operator as implemented in g++ from 4.7.0 (at least) onwards
does not behave as required by [expr.cond]p3 of the C++11 spec.

Given an expression "B ? E1 : E2", the result of the expression is required to
be an xvalue if E2 is an xvalue and E1 can be converted to T2&&. With E1 and E2
both being declval<int>(), the result should then be of type int&&, while g++
currently generates a plain int there.

Curiosly, this hides an oversight described in DR2141 [1], which reports the
common_type<T, U> trait as being defective. As soon as "true ? declval<int>() :
declval<int>()" yields int&& as required, common_type<int, int>::type of
libstdc++ will be int&& (is int right now). This will break <chrono> badly, as
experienced by clang++.


[1] http://cplusplus.github.com/LWG/lwg-active.html#2141

[Bug c++/53000] Conditional operator does not behave as standardized

[ismail at namtrac dot org]

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

--- Comment #1 from İsmail "cartman" Dönmez <ismail at namtrac dot org> 2012-04-24 14:32:34 UTC ---
clang people have the following patch proposed as a workaround to this issue:
http://llvm.org/viewvc/llvm-project/cfe/trunk/www/libstdc%2B%2B4.7-clang11.patch?revision=154890&content-type=text%2Fplain&pathrev=154890

[Bug c++/53000] Conditional operator does not behave as standardized

[redi at gcc dot gnu.org]

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

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2012-04-24
     Ever Confirmed|0                           |1

--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-04-24 14:47:49 UTC ---
Confirmed.

I suppose we could make the libstdc++ change now rather than waiting for the FE
fix, as it shouldn't change the current behaviour of the library.

[Bug c++/53000] Conditional operator does not behave as standardized

[marc.glisse at normalesup dot org]

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

Marc Glisse <marc.glisse at normalesup dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |marc.glisse at normalesup
                   |                            |dot org

--- Comment #3 from Marc Glisse <marc.glisse at normalesup dot org> 2012-04-24 19:31:52 UTC ---
(In reply to comment #2)
> Confirmed.
> 
> I suppose we could make the libstdc++ change now rather than waiting for the FE
> fix, as it shouldn't change the current behaviour of the library.

It doesn't seem completely obvious to me that this is the right library fix.
What happens if instead of the standard declval you use the trivial version?

  template<typename _Tp> _Tp __declval2() noexcept;

(except for the obvious problem with indestructible types, but then the decay
version may give you an answer that isn't constructible from the input for
references to a non-copyable type, so that's fair)

Rereading the DR, it appears that some people actually want to decay
independently from this rvalue issue, which is quite a strong change. And after
all, people can use decay<common_type>, but if decay is included in
common_type, it can't be undone.

Although now that I think as a library writer who has to specialize common_type
for some of his types, I don't really want to specialize it for all cv-ref
variants of my types, so I'd actually like the default common_type to decay not
only the result, but also its arguments! And while we are at it, it could even
try canonicalizing them, like operator auto().

Hmm, I guess you can forget this rant and go ahead (I am still posting it
because there may be real arguments somewhere).

[Bug c++/53000] Conditional operator does not behave as standardized

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-04-24 21:48:22 UTC ---
(In reply to comment #3)
> Hmm, I guess you can forget this rant and go ahead (I am still posting it
> because there may be real arguments somewhere).

:)  Thanks for the comments, it's not obvious to me what the right fix is
either so I'm not in a rush to change anything.

[Bug c++/53000] Conditional operator does not behave as standardized

[marc.glisse at normalesup dot org]

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

--- Comment #5 from Marc Glisse <marc.glisse at normalesup dot org> 2012-04-24 22:35:31 UTC ---
(In reply to comment #4)
> it's not obvious to me what the right fix is
> either so I'm not in a rush to change anything.

Actually, I now believe it is a good idea to rush (well, maybe not quite) the
change:
- it is needed by clang,
- it gives users an opportunity to complain against the proposed resolution (if
they don't, it is an argument in favor of it),
- it removes an excuse not to fix ?: with xvalues.

I think I've canceled my comment #3 enough that we are back to your comment #2
where you were proposing to make the change ;-)

[Bug c++/53000] Conditional operator does not behave as standardized

[pinskia at gcc dot gnu.org]

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

--- Comment #6 from Andrew Pinski <pinskia at gcc dot gnu.org> 2012-04-24 22:45:54 UTC ---
A good question from an semi outsider, which way is the standards committee
leaning?  And is there a big disagreement about the defect report?  I think if
there is a disagreement, then we should move slower but if there is a good
consensus of how they want to fix the standard, then we should move towards
that direction as fast as possible.

[Bug c++/53000] Conditional operator does not behave as standardized

[marc.glisse at normalesup dot org]

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

--- Comment #7 from Marc Glisse <marc.glisse at normalesup dot org> 2012-04-24 23:23:09 UTC ---
(In reply to comment #6)
> which way is the standards committee leaning?

The DR is young, there hasn't been a meeting since. There weren't many
objections to the proposed resolution, although it did seem strange to some
that common_type<int&,int&>::type would be int and not int&. I am too new to
the process to say more...

(I guess the proposed resolution should make the one-argument version of
common_type equivalent to decay, to be consistent)

[Bug c++/53000] Conditional operator does not behave as standardized

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |zeratul976 at hotmail dot
                   |                            |com

--- Comment #8 from Andrew Pinski <pinskia at gcc dot gnu.org> 2012-04-28 03:47:51 UTC ---
*** Bug 53151 has been marked as a duplicate of this bug. ***

[Bug c++/53000] Conditional operator does not behave as standardized

[ismail at namtrac dot org]

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

--- Comment #9 from İsmail "cartman" Dönmez <ismail at namtrac dot org> 2012-05-20 14:50:46 UTC ---
ping?

[Bug c++/53000] Conditional operator does not behave as standardized

[paolo.carlini at oracle dot com]

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

--- Comment #10 from Paolo Carlini <paolo.carlini at oracle dot com> 2012-10-04 15:57:07 UTC ---
*** Bug 54101 has been marked as a duplicate of this bug. ***

[Bug c++/53000] Conditional operator does not behave as standardized

[paolo.carlini at oracle dot com]

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

Paolo Carlini <paolo.carlini at oracle dot com> changed:

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

--- Comment #11 from Paolo Carlini <paolo.carlini at oracle dot com> 2012-10-10 09:54:28 UTC ---
Thus, the library bits are done in mainline, right Daniel?

Let's add Jason in CC about the C++ issue, it seems rather serious.

[Bug c++/53000] Conditional operator does not behave as standardized

[glisse at gcc dot gnu.org]

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

Marc Glisse <glisse at gcc dot gnu.org> changed:

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

--- Comment #12 from Marc Glisse <glisse at gcc dot gnu.org> 2012-10-10 10:27:39 UTC ---
(In reply to comment #11)
> Thus, the library bits are done in mainline, right Daniel?

So we now have:

common_type<const int&>::type -> const int&
common_type<const int&,const int&>::type -> int

?

If we are going with this resolution, I think the 1 argument version should
derive from decay.

[Bug c++/53000] Conditional operator does not behave as standardized

[daniel.kruegler at googlemail dot com]

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

--- Comment #13 from Daniel Krügler <daniel.kruegler at googlemail dot com> 2012-10-10 10:42:20 UTC ---
(In reply to comment #11)
> Thus, the library bits are done in mainline, right Daniel?

In regard to std::common_type, yes. But while making std::common_type
sfinae-friendly I searched for common_type in other tests and found at least
one test that locally defines a dual common_type and as far as I remember it
the test assumption was wrong. I cannot test it from here but I believe it was
something that effectively tested the common type of int and const int and the
decltype result was assumed to be int (instead of const int&&). Could someone
check on this one or I will do that this evening?

[Bug c++/53000] Conditional operator does not behave as standardized

[paolo.carlini at oracle dot com]

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

--- Comment #14 from Paolo Carlini <paolo.carlini at oracle dot com> 2012-10-10 10:43:22 UTC ---
Why you believe it should "derive" from decay? It doesn't in C++11 and it
doesn't in the proposed resolution of LWG 2141.

Anyway, if you think there is something seriously wrong ;) with Daniel's work,
please comment on the patch as posted on mailing list, CC Daniel of course,
this PR per se is about the C++ front-end issue.

[Bug c++/53000] Conditional operator does not behave as standardized

[paolo.carlini at oracle dot com]

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

--- Comment #15 from Paolo Carlini <paolo.carlini at oracle dot com> 2012-10-10 10:44:57 UTC ---
Daniel: yes, please, if you could take care of that it would be great.

[Bug c++/53000] Conditional operator does not behave as standardized

[daniel.kruegler at googlemail dot com]

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

--- Comment #16 from Daniel Krügler <daniel.kruegler at googlemail dot com> 2012-10-10 10:55:02 UTC ---
(In reply to comment #12)
> So we now have:
> 
> common_type<const int&>::type -> const int&
> common_type<const int&,const int&>::type -> int
> 
> ?
> 
> If we are going with this resolution, I think the 1 argument version should
> derive from decay.

I noticed the same problem recently, when playing around with a variadic
make_array function (search in the test-suite for it once Paolo has committed
my recent changes to the main line). The problem is now that common_type is now
dependent on the size of the variadic argument expansion. Personally I feel
uncertain what the best approach would be: Declaring LWG 2141 as NAD (and fix
the affected other places in the library, which at least unique_ptr's
comparison functions), or add decay to the unary form or finally keeping the
P/R. I'm in the process of sending a message to the LWG group with the
make_array as an example to make LWG of this problem aware. I have no problem
to accept that we undo the 2141 application in the library, if this is what you
would like to see for the moment. This is also a message to the committee.

[Bug c++/53000] Conditional operator does not behave as standardized

[paolo.carlini at oracle dot com]

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

--- Comment #17 from Paolo Carlini <paolo.carlini at oracle dot com> 2012-10-10 11:01:59 UTC ---
The patch is already in, of course. In hindsight, I think we shouldn't have
bundled the SFINAE bits with addressing LWG 2141, which, I realize now, is
still in flux. At least we should have discussed that.

For now, I would recommend reverting the changes related to LWG 2141.

[Bug c++/53000] Conditional operator does not behave as standardized

[daniel.kruegler at googlemail dot com]

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

--- Comment #18 from Daniel Krügler <daniel.kruegler at googlemail dot com> 2012-10-10 11:04:23 UTC ---
(In reply to comment #17)
> The patch is already in, of course. In hindsight, I think we shouldn't have
> bundled the SFINAE bits with addressing LWG 2141, which, I realize now, is
> still in flux. At least we should have discussed that.

I have asked you, before I did that.

[Bug c++/53000] Conditional operator does not behave as standardized

[paolo.carlini at oracle dot com]

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

--- Comment #19 from Paolo Carlini <paolo.carlini at oracle dot com> 2012-10-10 11:06:26 UTC ---
If it's just matter of removing the std::decay call and tweaking that testcase,
I can do it now. Otherwise, I would say, please send a patch...

[Bug c++/53000] Conditional operator does not behave as standardized

[daniel.kruegler at googlemail dot com]

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

--- Comment #20 from Daniel Krügler <daniel.kruegler at googlemail dot com> 2012-10-10 11:08:09 UTC ---
(In reply to comment #19)
It is more than that, because *my* own test-cases rely on the decay assumption.

[Bug c++/53000] Conditional operator does not behave as standardized

[paolo.carlini at oracle dot com]

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

--- Comment #21 from Paolo Carlini <paolo.carlini at oracle dot com> 2012-10-10 11:09:32 UTC ---
I see. Let's do that at your ease, then. But let's do it ;)

[Bug c++/53000] Conditional operator does not behave as standardized

[paolo.carlini at oracle dot com]

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

--- Comment #22 from Paolo Carlini <paolo.carlini at oracle dot com> 2012-10-10 11:43:00 UTC ---
I'm taking care of these reversion bits: just few lines in
sfinae_friendly_1.cc, besides the removal of std::decay and that line in
typedefs-1.cc.

[Bug c++/53000] Conditional operator does not behave as standardized

[glisse at gcc dot gnu.org]

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

--- Comment #23 from Marc Glisse <glisse at gcc dot gnu.org> 2012-10-10 11:45:03 UTC ---
(In reply to comment #17)
> The patch is already in, of course. In hindsight, I think we shouldn't have
> bundled the SFINAE bits with addressing LWG 2141, which, I realize now, is
> still in flux. At least we should have discussed that.
> 
> For now, I would recommend reverting the changes related to LWG 2141.

Just in case: I didn't post my remark to get the patch reverted, I think it is
ok to leave it in, I guess an email to LWG would have been more appropriate.

In any case, we are likely to know more after the meeting (in just a few days
now IIRC).

[Bug c++/53000] Conditional operator does not behave as standardized

[paolo.carlini at oracle dot com]

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

--- Comment #24 from Paolo Carlini <paolo.carlini at oracle dot com> 2012-10-10 11:47:20 UTC ---
Better reverting the LWG 2141-related bits. Only those of course!

[Bug c++/53000] Conditional operator does not behave as standardized

[glisse at gcc dot gnu.org]

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

--- Comment #25 from Marc Glisse <glisse at gcc dot gnu.org> ---
(not a complete fix)

r200821 | glisse | 2013-07-09 17:55:49 +0200 (Tue, 09 Jul 2013) | 9 lines

2013-07-09  Marc Glisse  <marc.glisse@inria.fr>

        PR c++/53000
gcc/cp/
        * call.c (build_conditional_expr_1): Preserve xvalues.

gcc/testsuite/
        * g++.dg/cpp0x/decltype17.C: Adjust.

[Bug c++/53000] Conditional operator does not behave as standardized

[paolo.carlini at oracle dot com]

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

Paolo Carlini <paolo.carlini at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ali.baharev at gmail dot com

--- Comment #26 from Paolo Carlini <paolo.carlini at oracle dot com> ---
*** Bug 58714 has been marked as a duplicate of this bug. ***

[Bug c++/53000] Conditional operator does not behave as standardized

[jason at gcc dot gnu.org]

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

Jason Merrill <jason at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #27 from Jason Merrill <jason at gcc dot gnu.org> ---
Should be fixed by patch for bug 58714.

[Bug c++/53000] Conditional operator does not behave as standardized

[paolo.carlini at oracle dot com]

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

Paolo Carlini <paolo.carlini at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |paolo.carlini at oracle dot com

--- Comment #28 from Paolo Carlini <paolo.carlini at oracle dot com> ---
Something is going wrong here: the bug is closed as fixed, but if I try to
enable in 20_util/common_type/requirements/sfinae_friendly_1.cc the lines which
require the bug to be fixed to pass, I'm still seeing a failure, for the line:

static_assert(is_type<std::common_type<const Ukn&&, volatile Ukn&&>,
          Ukn>(), "");

Maybe Daniel or Jason can clarify??

[Bug c++/53000] Conditional operator does not behave as standardized

[daniel.kruegler at googlemail dot com]

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

--- Comment #29 from Daniel Krügler <daniel.kruegler at googlemail dot com> ---
(In reply to Paolo Carlini from comment #28)
> Something is going wrong here: the bug is closed as fixed, but if I try to
> enable in 20_util/common_type/requirements/sfinae_friendly_1.cc the lines
> which require the bug to be fixed to pass, I'm still seeing a failure, for
> the line:
> 
> static_assert(is_type<std::common_type<const Ukn&&, volatile Ukn&&>,
> 	      Ukn>(), "");
> 
> Maybe Daniel or Jason can clarify??

Comparing this test with the current wording in 5.16 the assertion looks
incorrect and should be doomed to fail - sorry! I'll check the remaining ones
and will suggest a patch for it.
>From gcc-bugs-return-464174-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Oct 15 20:37:39 2014
Return-Path: <gcc-bugs-return-464174-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 26455 invoked by alias); 15 Oct 2014 20:37: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 26430 invoked by uid 48); 15 Oct 2014 20:37:35 -0000
From: "glisse at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/63537] [4.8/4.9/5 Regression] Missed optimization: Loop unrolling adds extra copy when returning aggregate
Date: Wed, 15 Oct 2014 20:37: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.1
X-Bugzilla-Keywords: missed-optimization
X-Bugzilla-Severity: normal
X-Bugzilla-Who: glisse at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.8.4
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-63537-4-m2g8p78fEB@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63537-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63537-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-10/txt/msg01195.txt.bz2
Content-length: 538

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

--- Comment #3 from Marc Glisse <glisse at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #1)
> Eventually a simple pass could handle
>
>   <retval> = ret;
>   ret ={v} {CLOBBER};
>   return <retval>;
>
> and back-propagate <retval> into all stores/loads of ret.

Shouldn't tree-nrv.c already handle this, except that it currently bails out if
TREE_ADDRESSABLE (found)? (strangely enough it has (dead) code to handle the
addressable case further in the same function)