Tcl Source Code: View Ticket

Ticket UUID:	748957
Title:	Tru64 cc needs -ieee flag
Type:	Bug	Version:	obsolete: 8.4.3
Submitter:	mmokrejs	Created on:	2003-06-04 15:59:05
Subsystem:	53. Configuration and Build Tools	Assigned To:	mdejong
Priority:	5 Medium	Severity:
Status:	Closed	Last Modified:	2003-06-26 04:35:50
Resolution:	Accepted	Closed By:	mdejong
		Closed on:	2003-06-25 18:57:54
Description:	Hi, I have compiled tcl8.4.3 on Tru64Unix (formerly OSF1) and make test fails in many cases. Would someone inspect the output? Thanks! I used cc/cxx from vendor, latest version, C*FLAGS"-O2 -arch ev56" if that matters. The original bugreport is at https://sourceforge.net/tracker/?func=detail&atid=110894&aid=748804&group_id=10894 ==== parseExpr-16.11 GetLexeme procedure, bad double lexeme too big FAILED ==== Contents of test case: list [catch {testexprparser {123.e+99999999999999} -1} msg] $msg ---- Result was: 1 {syntax error in expression "123.e+99999999999999": character not legal in expressions} ---- Result should have been (exact matching): 1 {floating-point value too large to represent} ==== parseExpr-16.11 FAILED
User Comments:	mdejong added on 2003-06-26 04:35:50: Logged In: YES user_id=90858 Nope, no reason. The change has now been cheked into core-8-4-branch. dgp added on 2003-06-26 03:16:42: Logged In: YES user_id=80530 thanks for taking care of this. Any reason not to back-port the fix to the core-8-4-branch as well? mdejong added on 2003-06-26 01:57:55: File Deleted - 54011: File Added - 54110: osf.patch mdejong added on 2003-06-26 01:57:54: Logged In: YES user_id=90858 Ok, I checked those changes into the CVS. mmokrejs added on 2003-06-26 01:46:55: Logged In: YES user_id=696559 Pass -ieee to cc. Pass -mieee to gcc. mdejong added on 2003-06-26 01:37:14: Logged In: YES user_id=90858 I don't understand what you just wrote. Are you saying that the -ieee flag should be passed to both cc and gcc for this platform? Are you saying the exact opposite? What exactly would fix the gcc compiled version on this system? mmokrejs added on 2003-06-25 18:30:22: Logged In: YES user_id=696559 So, I applied the patch to my old cvs checkout, config.status says: s,@EXTRA_CFLAGS@,-DHAVE_TZSET -std1 -ieee,;t t parseExpr.test succeeds. Please commit to configure.in and regenerate configure in cvs. Yes, it does not affect gcc - i.e. the -ieee is not passwed to gcc. But, the test fails with gcc: parseExpr.test ==== parseExpr-16.11 GetLexeme procedure, bad double lexeme too big FAILED ==== Contents of test case: list [catch {testexprparser {123.e+99999999999999} -1} msg] $msg ---- Result was: 1 {syntax error in expression "123.e+99999999999999": character not legal in expressions} ---- Result should have been (exact matching): 1 {floating-point value too large to represent} ==== parseExpr-16.11 FAILED Setting manually s,@EXTRA_CFLAGS@,-mieee,;t t while using gcc to compile, the parseExpr.test passes. So please fix also this case. mdejong added on 2003-06-25 01:36:11: File Added - 54011: osf.patch Logged In: YES user_id=90858 Ok, I have attached a patch for the current CVS that should fix the problem. Could you get the CVS version, apply the patch and test it out on your system to make sure it works? This patch assumes that the problem does not show up when compiling with gcc on this system, is that correct? dgp added on 2003-06-24 21:45:38: Logged In: YES user_id=80530 Just to clarify, this is not about adding a library to be linked. It is about adding a switch during compile. That is, the issue is a -ieee compile option, not a -lieee argument to the linker. I think (not certain) it is analogous to the -mieee compile switch we take care of on the Linux/Alpha platform. mmokrejs added on 2003-06-24 16:35:54: File Added - 53982: config.log Logged In: YES user_id=696559 serow# uname -a OSF1 serow.gsf.de V5.1 1885 alpha alpha unknown Tru64 serow# uname -s OSF1 serow# uname -r V5.1 serow# $ CC=cc CXX=cxx ./configure --prefix=/software/@sys/usr creating cache ./config.cache checking whether to use symlinks for manpages... no checking compression for manpages... no checking for gcc... cc checking whether the C compiler (cc -O2 -arch ev56 ) works... yes checking whether the C compiler (cc -O2 -arch ev56 ) is a cross-compiler... no checking whether we are using GNU C... no checking whether cc accepts -g... yes checking how to run the C preprocessor... cc -E checking for unistd.h... yes checking for limits.h... yes checking for building with threads... no (default) checking for required early compiler flags... none checking for 64-bit integer type... using long checking whether byte ordering is bigendian... no checking for getcwd... yes checking for opendir... yes checking for strstr... yes checking for strtol... yes checking for strtoll... no checking for strtoull... no checking for tmpnam... yes checking for waitpid... yes checking for strerror... yes checking for getwd... yes checking for wait3... yes checking for uname... yes checking for realpath... yes checking dirent.h... yes checking for errno.h... yes checking for float.h... yes checking for values.h... yes checking for limits.h... (cached) yes checking for stdlib.h... yes checking for string.h... yes checking for sys/wait.h... yes checking for dlfcn.h... yes checking for unistd.h... (cached) yes checking for sys/param.h... yes checking for sys/modem.h... no checking termios vs. termio vs. sgtty... termios checking for fd_set in sys/types... yes checking whether struct tm is in sys/time.h or time.h... time.h checking for sys/time.h... yes checking whether time.h and sys/time.h may both be included... yes checking for tm_zone in struct tm... yes checking for gmtime_r... yes checking for localtime_r... yes checking tm_tzadj in struct tm... no checking tm_gmtoff in struct tm... yes checking long timezone variable... yes checking for st_blksize in struct stat... yes checking for fstatfs... yes checking for 8-bit clean memcmp... yes checking for memmove... yes checking proper strstr implementation... yes checking for strtoul... yes checking for strtod... yes checking for strtod... (cached) yes checking for Solaris2.4/Tru64 strtod bugs... ok checking for ANSI C header files... yes checking for mode_t... yes checking for pid_t... yes checking for size_t... yes checking for uid_t in sys/types.h... yes checking for socklen_t... no checking for opendir... (cached) yes checking union wait... no checking for strncasecmp... yes checking for BSDgettimeofday... no checking for gettimeofday... yes checking for gettimeofday declaration... present checking whether char is unsigned... no checking signed char declarations... yes checking for a putenv() that copies the buffer... no checking for langinfo.h... yes checking whether to use nl_langinfo... yes checking for sin... no checking for main in -lieee... no checking for main in -linet... no checking for net/errno.h... no checking for connect... yes checking for gethostbyname... yes checking how to build libraries... shared checking for ranlib... ranlib checking if 64bit support is requested... no checking if 64bit Sparc VIS support is requested... no checking system version (for dynamic loading)... OSF1-V5.1 checking for dlopen in -ldl... no checking for ar... ar checking for build with symbols... no checking for sys/ioctl.h... yes checking for sys/filio.h... no checking FIONBIO vs. O_NONBLOCK for nonblocking I/O... FIONBIO checking how to package libraries... standard shared library updating cache ./config.cache creating ./config.status creating Makefile creating dltest/Makefile creating tclConfig.sh $ I'm attaching config.log output. The -ieee is a compiler flag(below is a snippet from cc(1) manpage): -ieee Ensure support of all portable features of the IEEE Standard for Binary Floating-Point Arithmetic (ANSI/IEEE Std 754-1985), including the treatment of denormalized numbers, NaNs, and infinities and the han- dling of error cases. This option also sets the _IEEE_FP C preproces- sor macro. If your program must use IEEE signaling features that are not portable across different IEEE implementations, see the ieee(3) reference page for a discussion of how to access them under the Tru64 UNIX operating system. There's no library libieee.* anywhere. The ieee.3 manpage says: ieee(3) ieee(3) NAME ieee, ieee_set_fp_control, ieee_get_fp_control, ieee_set_state_at_signal, ieee_get_state_at_signal, ieee_ignore_state_at_signal - libc ieee trap enable support routines. LIBRARY Standard C Library (libc.so, libc.a) SYNOPSIS #include <machine/fpu.h> void ieee_set_fp_control( unsigned long fp_control); unsigned long ieee_get_fp_control(); void ieee_set_state_at_signal( unsigned long fp_control, unsigned long fpcr); int ieee_get_state_at_signal( unsigned long fp_control, unsigned long fpcr); void ieee_ignore_state_at_signal(); PARAMETERS fp_control Software IEEE floating-point control. fpcr Hardware IEEE floating-point control register. DESCRIPTION These routines support the implementation of the IEEE Standard for Binary Floating-Point Arithmetic. IEEE-format floating-point operations are subject to the following traps: o Invalid operation o Division by zero o Overflow o Underflow o Inexact result (Note that floating-point-to-integer conversion operations may generate an integer overflow trap, which the operating system traps and delivers as an invalid operation.) By default, floating-point operations generate imprecise traps for invalid operation, division by zero, and overflow errors. To cause floating-point errors to be handled with precise exception faults, or with the signal han- dling specified in the IEEE floating-point standard, C language programmers should use the -ieee flag to the cc command. Assembly language programmers should use the su suffix on floating-point instruction opcodes and follow the software completion rules of the Alpha architecture. These methods allow you to access all features of the IEEE standard except the inexact result feature. The inexact result feature can sometimes degrade performance, so a differ- ent method is required to enable it. Assembly language programmers can access the inexact result feature by using the sui suffix on floating-point instruction opcodes. C language programmers can access the inexact result feature by replacing the -ieee flag to the cc command with the -ieee_with_inexact flag. On some Alpha implementations the inexact result feature is implemented by trapping to a software emulator. Using sui floating-point instructions or the -ieee_with_inexact flag might cause a significant drop in performance on such implementations. Because of this, you should use the inexact result feature only in those few program state- ments where inexact signaling is needed. When your code is compiled with ieee or ieee_with_inexact, the delivery of all floating-point traps to a user program is disabled by default. A user program can request the delivery of any of the five standard IEEE traps by calling ieee_set_fp_control to set the associated flags in the software IEEE floating-point control register (fp_control) that control trap deliv- ery. And, in a similar way, a user program can request delivery of an invalid operation trap whenever a denormalized operand is used. When the IEEE gradual underflow capability (that is, denormalized operands and results) is not desired, it can be disabled by specifying one or both of the options to map denormalized input operands to zero or to flush underflowing results to zero. The following constants are defined in machine/fpu.h and can be used to construct an appropriate set mask in the fp_control argument to an ieee_set_fp_control call: ------------------------------------------------- Constant Meaning ------------------------------------------------- IEEE_TRAP_ENABLE_INV Invalid operation IEEE_TRAP_ENABLE_DZE Divide by 0 IEEE_TRAP_ENABLE_OVF Overflow IEEE_TRAP_ENABLE_UNF Underflow IEEE_TRAP_ENABLE_INE Inexact IEEE_TRAP_ENABLE_DNO denormal operand IEEE_TRAP_ENABLE_MASK mask of all the trap enables IEEE_MAP_DMZ map denormal inputs to zero IEEE_MAP_UMZ map underflow results to zero ------------------------------------------------- The fp_control, which can be read by means of ieee_get_fp_control, also contains status flags which, when set, indicate one or more occurrences of individual floating-point exception conditions. These flags remain set until a user program explicitly clears them by calling ieee_set_fp_control. To allow manipulation of these flags, the following constants are defined in machine/fpu.h: ------------------------------------------ Constant Meaning ------------------------------------------ IEEE_STATUS_INV Invalid operation IEEE_STATUS_DZE Divide by 0 IEEE_STATUS_OVF Overflow IEEE_STATUS_UNF Underflow IEEE_STATUS_INE Inexact IEEE_STATUS_DNO denormal operand IEEE_STATUS_MASK mask of all the status flags ------------------------------------------ At thread creation (and process creation as a result of an exec(2) call), the delivery of all-floating point traps is disabled and all floating-point exception status flags in the fp_control are clear. If the thread creating the new process has set the inherit bit in its fp_control (by specifying the constant IEEE_INHERIT in the fp_control mask to an ieee_set_fp_control call), the newly-created process will inherit its creator's fpcr and fp_control settings. At a fork(2) call, the child process always inherits its parent's fp_con- trol and fpcr settings, regardless of the setting of the inherit bit. Users should be careful to remember that setting the bits in the fp_con- trol, like setting signal handlers, will affect other code within their thread. A user program calls ieee_get_fp_control to obtain a copy of the current fp_control. Additionally, the jmp_buf argument for setjmp(3), which uses struct sigcontext from signal(4) as an overlay, provides an sc_fp_control field. When a user program issues a longjmp(3) or sigreturn(2), the sc_fp_control includes the current set of trap flags. The IEEE standard specifies default result values (including denormalized numbers, NaNs, and infinities) for operations that cause traps that are not user-enabled. An operating system trap handler must "complete" these opera- tions by supplying the default IEEE result. For the operating system to properly fix the results of these operations, the code must be generated as resumption safe and software completion must be specified in the trapping mode. The concept of resumption-safe code warrants further explanation. Because Compaq Alpha systems incorporate pipelining and multi-instruction issue techniques, when an arithmetic exception occurs, the program counter may not contain the address of the instruction that actually caused the trap (referred to as the trigger PC). It may instead contain the address of the instruction that was executing at the time the trap was executed (referred to as the trap PC). Several intervening instructions may have been present and could have changed the machine state from what it was at the time of the exception. The instructions between the trigger PC and the trap PC are called the trap shadow. The Alpha Architecture Reference Manual specifies conventions for creating the trap shadow so that the operating system trap handler can provide an IEEE result value for an operation and continue execution. The architec- ture provides a way for software to mark instructions which abide by the conventions and a user may request this of the compiler driver (cc(1)) by specifying the -ieee flag on the command line. To determine which exception occurred, the operating system trap handler must back up instructions and look for the trigger PC. Once it finds the trigger PC, the software may need to re-execute or emulate the trigger instruction to determine which trap it actually caused. Once the validity of the trap shadow and the trigger exception is deter- mined, the operating system can then decide what to do when an exception occurs, depending on three factors: o Whether the user program has set any of the trap-enable flags in fp_control o Whether the user program has been created as resumption safe code o Whether the user program has specified a handler for SIGFPE, has decided to ignore the signal (SIG_IGN), or has accepted the signal's default treatment (SIG_DFL) The following table describes the system's actions based on these three factors: --------------------------------------------------------------- SIGFPE Trap enable Shadow Actions --------------------------------------------------------------- SIG_IGN clear invalid Continue at trap PC + 4. SIG_DFL clear invalid Cause core dump. SIG_IGN\|SIG_DFL clear safe Supply default IEEE result value and con- tinue at trig- ger PC + 4. SIG_IGN set invalid Continue at trap PC + 4. SIG_DFL set invalid Cause core dump. SIG_IGN set safe Supply default IEEE result value and con- tinue at trig- ger PC + 4. SIG_DFL set safe Cause core dump. user handler clear invalid Deliver SIGFPE to user pro- gram. user handler clear safe Supply default IEEE result value and con- tinue at trig- ger PC + 4. user handler set invalid Deliver SIGFPE to user pro- gram, trap PC == trigger PC, and set ieee_invalid_shadow. user handler set safe Deliver SIGFPE to user program and trap PC != trigger PC. --------------------------------------------------------------- See signal(4) for additional information on default actions for SIGFPE. A SIGFPE handler can also obtain additional information about floating- point exceptions from the sigcontext. The sigcontext contains a copy of the current fp_control in sc_fp_control, allowing a handler to determine which traps were enabled at the time of the exception. On precise floating faults (in which the system trap handler has indicated a valid trap shadow and executed successfully), indicated by codes FPE_xxxxx_FAULT, relevant sigcontext fields contain the following informa- tion: o sc_traparg_a0 contains the exception summary register reported by hardware. o sc_traparg_a1 contains the exception register write mask reported by hardware. o sc_fp_trap_pc contains the trap PC. o sc_pc contains the trigger PC. o sc_fp_trigger_sum contains the exception summary register reported by hardware with the SWC bit masked off. o sc_fp_trigger_inst is a copy of the trigger instruction. On precise arithmetic faults with valid trap shadows, the result register of the faulting instruction is loaded with the IEEE floating-point result that would have been generated if the exception had not been signaled. One way to continue from such a fault is to increment sc_pc by 4 and continue with this result (or some modification of it). Another way to continue from a precise fault is to modify the input registers to the floating oper- ation, leave the sc_pc field unchanged, and then reexecute the faulting instruction with the modified input. On imprecise arithmetic traps (for instance, when an invalid trap shadow has been detected), indicated by codes FPE_xxxxx_TRAP, sigcontext provides the same information, with the following differences: o sc_pc contains the trap PC. o sc_fp_trigger_inst is undefined. By default, the exception state at the time of a floating-point exception, as represented by the fp_control and fpcr, is the state provided to a sig- nal handler. The ieee_set_state_at_signal routine allows a user program to specify the values to be placed in the fp_control and the fpcr at the call to a signal handler. This enables the program to easily modify the trap enables or rounding modes so that a critical region (for instance, in third-party code executed from a signal handler) is immune from certain exception state. The original settings of the fp_control and the fpcr are saved in the sigcon- text prior to the signal. When the handler returns, the original floating- point context is restored. A user program can retrieve the current exception state reporting behavior by calling ieee_get_state_at_signal. The ieee_ignore_state_at_signal routine specifies that floating-point state is not modified when calling a signal handler. A user program calls this routine to restore the default exception state reporting behavior. FILES usr/include/excpt.h - include file usr/include/signal.h - include file usr/include/machine/fpu.h - include file RELATED INFORMATION Commands: cc(1). Functions: exec(2), ieee_functions(3), longjmp(3), setjmp(3), sigreturn(2), write_rnd(3). Files: c_excpt(4), excpt(4), signal(4). IEEE Standard for Binary Floating-Point Arithmetic (ANSI/IEEE Std 754-1985). Alpha Architecture Reference Manual. Assembly Language Programmer's Guide. Programmer's Guide. mdejong added on 2003-06-24 15:37:08: Logged In: YES user_id=90858 Well, what does the configure script say about finding the -lieee at configure time? This check is currently in the tcl.m4 macro SC_TCL_LINK_LIBS: AC_CHECK_FUNC(sin, MATH_LIBS="", MATH_LIBS="-lm") AC_CHECK_LIB(ieee, main, [MATH_LIBS="-lieee $MATH_LIBS"]) So, it should be including the -lieee lib if it is found on the system already. Also, could you post what your system returns as the results of the following commands: uname -s uname -r dgp added on 2003-06-11 23:35:30: Logged In: YES user_id=80530 Thank you for the testing. It looks like configure needs to detect your platform and add "-ieee" to the set of compile flags when compiling Tcl. Passing on to our configure expert, who may need further testing from you. mmokrejs added on 2003-06-11 15:27:56: Logged In: YES user_id=696559 $ cc test.c $ ./a.out Value of 123.e+99999999999999 is 1.79769e+308 Bytes consumed: 0 Errno: 0 $ $ cc -ieee test.c $ ./a.out Value of 123.e+99999999999999 is INF Bytes consumed: 20 Errno: 0 $ $ gcc test.c $ ./a.out Value of 123.e+99999999999999 is 1.79769e+308 Bytes consumed: 0 Errno: 0 $ dgp added on 2003-06-11 04:14:07: File Added - 52716: test.c dgp added on 2003-06-11 04:14:01: Logged In: YES user_id=80530 here's a test file to compile and run. post the output here please. mmokrejs added on 2003-06-06 15:47:23: Logged In: YES user_id=696559 If you tell me how to check that (i.e. provide the C code, I can compile and post results). ;-) dgp added on 2003-06-06 00:11:04: Logged In: YES user_id=80530 can you check what strtod("123.e+99999999999999", &termPtr); returns on your system? Both the (double) return value and the (char *) termPtr. Also does errno get set? to what? It appears that strtod on your system may not be setting errno to ERANGE on overflow? mmokrejs added on 2003-06-05 18:58:53: Logged In: YES user_id=696559 At least current cvs tcl/configure says: checking for strtod... yes checking for strtod... (cached) yes checking for Solaris2.4/Tru64 strtod bugs... ok dgp added on 2003-06-04 23:17:44: Logged In: YES user_id=80530 suspect platform-dependent badness in strtod()

Attachments:

osf.patch [download] added by mdejong on 2003-06-26 01:57:54. [details]
config.log [download] added by mmokrejs on 2003-06-24 16:35:54. [details]
test.c [download] added by dgp on 2003-06-11 04:14:05. [details]