Re: Fixing -pthreads (Re: ports and -current)
>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 fileexists("libthr") then LDFLAGS += -lthr
>* elseif fileexists("libc_r") then LDFLAGS += -lc_r
>* else error("Threading not supported.")
Hello Mike,
I too thought about making -pthread an exact alias for
env("PTHREADS_LIBS") (and, if empty, pick -lpthread or the classic
default -lc_r). The main issue is that the FSF gcc has not accepted
any code into the gcc driver which depends on environment variables.
Loren
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fixing -pthreads (Re: ports and -current)
> 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 is the stated collective opinion of the FSF gcc development team that -pthread should exist for all gcc ports which support POSIX threads. This is true even if not well documented. It would be best if adding the switch actually implied everything to support threads. If adding the -pthread switch is a NOOP to gcc but users could later add (e.g.): LD_PRELOAD=libc_r.so (or one of the newer choices) and not break anything, then I think that would be fully acceptable and meet the specification of the switch. This would be very cool in that you could test/run against multiple thread libraries without a re-link. If adding the -pthread switch is a NOOP to gcc but users must also add -lc_r (or one of the newer choices) for correct operation, then I think making it a NOOP is a bad idea and I attempted to state so. Regards, Loren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: GCC 3.3.1-RELEASE is coming
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++
e.g. `-pedantic -Werror' should add that option for best results).
Trying to consider how to best pull important differences back into
the FSF tree. Will this be true for all FreeBSD systems going forward?
< %{!dynamic-linker:-dynamic-linker /usr/libexec/ld-elf.so.1}}
---
> %{!dynamic-linker:-dynamic-linker /libexec/ld-elf.so.1}}
BTW, it seems to be inconsistent for the various CPUs in the system
compiler (e.g. missed in ia64). What is the official trigger point of
the change in the system? Given the nature of the change, may I
assume that a transition period exists during all of FreeBSD 5?
Regarding this thunk, also in config/alpha/freebsd.h (not in FSF but
in my mainline tree with a slightly less hostile comment):
> #undefSTARTFILE_SPEC
> #define STARTFILE_SPEC \
>"%{!shared: \
> %{pg:gcrt1.o%s} %{!pg:%{p:gcrt1.o%s} %{!p:crt1.o%s}}}\
>crti.o%s %{shared:crtbeginS.o%s}%{!shared:crtbegin.o%s}"
Pending a better reworking in the FSF tree to clarify what is strictly
per-CPU vs. per-CPU/OS, that could be replaced with:
/* Reset our STARTFILE_SPEC which was properly set in config/freebsd.h
but trashed by config//. */
#undef STARTFILE_SPEC
#define STARTFILE_SPEC FBSD_STARTFILE_SPEC
In config/i386/freebsd.h we have a similar override (logically same
but different format) which should be similarly replaced (or removed
since it appears it may not be strictly needed there anymore). I will
install patches in the FSF tree for these issues to both mainline and
3.3.X branch.
Speaking of config/i386/freebsd.h, the difference against the FSF tree
is quite large but most of it is not required anymore. The difference
in all other config//freebsd.h files is only a line or two. If I
proposed a /usr/src/contrib/gcc/ diff such that it produced the exact
same system compiler yet was the smallest delta from the FSF tree,
would you be interested? I'd like to get that difference down to make
it easiler to spot real differences going forward.
Regards,
Loren
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: optimization/10189: pentium4 breaks suns libm code for__ieee754_pow(double x, double y)
> Beautiful email!! Thanks David but, although the exact words are mine, I felt deja vu while writing them. I have been asked to contribute it to the gcc bug reporting docs as a warning against using the compiler in novel modes unless you actually first test it as I will describe. Then we will ask all reporters of CPU switch PRs whether they did or can do that test before attempting to stare at a full package/kernel failure mode. I will attempt to be a little more pro-active in watching the GNATS at gcc.gnu.org for FreeBSD. There appears to be an near endless supply of people that wish to add these CPU flags to kernel builds. ;-) >> Special secret #2: Although the FSF-side does want to improve all >> code generation (and I think proper PRs RE CPU switches will be >> looked at by someone given enough time) be aware that -O2 without >> special arch flags is probably the most stable for any given CPU >> for any given gcc release. Do you really want to trust a kernel >> built with optimization flags and arch flags that near zero or zero >> people have fully tested? Doubtful. However, inline with secret >> #1 and by virtual of being digital, if even one person tests it >> (i.e. yourself) and it appears OK, then it is probably safe to at >> least attempt to build a kernel and run it. > FreeBSD has for years recommended -O[1] vs. -O2. Do you think there is > value in having the GCC test suite runs you do at FreeBSD.org do runs > with both settings? Actually (slight backpettle), all of the modern DG test suite in gcc are run at the broad range of -O0,1,2,3. OTOH, by default, everyone is bootstrapping the compiler at -O2 everyday. > To also do runs with the newer CPU types? This would be quite revealing. I would like to extend the automatic regression checkers to cover that but, yow, I'm already eating a lot of cycles on those machines. Added to list of things to check. Regards, Loren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: C++ Exception handling with shared libs in current is broken again
> 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 gcc2 style EH: There are special ELF constructors/destructors hook symbols which are registered/found on a per-shared image basis by the Dwarf EH walking code... If those aren't present, then it doesn't work (the gcc mainline reports an error message before coring with your example code). Although it seems odd, all that support comes in the "startup code". Did using ld directly ever work on CURRENT after the first upgrade to gcc 3? I suppose it might have worked the gcc 2.95 way in gcc 3.1 since we were slow to adopt support for some of the newer ELF features in the FSF copy of gcc. -Loren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: C++ Exception handling with shared libs in current is broken again
>> 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.
[This response addresses your other thread as well:
ld -Bsharable broken in CURRENT ?]
Hi Martin,
If you really want to directly use ld to build a shared C++ image,
then you will need to do additional study because a lot of things
changed between gcc 2 (used longjump-based EH) and gcc 3 (dwarf-region
based EH, requires more environment support). From gcc 3.2.2
documentation as installed on CURRENT (regarding the *only* supported
way to make a C++ shared library): "However, if a library or main
executable is supposed to throw or catch exceptions, you must link it
using the G++ or GCJ driver, as appropriate for the languages used in
the program, or using the option @option{-shared-libgcc} [to the gcc
driver], such that it is linked with the shared @file{libgcc}."
Now, FreeBSD might have guaranteed other ways in the past, but from
the gcc side of things, this is the only supported way to make a C++
shared image with gcc3 on modern ELF platforms:
foo.so: foo.o
${CXX} -shared -o foo.so foo.o
Regards,
Loren
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
binutils symbol hiding and versioning (was Re: [PATCH] note the __sF change in src/UPDATING)
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 down the set of symbols exported from > libc.so. It does. Proof by example: libstdc++.so and libgcc_s.so built from sources included with FSF gcc 3.1 and all forward releases support this feature on FreeBSD. It works fine on FreeBSD 4.7 and 5.0 (with system copy of binutils in both cases). I don't know the exact version of binutils that added this feature but it was before 2.12[.2]. The ld features being used are both symbol versioning and symbol hiding. (Speaking of which, I am reminded to insert this advisement of a related minor issue with the current system compiler:) libstdc++.so as built along with the system compiler does not make use of these features yet on FreeBSD 5.0 since the system-static Makefiles to build the compiler-related libraries have not been updated to account for the feature and many extra symbols are exported as a result. libstdc++.so uses this linker features to present a more stable ABI, no matter the concrete implementation under the hood of the library. I am hoping that the gcc maintainer on the FreeBSD system-side will reconsider this issue before 5.0 is released. FYI, the libstdc++-v3 maintainers on the FSF side are only guaranteeing forward ABI compatibility of any sort if libstdc++.so is built with symbol versioning and symbol hiding. Also, I believe it may be an error to even ship a libstdc++.so unless it is linked against libgcc_s.so (and it currently is not so linked since we don't build libgcc_s.so). As I understand it, if a user of the system compiler attempts to build a stand-alone C++ shared library (i.e. no link against libstdc++.so) but then later uses it in an application that also uses libstdc++.so, EH will fail unless libgcc_s.so was properly built and used. I understand that FreeBSD circa 1996(?) attempted to use a "shared libgcc.so"; libgcc_s.so is similar but different. For one libgcc_s.so is only part of what was libgcc.a; i.e. all code still links against libgcc.a when libgcc_s.so is built and used properly. Regards, Loren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Objective-C threads
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 weak symbols. thr-posix doesn't do that... > I've been trying to get it to work with weak symbols, but have not had > any luck yet. I'm pretty sure I'm just missing something simple, but > if you have a working config for FreeBSD I'd love to see it. (I could tar up a built copy if you want to look at a stable configuration, but it is based on FSF configure not FreeBSD /usr/src Makefiles; however it should be easy for you to get to that point yourself.) > The current situation doesn't seem optimal, ie. requiring -pthread for > none threaded programs. There is also the issue of config.h.in, which > needs to become config.h. This shouldn't be a big deal, I'm just not > sure what the prefered method is (just repo copy it?). Sorry, I don't use/support ObjC at all, however gcc 3.2 doesn't require -pthread to link a single-threaded program when built using the FSF configure-generated Makefiles which build against thr-objc (gcc 3.[01].X should have all been similar). To wit: nm /usr/local/lib/libobjc.a|grep pthread w pthread_attr_destroy [...] w pthread_setspecific My only advise might be: A lot of configuration stuff regarding libobjc has subtly changed in the FSF tree, perhaps you should attempt to build a copy using the standard FSF configure technique then resync the master FreeBSD Makefiles for that package. Regards, Loren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Lack of real long double support
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 > DBL_EPSILON failed test 2 with prec 3 > %%% > The full brokenness only shows up with -O. When I run your program against gcc mainline (for 3.3 release) with the patch I have staged from RTH to correctly match our FP hardware default setup, I see: S rittle@latour; /usr/local/beta-gcc/bin/gcc t.c S rittle@latour; a.out LDBL_EPSILON failed test 2 with prec 3 S rittle@latour; /usr/local/beta-gcc/bin/gcc -O t.c S rittle@latour; a.out LDBL_EPSILON failed test 2 with prec 3 DBL_EPSILON failed test 2 with prec 3 S rittle@latour; /usr/local/beta-gcc/bin/gcc -O2 t.c S rittle@latour; a.out LDBL_EPSILON failed test 2 with prec 3 DBL_EPSILON failed test 2 with prec 3 S rittle@latour; /usr/local/beta-gcc/bin/gcc -O3 t.c S rittle@latour; a.out LDBL_EPSILON failed test 2 with prec 3 DBL_EPSILON failed test 2 with prec 3 I.e. the only time it "fails" is when the user made a call to change the default precision. Is that gcc 3.3 behavior acceptable (at least until gcc can be further refined to attempt to handle user override of the FP control word)? Regards, Loren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Objective-C threads
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 Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Lack of real long double support
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 work above. Yes, I know about that call. I conditionally added it to at least one gcc i386 FP test case that assumed 64-bit precision. However, the system header is suppose to reveal the FP hardware as it is configured not as some user could litter their code to make it so, no? > Yes. The standard didn't anticipate the fp hardware that intel made. C89, perhaps (although given the timing, I'm skeptical). C99, no way. > One could do something like: > > #define LDBL_EPSILON (fpgetprec() == FP_PE ? _LDBL_EPSILON : DBL_EPSILON) > > But as you said, this isn't a compile time constant. I'm not sure > that it would matter in any real context. I don't think that you can > do floating point in the preprocessor... This proposal isn't bad IMHO. It would clearly explain to the gcc team what type of FP support we'd want even if not in full compliance with the standard text. And, to avoid all compliance problems, perhaps: #if !defined(_ANSI_SOURCE) && !defined(_POSIX_SOURCE) && !defined(__STRICT_ANSI__) // for i386, match default as expressed in __INITIAL_NPXCW__ #define LDBL_MANT_DIG 53 #define LDBL_EPSILON 2.2204460492503131E-16 [...] // changing LDBL_MANT_DIG subtly changes every value not just LDBL_EPSILON) #else // Assume something would have to be done to avoid including #define LDBL_MANT_DIG (fpgetprec() == FP_PE ? _LDBL_MANT_DIG : DBL_MANT_DIG) #define LDBL_EPSILON (fpgetprec() == FP_PE ? _LDBL_EPSILON : DBL_EPSILON) [...] #endif To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Lack of real long double support (was Re: libstdc++ does notcontain fabsl symbol)
> 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 confused, the only IEEE exceptions you could be speaking about is "inexact"; Inf and NaN don't come into play. In any event: As I outlined, in this case (where we advertised 53-bit precision but the user "forced" 64-bit precision - it was not precise for you to use the word "supporting" since that does not characterize the situation I was speaking about properly), the user will have explicitly made a call to change the default precision as conveyed in the system header. At that point, I don't know why the user should be able to expect that the published values in are still valid. Do these validation suites typically run with a call to override the precision setting in the IEEE FP control word? Doubtful (or if they do, they know what they are doing; just as application code that monkeys with the control register would have to). I.e. the test suite would be running against the published which at the moment should be: #define LDBL_MANT_DIG53 #define LDBL_MIN_EXP (-16381) #define LDBL_MAX_EXP 16384 (All other published LDBL_ constants are derivable from these.) since they match the default FP control word setting on FreeBSD/i386. > I don't think that any amount of hand-waving will turn it into a > compiler-only issue. I am not trying to handwave anything. The currently published (both before and after recent patch) is what is attempting to handwave something. It doesn't match the hardware settings. That patch it just received fixed one thing (exponent range) but broke another (precision/epsilon). More than anything, I am attempting to have that file written exactly to match the default hardware setup. Since there is exactly one default hardware setup for any particular booted system, it seems possible to do. If I were doing what is claimed, I would have "fixed" the issue in gcc mainline without consulting FreeBSD-side experts. Perhaps we should just leave it broken in the FSF tree and let an "expert" sort it out when they import gcc 3.3 into FreeBSD. However, it seemed reasonable to me to fix the issues exposed by the gcc infrastructure change ASAP... > I'd like to see Bruce's issues with the 64 bit support taken care > of with long double (and the implicit cast that occurs in the one > case that Bruce complained about in his email, where there is *too > much* precision on the rvalue, which is a computation of dobule > operands done in long double form, with a double result). I think I now understand Bruce's point. There are two issues: (a) incorrect double-rounding (once to the precision of extended double in register and another to double when moved to memory allocated for double); (b) non-exact comparisons where might otherwise be expected by programmers even if not absolutely guaranteed by IEEE 754. To anyone that wishes to understand it, start reading page 249 of this version of _What Every Computer Scientist Should Know About Floating-Point Arithmetic_ http://www.validlab.com/goldberg/paper.ps FYI, by default, FreeBSD/i386 uses technique 4 on page 260 to circumvent these issues. (There is a proof earlier that fully explains why double-rounding doesn't affect double->float conversions on i386.) Now, in case anyone cares, gcc 3.3 will expose the C99 FLT_EVAL_METHOD macro (set to 2 for FreeBSD/i386) and related float_t and double_t types (which will both map to long double to represent the destination of intermediate results otherwise beyond the user's control). Given the extended range of the exponent of a double or float in an i386 HW FP register; I believe that is correct. Regards, Loren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Lack of real long double support (was Re: libstdc++ does notcontain fabsl symbol)
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 the resolution that made sense to us on the gcc side
(RTH, quickly; myself, some time to get up to speed). FYI, the system
header patch that was actually checked in claims 64-bit precision. Oh
well, at least the exponents are now correct. ;-) FYI, here is the
exact test case which shows the new value for LDBL_EPSILON (derived
directly from LDBL_MANT_DIG) is wrong verses the hardware default:
#include
// Force run-time computation of math (beware, inlining oneld will defeat this).
long double oneld() { return 1.0L; }
main ()
{
long double a = oneld();
long double b = oneld() + LDBL_EPSILON;
if (a == b) abort ();
}
On ref5 against gcc 3.2.X (as installed as system compiler), with the
latest , it crashes. By specification, this is one FP test
involving exact equality that is guaranteed to work (and report false,
in this case).
> Hopefully the precision won't be hard-coded into gcc in such
> a way as to completely break changing the precision at runtime. I think
> it should affect (only) constant folding. The issues are very similar
> to the ones with changing the rounding mode at runtime (C99 compilers
> shouldn't do constant folding in "#pragma STDC FENV_ACCESS ON" sections
> if the correct result might depend on the FP environment).
This exchange has been quite useful. I see that issue.
Unfortunately, changing precision of the FP hardware would seem to
change the value of epsilon that is exported, both in classic C
headers and C++ (the latter being how I originally took any
interest in this matter since a C++ test case started failing after
the new real.c code was installed).
gcc 3.3 will support a framework in which such changes would be easy
to convey at compile-time but, to my knowledge, there is no support
yet to obtain e.g. the precision setting at run-time. I.e.
is now completely dynamically created at compile-time based on the
exact knowledge within gcc of the FP hardware; but it is static
w.r.t. eventual run-time. It does not know how to effectively export
a function ala FreeBSD/alpha's :
#define FLT_ROUNDS __flt_rounds()
One issue, the standard says that various macros related to float
limits are constant expressions (as may be used to influence the
preprocessor?). The above construct doesn't conform but I understand
the intent.
I will advise RTH about that type of issue. Fortunately, in this
case, I think advertising 53-bit precision but really using 64-bit
precision (i.e. application code overrode system default) doesn't
invalidate the advertised epsilon, in terms of how it is used by the
application.
More generally, I will ask if gcc can support these details as gained
from the run-time environment instead of hard-coded defaults. This
would be useful for all free OSes not just FreeBSD running on hardware
with such "flexible" FP hardware.
Any more comments, before I start work on the gcc mainline side of
things?
Thanks,
Loren
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Lack of real long double support (was Re: libstdc++ does notcontain fabsl symbol)
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 mainline. More details in line below.
Regards,
Loren
>> ... Anyways, that work exposed some issues.
>> We have this in the system header:
>> #define LDBL_MANT_DIG DBL_MANT_DIG
>> #define LDBL_MIN_EXPDBL_MIN_EXP
>> #define LDBL_MAX_EXPDBL_MAX_EXP
>> [...]
> This seems to be correct. Long double precision is not really supported
> either at complie time or runtime. The default precision (on i386's)
> is 53 bits, so (normalized) long doubles have a hard time getting any
> larger than DBL_MAX or any smaller than DBL_MIN (you can create them
> as bits or using a hardware transcendental function, but any arithmetic
> on them will convert them to double precision).
It is easy to generate, with arithmetic, a long double value outside
the *exponent* range above no matter how the precision is set; it is
not truncated to Inf until it is actually cast to a double (as is
currently done just before a long double is printed with stdio). See
below for a program that demonstrates this behavior.
>> Yet, the FP hardware is actually configured by default to provide
>> `long double' as:
>> #define LDBL_MANT_DIG 53
> I think you mean 64 (the hardware default).
No sir, I did mean as configured in the system startup code, it is
forced to 53-bits (that choice affects long double as well as double).
But there are no IEEE control bits to limit the size of the exponent
field, are there? Thus, the following describes the exact size of the
HW's exponent field of a long double as configured by default:
>> #define LDBL_MIN_EXP(-16381)
>> #define LDBL_MAX_EXP16384
> gcc can't actually support the full range, since it doesn't control
> the runtime environement (it could issue a fninit before main() to
> change the default, but it shouldn't and doesn't). The exponent
> range is lost long before printf() is reached. E.g.,
> long double x= DBL_MAX;
> long double y = 2 * x;
> gives +Inf for y since the result is doesn't fit in 53-bit precision.
As you know, the selection of maximum precision is orthogonal to the
number of bits used for the exponent.
I do wish you were correct. Have you looked at the raw memory of y?
It is *not* the bit pattern for +Inf. If y were +Inf, then based on
the properties of IEEE math, the following would report Inf not
DBL_MAX/2:
#include
int main (void)
{
long double x= LDBL_MAX; // Same as DBL_MAX in current float.h
long double y = 2e100 * x; // If LDBL_MAX was correct, we should latch Inf.
long double z = y / 4e100;
printf ("%Lg\n", z);
}
It does, in fact, report DBL_MAX/2 with the system compiler on FreeBSD
4. FYI, I reviewed the generated code to ensure it was using run-time
calculations not compile-time calculations. I'd call that a rather
easy time getting a normalized long double much larger than
LDBL_MAX/DBL_MAX. This test alone proves in my mind that the
system header for i386 is itself wrong.
> The system header correctly reports this default precision. Any header
> genrated by the gcc build should be no different, since the build should
> run in the target environment.
I agree that the precision setting in the system header is fine. The
size of the exponent field is buggy. I held the opinion you have but
while trying to convince RTH (the guy that rewrote gcc FP support), I
did enough research that also leads me to think that it is the header
itself which is buggy.
If you really want, I can tell RTH that FreeBSD/i386 absolutely wants
`long double' to be:
53 mantissa bits
1024 max exponent
And we can let the chips fall where they may but that is lie verses
the hardware setup just to match a buggy system header. Attempting to
get that patch in was what triggered my research and first post.
>> Anyways, two questions for FreeBSD maintainers. How should gcc, as
>> provided from the FSF, describe the long double FP format for
>> FreeBSD/i386 4.x? Shall we assume that no changes for FreeBSD 5.x
>> will occur?
> It should use whatever is the default format for the host environment,
> It still has enquire.c for doing this automatically. [...]
I fear I didn't explain clearly enough. enquire.c is completely
*gone* in gcc 3.3. This is why gcc needs to fully understand the
exact FP default configuration. As you noted, enquire.c was buggy.
> I think he would be even unhappier with gcc's support for it. We default
> to 53-bit precision partly because Kahan's (his?) paranioa(1) is unhappy
> with 64-bit precision.
I can't disagree with the first statement. However, support for FP in
gcc has just been rewritten and the paranioa test was pulled into gcc.
Perhaps it is time to revisit some past assumptions related to FP when
gcc 3.3 is impo
Lack of real long double support (was Re: libstdc++ does not contain fabsl symbol)
>> 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 developers to check on this issue with FreeBSD developers.) The gcc mainline (what will become 3.3) recently got a new implementation of ``software floating point emulation'' (contained in gcc/real.[hc] which is used to format all compile-time FP constants, etc). Along with that change, the compiler wants to provide a copy of generated from its own knowledge of FP hardware instead of sucking information from /usr/include/float.h, as it had done in past gcc releases. I know that when we install gcc as the FreeBSD system compiler, we don't bother with such header files provided from gcc (but, for the moment please consider that people might build cross-compilers to FreeBSD and please consider that we test future releases of gcc as might be used as the FreeBSD system compiler from FSF sources). Anyways, that work exposed some issues. We have this in the system header: #define LDBL_MANT_DIG DBL_MANT_DIG #define LDBL_MIN_EXPDBL_MIN_EXP #define LDBL_MAX_EXPDBL_MAX_EXP [...] Yet, the FP hardware is actually configured by default to provide `long double' as: #define LDBL_MANT_DIG 53 #define LDBL_MIN_EXP(-16381) #define LDBL_MAX_EXP16384 Indeed, FP code using long double generated by gcc 2.95.X, installed as the FreeBSD 4 system compiler, uses the full exponent range of -16381 to 16384. However, printf(), etc loses on that exponent range and reports Inf. I suspect this is why the system header misreports the FP hardware, thus the header describes the largest printable long double value, not the largest that could be held in a calculation. Anyways, two questions for FreeBSD maintainers. How should gcc, as provided from the FSF, describe the long double FP format for FreeBSD/i386 4.x? Shall we assume that no changes for FreeBSD 5.x will occur? Unless someone strongly prefers otherwise, the I lean towards wanting to describe the default FP hardware setup exactly and assume that libc changes to properly support long double stdio, etc will follow at some point. However, that also brings to mind: Are we happy with the current default FP hardware setup especially if support for long double is to be improved? At the moment we support long double in name only. There is no extra dynamic range over a double; as might be implied (and allowed by the hardware). Also, as an aside, having just learned everything there is to know about IEEE FP from a witty 80-slide presentation on the WWW by one of the original designers of the spec@Berkeley, I'd say that he would be sad that we default to use 53-bit precision mode. I'd say that it is dumb to claim we even support long double unless we change that to 64-bit precision mode... Regarding the comment in sys/i386/include/npx.h: * 64-bit precision often gives bad results with high level languages * because it makes the results of calculations depend on whether * intermediate values are stored in memory or in FPU registers. This is pure bunk when considered in broad context. Using 53-bit precision mode with high level languages while making actual calculations yields more outright undetectable precision-related errors due to algorithm design by non-numerical analysts. I know which error I'd rather *not* find in my naively-written and compiled FP code. People that write their FP code to correctly use epsilon (the one appropriate for the type of the float they are using) should never see this problem, no? I don't see why FreeBSD should cater to people that don't know how to write FP code properly (i.e. anyone that expected exact results across compilation switches, etc) at the expense of being able to write code that fully utilizes the best mode available from the CPU. People that absolutely want to avoid the problem of spilling from register to memory truncation changing with optimization level may feel free to allocate long doubles instead of doubles. Problem solved. Anyways, that is my quick speech in favor of change. I will help commit bits to the FSF gcc tree that supports whatever people want to do. It is easy to support one FP model for FreeBSD 4 and another for FreeBSD 5. Regards, Loren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: GCC-3.1 Optimization -Os broken
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 test cases. FYI, there are 8 C failures in the gcc 3.1 testsuite for FreeBSD/i386: 4 involve -Os (Quite sorry I never got around to fixing them before the release; I don't usually do per-CPU fixes but I could have requested help from the people that do.) 4 involve -Wformat checking not working in all cases (vfscanf only and then again only when not using the proper system headers; the test cases attempt to declare the prototypes). There are 2 C++ failures (only one of which is seen without linking against -lc_r); neither are extremely important. See http://gcc.gnu.org/ml/gcc-testresults/2002-05/msg00412.html http://gcc.gnu.org/ml/gcc-testresults/2002-05/msg00458.html FreeBSD/alpha is looking almost as good (more libgcj failures) http://gcc.gnu.org/ml/gcc-testresults/2002-05/msg00455.html http://gcc.gnu.org/ml/gcc-testresults/2002-05/msg00425.html Regards, Loren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Report on FreeBSD 4.4 pthread implementation verses boehm-gc
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 >> below). [...] > Try the following patch; this is to -current, you'll have to massage > it a bit for -stable (Hint: s/curthread/_thread_run/ in -stable). I have added Daniel's patch to my 4.4-STABLE tree (converting it as he suggested) and rebuilt libc_r.so.4. I can confirm (1) that the test case I posted now operates fine; (2) that the hack to ignore the spurious EINTR return from pthread_join() in boehm-gc is no longer required; and (3) that the more complex test case runs, on average, about 200-400 complete test cycles without deadlock compared to the past rate of deadlock of approximately 1 out of every 6-12 cycles. The rarer deadlock is still being investigated but it looks like a different problem than that addressed by Daniel's patch. I will post another test case or more information (to -hackers) once I have it. Great work Daniel. I (and future libjava users) thank you. Regards, Loren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
