[lug] Something tweaked in RH 7.1 g++?

[D. Stimits]

"Keith C. Herold" wrote:
> 
> I have a curious problem.  I know that 7.1 shipped with an "experimental"
> version of the gcc, but what problems exist beyond just trying to compile
> the kernel?  I ask because I am having a tremendous amount of trouble
> compiling simple code, that seems to work correctly.  I have also had
> trouble compiling code that is supposedly tested against 7.1 (no missing
> libraries, either).

In reality the compiler is good, and the g++ version is better than the
one older RH 6.2 ships with. The problems exist in optimization when it
is expected certain assembler instructions are produced, and the kernel
code expects it to be done that way. So unless optimizing is involved,
there is very little chance major problems are caused by the compiler.
If optimizing is involved, then problems would be based on linking with
something that requires some particular assembler result. From what I
understand off of one of the SGI lists, and kernel dev, one big problem
is when working with 64 bit code...I don't know of all the circumstances
involved, but an example is that it is possible to use extra registers
in 64 bit, and the optimizer does something that can overwrite some of
those registers, and upon call return the smashed registers are not
restored (but they are used as if they were unaltered). Are you doing
something with 64 bit code?

> 
> For example, I am trying to retrieve an Entry from a class called Dataset.
> The copy and assignment constructors for Entry are implemented correctly
> (according to my testing :) ), and Dataset stores them in a list.  When I
> try to retrieve one item from the list using a list iterator in one
> particular function, it segfaults.  Every other function seems to operate
> correctly, and the various lists are populated with valid data.

Compile with -g, don't optimize; compare result with no -g, and
optimized -O6. Does it change? If so, stack or register corruption could
be involved. If you use -g and no optimizing, then run under gdb, what
does the backtrace show? My experiences with the STL on linux RH 6.2 and
7.1 tell me that sometimes things are not implemented to current
standards, stringstream being a big example, char_traits an example in
RH 6.2, but those things which are implemented seem to be done
correctly.

> 
> Is there something about the 7.1 gcc that you folks know of that causes this
> problem?  I have looked on the gnu web site, but nothing jumps out.

If you are using gcc for C++, that is itself a mistake, use g++.

D. Stimits, stimits at idcomm.com

> 
> --Keith
> 
> > -----Original Message-----
> > From: lug-admin at lug.boulder.co.us [mailto:lug-admin at lug.boulder.co.us]On
> > Behalf Of D. Stimits
> > Sent: Tuesday, September 18, 2001 12:02 PM
> > To: lug at lug.boulder.co.us
> > Subject: Re: [lug] C++ libraries in Linux
> >
> >
> > Keith Brown wrote:
> > >
> > > I hate to reply to my own mail, but my example is not correct.
> > The buf should be
> > > unfrozen with buf.freeze(false), at least according to
> > Josuttis.  Additionally,
> > > strstream has been depreciated and he suggest you use stringstream.
> >
> > I went and replied before I saw your reply :(
> >
> > But I would avoid stringstream unless you will not be porting to older
> > machines. Even RH 6.2 did not have stringstream, at least I recall it
> > was bare in that area. In RH, I think 7.0 is the first to offer it?
> >
> > D. Stimits, stimits at idcomm.com
> >
> > >
> > > Keith
> > >
> > > Keith Brown wrote:
> > >
> > > > Hi,
> > > >
> > > > I believe you have memory leak in your example.  Once you do
> > buf.str(), the
> > > > program owns the *char that is returned, unless it tells
> > strstream otherwise,
> > > > which I forget how to do.  I believe you need to do it like:
> > > >
> > > > char * s = buf.str();
> > > > rtnval = s;
> > > > delete [] s;
> > > > return rtnval;
> > > >
> > > > Keith
> > > >
> > > > "Scott A. Herod" wrote:
> > > >
> > > > > Hi,
> > > > >   I use something like the following:
> > > > >
> > > > > #include
> > > > > <strstream>
> > > > > string paraNode::toString()
> > > > > {
> > > > >     string rtnval;
> > > > >     strstream buf;
> > > > >
> > > > >     buf << "Paragraph: "
> > > > >         << ATTR_ALIGN << " = " << _align << ", "
> > > > >         << ATTR_WRAP_MODE << " = " << _mode
> > > > >         << ends;
> > > > >
> > > > >     rtnval = buf.str();
> > > > >     return rtnval;
> > > > > }
> > > > >
> > > > > > Can it be true?  There are no converters to go from an
> > int to a string?  Or
> > > > > > a double to a string?
> > > > > >
> > > > > > --Keith
> > > > > _______________________________________________
> > > > > Web Page:  http://lug.boulder.co.us
> > > > > Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
> > > >
> > > > --
> > > > Keith Brown
> > > > 12640 Xavier St
> > > > Broomfield, CO 80020
> > > > 303.438.8169
> > > >
> > > > _______________________________________________
> > > > Web Page:  http://lug.boulder.co.us
> > > > Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
> > >
> > > --
> > > Keith Brown
> > > 12640 Xavier St
> > > Broomfield, CO 80020
> > > 303.438.8169
> > >
> > > _______________________________________________
> > > Web Page:  http://lug.boulder.co.us
> > > Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
> > _______________________________________________
> > Web Page:  http://lug.boulder.co.us
> > Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
> >
> 
> _______________________________________________
> Web Page:  http://lug.boulder.co.us
> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug