This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: libstdc++/8231: iostream header position causes bad code generation
- From: paolo at gcc dot gnu dot org
- To: brister at pobox dot com, gcc-bugs at gcc dot gnu dot org, gcc-prs at gcc dot gnu dot org, ljrittle at gcc dot gnu dot org, nobody at gcc dot gnu dot org
- Date: 2 Nov 2002 21:43:30 -0000
- Subject: Re: libstdc++/8231: iostream header position causes bad code generation
- Reply-to: paolo at gcc dot gnu dot org, brister at pobox dot com, gcc-bugs at gcc dot gnu dot org, gcc-prs at gcc dot gnu dot org, ljrittle at gcc dot gnu dot org, nobody at gcc dot gnu dot org, gcc-gnats at gcc dot gnu dot org
Synopsis: iostream header position causes bad code generation
Responsible-Changed-From-To: unassigned->ljrittle
Responsible-Changed-By: paolo
Responsible-Changed-When: Sat Nov 2 13:43:29 2002
Responsible-Changed-Why:
Loren, could you please have a look at this PR, which, if
still an issue with current mainline and 3_2, seems
definitely target specific?
Thanks, Paolo.
State-Changed-From-To: feedback->analyzed
State-Changed-By: paolo
State-Changed-When: Sat Nov 2 13:43:29 2002
State-Changed-Why:
Of course my first tests on i686-pc-linux-gnu from
freebsd4.6 preprocessed source are completely meaningless
:-( Sorry.
Anyway, this is the source I have:
// ----------------------------------
//#include <iostream> // *1*
class A
{
public:
A(const char *addr);
std::ostream &print(std::ostream &ostr) const;
private:
long address;
};
//#include <iostream> // *2*
std::ostream &operator<<(std::ostream &ostr, const A &addr)
{
return addr.print(ostr);
}
//#include <iostream> // *3*
std::ostream &A::print(std::ostream &ostr) const
{
return ostr << "OK";
}
//#include <iostream> // *4*
A::A(const char *)
{
address = 0xa000001;
}
//#include <iostream> // *5*
int main(int argc, char **argv)
{
A a1("x");
std::cout << "result: " << a1 << std::endl;
}
// -------------------------------------
With current mainline and 3_2-branch on i686-pc-linux-gnu
only including in // *1* leads to a succesfull compilation.
In that case the run-time behaviour is Ok.
paolo:~/Gcc/PRs/v3/Analyzed> a.out
result: OK
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=8231