[Bug c++/61597] New: Unexpected behavior at runtime

[Bug c++/61597] New: Unexpected behavior at runtime

[adrien.hamelin+gcc at gmail dot com]

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

            Bug ID: 61597
           Summary: Unexpected behavior at runtime
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: adrien.hamelin+gcc at gmail dot com

When compiling the code visible at the link at the bottom, the compiler eat it
fine and produce an executable, but it doesn't work.

The problem is in the std::iota function present in the main. For the second
parameter, "begin + size", the operator+ is effectively called and works as
expected, but the result parameter given to the function is "begin" unmodified
(checked with gdb in without optimizations).

The code compiles and runs fine with Visual 13 and Clang 3.4.2.
It also runs fine if i use a "std::vector" instead of my "Memory::Array", or if
i use "std::next(begin, size)".

I tried to remove all unnecessary code to show the bug.

The option given to gcc are shown in the link, but it also doesn't work with no
optimizations. I had the bug on Mingw64 with gcc4.9 on Windows 7 64, and also
on the website.


http://coliru.stacked-crooked.com/a/d6fde84b59d4526a

[Bug c++/61597] Unexpected behavior at runtime

[adrien.hamelin+gcc at gmail dot com]

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

--- Comment #2 from Adrien Hamelin <adrien.hamelin+gcc at gmail dot com> ---
Created attachment 33000
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33000&action=edit
Preprocessed file compressed in 7z

I compressed the file to match the 1000KB criteria, but this is the
preprocessed file.

[Bug c++/61597] Unexpected behavior at runtime

[adrien.hamelin+gcc at gmail dot com]

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

--- Comment #6 from Adrien Hamelin <adrien.hamelin+gcc at gmail dot com> ---
I also wanted to say, my code may be not optimal or may be done in an easier
way or else (and if you have comments on it i'm ok with that), but what i think
what is the most important here is that it seems to trigger a bug from gcc.

Thus i wanted to report it to inform you of it, because it may be more critical
in other people codes.

I'm sorry that i was not able to pinpoint the (supposed) bug more precisely.

[Bug c++/61597] Unexpected behavior at runtime

[trippels at gcc dot gnu.org]

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

--- Comment #7 from Markus Trippelsdorf <trippels at gcc dot gnu.org> ---
Well, the default assumption, when someone posts a 77000 line preprocessed
program with strange runtime behavior, is that the program is buggy. 
You have to convince us that the error is on the compiler side. 
And the best way to do this is to come up with a minimal testcase,
that shows the issue clearly.

[Bug c++/61597] Unexpected behavior at runtime

[adrien.hamelin+gcc at gmail dot com]

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

Adrien Hamelin <adrien.hamelin+gcc at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #33000|0                           |1
        is obsolete|                            |

--- Comment #8 from Adrien Hamelin <adrien.hamelin+gcc at gmail dot com> ---
Created attachment 33002
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33002&action=edit
Preprocessed file

Effectively the problem can be showed with much less code lines. I just did a
custom iterator to show the problem (and removed my own array).

The problem comes from line 45. If the function takes a copy, it does not work
but if it takes a reference and do the copy inside (as shown line 52) it does
work.

Once again it works fine with Visual 2013.

The new code : http://coliru.stacked-crooked.com/a/e33afe532e7f1e55

[Bug c++/61597] Unexpected behavior at runtime

[adrien.hamelin+gcc at gmail dot com]

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

Adrien Hamelin <adrien.hamelin+gcc at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #33002|0                           |1
        is obsolete|                            |

--- Comment #9 from Adrien Hamelin <adrien.hamelin+gcc at gmail dot com> ---
Created attachment 33003
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33003&action=edit
Preprocessed file

Sorry to do such mutliple post, this one should be the last, i removed the
custom iterator - it has nothing to do with the bug.

So same as before, the function line 10 does not work when it takes a copy
parameter, and the function line 17 does work when it takes the parameter as
reference.

The new code: http://coliru.stacked-crooked.com/a/9a724fdda9ef1d06

[Bug c++/61597] Unexpected behavior at runtime

[redi at gcc dot gnu.org]

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

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

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

--- Comment #11 from Jonathan Wakely <redi at gcc dot gnu.org> ---
decltype(iter += i) is Iter& so you return a reference to a temporary which
goes out of scope

[Bug c++/61597] Unexpected behavior at runtime

[redi at gcc dot gnu.org]

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

--- Comment #12 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Jonathan Wakely from comment #11)
> decltype(iter += i) is Iter& so you return a reference to a temporary which
> goes out of scope

Sorry, temporary is the wrong word - a reference to a local variable, which
goes out of scope.  It's undefined behaviour.

[Bug c++/61597] Unexpected behavior at runtime

[adrien.hamelin+gcc at gmail dot com]

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

--- Comment #13 from Adrien Hamelin <adrien.hamelin+gcc at gmail dot com> ---
I'm sorry that i made you lose your time :-(

I thought that kind of code would trigger a warning though.

[Bug c++/61597] Unexpected behavior at runtime

[redi at gcc dot gnu.org]

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

--- Comment #14 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Yes, I can't convince gcc or clang to give a warning. Even address sanitizer
and undefined-behaviour sanitizer don't catch the problem.

[Bug c++/61597] Unexpected behavior at runtime

[glisse at gcc dot gnu.org]

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

--- Comment #15 from Marc Glisse <glisse at gcc dot gnu.org> ---
If you can reduce the testcase to a manageable size, I'll see why
https://gcc.gnu.org/ml/gcc-patches/2014-06/msg01692.html is not enough (it
should be, with -fkeep-inline-functions, but is apparently missing a tweak).

[Bug c++/61597] Unexpected behavior at runtime

[redi at gcc dot gnu.org]

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

--- Comment #16 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Marc:

struct Iter
{
  Iter& operator+=(int) { return *this; }

  int operator*() { return i; }

  int i;
};

Iter& func(Iter iter, int n) {
    return iter += n;
}

int main()
{
    Iter iter = Iter();
    Iter it = func(iter, 2);
    return *it;
}

[Bug c++/61597] Unexpected behavior at runtime

[glisse at gcc dot gnu.org]

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

--- Comment #17 from Marc Glisse <glisse at gcc dot gnu.org> ---
(In reply to Jonathan Wakely from comment #16)
> Marc:
> 
> struct Iter
> {
>   Iter& operator+=(int) { return *this; }
> 
>   int operator*() { return i; }
> 
>   int i;
> };
> 
> Iter& func(Iter iter, int n) {
>     return iter += n;
> }
> 
> int main()
> {
>     Iter iter = Iter();
>     Iter it = func(iter, 2);
>     return *it;
> }

Thanks, I only need to add to my patch:
 || TREE_CODE (valbase) == PARM_DECL
in find_explicit_erroneous_behaviour and it warns for this at -O2. I was only
handling local variables and not parameters. I'll have to check if returning
the address of a PARM_DECL is always wrong. And if func is inline, it will
require -fkeep-inline-functions.

e.cc: In function 'Iter& func(Iter, int)':
e.cc:11:20: warning: function returns address of local variable
[-Wreturn-local-addr]
     return iter += n;
                    ^
e.cc:10:17: note: declared here
 Iter& func(Iter iter, int n) {
                 ^

[Bug c++/61597] Unexpected behavior at runtime

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
   Last reconfirmed|2014-06-24 00:00:00         |2014-06-25
                 CC|                            |manu at gcc dot gnu.org
         Resolution|INVALID                     |---
     Ever confirmed|0                           |1

--- Comment #18 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Marc Glisse from comment #17)
> And if func is inline,
> it will require -fkeep-inline-functions.

What is the difference between inline/not inline?

> e.cc: In function 'Iter& func(Iter, int)':
> e.cc:11:20: warning: function returns address of local variable
> [-Wreturn-local-addr]
>      return iter += n;
>                     ^

Why it points to n?
>From gcc-bugs-return-454931-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Jun 25 17:15:32 2014
Return-Path: <gcc-bugs-return-454931-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 24416 invoked by alias); 25 Jun 2014 17:15:31 -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 24344 invoked by uid 48); 25 Jun 2014 17:15:22 -0000
From: "mpolacek at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/61240] [4.8/4.9/4.10 Regression] Incorrect warning "integer overflow in expression" on pointer-pointer subtraction
Date: Wed, 25 Jun 2014 17:15: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.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: mpolacek 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: cc
Message-ID: <bug-61240-4-W7PJH4VCHO@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-61240-4@http.gcc.gnu.org/bugzilla/>
References: <bug-61240-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/msg02013.txt.bz2
Content-length: 1186

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

Marek Polacek <mpolacek at gcc dot gnu.org> changed:

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

--- Comment #3 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Richi, did you mean something like this?  With this we wouldn't warn on nor p -
(p - 1); neither q - (q - 1); line...

--- a/gcc/c/c-typeck.c
+++ b/gcc/c/c-typeck.c
@@ -3513,6 +3513,9 @@ pointer_diff (location_t loc, tree op0, tree op1)
     {
       lit0 = TREE_OPERAND (con0, 1);
       con0 = TREE_OPERAND (con0, 0);
+      lit0 = convert (inttype, lit0);
+      if (TREE_CODE (lit0) == INTEGER_CST)
+       TREE_OVERFLOW (lit0) = 0;
     }
   else
     lit0 = integer_zero_node;
@@ -3521,6 +3524,9 @@ pointer_diff (location_t loc, tree op0, tree op1)
     {
       lit1 = TREE_OPERAND (con1, 1);
       con1 = TREE_OPERAND (con1, 0);
+      lit1 = convert (inttype, lit1);
+      if (TREE_CODE (lit1) == INTEGER_CST)
+       TREE_OVERFLOW (lit1) = 0;
     }
   else
     lit1 = integer_zero_node;

[Bug c++/61597] Unexpected behavior at runtime

[glisse at gcc dot gnu.org]

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

--- Comment #19 from Marc Glisse <glisse at gcc dot gnu.org> ---
(In reply to Manuel López-Ibáñez from comment #18)
> (In reply to Marc Glisse from comment #17)
> > And if func is inline,
> > it will require -fkeep-inline-functions.
> 
> What is the difference between inline/not inline?

After being inlined and becoming unused, a static or inline function is
discarded (doesn't exist anymore in the pass that warns), while a regular
function still needs to be emitted and is kept.

The function in which it was inlined probably has a use of a dead variable, but
warning for that is harder, as discussed in PR 60517 (I don't think we need to
keep both open).

> > e.cc: In function 'Iter& func(Iter, int)':
> > e.cc:11:20: warning: function returns address of local variable
> > [-Wreturn-local-addr]
> >      return iter += n;
> >                     ^
> 
> Why it points to n?

I am calling warning_at with gimple_location (return_stmt).
>From gcc-bugs-return-454959-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Jun 25 20:36:22 2014
Return-Path: <gcc-bugs-return-454959-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 29920 invoked by alias); 25 Jun 2014 20:36:21 -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 29882 invoked by uid 48); 25 Jun 2014 20:36:16 -0000
From: "ppluzhnikov at google dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/61614] New: [4.9/4.10 Regression] Bogus error: taking address of temporary array
Date: Wed, 25 Jun 2014 20:36:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: unknown
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: ppluzhnikov at google dot com
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: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter
Message-ID: <bug-61614-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/msg02041.txt.bz2
Content-length: 1000

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

            Bug ID: 61614
           Summary: [4.9/4.10 Regression] Bogus error: taking address of
                    temporary array
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: ppluzhnikov at google dot com

Google ref: b/15883782

This broke on trunk sometime after r200178, is broken currently (r211990), and
also on gcc-4_9-branch.

// --- cut ---
int Fn (...);

void
Test ()
{
  int j = Fn ((const int[]) { 0 });                    // OK
  unsigned long sz = sizeof Fn ((const int[]) { 0 });  // Error
}
// --- cut ---


gcc-svn-r211990/bin/g++ -c t.ii
t.ii: In function 'void Test()':
t.ii:7:52: error: taking address of temporary array
   unsigned long sz = sizeof Fn ((const int[]) { 0 });  // Error
                                                    ^

[Bug c++/61597] Unexpected behavior at runtime

[pinskia at gcc dot gnu.org]

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

--- Comment #21 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
The trunk can detect this with the reduced testcase in comment #16 with
-fsanitize=address (it could not in GCC 12 though):

=================================================================
==1==ERROR: AddressSanitizer: stack-use-after-return on address 0x7fed23a00020
at pc 0x000000401410 bp 0x7ffd3ef98df0 sp 0x7ffd3ef98de8
READ of size 4 at 0x7fed23a00020 thread T0
    #0 0x40140f in main /app/example.cpp:18
    #1 0x7fed26088082 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x24082) (BuildId:
1878e6b475720c7c51969e69ab2d276fae6d1dee)
    #2 0x4010ed in _start (/app/output.s+0x4010ed) (BuildId:
eae82a9845e6e2c7baecc615e9a9cf9fe73eac81)

Address 0x7fed23a00020 is located in stack of thread T0 at offset 32 in frame
    #0 0x4011b5 in func(Iter, int) /app/example.cpp:11

  This frame has 1 object(s):
    [32, 36) 'iter' (line 11) <== Memory access at offset 32 is inside this
variable
HINT: this may be a false positive if your program uses some custom stack
unwind mechanism, swapcontext or vfork
      (longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-use-after-return /app/example.cpp:18 in main
Shadow bytes around the buggy address:
  0x7fed239ffd80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x7fed239ffe00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x7fed239ffe80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x7fed239fff00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x7fed239fff80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x7fed23a00000: f5 f5 f5 f5[f5]f5 f5 f5 00 00 00 00 00 00 00 00
  0x7fed23a00080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x7fed23a00100: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x7fed23a00180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x7fed23a00200: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x7fed23a00280: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
==1==ABORTING