> You can start with the form in
> http://gcc.gnu.org/ml/gcc/2003-06/msg02298.html
Thanks,
David Edelsohn just sent it to me few hours ago.
--
Pierre-Matthieu Anglade
> Is this the David Mosberger libunwind that you are referring to?
Yes, it is.
> As far as I know, the actual HP libunwind only supports HPUX. The one David
> Mosberger wrote is different from the HP libunwind implementation, and
> is free software that supports linux.
It is called libunwind an
On Mon, Nov 07, 2005 at 06:27:40PM -0800, Jim Wilson wrote:
> Albert Chin wrote:
> >I set ':set showmatch' in vim and all the braces match up.
>
> Yes, the braces match up. You wouldn't have been able to build gcc if
> they didn't.
>
> However, they are still wrong. One of the braces is in the
Albert Chin wrote:
I set ':set showmatch' in vim and all the braces match up.
Yes, the braces match up. You wouldn't have been able to build gcc if
they didn't.
However, they are still wrong. One of the braces is in the wrong place,
and has to be moved. It looks like someone tried to mod
On Fri, Oct 28, 2005 at 03:29:25PM -0400, Daniel Berlin wrote:
> For those who want a starting point to mirror the entire repo from, i
> have placed an rzip'd (http://rzip.samba.org) copy of the repository in
>
> ftp://gcc.gnu.org/pub/gcc/infrastructure/gccrepo.tar.rz
>
>
> It is 549 meg and ex
Eric Botcazou wrote:
It works if the unwind library is HP's libunwind (aka system libunwind) but
doesn't if the unwind library is the bundled one (config/ia64/unwind-ia64.c).
Is this the David Mosberger libunwind that you are referring to? As far
as I know, the actual HP libunwind only suppor
> I get the following errors:
> /cdl/apps/.software/linux/gcc-3.4.4-x86-sparc/lib/gcc/sparc-sun-solaris2.9/
>3.4.4/../../../../sparc-sun-solaris2.9/bin/ld: skipping incompatible
> /cdl/apps/.software/linux/gcc-3.4.4-x86-sparc-build/sysroot/lib/libm.so
> when searching for -lm
> /cdl/apps/.software/
> I'm using "sparc-sun-solaris2.9" for the target... Does the 2.9 indicate
> the target version of Solaris, or the version of the SPARC architecture, or
> ??? .
2.9 means Solaris 9.
--
Eric Botcazou
Hi All
How do the target specifications work for a sun machine? I'm trying to
build a Linux to Solaris on SPARC cross compiler.
I'm using "sparc-sun-solaris2.9" for the target... Does the 2.9 indicate
the target version of Solaris, or the version of the SPARC architecture, or
??? . I've d
On Nov 7, 2005, at 3:19 PM, Jim Wilson wrote:
Pierre-Matthieu anglade wrote:
I'd like to contribute to the development of gfortran and for
that, it
appears that filling a copyright assignment form is mandatory. Can
someone tell me where to get this?
You can start with the form in
http:/
On Mon, Nov 07, 2005 at 03:13:24PM -0800, Jim Wilson wrote:
> Albert Chin wrote:
> >The "*libgcc" line from the 3.4.3/3.4.4 specs file:
> > *libgcc:
> > %{shared-libgcc:%{!mlp64:-lgcc_s}%{mlp64:-lgcc_s_hpux64}
> > %{static|static-libgcc:-lgcc -lgcc_eh
> > -lunwind}%{!static:%{!static-libgcc:%
Pierre-Matthieu anglade wrote:
I'd like to contribute to the development of gfortran and for that, it
appears that filling a copyright assignment form is mandatory. Can
someone tell me where to get this?
You can start with the form in
http://gcc.gnu.org/ml/gcc/2003-06/msg02298.html
--
Jim W
Albert Chin wrote:
The "*libgcc" line from the 3.4.3/3.4.4 specs file:
*libgcc:
%{shared-libgcc:%{!mlp64:-lgcc_s}%{mlp64:-lgcc_s_hpux64}
%{static|static-libgcc:-lgcc -lgcc_eh
-lunwind}%{!static:%{!static-libgcc:%{!shared:%{!shared-libgcc:-lgcc -lgcc_eh
-lunwind}%{shared-libgcc:-lgcc_s%M -l
One other thing to note - even though the compiler / linker complains about
these library incompatiblilties, the resulting a.out executes as expected on
a Solaris box wierd.
Mark
Mark Cuss, B. Sc.
Software Developer
Systems Administrator
CDL Systems Ltd.
Suite 220
3553 31 Street NW
Calgary
Hi All
I'm hoping one of the experts here can help me out with this problem...
I've built a Linux to Sun cross compiler using gcc-3.4.4. I've done this
before and had it work, but some problems have cropped up In the past
I've been able to build simple programs (ie - "Hello World") on li
Hi everyone.
I'm interested in extending g++ to support Java-style anonymous classes,
and I thought I would ping this list in case anyone here has any relevant
advice, experience, etc..
For those who don't know what I'm talking about, here's an example:
[snippet]
class Callback {
public:
On Nov 7, 2005, at 3:41 AM, [EMAIL PROTECTED] wrote:
I've looked at so many places that I'm thinking it won't have ways
to resolve
this problem. Then I remembered that exists this discussion list.
No, please forget everything you thought you knew about this list.
Try google, try gcc-help,
Steven Bosscher wrote:
> Of course, the semantics of "int : 0" are not defined by C99 for packed
> structs. As far as I can tell, extend.texi doesn't discuss this case,
> so we need to come up with something that makes sense.
The semantics of zero-width bitfields (outside of packed structures) a
Hi,
We have this interesting ABI change between GCC 3.3 and GCC 3.4, which
we are tracking in PR22275. A test case for the problem is this:
typedef unsigned long size_t;
#ifndef offsetof
#define offsetof(TYPE, MEMBER) ((size_t) &((TYPE *)0)->MEMBER)
Ulrich Drepper wrote:
>Andrew Pinski wrote:
>
>
>>You might not care about anything except for GNU/Linux but GCC has to care
>>to some point.
>>
>>
>The important point is that this (and similar things like vector
>instructions) is an issues which cannot be solved adequately with an
>one-siz
Andrew Pinski wrote:
> You might not care about anything except for GNU/Linux but GCC has to care
> to some point.
The important point is that this (and similar things like vector
instructions) is an issues which cannot be solved adequately with an
one-size-fits-all mechanism. It requires platfor
>
> This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
> --enigBEBEBAEF5B666A9C8D55160E
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: quoted-printable
>
> Andrew Pinski wrote:
> \> Uli you keep forgetting about other OS which don't use elf (like Mac
>
Andrew Pinski wrote:
\> Uli you keep forgetting about other OS which don't use elf (like Mac
OS X),
> though for Mac OS X, it is easier to support this as the way mach-o handles
> fat binaries, you only really need one libgcc which contains the functions
> for all of subprocessor types.
What is it
Ulrich Drepper wrote:
>Richard Guenther wrote:
>
>
>>Also, libgcc
>>does _not_ know the machine - it only knows the -march it was compiled
>>for. Inlining and transparently handling different sub-architecture just
>>does not play together well.
>>
>>
>Yes, libgcc doesn't know this. But the
>
> This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
> --enig26EB7A814A3B685CD0FE59C5
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: quoted-printable
>
> Daniel Jacobowitz wrote:
> > The only real problem with this is that it mandates use of shared
>
On Mon, Nov 07, 2005 at 07:40:51AM -0800, Ulrich Drepper wrote:
> Daniel Jacobowitz wrote:
> > The only real problem with this is that it mandates use of shared
> > libgcc for the routines in question... always. If they ever go into
> > libgcc.a, we can't make sure we got the right copy.
>
> This
Daniel Jacobowitz wrote:
> The only real problem with this is that it mandates use of shared
> libgcc for the routines in question... always. If they ever go into
> libgcc.a, we can't make sure we got the right copy.
This is what lies ahead of us anyway. Solaris apparently official
denounced sta
On Mon, Nov 07, 2005 at 07:19:01AM -0800, Ulrich Drepper wrote:
> Richard Guenther wrote:
> > Also, libgcc
> > does _not_ know the machine - it only knows the -march it was compiled
> > for. Inlining and transparently handling different sub-architecture just
> > does not play together well.
>
> Y
Richard Guenther wrote:
> Also, libgcc
> does _not_ know the machine - it only knows the -march it was compiled
> for. Inlining and transparently handling different sub-architecture just
> does not play together well.
Yes, libgcc doesn't know this. But the libgcc can be installed in the
correct
Richard Guenther <[EMAIL PROTECTED]> writes:
| On 11/7/05, Paolo Carlini <[EMAIL PROTECTED]> wrote:
| > Richard Guenther wrote:
| >
| > >Richard is right - it's enough that the inlined version doesn't agree with
| > >whatever smartness is in libgcc.
| > >
| > Like? If you are inlining atomic opera
I'm not believing that only sending my question to this address i will be
answered. Normally i have to subscribe a discussion list, and i'm not receiving
no mail message from any list.
If someone could tell me how to subscribe this list, send me a private message
to [EMAIL PROTECTED]
Gratefully,
Hi all!
I've looked at so many places that I'm thinking it won't have ways to resolve
this problem. Then I remembered that exists this discussion list.
So, here is my question:
Please, but please... How can I prevent the compiler of substituting the
character '\n' for the characters "\r\n"?
I'm
Richard Guenther wrote:
>That works, if only code playing well (or failing with SIGILL) with
>either locking scheme is ever inlined. I.e. for x86 you cannot inline
>the i386 variant.
>
Indeed, we are in perfect agreement now. The point is exactly that: the
i386 version cannot be inlined, can only
On 11/7/05, Paolo Carlini <[EMAIL PROTECTED]> wrote:
> Paolo Carlini wrote:
>
> >Richard Guenther wrote:
> >
> >>ou are screwed, because if you pass a std::vector (assuming it needs
> >>locking) to kdelibs to mungle with and in a separate thread mungle with
> >>it in the -march=i686 application you
Paolo Carlini wrote:
>Richard Guenther wrote:
>
>>ou are screwed, because if you pass a std::vector (assuming it needs
>>locking) to kdelibs to mungle with and in a separate thread mungle with
>>it in the -march=i686 application you're using two different types of locking
>>which surely won't pla
Richard Guenther wrote:
>You are screwed, because if you pass a std::vector (assuming it needs
>locking) to kdelibs to mungle with and in a separate thread mungle with
>it in the -march=i686 application you're using two different types of locking
>which surely won't play well with each other. A s
On 11/7/05, Paolo Carlini <[EMAIL PROTECTED]> wrote:
> Richard Guenther wrote:
>
> >>Like? If you are inlining atomic operations this means that you are
> >>passing -march=i686, therefore in order to run the code in the first
> >>place the machine has to be an i686, and libgcc certainly knows that.
Richard Guenther wrote:
>>Like? If you are inlining atomic operations this means that you are
>>passing -march=i686, therefore in order to run the code in the first
>>place the machine has to be an i686, and libgcc certainly knows that.
>>
>>
>You build like kdelibs for -march=i386, it gets th
On 11/7/05, Paolo Carlini <[EMAIL PROTECTED]> wrote:
> Richard Guenther wrote:
>
> >Richard is right - it's enough that the inlined version doesn't agree with
> >whatever smartness is in libgcc.
> >
> Like? If you are inlining atomic operations this means that you are
> passing -march=i686, therefo
Richard Henderson wrote:
>On Mon, Nov 07, 2005 at 09:03:08AM +0100, Richard Guenther wrote:
>
>
>>... but still does not support changing the decision at application
>>compile-time.
>>
>>
>Correct. And I don't think we should support that. It makes
>hellish work for us, supporting a featur
Richard Henderson wrote:
>On Mon, Nov 07, 2005 at 02:24:03AM +0100, Paolo Carlini wrote:
>
>
>>To be sure: can you confirm that there is no easy solution for the
>>x86_64 issue?
>>
>>
>What x86_64 issue?
>
>
The issue would be that in the scheme relying completely on libstdc++,
an x86_64 c
Richard Guenther wrote:
>Richard is right - it's enough that the inlined version doesn't agree with
>whatever smartness is in libgcc.
>
Like? If you are inlining atomic operations this means that you are
passing -march=i686, therefore in order to run the code in the first
place the machine has to
Richard Henderson wrote:
>On Mon, Nov 07, 2005 at 03:45:46AM +0100, Paolo Carlini wrote:
>
>
>>Richard, sorry, I don't agree, on second thought. You are not
>>considering that the idea is using a "smart" libgcc, a la glibc, as per
>>Mark and Uli messages.
>>
>>
>Yes, I am. I stand by my sta
On 11/7/05, Inder <[EMAIL PROTECTED]> wrote:
> Hi all,
> I am compiling small program on a SPARC gcc 3.4.3
>
> test.c
> ---
>
>
> int main()
> {
> struct test1* t1, t11;
> struct test2* t2 ;
> struct test3* t3;
>
> t1 = &t11;
> t2 = (struct t
Hi Richard
Well i know that this is a list for development of gcc.
Let me be more precise about my question -
I am using gcc 3.4.3 (sparc-elf) to compile my codebase which uses such kind of
assignments but the compiler gives no warnings what so ever.
but the more recent version given below gives t
On Mon, Nov 07, 2005 at 02:24:03AM +0100, Paolo Carlini wrote:
> To be sure: can you confirm that there is no easy solution for the
> x86_64 issue?
What x86_64 issue?
r~
On Mon, Nov 07, 2005 at 09:03:08AM +0100, Richard Guenther wrote:
> ... but still does not support changing the decision at application
> compile-time.
Correct. And I don't think we should support that. It makes
hellish work for us, supporting a feature that users won't use
correctly.
r~
On Mon, Nov 07, 2005 at 03:45:46AM +0100, Paolo Carlini wrote:
> Richard, sorry, I don't agree, on second thought. You are not
> considering that the idea is using a "smart" libgcc, a la glibc, as per
> Mark and Uli messages.
Yes, I am. I stand by my statement: libgcc is the wrong level at
which
On 11/7/05, Inder <[EMAIL PROTECTED]> wrote:
> Hi all,
> I am compiling small program on a SPARC gcc 3.4.3
>
> test.c
> ---
>
> struct test1
> {
> int a;
> int b;
> char c;
> };
>
> struct test2
> {
> char a;
> char b;
> char c;
> };
>
> st
On 11/7/05, Paolo Carlini <[EMAIL PROTECTED]> wrote:
> Richard Henderson wrote:
>
> >Actually, no, it's not possible. At least in the context we're
> >discussing here. Consider:
> >
> >One part of the application (say, libstdc++) is compiled with only
> >i386 support. Here we wind up relying on
50 matches
Mail list logo
