[Bug c++/53000] Conditional operator does not behave as standardized
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_typestd::common_typeconst Ukn, volatile Ukn, Ukn(), ); Maybe Daniel or Jason can clarify??
[Bug c++/53000] Conditional operator does not behave as standardized
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_typestd::common_typeconst 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.
[Bug c++/53000] Conditional operator does not behave as standardized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53000 --- Comment #30 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org --- Author: paolo Date: Wed Oct 15 21:08:59 2014 New Revision: 216287 URL: https://gcc.gnu.org/viewcvs?rev=216287root=gccview=rev Log: 2014-10-15 Daniel Krugler daniel.krueg...@gmail.com * testsuite/20_util/common_type/requirements/sfinae_friendly_1.cc: Enable tests predicated on PR c++/53000. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/testsuite/20_util/common_type/requirements/sfinae_friendly_1.cc
[Bug c++/53000] Conditional operator does not behave as standardized
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
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
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.gli...@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
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
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_typeconst int::type - const int common_typeconst 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
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
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
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
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_typeconst int::type - const int common_typeconst 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
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
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
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
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
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
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
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
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
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
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
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
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=154890content-type=text%2Fplainpathrev=154890
[Bug c++/53000] Conditional operator does not behave as standardized
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
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? templatetypename _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 decaycommon_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
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
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
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
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_typeint,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)
