[Bug c++/61528] New: std::min std::max and RValue

[Bug c++/61528] New: std::min std::max and RValue

[lisp2d at lisp2d dot net]

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

            Bug ID: 61528
           Summary: std::min std::max and RValue
           Product: gcc
           Version: 4.8.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: lisp2d at lisp2d dot net

Declaring reference of result of functions MIN or MAX we get a DEAD memory when
one of arguments is an RValue.

// gcc -std=c++11 -Os bug.cpp
// gcc -std=c++11 -O2 bug.cpp
#include<iostream>

void  f(size_t  const & x){
  std::cout <<  "f:x="  <<  x <<  std::endl;}

int main(void){
  size_t  x{1};
  size_t  y{2};
  size_t  z{4};
  size_t  const & i=std::min(z,x  + y);
  f(i);
  size_t  const & a=std::max(x,y  + z);
  f(a);}

[Bug c++/61528] std::min std::max and RValue

[glisse at gcc dot gnu.org]

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

--- Comment #1 from Marc Glisse <glisse at gcc dot gnu.org> ---
Yes, that's required by the standard, nothing we can do about it.

[Bug c++/61528] std::min std::max and RValue

[lisp2d at lisp2d dot net]

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

--- Comment #2 from Lisp2D <lisp2d at lisp2d dot net> ---
Issue a warning would not hurt.

[Bug c++/61528] std::min std::max and RValue

[glisse at gcc dot gnu.org]

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

--- Comment #3 from Marc Glisse <glisse at gcc dot gnu.org> ---
The warning is discussed in PR 60517.

[Bug c++/61528] std::min std::max and RValue

[lisp2d at lisp2d dot net]

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

--- Comment #4 from Lisp2D <lisp2d at lisp2d dot net> ---
 Likely error in the standard. The right set of functions must return a copy of
the data and return a the temporary link with real data.
 Working version of it:

size_t  const & min2(size_t const & x,size_t  const & y){
  return  std::min(x,y);}

size_t  min2(size_t const &&  x,size_t  const & y){
  return  {std::min(x,y)};}

size_t  min2(size_t const &  x,size_t  const && y){
  return  {std::min(x,y)};}  


May be do like this?

[Bug c++/61528] std::min std::max and RValue

[glisse at gcc dot gnu.org]

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

--- Comment #5 from Marc Glisse <glisse at gcc dot gnu.org> ---
Feel free to post a message on
https://groups.google.com/a/isocpp.org/forum/#!forum/std-proposals to suggest
this. https://isocpp.org/std gives information on making official proposals. In
gcc we only implement what the standard tells us.

[Bug c++/61528] std::min std::max and RValue

[daniel.kruegler at googlemail dot com]

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

Daniel Krügler <daniel.kruegler at googlemail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |daniel.kruegler@googlemail.
                   |                            |com

--- Comment #6 from Daniel Krügler <daniel.kruegler at googlemail dot com> ---
(In reply to Marc Glisse from comment #5)
> Feel free to post a message on
> https://groups.google.com/a/isocpp.org/forum/#!forum/std-proposals to
> suggest this. https://isocpp.org/std gives information on making official
> proposals. In gcc we only implement what the standard tells us.

It is off-topic here, but Howard's similar proposal had been rejected:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2199.html

Well yes, that is now 7 years ago...
>From gcc-bugs-return-454820-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Jun 24 18:34:33 2014
Return-Path: <gcc-bugs-return-454820-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 8707 invoked by alias); 24 Jun 2014 18:34: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 8340 invoked by uid 48); 24 Jun 2014 18:34:29 -0000
From: "ubizjak at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/61586] ICE on alpha in alpha_handle_trap_shadows, at config/alpha/alpha.c:8724
Date: Tue, 24 Jun 2014 18:34: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.10.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: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-61586-4-pCI60s2iku@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-61586-4@http.gcc.gnu.org/bugzilla/>
References: <bug-61586-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-06/txt/msg01902.txt.bz2
Content-length: 1900

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

--- Comment #4 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to Richard Henderson from comment #3)
> (In reply to Uroš Bizjak from comment #2)
> > (I also wonder why we have to break the loop for naked USEs and CLOBBERs. We
> > should just skip the problematic insn and continue - as proposed in the
> > above patch).
> 
> Because it's not breaking out of the loop, it's breaking
> out of the switch, case INSN.
> 
> I don't think we should special-case TRAP_IF, but rather
> special-case BARRIER.  Suppose some -O0 test case involving
> __builtin_unreachable, which expands to no code at all.
> 
> Otherwise, I think the close_shadow_notrapb change is good.

Thanks for the comment (and the eye opener ;) ). Following is the patch I'm
going to regtest:

--cut here--
Index: alpha.c
===================================================================
--- alpha.c     (revision 211941)
+++ alpha.c     (working copy)
@@ -8717,6 +8781,11 @@
                        }
                      break;

+                   case BARRIER:
+                     /* __builtin_unreachable can expand to no code at all,
+                        leaving (barrier) RTXes in the instruction stream.  */
+                     goto close_shadow_notrapb;
+
                    case JUMP_INSN:
                    case CALL_INSN:
                    case CODE_LABEL:
@@ -8732,6 +8801,7 @@
                  n = emit_insn_before (gen_trapb (), i);
                  PUT_MODE (n, TImode);
                  PUT_MODE (i, TImode);
+               close_shadow_notrapb:
                  trap_pending = 0;
                  shadow.used.i = 0;
                  shadow.used.fp = 0;
--cut here--
>From gcc-bugs-return-454819-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Jun 24 18:34:06 2014
Return-Path: <gcc-bugs-return-454819-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 7622 invoked by alias); 24 Jun 2014 18:34: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 7598 invoked by uid 48); 24 Jun 2014 18:34:02 -0000
From: "trippels at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/61597] Unexpected behavior at runtime
Date: Tue, 24 Jun 2014 18:34: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.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: trippels 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-61597-4-BftzdipVA6@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-61597-4@http.gcc.gnu.org/bugzilla/>
References: <bug-61597-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-06/txt/msg01901.txt.bz2
Content-length: 198

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

--- Comment #4 from Markus Trippelsdorf <trippels at gcc dot gnu.org> ---
Also what is this Memory::Array thing? A std::array works as expected.

[Bug c++/61528] std::min std::max and RValue

[paolo.carlini at oracle dot com]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |DUPLICATE

--- Comment #7 from Paolo Carlini <paolo.carlini at oracle dot com> ---
Linking to the diagnostic issue.

*** This bug has been marked as a duplicate of bug 60517 ***

[Bug c++/61528] std::min std::max and RValue

[glisse at gcc dot gnu.org]

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

--- Comment #8 from Marc Glisse <glisse at gcc dot gnu.org> ---
If I mark f as static or inline (so the optimizer changes f to take its
argument by value), I get with g++-5:

w2.c: In function 'int main()':
w2.c:11:7: warning: '<anonymous>' is used uninitialized in this function
[-Wuninitialized]
   f(i);
       ^
w2.c:13:7: warning: '<anonymous>' is used uninitialized in this function
[-Wuninitialized]
   f(a);
       ^

(not the best error message, but a good first step)

It is quite fragile though, if instead f is inlined (rename main to help
convince the optimizer), we end up with:
  _49 = std::basic_ostream<char>::_M_insert<long unsigned int> (&cout, _9(D));
and don't warn about it (I didn't check, but I assume _9 is marked
TREE_NO_WARNING).