public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
* Re: libstdc++/2644: g++ produces wrong code
@ 2001-05-02 18:16 Phil Edwards
0 siblings, 0 replies; 3+ messages in thread
From: Phil Edwards @ 2001-05-02 18:16 UTC (permalink / raw)
To: gdr; +Cc: gcc-prs
The following reply was made to PR libstdc++/2644; it has been noted by GNATS.
From: Phil Edwards <pedwards@disaster.jaj.com>
To: bkoz@gcc.gnu.org
Cc: gdr@gcc.gnu.org, gcc-gnats@gcc.gnu.org
Subject: Re: libstdc++/2644: g++ produces wrong code
Date: Wed, 2 May 2001 19:52:58 -0400
On Wed, May 02, 2001 at 07:16:01PM -0000, bkoz@gcc.gnu.org wrote:
> Hey folks, I cannot reproduce this with current CVS gcc. I'm not quite sure what is up, but perhaps this bug was filed before wchar_t support was on by default. Can everybody try with current CVS and see what's up?
> here's what I get:
>
> %COMP.sh "-static" 2644.cc
> <bkoz@fillmore> /mnt/hd/bliss/src.gcc/libstdc++-v3/testsuite %a.out
> 31 wchar_t digits
> 2147483647 wchar_t max
>
> Looks right to me.
Ditto for the trunk, but this morning's 3.0 branch produces zeros.
(The submitter specified 3.0 in the "release" field.) I thought the
wchar_t change was on the branch now... *looks* ugh, there's a bunch of
wchar-related things in the trunk ChangeLog not mentioned in the branch
ChangeLog.
*sigh* The branch/trunk differences are driving me nuts. If we just did
a bulk merge, do you think anyone would notice? :-)
--
pedwards at disaster dot jaj dot com | pme at sources dot redhat dot com
devphil at several other less interesting addresses in various dot domains
The gods do not protect fools. Fools are protected by more capable fools.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: libstdc++/2644: g++ produces wrong code
@ 2001-05-02 19:46 Benjamin Kosnik
0 siblings, 0 replies; 3+ messages in thread
From: Benjamin Kosnik @ 2001-05-02 19:46 UTC (permalink / raw)
To: gdr; +Cc: gcc-prs
The following reply was made to PR libstdc++/2644; it has been noted by GNATS.
From: Benjamin Kosnik <bkoz@redhat.com>
To: Phil Edwards <pedwards@disaster.jaj.com>
Cc: gdr@gcc.gnu.org, gcc-gnats@gcc.gnu.org
Subject: Re: libstdc++/2644: g++ produces wrong code
Date: Wed, 2 May 2001 19:38:30 -0700 (PDT)
> *sigh* The branch/trunk differences are driving me nuts. If we just did
> a bulk merge, do you think anyone would notice? :-)
the libsupc++ bits are pretty hard to get around.
-benjamin
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: libstdc++/2644: g++ produces wrong code
@ 2001-05-02 19:46 Phil Edwards
0 siblings, 0 replies; 3+ messages in thread
From: Phil Edwards @ 2001-05-02 19:46 UTC (permalink / raw)
To: gdr; +Cc: gcc-prs
The following reply was made to PR libstdc++/2644; it has been noted by GNATS.
From: Phil Edwards <pedwards@disaster.jaj.com>
To: Benjamin Kosnik <bkoz@redhat.com>
Cc: gdr@gcc.gnu.org, gcc-gnats@gcc.gnu.org
Subject: Re: libstdc++/2644: g++ produces wrong code
Date: Wed, 2 May 2001 21:23:30 -0400
On Wed, May 02, 2001 at 07:38:30PM -0700, Benjamin Kosnik wrote:
> > *sigh* The branch/trunk differences are driving me nuts. If we just did
> > a bulk merge, do you think anyone would notice? :-)
>
> the libsupc++ bits are pretty hard to get around.
That's the problem with having umpteen thousand customers watching... no
sneaky stuff permitted during development.
--
pedwards at disaster dot jaj dot com | pme at sources dot redhat dot com
devphil at several other less interesting addresses in various dot domains
The gods do not protect fools. Fools are protected by more capable fools.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2001-05-02 19:46 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-05-02 18:16 libstdc++/2644: g++ produces wrong code Phil Edwards
2001-05-02 19:46 Phil Edwards
2001-05-02 19:46 Benjamin Kosnik
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).