From: pavenis AT lanet DOT lv
Message-ID: <B0000101024@stargate.astr.lu.lv>
To: Martin Stromberg <Martin DOT Stromberg AT lu DOT erisoft DOT se>,
        djgpp-workers AT delorie DOT com
Date: Thu, 9 Sep 1999 20:07:37 +0300
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: gcc-2.95
In-reply-to: <199909091439.QAA20898@propus.lu.erisoft.se>
X-mailer: Pegasus Mail for Win32 (v3.12a)
Reply-To: djgpp-workers AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

It's in STL (I don't know more exactly)

Here is example posted today to djgpp AT delorie DOT com
======================================
#include <iostream>
#include <string>

string foo = "bar";

void main()
{
  cout << "test: " << foo << endl;
}
======================================

I only verified that problem exists. I don't think we need to study in 
details why it happens. It's clear that at least some code compiled with
-march=pentium doesn't work on 386 (no such examples for code that 
is compiled for pentium but doesn't work on 486 yet). It happens 
seldom and my previous (and not only my) tests didn't show any 
problems. I have seen some notes that somebody has said that there 
were similar problems in Debian distribution of Linux and therefore 
some packages in Slackware were rebuilt  for 386.

Anyway using -march=pentium on something less than pentium is a 
hack and if we have found a case were it breaks something, we should 
stop using it (I don't think that not supporting 386 is acceptable)

Andris

On 9 Sep 99, at 16:39, Martin Stromberg wrote:

> Andris said:
> > ------------------  assembler code generated by gcc-2.95
> >         leal -16(%ecx),%ebx
> >         movl $-1,%eax
> >         leal 8(%ebx),%edx
> > /APP
> >         .byte 0xf0, 0x0f, 0xc1, 0x02
> > /NO_APP
> >         cmpl $1,%eax
> >         jne L712
> > -------------------------  what I'm getting from objdump  -----------------------
> >  4f7:   b8 ff ff ff ff  movl   $0xffffffff,%eax
> >  4fc:   8d 53 08        leal   0x8(%ebx),%edx
> >  4ff:   f0 0f c1 02     lock xaddl %eax,(%edx)
> >                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >                        This command is valid for i486++
> >  503:   83 f8 01        cmpl   $0x1,%eax
> >  506:   75 34           jne    53c 
> > <_replace__t12basic_string3ZcZt18string_char_traits1ZcZt24__defaul
> > t_alloc_template2b0i0UlUlPCcUl+0x1e4>
> 
> Any chance of identifying the C++ source that causes this to be 
> generated?
> 
> 
> Lush, Split,
> 
> 							MartinS
>