Paolo Carlini | 1 Sep 01:36 2002
Picon

Re: <strstream> vs <sstream>

Igor Markov wrote:

>   Paolo,
>
>    thanks for the equivalent code,
>    but it does not seem to compile either
>
Sorry for the typo, of course I meant:

#include <sstream>
int main() { std::string buf; std::ostringstream s(buf); }

Ciao, Paolo.

Guy Montag | 1 Sep 01:37 2002
Picon

Linking a shared library into libbackend.a?

I have written a hook directly into
rest_of_compilation in toplev.o. I would like this
hook to be present for the entire compiler proper. I
understand perfectly well how to add in an unlinked
object file, under “EXTRA_OBJS.” The challenge is that
the hook is written in C++. I have to compile and link
the object file with libstdc++, creating libhook.so.
When I add in this file into EXTRA_OBJS, the compiler
complains:

./cc1: relocation error: ./cc1: undefined symbol: hook

I am afraid that I do not yet have the knowledge to
identify why the shared library isn't working. I also
do not know where I might add in the flags “.L/.
-lhook” to directly tell GCC what to do.

Any help would be GREATLY appreciated!!!

-Guy

hook.h
int hook(void);

hook.cpp
#include <iostream>
extern "C" int hook() {...}

gcc -fpic -c hook.cpp
gcc -shared -o libhook.so hook.o -lstdc++
(Continue reading)

Scott Barnett | 1 Sep 04:06 2002
Picon
Picon

Piping Compiler Output

Hello,

I'd like to write the output of the gcc compiler to a file (logging). I've
tried using the > operator, but that doesn't seem to work, and I also
download the source to cat, and modified it so it logged to file instead of
printing text, and that won't work either (although it does work if I do an
ls or any other simple command).

Any ideas?

Regards, Scott.

Phil Edwards | 1 Sep 06:33 2002

Re: Piping Compiler Output

On Sun, Sep 01, 2002 at 12:06:26PM +1000, Scott Barnett wrote:
> Hello,
> 
> I'd like to write the output of the gcc compiler to a file (logging). I've
> tried using the > operator, but that doesn't seem to work,

The compiler also writes to standard error.  How to redirect that depends on
your shell.  Try

    gcc ..... > file 2>&1

Phil

--

-- 
I would therefore like to posit that computing's central challenge, viz. "How
not to make a mess of it," has /not/ been met.
                                                 - Edsger Dijkstra, 1930-2002

Mike Laman | 1 Sep 06:41 2002
Picon
Picon

FIRST_PARM_OFFSET() depending on "frame_pointer_needed" and "regs_ever_live[]". Can it?

Hi,

I've been working on a port for almost three months now (3.1 at this time)
of evenings when I can squeeze in the time. I've read the documentation
(a bit like drinking from a fire hose :-)), and I have managed to get
through
a lot of issues. As challenging and difficult as this has been, I am having
fun...
I have had my compiler generating code for a month, but now I'm working on
getting it
to generate the correct code :-).

I'm working on the function call logic (so it will work and be efficient in
space(!)).
I'm trying to let the compiler use only the stack pointer if it needs to
access the
arguments and local variables. Therefore I'm trying to let the compiler
generate
code to access the arguments and local data (well, everything) from the
stack pointer.

The problem I'm having (which could very well be self induced), is that
FIRST_PARM_OFFSET()
is sometimes getting values of  "frame_pointer_needed" and
"regs_ever_live[]"
that are different than when my prologue and epilogue generating functions
are called.
Consequently, the offsets from the stack pointer to the arguments and local
variables
are wrong. (I'm working on code generated with and without the frame pointer
(Continue reading)

Guy Montag | 1 Sep 06:43 2002
Picon

Re: Linking a shared library into libbackend.a?

--- Guy Montag <theguymontag <at> yahoo.com> wrote:
> I have written a hook directly into
> rest_of_compilation in toplev.o. I would like this
> hook to be present for the entire compiler proper. I
> understand perfectly well how to add in an unlinked
> object file, under “EXTRA_OBJS.” The challenge is
> that
> the hook is written in C++. I have to compile and
> link
> the object file with libstdc++, creating libhook.so.
> When I add in this file into EXTRA_OBJS, the
> compiler
> complains:
> 
> ./cc1: relocation error: ./cc1: undefined symbol:
> hook
> 
> I am afraid that I do not yet have the knowledge to
> identify why the shared library isn't working. I
> also
> do not know where I might add in the flags “.L/.
> -lhook” to directly tell GCC what to do.
> 
> Any help would be GREATLY appreciated!!!
> 
> -Guy
> 
> hook.h
> int hook(void);
> 
(Continue reading)

Erik Schnetter | 1 Sep 15:01 2002
Picon

Re: RFC: attribute "unpadded" (cf flexible array members)

On ,30 Aug 2002 08:58:00 +0200 kaih at khms dot westfalen dot de (Kai Henningsen) wrote:
> So then it seems to me that a reasonably sane model of this for C would be  
> to make an unpadded type be similar to an incomplete type, *except* that  
> it can be used as a structure field (and possibly that we can dereference  
> its fields from a pointer to it).
>
> Can't use it to construct a variable or an array, same as you can't with  
> an incomplete type. Can have pointers to it as long as you don't try  
> pointer arithmetic, but again that should be the same as with an  
> incomplete type.
>
> Incomplete types can't sizeof(); no idea if it would be wiser to allow or  
> forbid this for unpadded types.
>
> Summary: an unpadded struct type is the same as an incomplete struct type,  
> except there are a very few things more that can be done with it (and that  
> can easily be enumerated in the docs) - *not* a complete struct type with  
> a number of hard-to-predict things that you can't do with it.

There might be a precedent where a struct type in ANSI C99 has a size
which is not a multiple of its alignment, namely a struct with a flexible
array member.  See http://gcc.gnu.org/ml/gcc/2002-05/msg02844.html.  It
seems that Mark's unpadded types and structs with flexible array members
have something in common.  If so, they should be treated similarly.

-erik

--

-- 
Erik Schnetter <schnetter <at> uni-tuebingen.de>
Web: http://www.tat.physik.uni-tuebingen.de/~schnette/
(Continue reading)

Kai Henningsen | 1 Sep 10:33 2002
Picon

Re: Garbage Collection

dewar <at> gnat.com (Robert Dewar)  wrote on 31.08.02 in <20020831115757.62F37F2D75 <at> nile.gnat.com>:

> <<1. Their garbage collection guy worked on GC for 8 years straight, full
> time. Getting it right is tough.
> >>
>
> One useful source of information here is all the published work on Algol-68
> which was the first general purpose language to require garbage collection.

Surely Lisp is a general purpose language *much* older than Algol 68?

MfG Kai

Robert Dewar | 1 Sep 15:32 2002

Re: Garbage Collection

>>Surely Lisp is a general purpose language *much* older than Algol 68?

Lisp does not really raise the full range of issues in its garbage 
collection. For one thing it has fixed length blocks. Also, historically
Lisp is hardly what I would call a general purpose langauge (yes, I know
it can be used for anything, so can Postscript! I am talking about actual
general use in practice:-)

Algol-68 is much more relevant to Java than Lisp!

Christian Jönsson | 1 Sep 17:29 2002

Re: stage1 bootstrap failuer to build gcc.3.3: cppfiles.c:1168: error: parse error before ']' token etc.

On Tue, Aug 27, 2002 at 05:57:32PM +0100, Neil Booth wrote:
> Christian J?nsson wrote:-
> 
> > FWIW, I can bootstrap gcc-3.2, but still the same problem with
> > gcc-3.3...
> > 
> > The problem:
> > 
> > stage1 compile with installed gcc-2.95.4 (debian prerelase) "works" on
> > cppfiles.c
> > 
> > Stage2 compile with stage1/gcc bails out on cppflies.c
> > 
> > (I had the wrong subject, it's stage2 of the bootstrap that fails)
> 
> You are the only person that has ever reported this.  I'm afraid
> you will need to investigate it yourself.

hmm, I just tried the recently release Aurora SPARC Linux build-0.32,
same thing there... I am really lost here. Is there something with my
config options that are, well, bad?

--enable-shared --enable-threads=posix --with-gnu-as --with-gnu-ld
--with-system-zlib --enable-long-long
--enable-languages=c,c++,f77,java,objc --enable-nls --enable-symvers
--without-x --without-included-gettext --disable-checking

or is it that the joining of the gcc and binutils trunk trees should
be done in an other fashion these days? I have these symlinks from the
gcc dir into the src dir of binutils:
(Continue reading)


Gmane