Mail Archives: djgpp-workers/2004/09/30/17:28:14
On Thu, 30 Sep 2004 19:04:49 +0200 (CEST), ams AT ludd DOT ltu DOT se wrote:
>I'm CCing djgpp-workers too.
>
>According to Andris Pavenis:
>> On Friday 10 September 2004 20:53, you wrote:
>> > In article <200409101743 DOT i8AHhRmY028387 AT delorie DOT com> Andris Pavenis
>> <pavenis AT latnet DOT lv> wrote:
>> > > Note for users of C++ IO classes fstream, ifstream, ofstream
>> > > ============================================================
>> > >
>> > > There is a regression against GCC versions 2.95.3 and
>> > > earlier: Member functions tellp(), tellg(), seekp() and seekg()
>> > > are broken when stream is opened not in binary mode. If You are going
>> > > to use any similar functions You must open stream in binary mode.
>> >
>> > Perhaps you should add that g++ generates opcodes for 486 or later
>> > (i. e. doesn't support 386s) unless that has been corrected?
>>
>> I'm not sure, but as far as I understand, it could possibly work for 386, if
>> rebuilt from sources for i386-pc-msdosdjgpp.
>
>Do I understand you correctly that you know that your gpp package
>doesn't work on 386s? "Work" here means that the compiler _and_ the
>executables it builds do run on a 386. (I know that some older version
>didn't make workable 386 executables.)
>
>No, I misunderstood something:
> Then I guess we don't know if it does work or not. But 1 below
> should be considered.
>
>Yes, that's what you're saying:
> Well, IMO:
> 1. You really really really should point out that things built
> with gpp only is for 486 (or Pentium or whatever) or later.
>
> 2. Shouldn't it be compiled for i386-pc-msdosdjgpp then so
> that it potentially does work 386s?
>
>If the bug still is in gpp even when built for i386-pc-msdosdjgpp,
>then we have to wait to get it fixed, but 1 still applies. Plus we
>might need to change some texts which say "DJGPP requires at least a
>386" adding ", 486 (or whatever) for C++ programs".
'info gcc invoking submodel i386' says under -mtune:
"While picking a specific CPU-TYPE will schedule things
appropriately for that particular chip, the compiler will not
generate any code that does not run on the i386 without the
`-march=CPU-TYPE' option being used."
There was a problem noted last year with 486 lock codes being
generated in parts of libstdc++ causing SIGILL illegal opcode errors,
that I think was worked around with a rebuild.
If the problem still exists, that's a g++/libstdc++ bug and not a
limitation of DJGPP, and should be noted as such, with a Bugzilla
link, if one exists; was it reported?
--
Thanks. Take care, Brian Inglis
Business: +1(403)547-8816 Brian DOT Inglis AT SystematicSW DOT ab DOT ca
Residence: +1(403)239-6520 BWInglis AT Shaw DOT ca
Cellular: +1(403)708-7006 Brian_Inglis AT CompuServe DOT com
Facsimile: +1(403)547-8816 Brian_Inglis AT CSi DOT com
- Raw text -