public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
* c++/1833: inlining sometimes causes incorrect behavior
@ 2002-11-20 18:56 Wolfgang Bangerth
  0 siblings, 0 replies; 3+ messages in thread
From: Wolfgang Bangerth @ 2002-11-20 18:56 UTC (permalink / raw)
  To: nobody; +Cc: gcc-prs

The following reply was made to PR c++/1833; it has been noted by GNATS.

From: Wolfgang Bangerth <bangerth@apex68.ticam.utexas.edu>
To: gcc-gnats@gcc.gnu.org
Cc:  
Subject: c++/1833: inlining sometimes causes incorrect behavior
Date: Thu, 14 Nov 2002 14:35:19 -0600

 Re-confirmed with 3.3 CVS from 2002-11-10 and 3.2.1 pre from the same date.


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: c++/1833: inlining sometimes causes incorrect behavior
@ 2002-10-30 17:26 Wolfgang Bangerth
  0 siblings, 0 replies; 3+ messages in thread
From: Wolfgang Bangerth @ 2002-10-30 17:26 UTC (permalink / raw)
  To: nobody; +Cc: gcc-prs

The following reply was made to PR c++/1833; it has been noted by GNATS.

From: Wolfgang Bangerth <bangerth@ticam.utexas.edu>
To: gcc-bugs@gcc.gnu.org, <gcc-gnats@gcc.gnu.org>
Cc:  
Subject: Re: c++/1833: inlining sometimes causes incorrect behavior
Date: Wed, 30 Oct 2002 19:27:24 -0600 (CST)

 I can confirm this also with newer gcc's, and this indeed very surprising. 
 Here's the thing:
 -----------------------------------
 #include <iostream>
 using namespace std;
 
 typedef char *pchar;
 
 void advance_by_3 (pchar &s) { s += 3; }
 
 inline void frob_fail (char *s) {
   advance_by_3((pchar)s);
   cerr << "should be 34567: " << s << endl;
 }
 
 void frob_pass (char *s) {
   advance_by_3((pchar)s);
   cerr << "should be 34567: " << s << endl;
 }
 
 int main () {
   char *x = "01234567";  frob_fail(x);
   char *y = "01234567";  frob_pass(y);
 }
 -----------------------------------
 and I get:
   tmp/g> /home/bangerth/bin/gcc-3.2.1-pre/bin/c++ -O2 x.cc
   tmp/g> ./a.out
   should be 34567: 01234567
   should be 34567: 01234567
 
   tmp/g> /home/bangerth/bin/gcc-3.2.1-pre/bin/c++ x.cc
   tmp/g> ./a.out
   should be 34567: 34567
   should be 34567: 34567
 
 With present CVS I get the first results also for -O0. For 2.95, I get the 
 wrong result only for the _inlined_ function, where I now get it 
 uniformly.
 
 The problem is rather surreal, since touching it somewhere makes it go 
 away. For example, removing the (pchar) casts in the call to advance_by_3 
 make a difference, although the variable is already a char*.
 
 Regards
   Wolfgang
 
 -------------------------------------------------------------------------
 Wolfgang Bangerth              email:           bangerth@ticam.utexas.edu
                                www: http://www.ticam.utexas.edu/~bangerth
 
 


^ permalink raw reply	[flat|nested] 3+ messages in thread

* c++/1833: inlining sometimes causes incorrect behavior
@ 2001-04-01  0:00 peteb
  0 siblings, 0 replies; 3+ messages in thread
From: peteb @ 2001-04-01  0:00 UTC (permalink / raw)
  To: gcc-gnats

>Number:         1833
>Category:       c++
>Synopsis:       inlining sometimes causes incorrect behavior
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Feb 01 11:26:00 PST 2001
>Closed-Date:
>Last-Modified:
>Originator:     Peter Bartlett
>Release:        gcc version 2.95.2 19991024 (release)
>Organization:
>Environment:

>Description:
The attached program calls two versions of a function,
one inlined and the other not. The inlined function does
not behave correctly. The type casting of a (char *)
argument to (const char *) as an argument to another funtion
that takes (const char *&) does not properly modify the
argument in the calling function in the inlined version.
>How-To-Repeat:
#include <iostream>


void frob2 (const char*& s)
{
  s += 3;
}


inline void frob_fail (char *s)
{
  frob2((const char *)s);

  cerr << "should be 34567: " << s << endl;
}


void frob_pass (char *s)
{
  frob2((const char *)s);

  cerr << "should be 34567: " << s << endl;
}


int main (unsigned argc, const char *const argv[])
{
  char *x = "01234567";
  frob_fail(x);

  char *y = "01234567";
  frob_pass(y);
}
>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted:
>From David.Billinghurst@riotinto.com Sun Apr 01 00:00:00 2001
From: "Billinghurst, David \(CRTS\)" <David.Billinghurst@riotinto.com>
To: nobody@gcc.gnu.org
Cc: gcc-prs@gcc.gnu.org
Subject: re: c/1872
Date: Sun, 01 Apr 2001 00:00:00 -0000
Message-id: <20010205234601.11151.qmail@sourceware.cygnus.com>
X-SW-Source: 2001-q1/msg00983.html
Content-length: 780

The following reply was made to PR c/1872; it has been noted by GNATS.

From: "Billinghurst, David (CRTS)" <David.Billinghurst@riotinto.com>
To: "'gcc-gnats@gcc.gnu.org'" <gcc-gnats@gcc.gnu.org>,
        "Billinghurst, David (CRTS)" <David.Billinghurst@riotinto.com>,
        "'nobody@gcc.gnu.org'" <nobody@gcc.gnu.org>
Cc:  
Subject: re: c/1872
Date: Mon, 5 Feb 2001 23:38:32 -0000 

 This can be closed.  
 
 Fixed by:
 
 Mon Feb  5 11:23:16 2001  Richard Kenner  <kenner@vlsi1.ultra.nyu.edu>
 
 	* config/mips/mips.c (override_options): Fix typo in last change.
 	(mips_make_temp_file): Call fatal_io_error, not pfatal_with_name.
 	(mips_asm_file_end): Likewise; also pass more args to
 fatal_io_error.
 
 
 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=1872&database=gcc
>From neil@gcc.gnu.org Sun Apr 01 00:00:00 2001
From: neil@gcc.gnu.org
To: egcs@cygnus.com
Cc: gcc-prs@gcc.gnu.org
Subject: Re: c++/1688
Date: Sun, 01 Apr 2001 00:00:00 -0000
X-SW-Source: 2001-q1/msg02357.html
Content-length: 0


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2002-11-14 20:36 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-11-20 18:56 c++/1833: inlining sometimes causes incorrect behavior Wolfgang Bangerth
  -- strict thread matches above, loose matches on Subject: below --
2002-10-30 17:26 Wolfgang Bangerth
2001-04-01  0:00 peteb

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).