Re: libstdc++/2568

[Rainer Orth <ro@TechFak.Uni-Bielefeld.DE>]

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

From: Rainer Orth <ro@TechFak.Uni-Bielefeld.DE>
To: Brad Lucier <lucier@math.purdue.edu>
Cc: bkoz@gcc.gnu.org, gcc-gnats@gcc.gnu.org, David.Billinghurst@riotinto.com,
        neil@gcc.gnu.org, amacleod@cygnus.com (Andrew Macleod)
Subject: Re: libstdc++/2568
Date: Fri, 25 May 2001 21:28:14 +0200 (MEST)

 Brad Lucier writes:
 
 > Is this on the 3.0 branch or on the trunk (3.1)?  I don't care if 3.0
 
 The 3.0 branch.  I don't start working on the trunk until the 3.0 release
 is out of the door; I'd like to make sure as many problems as possible are
 fixed once GCC 3.0 goes out.
 
 > bootstraps on sparcv9 because I don't believe that 64-bit support
 > works on the branch because Jakub's subreg-byte patches have not been applied
 > there, and I can't find any code that looks like this in c-lex.c on the
 > trunk at all, i.e., I couldn't even apply this patch manually to the trunk.
 
 I'm not sure what I'll find, but I will compare make check results of
 
 * a sparc-sun-solaris2.8 configuration (sparcv7),
 
 * sparcv9-sun-solaris2.8 without multilib options (i.e. -m64) (sparcv9)
 
 * sparcv9-sun-solaris2.8 with -m32 (sparcv7)
 
 and maybe, time permitting, though this is by far the most interesting to
 me
 
 * bi-arch sparc-sun-solaris2.8 (default -m32) (sparcv7)
 
 * bi-arch sparc-sun-solaris2.8 -m64 (sparcv9)
 
 once I've re-enabled bi-arch/multilibbing for this configuration).
 
 	Rainer
 
 -----------------------------------------------------------------------------
 Rainer Orth, Faculty of Technology, Bielefeld University
 
 Email: ro@TechFak.Uni-Bielefeld.DE