From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-prs-return-23895-listarch-gcc-prs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 17597 invoked by alias); 2 Nov 2002 21:43:30 -0000
Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Archive: <http://gcc.gnu.org/ml/gcc-prs/>
List-Post: <mailto:gcc-prs@gcc.gnu.org>
List-Help: <mailto:gcc-prs-help@gcc.gnu.org>
Sender: gcc-prs-owner@gcc.gnu.org
Received: (qmail 17573 invoked by uid 61); 2 Nov 2002 21:43:30 -0000
Date: Sat, 02 Nov 2002 13:43:00 -0000
Message-ID: <20021102214330.17572.qmail@sources.redhat.com>
To: brister@pobox.com, gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org,
  ljrittle@gcc.gnu.org, nobody@gcc.gnu.org
From: paolo@gcc.gnu.org
Reply-To: paolo@gcc.gnu.org, brister@pobox.com, gcc-bugs@gcc.gnu.org,
  gcc-prs@gcc.gnu.org, ljrittle@gcc.gnu.org, nobody@gcc.gnu.org,
  gcc-gnats@gcc.gnu.org
Subject: Re: libstdc++/8231: iostream header position causes bad code generation
X-SW-Source: 2002-11/txt/msg00109.txt.bz2
List-Id: <gcc-prs.sourceware.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