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).