I was looking through gcc last night to see how conceptually difficult
it would be to do something like this. But instead of a file, I was
thinking of this process:
* if env(PTHREADS_LIBS) then LDFLAGS += PTHREADS_LIBS
* elseif fileexists(libpthread) then LDFLAGS += -lpthread
* elseif
I'm all for removing it, but our FSF GCC maintainer thought
it better to make it a NOOP. We're just going by his advice.
I agreed that making -pthread == NOOP was probably better than the
~Sept 5 -CURRENT system compiler however that was not my full advice.
In my view (and thus my advice), it
Alexander Kabaev wrote:
I am about to import an official GCC 3.3.1-release into our
source tree. Please hold your updates until 'all clear' message
is posted.
Done.
Alex, nice. Thank you for making -Wno-system-headers work in the
system compiler (henceforth, users that want to compile C++
I do know now why I have again problems with building openoffice.
It seems that exceptions over shared libraries are broken again in
CURRENT.
Alexander, do you have a idea why this got broken again ?
rtld from 19.October has the same problem. I guess it must be gcc3.2
which is the problem.
Thank you even I have found that out myself too :) Using
ld directly is a no-go for a gcc3.2 platform. Linking with
the crt files fixes the problem.
OK, cool. BTW, in case you care, the exact reason why you now need
the startup file wrappers in the shared image with gcc3 style EH but
not with
Doug Rabson wrote:
In the windows world, all this is handled by having a strict list of explicit
symbol exports, either in the source code using syntax extensions or with a
file supplied to the linker. I'm not sure whether binutils supports this kind
of thing but it would allow us to cut
In article [EMAIL PROTECTED],
Bruce Evans[EMAIL PROTECTED] writes:
Example of how fixing this breaks a similar assertion for DBL_ESPILON:
%%%
$ cat z.c
[...]
$ cc -o z z.c
$ ./z
LDBL_EPSILON failed test 1 with prec 2
$ cc -O -o z z.c.
$ ./z
LDBL_EPSILON failed test 1 with prec 2
In article [EMAIL PROTECTED],
Chad David[EMAIL PROTECTED] writes:
Use thr-objc not thr-posix. thr-objc maps to the gcc generic thread
abstration layer and is better supported these days. It will also
correctly disable overhead related to threading when a program is
single-threaded using
Use thr-objc not thr-posix. thr-objc maps to the gcc generic thread
abstration layer and is better supported these days. It will also
correctly disable overhead related to threading when a program is
single-threaded using weak symbols. thr-posix doesn't do that...
Regards,
Loren
To
Claiming 53 bits but supporting 64, and then not raising an exception
and/or giving a NaN or INF result on overflow to the 54th bit is
broken. If you do this, you will fail runtime validation suites.
Huh? The 53-bit quantity refers to the mantissa not the exponent.
Unless I'm sorely
In article [EMAIL PROTECTED] imp writes:
This works. I'm not sure why this isn't the default. It looks like
we have hacks in the local tree to do this, which is why I thought
that it worked great by default
This is true too. See the fpsetprec() call that I had to add to make
things
In article [EMAIL PROTECTED],
Bruce Evans[EMAIL PROTECTED] writes:
If you really want, I can tell RTH that FreeBSD/i386 absolutely wants
`long double' to be:
53 mantissa bits
1024 max exponent
No need. I prefer to keep the 53-bit precision for now, but fix the
exponents.
OK. This was
Note that while you're adding the C99 math stuff, you
might want to fix up float.h, which is just wrong about long
doubles (see PR i386/38288).
Right, I should have said no one has started committing C99 math
functions.
(Reading this exchange reminded me that I promised fellow gcc
Thanks for the quick answer Bruce. Based on the statement: ``It
should use whatever is the default format for the host environment''
and the statements that make it clear gcc isn't changing its default
precision setting anytime soon, I think I now know how to make a
correct patch for the FSF gcc
In article [EMAIL PROTECTED] you write:
found the bug: -Os compilation seems broken with gcc-3.1. I normally
[...] I know any other optimization than -O isn't supported but this bug
(either in libalias or in gcc) should be investigated.
I can narrow it down *much* further to exact small
In article [EMAIL PROTECTED],
Daniel Eischen [EMAIL PROTECTED] writes:
[ Followups to -current ]
[...] However, this work has uncovered either a rare race condition
in the 4.X pthread implementation (also seen on a current 5.0
system) or a bad assumption in the GC signal code (abstracted
16 matches
Mail list logo
