Re: Call for compiler help/advice: atomic builtins for v3
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 a mutex to protect the > >memory update. Another part of the application (say, the exe) is > >compiled with i686 support, and so chooses to use atomic operations. > >The application will now fail because not all updates to the memory > >location are protected by the mutex. > > > > > 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. > > A "libstdc++ compiled with only i386 support" what is it? It is a > libstdc++ which at run time will call into libgcc, it has nothing > inline. Then libgcc will use the best the machine has available, that > is, certainly atomic operations, if the exe (compiled with -march=i686) > can possibly run. > > In short, the keys are: > 1- The "smart" libgcc, which always makes available the best the machine. > 2- Mutexes cannot be inline, only atomic operations can. Richard is right - it's enough that the inlined version doesn't agree with whatever smartness is in libgcc. But I also don't understand Richards suggestion -- it basically means you decide at libstdc++ compile-time, whether you can run on i386 or not. This is of course ok for 99.99% of all cases (distribution vendors supporting only i486+ anyway), but still does not support changing the decision at application compile-time. Note that in this particular case of atomic operations I can care less about i386... ;) Richard.
Re: no warning being displayed.
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;
> };
>
> struct test3
> {
> int a;
> int b;
> int c;
> };
>
> int main()
> {
> struct test1* t1, t11;
> struct test2* t2 ;
> struct test3* t3;
>
> t1 = &t11;
> t2 = (struct t2*)t1;
> t3 = (struct t3*)t1;
> return 0;
> }
>
>
> I suppose such an assignment should give a warning
> "incompatible pointer type" but when compiling with
> gcc 3.4.3 no such warning is given even with -Wall enabled.
>
> Is this a bug in this version?
First of all, this list is for development of gcc, not with gcc. Use
[EMAIL PROTECTED] for such questions. Second, you are
assigning a pointer of type (struct t2*) to a pointer of type
(struct t2*). This is of course fine - if you remove the cast, you
get the warning you want. This is just like f.i. double x = (int)i.
Richard.
Re: Call for compiler help/advice: atomic builtins for v3
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 to attack this. If you want to make libstdc++ auto-detect the machine, that's fine. But it has to be in code specific to that library. r~
Re: Call for compiler help/advice: atomic builtins for v3
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~
Re: Call for compiler help/advice: atomic builtins for v3
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~
Re: no warning being displayed.
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 these warnings. So the question now is if this is a problem for that particular version of gcc(3.4.3) where can i start to fix it. [EMAIL PROTECTED] gcc]$ ./cc1 test.c main ../../gccbin/gcc/test.c: In function main: ../../gccbin/gcc/test.c:33: warning: assignment from incompatible pointer type ../../gccbin/gcc/test.c:34: warning: assignment from incompatible pointer type ../../gccbin/gcc/test.c:35: warning: assignment from incompatible pointer type [EMAIL PROTECTED] gcc]$ ./cc1 --version GNU C version 4.1.0 20051102 (experimental) (sparc-elf) compiled by GNU C version 3.2.3 20030502 (Red Hat Linux 3.2.3-20). GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Re: no warning being displayed.
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 t2*)t1;
> t3 = (struct t3*)t1;
these should indeed give a warning, as you introduce a new structure
t2/t3 here. You want to use struct test2* and struct test3* here. If we
don't get a warning here for older compilers it may be due to some weird
interaction in the warning machinery that is confused by the decl for t2/t3.
But this surely isn't going to be fixed in older compilers.
Richard.
Re: Call for compiler help/advice: atomic builtins for v3
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 statement: libgcc is the wrong level at >which to attack this. If you want to make libstdc++ auto-detect >the machine, that's fine. But it has to be in code specific to >that library. > > I don't see, however, a detailed scenario where something can go wrong. If you mean you have a "feeling" that it's better not to touch libgcc, it's another thing, I respect your feelings about the architecture of gcc, of course, but you have yet to provide a specific situation where things can go wrong. To repeat, my point is that in most of the cases application would not have anything inlined and the choice would be deferred completely to libgcc, which knows the machine. If, on the other hand, something is inlined in the application (an atomic operation) had better to be ok for that machine in the first place (i.e., if you pass -march=i686, then you need an i686). Paolo.
Re: Call for compiler help/advice: atomic builtins for v3
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 be an i686, and libgcc certainly knows that. In principle I can see now that you can do absolutely new things wrt atomic operations in the application and keep around an old libgcc, not even able to deal with the newer machine (which supports the former), but I'd like to see something less theoretical. Paolo.
Re: Call for compiler help/advice: atomic builtins for v3
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 can be used multilibed, and in that case becomes by default an i386. I don't think we can inline the atomics on x86_64, and that's werry sad. Paolo.
Re: Call for compiler help/advice: atomic builtins for v3
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 feature that users won't use >correctly. > > Certainly, someone has to write the out-of-line versions of the various atomic operations, for the various machines, either for libgcc or for libstdc++-v3 ;) But probably you consider that the easy part, the difficult part making sure that the whole framework is robust. Paolo.
Re: Call for compiler help/advice: atomic builtins for v3
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, 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 the ool version. Now you compile application foobar with -march=i686 and link against kdelibs. You're screwed. You cannot possibly catch all these cases. 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. > In principle I can see now that you can do absolutely new things wrt > atomic operations in the application and keep around an old libgcc, not > even able to deal with the newer machine (which supports the former), > but I'd like to see something less theoretical. The solution with the same amount of problems like the libgcc solution, but localized to libstdc++ would be to support installing a libstdc++ with support for i386 disabled (and thus inlining using the builtins would be possible). Richard.
Re: Call for compiler help/advice: atomic builtins for v3
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 the ool version. Now you >compile application foobar with -march=i686 and link against kdelibs. >You're screwed. You cannot possibly catch all these cases. Also, libgcc >does _not_ know the machine - it only knows the -march it was compiled >for. > No! You didn't read yesterday's Mark and Uli messages! The idea is having a "smart" version of libgcc which *knows* the machine. glibc is already doing that and Mark knows the idea and would also like to have that for other reasons. Please read yesterday messages. In your example, for instance, you are not screwed at all because kdelibs ends up using out-of-line atomic operations. Paolo.
Re: Call for compiler help/advice: atomic builtins for v3
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. > >> > >> > >You build like kdelibs for -march=i386, it gets the ool version. Now you > >compile application foobar with -march=i686 and link against kdelibs. > >You're screwed. You cannot possibly catch all these cases. Also, libgcc > >does _not_ know the machine - it only knows the -march it was compiled > >for. > > > No! You didn't read yesterday's Mark and Uli messages! The idea is > having a "smart" version of libgcc which *knows* the machine. glibc is > already doing that and Mark knows the idea and would also like to have > that for other reasons. Please read yesterday messages. > > In your example, for instance, you are not screwed at all because > kdelibs ends up using out-of-line atomic operations. 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 smart libgcc cannot fix any inlined locking primitives. Richard.
Re: Call for compiler help/advice: atomic builtins for v3
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 smart libgcc cannot fix >any inlined locking primitives. > locking is not inlined. Paolo.
Re: Call for compiler help/advice: atomic builtins for v3
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 play well with each other. A smart libgcc cannot fix any >>inlined locking primitives. >> >locking is not inlined. > > A few more words: I suppose by "locking" you mean fall back for atomic operations on old arches, because otherwise some mutexes around have nothing to do with the case at issue. Now, that kind of locking can only take place inside libgcc and the libgcc uses atomic operations on that machine, of course, because the application that you are running is compiled with -march=i686. Paolo.
Re: Call for compiler help/advice: atomic builtins for v3
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're using two different types of > >>locking which surely won't play well with each other. A smart libgcc > >>cannot fix any inlined locking primitives. > >> > >locking is not inlined. > > > > > A few more words: I suppose by "locking" you mean fall back for atomic > operations on old arches, because otherwise some mutexes around have > nothing to do with the case at issue. Now, that kind of locking can only > take place inside libgcc and the libgcc uses atomic operations on that > machine, of course, because the application that you are running is > compiled with -march=i686. 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. If such simple rule is possible on other architectures affected is beyond my knowledge. And of course currently libgcc is not clever enough in the sense of Uli. Richard.
Re: Call for compiler help/advice: atomic builtins for v3
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 be out of line inside libgcc, in this theoretical scheme. Really, I think it can pretty much robust. > If such >simple rule is possible on other architectures affected is beyond my knowledge. >And of course currently libgcc is not clever enough in the sense of Uli. > Eh ;) Paolo.
\n to \r\n in stdout
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 trying to open a binary file and print it to the stdout, but substituting '\n' for "\r\n", the file generated is corrupted. Thanks you all! Gratefully, Thales Medeiros. This message was sent using IMP, the Internet Messaging Program.
Subscribing the mailing list
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, Thales Medeiros. This message was sent using IMP, the Internet Messaging Program.
Re: Call for compiler help/advice: atomic builtins for v3
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 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 the ool version. Now you | compile application foobar with -march=i686 and link against kdelibs. | You're screwed. You cannot possibly catch all these cases. 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. I agree. I think it is a can of warms we would not like to open. -- Gaby
Re: Call for compiler help/advice: atomic builtins for v3
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 place and the dynamic linker, which does in fact know what arch is used, can make the decision. It's really pretty easy for those platforms with sufficient flexibility. Use if cascades or indirect jumps for the others, if necessary. -- ➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖ signature.asc Description: OpenPGP digital signature
Re: Call for compiler help/advice: atomic builtins for v3
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. > > Yes, libgcc doesn't know this. But the libgcc can be installed in the > correct place and the dynamic linker, which does in fact know what arch > is used, can make the decision. It's really pretty easy for those > platforms with sufficient flexibility. Use if cascades or indirect > jumps for the others, if necessary. 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. -- Daniel Jacobowitz CodeSourcery, LLC
Re: Call for compiler help/advice: atomic builtins for v3
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 static linking for the system libs completely and you can find many comments to the same effect from me, too. We have to get away from the limitations static linking is imposing. For those who really really need static linking, use the least common denominator. It's those people who have to pay the price, not the (sane) rest of us. -- ➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖ signature.asc Description: OpenPGP digital signature
Re: Call for compiler help/advice: atomic builtins for v3
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 is what lies ahead of us anyway. Solaris apparently official > denounced static linking for the system libs completely and you can find > many comments to the same effect from me, too. We have to get away from > the limitations static linking is imposing. > > For those who really really need static linking, use the least common > denominator. It's those people who have to pay the price, not the > (sane) rest of us. Works for me. I'll let someone else figure out how to handle this on targets without shared libgcc. -- Daniel Jacobowitz CodeSourcery, LLC
Re: Call for compiler help/advice: atomic builtins for v3
> > 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 > > 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 static linking for the system libs completely and you can find > many comments to the same effect from me, too. We have to get away from > the limitations static linking is imposing. So has Mac OS X (darwin) but this did not keep libgcc from being a static library until Apple started to use GCC 4.0. > For those who really really need static linking, use the least common > denominator. It's those people who have to pay the price, not the > (sane) rest of us. You mean like embeded targets. Though for embedded targets usually you only want the version for processor and don't care about anything else. 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. -- Pinski
Re: Call for compiler help/advice: atomic builtins for v3
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 libgcc can be installed in the >correct place and the dynamic linker, which does in fact know what arch >is used, can make the decision. It's really pretty easy for those >platforms with sufficient flexibility. Use if cascades or indirect >jumps for the others, if necessary. > > Thanks for the explanation. Frankly, my impression is that there is something to learn from this story: even if we decide to not proceed this route (now), it makes for a good example of what dynamic linking can make possible, maybe at the cost of some additional complexity but by far more sophisticated and powerful than traditional ways to approach this kind of problem. Paolo.
Re: Call for compiler help/advice: atomic builtins for v3
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 you are complaining about then? I don't care about any platform other than Linux. My goal is to prevent the solution from being suboptimal even though the means to support the best solution exist and it requires almost no extra work. If other platforms can use the same mechanisms, good for them. If not it's up to somebody who cares to come up with a solution. -- ➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖ signature.asc Description: OpenPGP digital signature
Re: Call for compiler help/advice: atomic builtins for v3
> > 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 > OS X), > > though for Mac OS X, it is easier to support this as the way mach-o han= > dles > > fat binaries, you only really need one libgcc which contains the functi= > ons > > for all of subprocessor types. > > What is it you are complaining about then? > I don't care about any platform other than Linux. You might not care about anything except for GNU/Linux but GCC has to care to some point. And just saying don't link staticly will not do for some customers of GCC. -- Pinski
Re: Call for compiler help/advice: atomic builtins for v3
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 platform specific solutions even if this means more maintenance effort. Equalizing is not acceptable since it punishes the more evolved platforms. -- ➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖ signature.asc Description: OpenPGP digital signature
Re: Call for compiler help/advice: atomic builtins for v3
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-size-fits-all mechanism. It requires platform specific solutions >even if this means more maintenance effort. Equalizing is not >acceptable since it punishes the more evolved platforms. > Indeed, I think that if try to explain to some "lay" people that we cannot expand inline the *existing* atomic builtins on i686 for the sake of i386, I think they would laugh at us. Frankly. Paolo.
[RFC] What should be the semantics of a zero-bit bit-field with pragma pack?
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)
#endif
extern void abort (void) __attribute__((noreturn));
#pragma pack(1)
typedef struct
{
int a : 16;
int : 0;
int b;
} c;
int
main (void)
{
printf ("%d\n", offsetof (c, b));
if (sizeof (c) != 8)
abort ();
}
GCC 3.3 and earlier pass this test case. The offset of field "b" is 4
and the size of "c" is 8. But GCC 3.4 and later give "b" an offset of
2 and the size of "c" is now 6. The change in behavior is the result
of a patch from Jason from 2 and a half years ago, and the test case
was reduced from WINE.
I believe this piece of C code is valid C99, because of C99's 6.7.2.1
sub 3, which says:
"The expression that specifies the width of a bit-field shall be an
integer constant expression that has nonnegative value that shall not
exceed the number of bits in an object of the type that is specified
if the colon and expression are omitted. If the value is zero, the
declaration shall have no declarator."
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.
We discussed this briefly on IRC. We have only two options AFAICT:
1) ignore the ": 0" field completely. This is what we seem to do
since Jason's patch was commited.
2) when we see :0 align to the next unit, which seems to be the
behavior of GCC pre-3.4.
Jason suggested that it looks like they want it to mean "align the
next field despite pragma pack". So that is option (2),
Is this acceptable to everyone here?
Gr.
Steven
P.S. Just as an interesting observation: Intel ICC 8.0 follows the GCC
3.3 behavior, but ICC 9.0 breaks in the same way that GCC 3.4 and
later do :-)
Re: [RFC] What should be the semantics of a zero-bit bit-field with pragma pack?
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) are part of the ABI for each system. They very somewhat from system-to-system, but, in general, they are interpreted as alignment directives. > We discussed this briefly on IRC. We have only two options AFAICT: > 1) ignore the ": 0" field completely. This is what we seem to do >since Jason's patch was commited. > 2) when we see :0 align to the next unit, which seems to be the >behavior of GCC pre-3.4. > > Jason suggested that it looks like they want it to mean "align the > next field despite pragma pack". So that is option (2), Yes, I think we should do option (2). There's otherwise no point at all in putting a zero-width bitfield into a packed structure; it seems better to assume the user had a purpose in having the zero-width bitfield. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: \n to \r\n in stdout
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, try a friend... This list is for people that are working on the compiler, not with the compiler.
Anonymous class closures in g++
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:
virtual ~Callback() { }
virtual void handle(int result);
};
class A {
public:
void process(int a, int b);
};
void foo(Callback* c);
int bar(A* a, int x) {
// call foo with an instance of an anonymous subclass of Callback:
foo(new Callback() {
void handle(int result) {
a->process(result, x);
}
});
}
[/snippet]
Now, if bar were implemented in valid C++, we'd have this much more
verbose and brittle version:
[snippet]
int bar(A* a, int x) {
class ClosureCallback: public Callback {
Action* a;
int x;
public:
ClosureCallback(Action* a, int x): a(a), x(x) { }
void handle(int result) {
a->process(result, x);
}
};
foo(new ClosureCallback(a, x));
}
[/snippet]
Anyway, I'm just now starting to look at the g++ code to find out where
code supporting this feature might fit. If anyone else has any interest
in this, please respond. Thanks.
- Joel
Skipping incompatable libaries on a SPARC cross compile
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 linux and
execute them under Solaris on Sparc hardware, but it's quit working.
I'm using gcc-3.4.4 configured as follows:
/cdl/apps/.software/linux/gcc-3.4.4-x86-sparc/sparc-sun-solaris2.9/bin/g++
-v
Reading specs from
/cdl/apps/.software/linux/gcc-3.4.4-x86-sparc/lib/gcc/sparc-sun-solaris2.9/3.4.4/specs
Configured with:
../gcc-3.4.4/configure --host=i686-pc-linux-gnu --target=sparc-sun-solaris2.9
--with-sysroot=/cdl/apps/.software/linux/gcc-3.4.4-x86-sparc-build/sysroot
--with-gnu-as --with-gnu-ld --enable-languages=c,c++ --prefix=/cdl/apps/.software/linux/gcc-3.4.4-x86-sparc
Thread model: posix
gcc version 3.4.4
[EMAIL PROTECTED] helloworld]$
The "sysroot" directory contains all of the goodies from /usr/lib,
/usr/include, etc from a Sun box running Solaris 9. I can send a complete
file list if anyone wants it I was really careful to make sure that all of
the symlinks that were in these directories on the Sun machine were
preserved. When I try to build a simple hello world program:
#include
int main(void)
{
printf("Hello World!\n");
return 0;
}
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/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.a when
searching for -lm
/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/libc.so when
searching for -lc
/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/libc.a when
searching for -lc
/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/libc.so when
searching for -lc
/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/libc.a when
searching for -lc
(when compiling more complex examples I get a similar problem for -lrt)
Can anyone shed some light on this? I've done some googling and turned up
some talk of 32 bit versus 64 bit architectures, but trying the build with
an -m32 or -m64 made no difference. I've had this work before, so I'm
probably missing something obvious...
Thanks
Mark
Mark Cuss, B. Sc.
Software Developer
Systems Administrator
CDL Systems Ltd.
Suite 220
3553 31 Street NW
Calgary, AB, Canada
T2L 2K7
Phone 403 289 1733 ext 226
Fax 403 289 3967
[EMAIL PROTECTED]
www.cdlsystems.com
Re: Skipping incompatable libaries on a SPARC cross compile
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, AB, Canada
T2L 2K7
Phone 403 289 1733 ext 226
Fax 403 289 3967
[EMAIL PROTECTED]
www.cdlsystems.com
- Original Message -
From: "Mark Cuss" <[EMAIL PROTECTED]>
To:
Sent: Monday, November 07, 2005 3:25 PM
Subject: Skipping incompatable libaries on a SPARC cross compile
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 linux and
execute them under Solaris on Sparc hardware, but it's quit working.
I'm using gcc-3.4.4 configured as follows:
cdl/apps/.software/linux/gcc-3.4.4-x86-sparc/sparc-sun-solaris2.9/bin/g++
-v
Reading specs from
/cdl/apps/.software/linux/gcc-3.4.4-x86-sparc/lib/gcc/sparc-sun-solaris2.9/3.4.4/specs
Configured with:
../gcc-3.4.4/configure --host=i686-pc-linux-gnu --target=sparc-sun-solaris2.9
--with-sysroot=/cdl/apps/.software/linux/gcc-3.4.4-x86-sparc-build/sysroot --with-gnu-as --with-gnu-ld --enable-languages=c,c++ --prefix=/cdl/apps/.software/linux/gcc-3.4.4-x86-sparc> Thread model: posix> gcc version 3.4.4> [EMAIL PROTECTED] helloworld]$>> The "sysroot" directory contains all of the goodies from /usr/lib,/usr/include, etc from a Sun box running Solaris 9. I can send a completefile list if anyone wants it I was really careful to make sure that all ofthe symlinks that were in these directories on the Sun machine werepreserved. When I try to build a simple hello world program:>> #include > int main(void)> {> printf("Hello World!\n");> return 0;> }>> 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 whensearching for -lm>/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.a whensearching for -lm>/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/libc.so whensearching for -lc>/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/libc.a whensearching for -lc>/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/libc.so whensearching for -lc>/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/libc.a whensearching for -lc>> (when compiling more complex examples I get a similar problem for -lrt)>> Can anyone shed some light on this? I've done some googling and turned upsome talk of 32 bit versus 64 bit architectures, but trying the build withan -m32 or -m64 made no difference. I've had this work before, so I'mprobably missing something obvious...>> Thanks> Mark>>> Mark Cuss, B. Sc.> Software Developer> Systems Administrator> CDL Systems Ltd.> Suite 220> 3553 31 Street NW> Calgary, AB, Canada> T2L 2K7>> Phone 403 289 1733 ext 226> Fax 403 289 3967> [EMAIL PROTECTED]> www.cdlsystems.com>>
Re: Does gcc-3.4.3 for HP-UX 11.23/IA-64 work?
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 -lunwind -lgcc}}%{shared:-lgcc_s%M
-lunwind%{!shared-libgcc:-lgcc}
It looks like there is a close-brace '}' missing after the
-lgcc_s_hpux64. This will terminate the shared-libgcc rule before the
static rule starts. Then delete one of the 4 close braces after the
-lunwind. There are one too many braces here.
I don't see this problem in the FSF gcc tree. I'm guessing this is a
mistake in the HP gcc sources that you are using.
--
Jim Wilson, GNU Tools Support, http://www.specifix.com
Re: copyright assignement
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 Wilson, GNU Tools Support, http://www.specifix.com
Re: Does gcc-3.4.3 for HP-UX 11.23/IA-64 work?
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:%{!shared:%{!shared-libgcc:-lgcc
> > -lgcc_eh -lunwind}%{shared-libgcc:-lgcc_s%M -lunwind
> > -lgcc}}%{shared:-lgcc_s%M -lunwind%{!shared-libgcc:-lgcc}
>
> It looks like there is a close-brace '}' missing after the
> -lgcc_s_hpux64. This will terminate the shared-libgcc rule before
> the static rule starts. Then delete one of the 4 close braces after
> the -lunwind. There are one too many braces here.
I set ':set showmatch' in vim and all the braces match up.
> I don't see this problem in the FSF gcc tree. I'm guessing this is
> a mistake in the HP gcc sources that you are using.
The above is from gcc-3.4.3 + some patches. However, the HP 3.4.4
binary has the same "*libgcc" line. Do you have a GCC 3.4.x binary on
HP/IA-64 which works correctly with -shared?
--
albert chin ([EMAIL PROTECTED])
Re: copyright assignement
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://gcc.gnu.org/ml/gcc/2003-06/msg02298.html I know, let add this to the web site. ^L :-)
Question on target specifications for a SPARC machine
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 dug around and can't seem to track this info down... I'm a bit
of a newbie at this stuff so any help is greatly appreciated.
Thanks
Mark
Mark Cuss, B. Sc.
Software Developer
Systems Administrator
CDL Systems Ltd.
Suite 220
3553 31 Street NW
Calgary, AB, Canada
T2L 2K7
Phone 403 289 1733 ext 226
Fax 403 289 3967
[EMAIL PROTECTED]
www.cdlsystems.com
- Original Message -
From: "Albert Chin" <[EMAIL PROTECTED]>
To:
Sent: Monday, November 07, 2005 4:39 PM
Subject: Re: Does gcc-3.4.3 for HP-UX 11.23/IA-64 work?
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:%{!shared:%{!shared-libgcc:-lgcc
> -lgcc_eh -lunwind}%{shared-libgcc:-lgcc_s%M -lunwind
> -lgcc}}%{shared:-lgcc_s%M -lunwind%{!shared-libgcc:-lgcc}
It looks like there is a close-brace '}' missing after the
-lgcc_s_hpux64. This will terminate the shared-libgcc rule before
the static rule starts. Then delete one of the 4 close braces after
the -lunwind. There are one too many braces here.
I set ':set showmatch' in vim and all the braces match up.
I don't see this problem in the FSF gcc tree. I'm guessing this is
a mistake in the HP gcc sources that you are using.
The above is from gcc-3.4.3 + some patches. However, the HP 3.4.4
binary has the same "*libgcc" line. Do you have a GCC 3.4.x binary on
HP/IA-64 which works correctly with -shared?
--
albert chin ([EMAIL PROTECTED])
Re: Question on target specifications for a SPARC machine
> 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
Re: Skipping incompatable libaries on a SPARC cross compile
> 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/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.a when > searching for -lm > /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/libc.so > when searching for -lc > /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/libc.a when > searching for -lc > /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/libc.so > when searching for -lc > /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/libc.a when > searching for -lc What does 'sparc-sun-solaris2.9-objdump -f' return on these objects? -- Eric Botcazou
Re: Unwinding through signal handlers on IA-64/Linux
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 supports HPUX. The one David Mosberger wrote is different from the HP libunwind implementation, and is free software that supports linux. Anyways, I strongly recommend using David Mosberger's libunwind implementation. I consider any ia64 linux machine which doesn't have it installed to be broken. The gcc libunwind is probably never going to be as good as the one David Mosberger wrote. That said, it would be nice to fix the gcc unwinder if we can. The code in question is in Jakub's patch that added the MD_HANDLE_UNWABI support. So it has been there since the beginning for this macro. http://gcc.gnu.org/ml/gcc-patches/2003-12/msg00940.html I find it curious that there are some unexplained differences between the MD_HANDLE_UNWABI and MD_FALLBACK_FRAME_STACK_FOR macros. The latter supports fpsr for instance, and the former does not. There is also a difference for psp. And the code at the end of each macro is difference. It is this last bit you are complaining about. Some of these differences are probably bugs. Maybe changes to the linux kernel and/or glibc have affected this code, in which case we may need different versions for different kernel/glibc versions. Or maybe smarter code that works with every linux kernel and/or glibc version. I'm just guessing here. There is probably a reason why Jakub included that code in his patch, but I don't know offhand what it is. I've never looked at the low level details of the unwinder, and how it interacts with signal stack frames, so I'm not sure how much help I can be here. -- Jim Wilson, GNU Tools Support, http://www.specifix.com
Re: Copies of the GCC repository
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 expands to 8.5 gig. I have generated an SVK repository to go with this. As anyone who's doing or done this themselves can attest, it takes a long time and a lot of RAM and a whole ton of I/O. So I recommend grabbing the dump and then updating it, for the foreseeable future. The dump is here: ftp://gcc.gnu.org/pub/gcc/infrastructure/svk-all-entire-history.tar.rz You need rzip to uncompress it. Before using it, set the repository UUID: uuidgen > svk/db/uuid Then, just tell svk where the depot is by using svk depotmap, and pointing at the unpacked copy. At that point it should work. //gcc (or /depot/gcc if you use a named depot) is mirrored from There's a lot to be learned (for me at least) about using svk. At some point I will update the wiki with useful bits, but I don't have many just yet. For instance, two open questions while I was writing this: - how to make svk refuse commits to the mirrored portion instead of wanting to push them upstream - how to make svk access depots remotely I'm sure they're both possible, I just don't know how yet :-) -- Daniel Jacobowitz CodeSourcery, LLC
Re: Does gcc-3.4.3 for HP-UX 11.23/IA-64 work?
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 modify the libgcc specs, got a build error, then added a brace to fix it, but mistakenly added the brace in the wrong place. As mentioned before, there is a brace missing after the gcc_s_hpux64. This brace is needed to close off the shared-libgcc rule before the static-libgcc rule starts. You then must delete a brace from the end of the !static rule which has one too many. The libgcc spec in the FSF gcc sources do not match the one you have given, so this appears to be a bug in patches that you or HP have added to gcc. Alternatively, it could be a miscompilation problem, but that seems rather unlikely. The above is from gcc-3.4.3 + some patches. However, the HP 3.4.4 binary has the same "*libgcc" line. Do you have a GCC 3.4.x binary on HP/IA-64 which works correctly with -shared? I do not have an ia64-hpux machine. I have an HP loaner, but not a copy of HPUX, so my machine is only running linux. -- Jim Wilson, GNU Tools Support, http://www.specifix.com
Re: Does gcc-3.4.3 for HP-UX 11.23/IA-64 work?
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 wrong place, > and has to be moved. It looks like someone tried to modify the libgcc > specs, got a build error, then added a brace to fix it, but mistakenly > added the brace in the wrong place. > > As mentioned before, there is a brace missing after the gcc_s_hpux64. > This brace is needed to close off the shared-libgcc rule before the > static-libgcc rule starts. You then must delete a brace from the end of > the !static rule which has one too many. Yes, doing so gives the correct 'gcc -shared' output. > The libgcc spec in the FSF gcc sources do not match the one you have > given, so this appears to be a bug in patches that you or HP have added > to gcc. I just built gcc-3.4.4 with one patch to fix a sco_math fixinc bug on this platform: http://gcc.gnu.org/ml/gcc-patches/2004-11/msg00985.html The build of gcc-3.4.4 exhibits the same problem. I've filed PR24718 on this issue. Thanks for your help. -- albert chin ([EMAIL PROTECTED])
Re: Unwinding through signal handlers on IA-64/Linux
> 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 and comes from HP, so HP's libunwind is probably not too much of a misnome.r:-) http://www.hpl.hp.com/research/linux/libunwind. > Anyways, I strongly recommend using David Mosberger's libunwind > implementation. I consider any ia64 linux machine which doesn't have it > installed to be broken. The gcc libunwind is probably never going to be > as good as the one David Mosberger wrote. I agree than HP's libunwind is more robust. The problem is that GCC 3.4.x requires a libunwind that conforms to the extended unwind ABI: http://www.kernel.org/pub/linux/devel/gcc/unwind and older systems don't have it (e.g. RHEL 3). > That said, it would be nice to fix the gcc unwinder if we can. The code > in question is in Jakub's patch that added the MD_HANDLE_UNWABI support. > So it has been there since the beginning for this macro. > http://gcc.gnu.org/ml/gcc-patches/2003-12/msg00940.html Right, but the very same problem exists for MD_FALLBACK_FRAME_STACK_FOR. > I find it curious that there are some unexplained differences between > the MD_HANDLE_UNWABI and MD_FALLBACK_FRAME_STACK_FOR macros. The latter > supports fpsr for instance, and the former does not. There is also a > difference for psp. And the code at the end of each macro is > difference. It is this last bit you are complaining about. Some of > these differences are probably bugs. MD_HANDLE_UNWABI need not do as much work as MD_FALLBACK_FRAME_STACK_FOR because of the presence of unwind info, so I think differences are expected. > Maybe changes to the linux kernel and/or glibc have affected this code, > in which case we may need different versions for different kernel/glibc > versions. Or maybe smarter code that works with every linux kernel > and/or glibc version. I'm just guessing here. There is probably a > reason why Jakub included that code in his patch, but I don't know > offhand what it is. The current code works only if the signal is triggered in leaf functions. Maybe that was enough in most cases, but it is not for Ada. > I've never looked at the low level details of the unwinder, and how it > interacts with signal stack frames, so I'm not sure how much help I can > be here. Thanks for your feedback. We have a fix that passes all our internal tests, both on RHEL 3 which uses MD_FALLBACK_FRAME_STACK_FOR and on SLES 9 which uses MD_HANDLE_UNWABI. I'll submit it shortly. -- Eric Botcazou
Re: copyright assignement
> 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
