public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
* fortran integer sizes on linux AXP @ 1999-03-04 0:05 Martin Kahlert 1999-03-31 23:54 ` Dave Love 0 siblings, 1 reply; 36+ messages in thread From: Martin Kahlert @ 1999-03-04 0:05 UTC (permalink / raw) To: egcs-bugs [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 16396 bytes --] Hi! Three snapshots ago i complained about this bug in g77 write(*,*) 'Hello World' end on Linux Alpha. If you run the executable, it seg-faults. I was told to use Richard Henderson's patch (integer sizes for libf2c) but that didn't work either. Yesterday i gave egcs-19990228 a try and it seems to me, that this patch is already included there, but the problem remains. Perhaps i do something silly. Here is the script i use for compilation: #!/bin/sh CFLAGS='-O3 -fomit-frame-pointer' export CFLAGS ../egcs-19990228/configure --prefix=/sw/snapshots --enable-shared gmake LANGUAGES='c c++ f77' CFLAGS='-O3 -fomit-frame-pointer' LIBCFLAGS='-O3 -fomit-frame-pointer' LIBCXXFLAGS='-O3 -fno-implicit-templates -fomit-frame-pointer' bootstrap-lean I suppose, there are problems left in the configure script of libf2c: I append the file config.cache from that subdir. It contains these (bad?) lines: g77_cv_sys_f2cinteger=${g77_cv_sys_f2cinteger='long int'} g77_cv_sys_f2clongint=${g77_cv_sys_f2clongint='long long int'} I think writing call f(string) calls a C function like f_(char *string,int len), but not f_(char *string,long int len). (Why?) But i don't know exactly how this is meant to work. What can i do to successfully use Fortran with snapshots again? Thanks in advance, Martin. Here comes my config.cache: # This file is a shell script that caches the results of configure # tests run on this system so they can be shared between configure # scripts and configure runs. It is not useful on other systems. # If it contains results you don't want to keep, you may remove or edit it. # # By default, configure uses ./config.cache as the cache file, # creating it if it does not exist already. You can give configure # the --cache-file=FILE option to use a different cache file; that is # what configure does when it calls configure scripts in # subdirectories, so they share the cache. # Giving --cache-file=/dev/null disables caching, for debugging configure. # config.status only pays attention to the cache file if you give it the # --recheck option to rerun configure. # ac_cv_c_const=${ac_cv_c_const='yes'} ac_cv_c_cross=${ac_cv_c_cross='no'} ac_cv_func_alarm=${ac_cv_func_alarm='yes'} ac_cv_func_clock=${ac_cv_func_clock='yes'} ac_cv_func_fstat=${ac_cv_func_fstat='yes'} ac_cv_func_getcwd=${ac_cv_func_getcwd='yes'} ac_cv_func_getgid=${ac_cv_func_getgid='yes'} ac_cv_func_gethostname=${ac_cv_func_gethostname='yes'} ac_cv_func_getlogin=${ac_cv_func_getlogin='yes'} ac_cv_func_getrusage=${ac_cv_func_getrusage='yes'} ac_cv_func_gettimeofday=${ac_cv_func_gettimeofday='yes'} ac_cv_func_getuid=${ac_cv_func_getuid='yes'} ac_cv_func_getwd=${ac_cv_func_getwd='yes'} ac_cv_func_kill=${ac_cv_func_kill='yes'} ac_cv_func_link=${ac_cv_func_link='yes'} ac_cv_func_lstat=${ac_cv_func_lstat='yes'} ac_cv_func_strerror=${ac_cv_func_strerror='yes'} ac_cv_func_symlink=${ac_cv_func_symlink='yes'} ac_cv_func_tempnam=${ac_cv_func_tempnam='yes'} ac_cv_func_times=${ac_cv_func_times='yes'} ac_cv_func_ttyname=${ac_cv_func_ttyname='yes'} ac_cv_header_fcntl_h=${ac_cv_header_fcntl_h='yes'} ac_cv_header_limits_h=${ac_cv_header_limits_h='yes'} ac_cv_header_stdc=${ac_cv_header_stdc='yes'} ac_cv_header_stdio_h=${ac_cv_header_stdio_h='yes'} ac_cv_header_stdlib_h=${ac_cv_header_stdlib_h='yes'} ac_cv_header_string_h=${ac_cv_header_string_h='yes'} ac_cv_header_sys_param_h=${ac_cv_header_sys_param_h='yes'} ac_cv_header_sys_time_h=${ac_cv_header_sys_time_h='yes'} ac_cv_header_sys_times_h=${ac_cv_header_sys_times_h='yes'} ac_cv_header_time=${ac_cv_header_time='yes'} ac_cv_header_unistd_h=${ac_cv_header_unistd_h='yes'} ac_cv_lib_m_drem=${ac_cv_lib_m_drem='yes'} ac_cv_lib_socket_gethostname=${ac_cv_lib_socket_gethostname='no'} ac_cv_path_ac_cv_prog_chmod=${ac_cv_path_ac_cv_prog_chmod='/bin/chmod'} ac_cv_prog_CC=${ac_cv_prog_CC='/home/martin/obj/gcc/xgcc -B/home/martin/obj/gcc/ -B/sw/snapshots/alphaev56-unknown-linux-gnu/bin/'} ac_cv_prog_CPP=${ac_cv_prog_CPP='/home/martin/obj/gcc/xgcc -B/home/martin/obj/gcc/ -B/sw/snapshots/alphaev56-unknown-linux-gnu/bin/ -E'} ac_cv_prog_cc_cross=${ac_cv_prog_cc_cross='no'} ac_cv_prog_cc_g=${ac_cv_prog_cc_g='yes'} ac_cv_prog_cc_works=${ac_cv_prog_cc_works='yes'} ac_cv_prog_chmod=${ac_cv_prog_chmod='/bin/chmod'} ac_cv_prog_gcc=${ac_cv_prog_gcc='yes'} ac_cv_prog_make_make_set=${ac_cv_prog_make_make_set='yes'} ac_cv_struct_st_blksize=${ac_cv_struct_st_blksize='yes'} ac_cv_struct_st_blocks=${ac_cv_struct_st_blocks='yes'} ac_cv_struct_st_rdev=${ac_cv_struct_st_rdev='yes'} ac_cv_struct_tm=${ac_cv_struct_tm='time.h'} ac_cv_type_mode_t=${ac_cv_type_mode_t='yes'} ac_cv_type_pid_t=${ac_cv_type_pid_t='yes'} ac_cv_type_signal=${ac_cv_type_signal='void'} ac_cv_type_size_t=${ac_cv_type_size_t='yes'} f77_cv_compiler_exists=${f77_cv_compiler_exists='yes'} g77_cv_header_posix=${g77_cv_header_posix='yes'} g77_cv_lib_gnu=${g77_cv_lib_gnu='yes'} g77_cv_sys_cygwin32=${g77_cv_sys_cygwin32='no'} g77_cv_sys_f2cinteger=${g77_cv_sys_f2cinteger='long int'} g77_cv_sys_f2clongint=${g77_cv_sys_f2clongint='long long int'} g77_cv_sys_mingw32=${g77_cv_sys_mingw32='no'} g77_cv_sys_sprintf_ansi=${g77_cv_sys_sprintf_ansi='yes'} -- Your mouse has moved. Windows must be restarted for the change to take effect. Reboot now? >From martin@mira.isdn.cs.tu-berlin.de Thu Mar 04 00:49:00 1999 From: "Martin v. Loewis" <martin@mira.isdn.cs.tu-berlin.de> To: nbecker@fred.net Cc: egcs-bugs@cygnus.com, loewis@informatik.hu-berlin.de Subject: Re: sorry, not implemented: `namespace_decl' not supported by dump_type Date: Thu, 04 Mar 1999 00:49:00 -0000 Message-id: <199903040842.JAA00631@mira.isdn.cs.tu-berlin.de> In-reply-to: < 874so1gbiv.fsf@nbecker.fred.net > (message from Neal Becker on 03Mar 1999 22:48:56 -0500) References: <874so1gbiv.fsf@nbecker.fred.net> <874so1gbiv.fsf@nbecker.fred.net> X-SW-Source: 1999-03/msg00153.html Content-length: 962 > Include/CXX_Objects.h:948: sorry, not implemented: `namespace_decl' > not supported by dump_type Thanks for your bug report. What you are seeing is a combination of two bugs. I believe one was fixed with 1998-09-08 Martin von Löwis <loewis@informatik.hu-berlin.de> * decl.c (make_typename_type): If context is a namespace, the code is in error. in the development branch; the current compiler gives Include/CXX_Objects.h:948: no class template named `iterator' in `std' (I haven't checked whether this is really the right patch). Now, egcs currently doesn't provide std::iterator, because the library is not in std::, and SGI decided that we shouldn't put 'iterator' in the global namespace. There is an easy work-around: If you compile with g++ (or any other copy of SGI STL), you can use std::random_access_iterator<seqref<T>, int> instead of public std::iterator<std::random_access_iterator_tag, seqref<T>,int> Hope this helps, Martin >From root@ihack.net Thu Mar 04 02:04:00 1999 From: "Charles M. Hannum" <root@ihack.net> To: egcs-bugs@egcs.cygnus.com, bug-gcc@prep.ai.mit.edu Cc: felix@dworkin.nl, lehotsky@mc.com Subject: Re: Masked bitfield comparisons may yield incorrect results Date: Thu, 04 Mar 1999 02:04:00 -0000 Message-id: <199903041003.FAA25336@trinity.ihack.net> X-SW-Source: 1999-03/msg00154.html Content-length: 9143 It turns out there's at least one more bug in fold_truthop(). It's possible for the combined ll_mask and lr_mask to be identical, but for the bitfields being compared to be shifted in different positions. Tests g4-g7 and h4-h7 in the expanded test program below reproduce this condition. The correct output for these cases is: g4: 0 g5: 0 g6: 1 g7: 1 h4: 0 h5: 0 h6: 1 h7: 1 The incorrect output on sparc--netbsd1.3I, with my previous patch applied, looks like: g4: 0 g5: 1 g6: 1 g7: 0 h4: 1 h5: 0 h6: 0 h7: 1 (On a little endian machine, the result of each test is inverted.) A patch to fix this problem is attached. This patch also generates more efficient code in some of the other cases, by eliminating shifts. ----- truth-test.c ---------snip-----8<-----snip-----8<-----snip-----8<----- #include <stdio.h> struct a { char a, b; short c; }; int a1() { static struct a x = { 1, 2, ~1 }, y = { 65, 2, ~2 }; return (x.a == (y.a & ~64) && x.b == y.b); } int a2() { static struct a x = { 1, 66, ~1 }, y = { 1, 2, ~2 }; return (x.a == y.a && (x.b & ~64) == y.b); } int a3() { static struct a x = { 9, 66, ~1 }, y = { 33, 18, ~2 }; return ((x.a & ~8) == (y.a & ~32) && (x.b & ~64) == (y.b & ~16)); } struct b { int c; short b, a; }; int b1() { static struct b x = { ~1, 2, 1 }, y = { ~2, 2, 65 }; return (x.a == (y.a & ~64) && x.b == y.b); } int b2() { static struct b x = { ~1, 66, 1 }, y = { ~2, 2, 1 }; return (x.a == y.a && (x.b & ~64) == y.b); } int b3() { static struct b x = { ~1, 66, 9 }, y = { ~2, 18, 33 }; return ((x.a & ~8) == (y.a & ~32) && (x.b & ~64) == (y.b & ~16)); } struct c { unsigned int c:4, b:14, a:14; }; int c1() { static struct c x = { ~1, 2, 1 }, y = { ~2, 2, 65 }; return (x.a == (y.a & ~64) && x.b == y.b); } int c2() { static struct c x = { ~1, 66, 1 }, y = { ~2, 2, 1 }; return (x.a == y.a && (x.b & ~64) == y.b); } int c3() { static struct c x = { ~1, 66, 9 }, y = { ~2, 18, 33 }; return ((x.a & ~8) == (y.a & ~32) && (x.b & ~64) == (y.b & ~16)); } struct d { unsigned int a:14, b:14, c:4; }; int d1() { static struct d x = { 1, 2, ~1 }, y = { 65, 2, ~2 }; return (x.a == (y.a & ~64) && x.b == y.b); } int d2() { static struct d x = { 1, 66, ~1 }, y = { 1, 2, ~2 }; return (x.a == y.a && (x.b & ~64) == y.b); } int d3() { static struct d x = { 9, 66, ~1 }, y = { 33, 18, ~2 }; return ((x.a & ~8) == (y.a & ~32) && (x.b & ~64) == (y.b & ~16)); } struct e { int c:4, b:14, a:14; }; int e1() { static struct e x = { ~1, -2, -65 }, y = { ~2, -2, -1 }; return (x.a == (y.a & ~64) && x.b == y.b); } int e2() { static struct e x = { ~1, -2, -1 }, y = { ~2, -66, -1 }; return (x.a == y.a && (x.b & ~64) == y.b); } int e3() { static struct e x = { ~1, -18, -33 }, y = { ~2, -66, -9 }; return ((x.a & ~8) == (y.a & ~32) && (x.b & ~64) == (y.b & ~16)); } struct f { int a:14, b:14, c:4; }; int f1() { static struct f x = { -65, -2, ~1 }, y = { -1, -2, ~2 }; return (x.a == (y.a & ~64) && x.b == y.b); } int f2() { static struct f x = { -1, -2, ~1 }, y = { -1, -66, ~2 }; return (x.a == y.a && (x.b & ~64) == y.b); } int f3() { static struct f x = { -33, -18, ~1 }, y = { -9, -66, ~2 }; return ((x.a & ~8) == (y.a & ~32) && (x.b & ~64) == (y.b & ~16)); } struct gx { int c:4, b:14, a:14; }; struct gy { int b:14, a:14, c:4; }; int g1() { static struct gx x = { ~1, -2, -65 }; static struct gy y = { -2, -1, ~2 }; return (x.a == (y.a & ~64) && x.b == y.b); } int g2() { static struct gx x = { ~1, -2, -1 }; static struct gy y = { -66, -1, ~2 }; return (x.a == y.a && (x.b & ~64) == y.b); } int g3() { static struct gx x = { ~1, -18, -33 }; static struct gy y = { -66, -9, ~2 }; return ((x.a & ~8) == (y.a & ~32) && (x.b & ~64) == (y.b & ~16)); } int g4() { static struct gx x = { ~1, 0x0020, 0x0010 }; static struct gy y = { 0x0200, 0x0100, ~2 }; return ((x.a & 0x00f0) == (y.a & 0x0f00) && (x.b & 0x00f0) == (y.b & 0x0f00)); } int g5() { static struct gx x = { ~1, 0x0200, 0x0100 }; static struct gy y = { 0x0020, 0x0010, ~2 }; return ((x.a & 0x0f00) == (y.a & 0x00f0) && (x.b & 0x0f00) == (y.b & 0x00f0)); } int g6() { static struct gx x = { ~1, 0xfe20, 0xfd10 }; static struct gy y = { 0xc22f, 0xc11f, ~2 }; return ((x.a & 0x03ff) == (y.a & 0x3ff0) && (x.b & 0x03ff) == (y.b & 0x3ff0)); } int g7() { static struct gx x = { ~1, 0xc22f, 0xc11f }; static struct gy y = { 0xfe20, 0xfd10, ~2 }; return ((x.a & 0x3ff0) == (y.a & 0x03ff) && (x.b & 0x3ff0) == (y.b & 0x03ff)); } struct hx { int a:14, b:14, c:4; }; struct hy { int c:4, a:14, b:14; }; int h1() { static struct hx x = { -65, -2, ~1 }; static struct hy y = { ~2, -1, -2 }; return (x.a == (y.a & ~64) && x.b == y.b); } int h2() { static struct hx x = { -1, -2, ~1 }; static struct hy y = { ~2, -1, -66 }; return (x.a == y.a && (x.b & ~64) == y.b); } int h3() { static struct hx x = { -33, -18, ~1 }; static struct hy y = { ~2, -9, -66 }; return ((x.a & ~8) == (y.a & ~32) && (x.b & ~64) == (y.b & ~16)); } int h4() { static struct hx x = { 0x0010, 0x0020, ~1 }; static struct hy y = { ~2, 0x0100, 0x0200 }; return ((x.a & 0x00f0) == (y.a & 0x0f00) && (x.b & 0x00f0) == (y.b & 0x0f00)); } int h5() { static struct hx x = { 0x0100, 0x0200, ~1 }; static struct hy y = { ~2, 0x0010, 0x0020 }; return ((x.a & 0x0f00) == (y.a & 0x00f0) && (x.b & 0x0f00) == (y.b & 0x00f0)); } int h6() { static struct hx x = { 0xfd10, 0xfe20, ~1 }; static struct hy y = { ~2, 0xc11f, 0xc22f }; return ((x.a & 0x03ff) == (y.a & 0x3ff0) && (x.b & 0x03ff) == (y.b & 0x3ff0)); } int h7() { static struct hx x = { 0xc11f, 0xc22f, ~1 }; static struct hy y = { ~2, 0xfd10, 0xfe20 }; return ((x.a & 0x3ff0) == (y.a & 0x03ff) && (x.b & 0x3ff0) == (y.b & 0x03ff)); } int main() { printf("a1: %d\n", a1()); printf("a2: %d\n", a2()); printf("a3: %d\n", a3()); printf("b1: %d\n", b1()); printf("b2: %d\n", b2()); printf("b3: %d\n", b3()); printf("c1: %d\n", c1()); printf("c2: %d\n", c2()); printf("c3: %d\n", c3()); printf("d1: %d\n", d1()); printf("d2: %d\n", d2()); printf("d3: %d\n", d3()); printf("e1: %d\n", e1()); printf("e2: %d\n", e2()); printf("e3: %d\n", e3()); printf("f1: %d\n", f1()); printf("f2: %d\n", f2()); printf("f3: %d\n", f3()); printf("g1: %d\n", g1()); printf("g2: %d\n", g2()); printf("g3: %d\n", g3()); printf("g4: %d\n", g4()); printf("g5: %d\n", g5()); printf("g6: %d\n", g6()); printf("g7: %d\n", g7()); printf("h1: %d\n", h1()); printf("h2: %d\n", h2()); printf("h3: %d\n", h3()); printf("h4: %d\n", h4()); printf("h5: %d\n", h5()); printf("h6: %d\n", h6()); printf("h7: %d\n", h7()); } -----8<-----snip-----8<-----snip-----8<-----snip-----8<-----snip-----8<----- ----- truth-patch-2 --------snip-----8<-----snip-----8<-----snip-----8<----- Index: fold-const.c =================================================================== RCS file: /cvsroot/src/gnu/dist/gcc/fold-const.c,v retrieving revision 1.2 diff -c -2 -r1.2 fold-const.c *** fold-const.c 1999/03/04 05:38:06 1.2 --- fold-const.c 1999/03/04 09:44:26 *************** *** 3645,3664 **** /* Make a mask that corresponds to both fields being compared. ! Do this for both items being compared. If the masks agree, ! we can do this by masking both and comparing the masked ! results. */ ll_mask = const_binop (BIT_IOR_EXPR, ll_mask, rl_mask, 0); lr_mask = const_binop (BIT_IOR_EXPR, lr_mask, rr_mask, 0); ! if (operand_equal_p (ll_mask, lr_mask, 0) && lnbitsize == rnbitsize) { lhs = make_bit_field_ref (ll_inner, type, lnbitsize, lnbitpos, ll_unsignedp || rl_unsignedp); rhs = make_bit_field_ref (lr_inner, type, rnbitsize, rnbitpos, lr_unsignedp || rr_unsignedp); ! if (! all_ones_mask_p (ll_mask, lnbitsize)) ! { ! lhs = build (BIT_AND_EXPR, type, lhs, ll_mask); ! rhs = build (BIT_AND_EXPR, type, rhs, ll_mask); ! } return build (wanted_code, truth_type, lhs, rhs); } --- 3645,3667 ---- /* Make a mask that corresponds to both fields being compared. ! Do this for both items being compared. */ ll_mask = const_binop (BIT_IOR_EXPR, ll_mask, rl_mask, 0); lr_mask = const_binop (BIT_IOR_EXPR, lr_mask, rr_mask, 0); ! ! /* If the operand size is the same, and the bits being compared are ! in the same position in both operands, we can use the mask to do ! the bitfield extraction, rather than shifting. */ ! if (lnbitsize == rnbitsize && xll_bitpos == xlr_bitpos) { lhs = make_bit_field_ref (ll_inner, type, lnbitsize, lnbitpos, ll_unsignedp || rl_unsignedp); + if (! all_ones_mask_p (ll_mask, lnbitsize)) + lhs = build (BIT_AND_EXPR, type, lhs, ll_mask); + rhs = make_bit_field_ref (lr_inner, type, rnbitsize, rnbitpos, lr_unsignedp || rr_unsignedp); ! if (! all_ones_mask_p (lr_mask, rnbitsize)) ! rhs = build (BIT_AND_EXPR, type, rhs, lr_mask); ! return build (wanted_code, truth_type, lhs, rhs); } -----8<-----snip-----8<-----snip-----8<-----snip-----8<-----snip-----8<----- ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: fortran integer sizes on linux AXP 1999-03-04 0:05 fortran integer sizes on linux AXP Martin Kahlert @ 1999-03-31 23:54 ` Dave Love 1999-03-31 23:54 ` craig 1999-03-31 23:54 ` fortran integer sizes on linux AXP Martin Kahlert 0 siblings, 2 replies; 36+ messages in thread From: Dave Love @ 1999-03-31 23:54 UTC (permalink / raw) To: Martin Kahlert; +Cc: egcs-bugs >>>>> "MK" == Martin Kahlert <martin.kahlert@mchp.siemens.de> writes: MK> I was told to use Richard Henderson's patch (integer sizes for libf2c) MK> but that didn't work either. If you look in config.log from the libf2c configure and see cpp error messages concerning libiberty.h and/or gansidecl.h (?), then it's due to a problem with libf2c/configure.in for which there's a fix still awaiting approval. ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: fortran integer sizes on linux AXP 1999-03-31 23:54 ` Dave Love @ 1999-03-31 23:54 ` craig [not found] ` <craig@jcb-sc.com> 1999-03-31 23:54 ` fortran integer sizes on linux AXP Martin Kahlert 1 sibling, 1 reply; 36+ messages in thread From: craig @ 1999-03-31 23:54 UTC (permalink / raw) To: d.love; +Cc: craig >>>>>> "MK" == Martin Kahlert <martin.kahlert@mchp.siemens.de> writes: > > MK> I was told to use Richard Henderson's patch (integer sizes for libf2c) > MK> but that didn't work either. > >If you look in config.log from the libf2c configure and see cpp error >messages concerning libiberty.h and/or gansidecl.h (?), then it's due >to a problem with libf2c/configure.in for which there's a fix still >awaiting approval. Where's the list of patches awaiting approval? I don't know offhand what you're referring to above. tq vm, (burley) ^ permalink raw reply [flat|nested] 36+ messages in thread
[parent not found: <craig@jcb-sc.com>]
* Re: fortran integer sizes on linux AXP [not found] ` <craig@jcb-sc.com> @ 1999-03-09 4:18 ` Dave Love 1999-07-31 23:33 ` Bug with g77 and -mieee on Alpha Linux Dave Love 1 sibling, 0 replies; 36+ messages in thread From: Dave Love @ 1999-03-09 4:18 UTC (permalink / raw) To: egcs-bugs >>>>> "JCB" == <craig@jcb-sc.com> writes: JCB> I don't know offhand what you're referring to above. This is what I have for libf2c/configure.in. (I'm not sure all the include directories are actually now necessary.) 1999-01-18 Rainer Orth <ro@TechFak.Uni-Bielefeld.DE> * configure.in: Need to search toplevel include dir for ansidecl.h and libiberty.h needed by config.h and system.h, respectively. 1998-11-30 Dave Love <d.love@dl.ac.uk> * configure.in: Use `g77_cv_...', not `f77_cv_...'. Index: configure.in =================================================================== RCS file: /egcs/carton/cvsfiles/egcs/libf2c/configure.in,v retrieving revision 1.21 diff -u -p -r1.21 configure.in --- configure.in 1998/11/26 01:48:26 1.21 +++ configure.in 1999/02/10 18:14:59 @@ -40,21 +40,21 @@ AC_CONFIG_AUX_DIR($topsrcdir) compiler_name=f771 rm -f skip-this-dir AC_MSG_CHECKING(if compiler $compiler_name has been built) -AC_CACHE_VAL(f77_cv_compiler_exists, - [f77_cv_compiler_exists=yes +AC_CACHE_VAL(g77_cv_compiler_exists, + [g77_cv_compiler_exists=yes if test -n "$r"; then if test -d "$r"/gcc; then if test -f "$r"/gcc/$compiler_name; then true else - f77_cv_compiler_exists=no + g77_cv_compiler_exists=no echo "rm -f config.cache config.log multilib.out" > skip-this-dir fi fi fi ]) -AC_MSG_RESULT($f77_cv_compiler_exists) -if test x$f77_cv_compiler_exists = xno +AC_MSG_RESULT($g77_cv_compiler_exists) +if test x$g77_cv_compiler_exists = xno then rm -f Makefile conftest* confdefs* core exit 0 @@ -91,9 +91,9 @@ then the target library, then build with # is in gcc/ and the config files are in gcc/config/. AC_MSG_CHECKING(f2c integer type) late_ac_cpp=$ac_cpp -ac_cpp="$late_ac_cpp -I../../gcc/f -I../../gcc -I../../gcc/config" +ac_cpp="$late_ac_cpp -I../../gcc/f -I../../gcc -I../../gcc/config -I../../include" if test "$srcdir" != . ; then - ac_cpp="$ac_cpp -I$srcdir/../gcc/f -I$srcdir/../gcc -I$srcdir/../gcc/config" + ac_cpp="$ac_cpp -I$srcdir/../gcc/f -I$srcdir/../gcc -I$srcdir/../gcc/config -I$srcdir/../include" fi AC_CACHE_VAL(g77_cv_sys_f2cinteger, echo "configure:__oline__: using $ac_cpp" >&AC_FD_CC @@ -138,9 +138,9 @@ AC_SUBST(F2C_INTEGER) AC_MSG_CHECKING(f2c long int type) late_ac_cpp=$ac_cpp -ac_cpp="$late_ac_cpp -I../../gcc/f -I../../gcc -I../../gcc/config" +ac_cpp="$late_ac_cpp -I../../gcc/f -I../../gcc -I../../gcc/config -I../../include" if test "$srcdir" != . ; then - ac_cpp="$ac_cpp -I$srcdir/../gcc/f -I$srcdir/../gcc -I$srcdir/../gcc/config" + ac_cpp="$ac_cpp -I$srcdir/../gcc/f -I$srcdir/../gcc -I$srcdir/../gcc/config -I$srcdir/../include" fi AC_CACHE_VAL(g77_cv_sys_f2clongint, echo "configure:__oline__: using $ac_cpp" >&AC_FD_CC >From d.love@dl.ac.uk Tue Mar 09 04:23:00 1999 From: Dave Love <d.love@dl.ac.uk> To: olly@scatcat.demon.co.uk Cc: egcs-bugs@egcs.cygnus.com Subject: Re: problem bootstrapping egcs-1.1.1 on rs6000-ibm0-aix4.1.4.0 machine Date: Tue, 09 Mar 1999 04:23:00 -0000 Message-id: <rzqn21mvoml.fsf@djlvig.dl.ac.uk> In-reply-to: "Olly Stephens"'s message of "Mon, 8 Mar 1999 15:00:50 -0000" References: <E10K1X9-0004eX-0A@finch-post-10.mail.demon.net> X-SW-Source: 1999-03/msg00267.html Content-length: 71 See <URL: http://egcs.cygnus.com/faq.html > concerning linking on AIX. >From sch@leading.net Tue Mar 09 06:25:00 1999 From: Stephen Hite <sch@leading.net> To: egcs-bugs@cygnus.com Subject: -Wall addition to g++? Date: Tue, 09 Mar 1999 06:25:00 -0000 Message-id: <Pine.BSI.4.05L.9903090919100.23853-100000@users.southeast.net> X-SW-Source: 1999-03/msg00268.html Content-length: 592 When running egcs-2.92.33 19981226 (gcc2 ss-980609 experimental), I don't get a warning when I compile this code: class A { public: virtual void func() const; }; class B : public A { public: virtual void func(); }; According to Scott Meyers' 2nd edition "Effective C", item 48 suggests that a warning should be telling the user that func() delared in A has not been redeclared in B; it's been hidden entirely. Looks like a common programming mistake that could have been caught by the compiler. Perhaps a warning should be issued when -Wall is used??? Steve Hite sch@southeast.net ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Bug with g77 and -mieee on Alpha Linux [not found] ` <craig@jcb-sc.com> 1999-03-09 4:18 ` Dave Love @ 1999-07-31 23:33 ` Dave Love 1999-07-11 23:54 ` craig 1999-07-31 23:33 ` Toon Moene 1 sibling, 2 replies; 36+ messages in thread From: Dave Love @ 1999-07-31 23:33 UTC (permalink / raw) To: egcs-bugs >>>>> "JCB" == <craig@jcb-sc.com> writes: JCB> Hardly. it's a *precise* description of what Toon constantly JCB> advocates: the idea that any program written to exploit the full JCB> range of IEEE 754 *values* (not even using *features* like JCB> signalling NaNs, trapping on inexact, etc.) is inherently JCB> *wrong*, I don't recall so, though perhaps that's what he thinks; it's obviously silly. I can say that when I maintained a system used by a lot of the world's protein crystallographers, such a program would have to have been considered broken because it wouldn't run on 3 architectures required (one of which is probably now a non-issue, but not the others). Thus, for instance, I wouldn't have been able to use Knuth's currently recommended random number generator. For historical reasons IEEE conformance is basically irrelevant to the code, for large values of `the code'. That doesn't mean it's worthless generally. JCB> Yet, programs *aren't* working, when compiled with g77. Toon says JCB> they're buggy programs Most of the time they are, and I say ``read `Working Programs'''. The one in question is likely buggy, given that it's optimization-dependent, regardless of the problem printing the results. JCB> -- my impression is, users are concluding *g77* is buggy, in JCB> droves. They've always done so. To minimize it, you'll want defaults taken from `Working Programs', and then they'll say it's just slow. JCB> I'm coming to the same conclusion myself, that g77 is fatally JCB> buggy, by design, because of its refusal to offer even basic, JCB> predictable behavior. I've certainly wanted a framework for controlling the FP behaviour across platforms as consistently as possible, as have other users, but the work I did on it was rejected and it was clear that working on the f2000 features would be a waste of time. Complete consistency across even IEEE-ish targets is surely doomed, though. JCB> So other systems crash on overflow (instead of generating Inf)? Of course they do, though they're decreasing in importance in my game, if you mean the basic hardware. However, I'd almost always want to set up the FP system on an IEEE box to do that anyway to find the bugs. I distributed the crystallographic suite that way for all the systems I knew how. I got grief from users who seemed to want bogus output, but I fixed plenty of bugs. >> They might, but that's not what the actual behaviour is here; >> underflows give zero. Not that experimental results seem to carry >> much weight. JCB> No, Please spare me the diatribes when I report how things actually behave. $ uname -a OSF1 pxsv6.dl.ac.uk V4.0 1091 alpha $ cat >z.f a=exp(-100.) print *, a end $ f77 -O0 -ieee_with_no_inexact z.f && ./a.out 3.7835059E-44 $ f77 -O0 z.f && ./a.out 0.0000000E+00 $ g77 z.f && ./a.out 0. JCB> the *actual* behavior appears to be that, I refer to the behaviour I actually observe. I can now check how an Alpha works rather than just being told I don't understand it without useful explanation. JCB> depending on where the number comes from, a denormal *crashes* a JCB> "working" program, while other sorts of underflow (below the JCB> denormal range, I expect) don't. If you generate a subnormal-style bit pattern either directly or from separately compiled -mieee code and operate on it in -mno-ieee code, yes, you get a crash. The issue with libI77 is trivially fixed. >> Note that gcc's default is the same as Digital's. JCB> If only that were the case, we'd have few of the problems we JCB> have now. I'm using the Digital compiler and I checked before saying so. They both default to the non-IEEE mode, as documented. JCB> Digital Fortran offers a fully-working environment based on what JCB> we call -mno-ieee *and* offers a fully-working environment based on JCB> what we call -mieee as well. It happens to offer the first as a JCB> default. JCB> g77 offers neither choice. I don't understand what `fully-working' means -- bug free? (g77 clearly doesn't provide a fully-working environment on any system; particularly because debugging doesn't work properly.) The DEC default is to crash on overflow, for instance, which it sounds as though you think is wrong. I get a segv from attempted i/o of a subnormal in default mode compiling with it. I've verified that gcc and g77 pass paranoia perfectly with gcc -mieee and appropriately multilibbed libg2c. Given the value of `offers neither choice', perhaps someone can sort it out. I'd fix and test the multilibbing if I thought it stood a better chance of being accepted than similar stuff I've wasted time on. JCB> Remember, my original statement was to the effect that -mno-ieee JCB> as a default was a poor choice because we didn't bother to JCB> properly implement it, whereas, at least with -mieee, we'd have JCB> had plenty of *existing* code (coming from other, JCB> IEEE-754-conforming, environments), such as library routines, JCB> test suites, and so on, to just "plug in" for ordinary use. I don't understand what that's about. How is it not properly implemented (modulo general bugs with 64-bit targets and other bugs not directly related to the fP model)? Why the confidence that -mieee is properly implemented in contrast? (libf2c was developed on VAXen, presumably along with Berkeley libm stuff originally.) JCB> The assertions so far amount to "but any code that doesn't work JCB> with g77 is inherently broken", or some Gatesian approximation JCB> thereof. I fail to see how, at least from me. g77 on Alphas has clearly had serious problems unrelated to IEEE FP behaviour. I don't get the rant about DEC's FP models. VAX FP is the major reason that most code doesn't require IEEE conformance, for historical reasons if nothing else. If DEC decided (for such reasons?) that that a non-IEEE default was appropriate, and they're so good at such things, I'm baffled why it was so wrong for kenner to follow the lead. ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Bug with g77 and -mieee on Alpha Linux 1999-07-31 23:33 ` Bug with g77 and -mieee on Alpha Linux Dave Love @ 1999-07-11 23:54 ` craig 1999-07-12 1:24 ` Jeffrey A Law 1999-07-31 23:33 ` Toon Moene 1 sibling, 1 reply; 36+ messages in thread From: craig @ 1999-07-11 23:54 UTC (permalink / raw) To: d.love; +Cc: craig >>>>>> "JCB" == <craig@jcb-sc.com> writes: > > JCB> Hardly. it's a *precise* description of what Toon constantly > JCB> advocates: the idea that any program written to exploit the full > JCB> range of IEEE 754 *values* (not even using *features* like > JCB> signalling NaNs, trapping on inexact, etc.) is inherently > JCB> *wrong*, > >I don't recall so, though perhaps that's what he thinks; it's >obviously silly. When it was asserted that even -mno-ieee didn't behave reasonably in the presence of denormals, that fact *was* hand-waved, effectively as not being evidence of our failure to provide a sufficiently clean, consistent environment. So, to me, it doesn't matter whether the *assertion* was wrong: it's the *hand-waving* that's wrong, and I will no longer put up with it (especially as done by management) on projects with which I'm associated. >Most of the time they are, and I say ``read `Working Programs'''. The >one in question is likely buggy, given that it's >optimization-dependent, regardless of the problem printing the >results. I wonder what percentage of people who are told "read `Working Programs'", pertaining to correct accommodation of FP behaviors across the present bunch of compiler/CPU combinations, actually *modify* their programs to meet the requirements; and what percentage of people find they can simply abandon g77 in favor of a compiler (even on a problematic CPU, like IA32) that is *sufficiently* predictable, FP-wise, that they need make many fewer changes, if any? Have you ever tried to find out, e.g. by following up with people a month or two after the fact? (I haven't seen a quote like the now-years-old, paraphrased, "g77 always comes up smelling of roses" in a *long* time, and I think this whole discussion explains why -- because, against my wishes, we've collectively allowed g77 to acquire a real stench about it, of unpredictability, instability, and lack of proper attention to important issues, like ensuring the viability of testing using standard test suites, of component testing, and so on.) The problem being that, while I don't like changing g77 to support gratuitously buggy programs, I have little faith that these sorts of bugs are *exclusively* gratuitous -- and, in the meantime, we lose out on that latter group of users helping test g77 on codes it doesn't otherwise see, at least not on the problematic CPUs. > JCB> -- my impression is, users are concluding *g77* is buggy, in > JCB> droves. > >They've always done so. To minimize it, you'll want defaults taken >from `Working Programs', and then they'll say it's just slow. I wonder what percentage of users we'd *lose* as a result of it being "slow", despite offering options (like -ffast-math, -mno-ieee, -ftruncate-fp-spills, the latter being the only one we don't already have) for "expert" users to use to speed things up? I wonder what percentage of users we'd *gain*, because, even though their *production* code *starts* out as slow, they are able to gain confidence by running their own code that *tests* for reasonable FP behavior, even if just to validate the compiler's own integrity, before turning on options to gain speed at the expense of some of that reasonable behavior? I wonder if anyone ever paid attention to these issues before making the pertinent decisions, and if anyone ever will, when it comes to GNU/GCC? (Well, I know from experience, we sometimes try, but the more effect a decision has, the more objective analysis that needs to be done up front. I see nearly *zero* evidence that such analysis is favored, even *now*, with all the controversy that has ensued, with all the users who've complained, some of which have *not* been so easily hand- waved as having "broken code", e.g. they're simply trying to test IEEE compliance on systems that, using *other* compilers, actually offer it!) > JCB> I'm coming to the same conclusion myself, that g77 is fatally > JCB> buggy, by design, because of its refusal to offer even basic, > JCB> predictable behavior. > >I've certainly wanted a framework for controlling the FP behaviour >across platforms as consistently as possible, as have other users, but >the work I did on it was rejected and it was clear that working on the >f2000 features would be a waste of time. What do you mean by "was rejected"? If you mean I didn't add the code you'd wanted added to libg2c to set up exceptions, then please say so, but I assure you, that wasn't a *rejection* in the sense I think others might take it as. That is, you're leaving the impression that you tried to make things *better* by offering such patches for inclusion in g77/libg2c, and that your *desire* to improve things was rejected. That was hardly the case. The problem was the method you chose, which, while perhaps best for a non-GNU-like vendor (which could easily include another OSS effort, so I don't mean "proprietary", though they often are able to expend up-front resources to make sure things work), involved changing the way the *system* behaved, by default. Now, *libf2c* already changes that by setting up exception handlers, but g77 already "swallows" whatever is "special" about libf2c, with a few exceptions. And, we've already gotten somewhat burnt by our (mostly my) feeling we're able to maintain our own libg2c, a libf2c with *source* (not just configury/build) modifications. Modifications I, myself, can at least fairly easily reason about because they're in straightforward C. Now, add on top of those problems modifications to the signal/exception environment, or that make use of pre-main()-invocation initialization, which *I* don't really know anything about (except that I've gotten the impression it isn't supported so uniformly as straight C code, might have bugs, etc.), and perhaps you can understand why I didn't just throw the code in -- especially back during the gcc 2.7 -> 2.8 fiasco, which included the g77 0.5.20 fiasco, both of which went for a *long* time and made for *substantial* changes of attitude among many of us (well, at least me) regarding how to properly maintain g77. So, I've (slowly) learned to minimize the changes g77 makes to the fundamental environments in which it operates: - The underlying CPU, whose default FP behavior and *recommended use* (which, frankly, includes 80-bit spills, though I can't do anything about that in g77) should be honored by g77, since we can neither take a big performance hit via emulation nor deploy resources to do "fast FP" our own way. Also, this honors the CPU choice of the user, to a bit of an extent (though g77 tries to cater to a wide audience here -- e.g. those effectively *forced* to do useful work on IA32, as well as those who buy a T3 or whatever, so that particular argument applies most weakly to the CPU, I would think). - The underlying OS, whose choices for the signal/exception environment, initial FP state, and so on, should be honored, again, because we don't want to emulate our way into a perfectly consistent environment, nor do we have the resources to go our own way, and, again, because it respects the OS choice of the user (thus encouraging users to complain to OS vendors, rather than us, about defaults they don't like, or at least read the docs for *their* environment *themselves* and thus discover how to override the defaults, rather than relying on us to guess at all sorts of configury hacks to install working patches that reset the defaults for them -- and for *other* unsuspecting users of those same systems). - Netlib libf2c, whose choices regarding changing the signal/exception environment, FP support, and so on, should be honored, again, ditto the reasons stated elsewhere (though we currently don't give g77 users a choice by supporting another run-time library, we will someday), plus we get a *more* robust product to the extent we "join in" with the testing people do on the f2c/libf2c combo. (And we've indeed taken hits, one way or another, by going our own way via libg2c.) - The gcc back end, which could be argued makes the *worst* choices for g77/FP work of the items under discussion, though it *is* improving. (After all, we've been avoiding its complex divide for about 99% of g77's history, avoiding *all* of its complex arithmetic for most of g77's public life, etc.) But, the more we can simply "fall in line" with gcc -- e.g. via Toon's patches to offer a better complex divide -- the better (though Toon's work is not yet a great example of this, as it involves simply switching among methods based on the front end, and the g77 method is "new" code, but at least that new method can be used by other front ends as-is, which was not the case for using c_div/z_div). So while I rejected some proposed changes to g77 or libg2c that *might* have made things somewhat better, I certainly have *never* rejected the ideas that lay behind them, to the extent they were preferably implemented in the gcc back end, in libf2c, in the underlying OS, or in the CPU. And, keep in mind, Toon has been, in effect, arguing *against* changes like yours, because, as he points out, we're not going to get "perfect" consistent behavior *anyway*, so why do anything that might slow down code, which adding a signal handler (or changing an FP mode) might? (Though I don't recall having specifically objected to *that* -- he probably wouldn't, since such code wouldn't be in a loop!) For myself, not having had, prior to a year or so ago, a particularly clear picture of the issues, I had to rely on advice as to how to generally handle these issues, combined with my own need to know, to at least some extent, what was going on. I was probably, back when you submitted the patches you're talking about, in the mode Toon still is, which is "if it involves FP, you're on your own", loosely stated, and doing everything I could to *avoid* having g77 adjust the underlying components (libf2c, gcc, OS, and CPU), especially system-specific changes (which can easily mushroom into bazillions of #ifdef's, as most everyone who does GNU-like development realizes by now). Also, I thought I made it perfectly clear that I was in constant- apology mode regarding my lack of being up to snuff wrt Internet access, ability to upload/download bugs, investigate stuff, etc. Until early this year, that was a *huge* problem, making investigating anything "peripheral" to my fundamental job as g77 front-end maintainer be poorly treated by me. Add to that the fact that, also until very recently (starting with the EGCS project, but, more practically, ramping up through early this year), nobody could really get anything into g77 without going through me, in the sense that I had to be the one to distribute not only *releases* of g77, but *alpha* versions. So, if I added a patch that would, even in practice, improve g77's behavior on a particular system, and went to the (significant!) trouble of distributing that version of g77 for alpha-testing, and it blew up *other* systems, that'd be a *huge* waste of various resources, which were in such short supply at that time, I was even ignoring some pretty mainline g77 front-end issues. (Heck, until I got my PII and except when using my Alpha, I avoided making significant changes to f/com.c and f/expr.c, because Emacs C-mode couldn't keep up with my thought/typing process -- seemed like its indentation handling, which gets invoked when typing `}', had slowed down at some point or something, making my poor little 486 sputter for a few seconds every few keystrokes.) That, and other circumstances, conspired to make me *very* reticent to add any changes in which I didn't *personally* have a high degree of confidence, that didn't come from a source that suggested a high degree of confidence was due the changes (e.g. I accepted changes by dmg to netlib libf2c for libg2c pretty much blindly), and that could easily break lots of things, *especially* in subtle, not-discovered-until- way-down-the-road things. Further, on many of the occasions where I *did* confidently forge ahead with similarly risky changes to g77, whether made by me or incorporated on someone else's say-so, we got severely burnt. (Some of what made g77 circa 0.5.21, I forget exactly which versions, buggy was because I'd pretty much blindly folded in most, or maybe all, of the GNAT patches to the gcc back end, on kenner's say-so. For all I know, *they* might have been all correct -- bugs might have been all due to the interactions they had with g77's patches -- but the upshot was, if I hadn't integrated them, we *might* have had a more stable g77 for awhile there.) To sum up my reasons for not immediately integrating whatever such patches you might submit as "rejection" does both me, and my reasoning for not taking them as-is a disservice. >Complete consistency across >even IEEE-ish targets is surely doomed, though. I'm not quite ready to say *that*, but I certainly wouldn't encourage GCC to attempt it, especially not as a default. Certainly the current crop of g77/gcc users is not interested in it. What I would *love* to see is a full-court-press by the number-crunching industry to effectively *mandate* strict IEEE 754 conformance (to the "range" of the standard appropriate, e.g. not bothering with trapping/ exceptions or extra rounding modes in FORTRAN-77-based languages, but still getting all the precision and consistency exactly right, for the *default* types, with no excess precision, thus no spill issues, etc.). Not that I think that highly of IEEE 754 per se (how can I, not being a numerical analyst?), but if the industry did just make every Fortran compiler do whatever it took to conform to that standard by default, the benefits would be enormous, in better, more widespread, testing at component/unit levels, in reducing complexity for programmers, allowing them to focus on *their* problems rather than peripheral issues (like "which floating-point behavior do I get *today*?")... ...and, most importantly, it would probably result in whatever Intel shipped as the next IA32 "upgrade" finally delivering IEEE-754- conforming *performance*, instead of *punishment*. > JCB> So other systems crash on overflow (instead of generating Inf)? > >Of course they do, though they're decreasing in importance in my game, >if you mean the basic hardware. However, I'd almost always want to >set up the FP system on an IEEE box to do that anyway to find the >bugs. I distributed the crystallographic suite that way for all the >systems I knew how. I got grief from users who seemed to want bogus >output, but I fixed plenty of bugs. Excellent!! The better a job we can do communicating these potential means for finding problems to users, the better. Yes, a completely uniform g77 environment across platforms that, e.g., defaulted to crashing on overflow rather than returning Inf might be ideal, but, failing that, I think we should a) go with whatever the (four-part) environment, described above, decides and b) document as best we can how to override that environment. (Though, I have had some people tell me that a default of crashing instead of returning Inf is wrong. I am not prepared to make that sort of decision myself.) >Please spare me the diatribes when I report how things actually behave. What in the world prompted you to say that?? >$ uname -a >OSF1 pxsv6.dl.ac.uk V4.0 1091 alpha >$ cat >z.f > a=exp(-100.) > print *, a > end >$ f77 -O0 -ieee_with_no_inexact z.f && ./a.out > 3.7835059E-44 >$ f77 -O0 z.f && ./a.out > 0.0000000E+00 >$ g77 z.f && ./a.out > 0. Well, *that's* good news! How does this behave? CHARACTER*50 A EQUIVALENCE (I, R) A = '1E-40' READ (UNIT=A, FMT=*) R PRINT '(Z8)', I END (It should print "116C2", modulo endianness, if my IA32 system is any guide.) If it crashes, how does it behave if "1E-40" is replaced by "1E-400", and by "1E-4"? > JCB> the *actual* behavior appears to be that, > >I refer to the behaviour I actually observe. I can now check how an >Alpha works rather than just being told I don't understand it without >useful explanation. Who told you you didn't understand it? Could you provide a reference? Keep in mind *I* have pretty consistently pointed out that I don't have my Alpha up and running yet (as my web site makes pretty clear). >The issue with libI77 is trivially fixed. By compiling it with -mieee? But we won't be doing that for gcc 2.95, so if doing so exposes bugs not caught by *our* limited testing, but that might be caught by the wider base of users who limit their testing to releases (or prereleases) of g77, that's going to be painful. Alternatively, we could make a modification to libg2c's pertinent routines. Not the approach I want to take anymore. Or, we could convince dmg to change netlib libf2c, which, if we can agree that the change makes sense within the context of a consistent numerical environment, is the option I'd prefer. (More and wider testing, etc.) > >> Note that gcc's default is the same as Digital's. > > JCB> If only that were the case, we'd have few of the problems we > JCB> have now. > >I'm using the Digital compiler and I checked before saying so. They >both default to the non-IEEE mode, as documented. Did you not bother reading the rest of what I wrote? I *know* they chose what we call -mno-ieee as a *compiler* option the default, but they did *not* choose failing to properly *research*, *design*, and *implement* it as a default, did they? I've explained that *many* times now. Why are you insisting on twisting my words around, just to make a point? Do you really have so little respect for my efforts here? > JCB> Digital Fortran offers a fully-working environment based on what > JCB> we call -mno-ieee *and* offers a fully-working environment based on > JCB> what we call -mieee as well. It happens to offer the first as a > JCB> default. > > JCB> g77 offers neither choice. > >I don't understand what `fully-working' means -- bug free? (g77 >clearly doesn't provide a fully-working environment on any system; >particularly because debugging doesn't work properly.) No, I've *explained* what fully-working means before -- and probably even in that email. Didn't you bother reading it? >The DEC default is to crash on overflow, for instance, which it sounds >as though you think is wrong. I get a segv from attempted i/o of a >subnormal in default mode compiling with it. I've verified that gcc >and g77 pass paranoia perfectly with gcc -mieee and appropriately >multilibbed libg2c. No, I don't think crashing on overflow is wrong *per se*. I think g77-compiled code crashing on overflow, denormal, underflow, or even divide by zero is wrong if the underlying system (e.g. the native compiler who we're perhaps trying to emulate to some degree, or the way the OS normally behaves under, say, f2c/libf2c) does *not* do so. The idea I keep trying to get across is that, to the extent we don't tightly adhere to *standards*, we lose opportunities for testing, code re-use, user understanding, etc. (Some of those "standards" are really ad-hoc, "this is how this machine behaves" sort of things, and that makes consistency really difficult to achieve in some cases, I realize. Each issue must be carefully thought through.) (I had, up until several months ago, been hoping/assuming people would just magically do the right testing during development and early prerelease. It's now clear that's not the case, so I support, with more understanding now rather than just faith or appreciation for attempts to DTRT, the "longish" release schedules adopted by the EGCS project. I now think they may well not be long enough, or allow for enough show-stopper bugs to be discovered, tracked down, fixed, and respun.) The next choice is to adhere to what a particular *system* normally does, and then implement that properly. My impression was, based on submissions *to this list*, that we did *not* do that for g77 vis-a-vis Digital's compilers. Now, you can claim that, in fact, those submissions were in error, that we do, in fact, offer (fundamentally, aside from typical sorts of bugs) the same environment Digital does (at least for -mno-ieee; clearly that's not the case for -mieee, so we cannot really "capture" users who want to *start* with -mieee and then selectively "migrate" codes to -mno-ieee). But, my problem with this whole debate has been how people like Toon and yourself have responded to these mere *allegations* of incorrect behavior: "It's not incorrect, fix your code." "Any code that generates a denormal or computes an underflow is wrong, so it's better to crash." (Even if *Digital* offerings *don't* crash in the same circumstances!!) And we've seen the same attitude manifested before as regards 80-bit spills. Further, this attitude is now being copped by people upon whom I previously relied to support my efforts to make g77 a great product, and who were not even the people who made these short-sighted decisions in the first place (meaning there are even *more* people who have these attitudes, and have, or at least had, the power to impose them on others). So I'll no longer be working on new g77 stuff, since I have concluded that I won't have the support I need to do it right, nor to withstand assaults on my attempts to make it *work* first, *then* make it fast, as defined by *me* using *my* 25 years of experience in the field. >Given the value of `offers neither choice', perhaps someone can sort >it out. I'd fix and test the multilibbing if I thought it stood a >better chance of being accepted than similar stuff I've wasted time >on. Please explain what you mean by "similar stuff", and give examples, as the only things I can guess at what you *might* be talking about aren't *remotely* similar in ways that pertain to this discussion. Particularly disturbing is the fact that you're the *only* other person to whom I can go to for help maintaining libg2c; that you and I took *lots* of heat (e.g. from HJ Lu) trying to make libg2c work with multilibs (work mostly done by Robert Lipe, IIRC); and, here you are, implying that I'd actively resist attempts you make trying to *use* that multilib facility to extract the exact same benefits I've clearly said I *assumed* had been present all along, and would have fixed *myself* if I'd discovered, on my own, had been omitted (by virtue, for example, of having a running Alpha). All because I didn't accept patches from you to change how libg2c sets up the exception environment, or some such thing? If you didn't before, now you (and others) can understand now, why I no longer see my working on g77 as particular productive. You'd rather argue with me than let me work, especially if the alternative is that I might make g77 more robust for more users, but perhaps a little slower for a few. Whether it's entirely my fault, I've now lost the support of the very people who've been most important to g77's success in the past (other than myself): Dave Love, who made libU77 and libg2c happen, but who now appears to claim I actively resist his attempts to improve g77; Toon Moene, almost *the* biggest supporter of my g77 work over the years, who takes up a huge, long argument with me (while I *could* have been working on the rewrite) because he didn't agree with me that the hassle users have to deal with to use -mieee was just too much, and who has previously (among other things) dismissed my proposal to do 80-bit spills as a default nearly out-of-hand; and Richard Henderson, whose also dismissed that same proposal nearly out of hand, yet without whom g77's current performance would be *abysmal* on some machines (like Alphas). I mean, yes, it's been wonderful to get the statements of support I *have* gotten on these issues, but they've all come from people who I don't recognize as active participants in improving g77 (or the gcc back end). There's nobody who has consistently spoken up to support my view that we should choose defaults that tend to lead to an overall more robust environment *and* to whom I can look to to be taken seriously by others who are doing the actual *work* on these projects. (Certainly their statements of support, in these public discussions, have apparently accomplished nothing vis-a-vis the opinions expressed by those who *do* directly influence g77's evolution.) I can't carry the water for doing things right anymore vis-a-vis g77. There's no way the architecture I intended to use for my rewrite will be tolerated in this environment, and it's highly unlikely g77 will offer reasonable, consistent-with-vendor-practice stable numerics in the timeframe that *I* require it to to make that rewrite (and the features I expected to add via it) worthwhile anyway. I'm not going to fight anymore. And, despite Toon's attempts to get me to do so, I'm not just going to be a code-boy who obediently (and *voluntarily*) "improves" g77 exactly as directed by others, when I *know* those directions are wrong-headed and short-sighted, as well as that the results don't speak well for my *overall* abilities (which include product *architecting* and *design*, not just implementation and debugging, which appears to be the only areas, if any, for which I'm respected by you). Best of all, by stepping aside, I make it *much* easier for you, Toon, and others to designate a replacement g77 maintainer, someone for whose opinions and experience you'll have much more respect *or* who will happily make whatever changes you suggest, regardless of how little actual R&D has been put into them. (I sincerely hope the former occurs, but don't hold out much hope for it. I'll certainly have plenty of email-archive URLs ready to offer to anyone who asks me "what sorts of things happen on this project when somebody stands up and says, here's the *right* way to solve this problem, when the right way isn't the convenient, cheap, or fast way?") > JCB> Remember, my original statement was to the effect that -mno-ieee > JCB> as a default was a poor choice because we didn't bother to > JCB> properly implement it, whereas, at least with -mieee, we'd have > JCB> had plenty of *existing* code (coming from other, > JCB> IEEE-754-conforming, environments), such as library routines, > JCB> test suites, and so on, to just "plug in" for ordinary use. > >I don't understand what that's about. How is it not properly >implemented (modulo general bugs with 64-bit targets and other bugs >not directly related to the fP model)? Why the confidence that -mieee >is properly implemented in contrast? (libf2c was developed on VAXen, >presumably along with Berkeley libm stuff originally.) We didn't make sure we implemented -mno-ieee with *nearly* as much attention to detail as *Digital* did when *it* chose to go out-of-step with the industry (IEEE 754). (A choice I gather it now regrets, or at least no longer sticks with, if my impressions about the 21264 are correct. I'd love to find out, for sure, what the top Digital/Compaq technical gurus now think about making -mno-ieee the default, assuming that they now, on 21264, effectively offer -mieee the default.) And, by not choosing -mieee, we've clearly chosen to not ensure that we offer a consistent IEEE 754 environment on Alphas, a choice Digital *did* make, because -mieee doesn't even work under g77. So all the testing that *could* have gone on, using codes that assumed IEEE 754 (even if just codes whose *only purpose* was to test IEEE 754 compliance, i.e. *not* codes subject to Toon's numerical-analysis-expertise-based rejection), has *never* gone on for g77/Alpha, or gcc/Alpha, or g++/Alpha. To put it coarsely: the decision GNU made regarding -mieee was made mainly to avoid the hard work of getting FP right in gcc (and, by extensions, unfortunately, g77). That hard work might have included doing difficult optimizations to make -mieee perform well (as it could, I gather, perform *much* better than it does today, since there are "trap shadows" we could account for and thereby avoid some uses of TRAPB). And/or, it might have included making sure all the libraries supported it properly. And/or, it might have included making sure most of the code out there that helps people test IEEE 754 conformance was run by volunteers using -mieee. And/or, it might have included thoroughly documented these issues up front, so that not only end users, but "middle" people, like myself, would have been made aware of them up front -- to make better decisions regarding testing, for example. We didn't do any of that, AFAICT. I assert that Digital did *all* of it, up front. Taking that into account, saying that "we made the same choice as Digital" would probably be litigable. It certainly hides the truth. And it hides it in a way that is consistent with likely *future* blunders like this, i.e. where someone just says "well, it's okay for us to not do this right, because some other vendor doesn't", and everybody goes "uh-huh, okay, sounds great", and nobody asks (or they're yelled at for doing so) questions like "well, what *else* might that vendor have done to mitigate *their* choice, that *we* had better consider doing?". (Remember, for example, that it might often be the case that $100K worth of test codes might be publicly available that test against some *standard*, and therefore available to GNU products, while any *vendor* that chooses to *not* follow that standard can pony up $100K - $1M, or more, to obtain a *proprietary* set of test codes, equivalent to the public ones, but that test *their* choice of protocols, formats, or whatever. If GNU copies the *vendor* choice, it locks itself out of that free $100K-worth of test codes, and probably won't have reasonable access to that $1M worth of *proprietary* codes, either. If this theory is correct, and if it applies here, I wonder just how many bugs we would have flushed out of `-mno-ieee' as the default if we'd been able to run all the tests Digital designed and ran on its Alpha product line, from the beginning? I wouldn't be surprised if we *still* fail more in *their* test suite than *they* failed as of their first public, non-beta release. But we have no easy way of finding out. Even if not specifically the case with -mno-ieee and Digital, this, as a hypothetical situation, illustrates the hazards we *must* account for every time we decide to go our own way.) > JCB> The assertions so far amount to "but any code that doesn't work > JCB> with g77 is inherently broken", or some Gatesian approximation > JCB> thereof. > >I fail to see how, at least from me. g77 on Alphas has clearly had >serious problems unrelated to IEEE FP behaviour. Not from you, but you've tended to agree with Toon's statements concerning the irrelevance of IEEE 754 support in Fortran codes. Toon certainly made the sharpest statements in regard to this issue, and he was *not* alone in doing so back in December during the 80-bit-spill debacle. >I don't get the rant about DEC's FP models. What rant? I was *applauding* Digital's decision to do these things *right* -- make sure the industry-standard stuff works, and make sure their non-standard choices work. (And their VAX FP models *predated* IEEE 754, I'm pretty sure -- I think VAX came out in early 1978 or so, and I would assume its F_floating, D_floating, and G_floating formats were present, or at least all specified, from the beginning, whereas I'm under the impression IEEE 754 came out years later.) So I was hardly criticizing them for creating *those* formats. My point was that Digital goes, or went, to a *lot* of trouble to make sure it supports, with a minimum of surprise to its end users, any decisions it makes that involve being outside the boundaries of standards, de facto or otherwise. (Heck, when they designed the STRUCTURE facility, they actually tried hard to make sure it *wouldn't* look like whatever future facility standard Fortran might want to offer, so there wouldn't be collisions in the "space" of language design. Exactly the opposite sort of behavior, especially as regards ethics, towards the industry, *and* its customer base, over the long haul, exhibited by MS, and some others as well.) Now, it's true that Digital didn't become what MS became, and that one could claim it was their very attention to detail and elegance that doomed them. I might agree. I *don't* agree that GNU should copy the worst aspects of MS' impact on the industry -- the general unwillingness to appreciate and execute proper design and engineering, as well the refusal to stick as closely as possible to standards and then deviate only *properly* from them, when necessary, in ways that at least don't hinder the long-term prospects of the industry and/or its customer base (*even* if they decide to move to a different vendor!). >VAX FP is the major >reason that most code doesn't require IEEE conformance, for historical >reasons if nothing else. If DEC decided (for such reasons?) that that >a non-IEEE default was appropriate, and they're so good at such >things, I'm baffled why it was so wrong for kenner to follow the >lead. Because kenner, or really the *rest* of us, didn't bother to actually *follow* the lead. We merely appropriated the stance that IEEE 754 conformance wasn't worthwhile as a default. Further, we decided (by fiat) that properly *following through* on that decision, e.g. by ensuring we produced a product designed *properly* despite being non-standard out of the box, wasn't worthwhile either, a stance Digital surely did *not* take. As a result, we continue to play whack-a-mole with g77-, gcc-, and, generally, GNU-wide choices to "march to a different drummer" and how those choices affect our ability to attract a wide user base, maintain products, and so on. (I fully recognize that some of these issues make good arguments for going *against* current/standard practice, so I'm not making a blanket statement about the *appropriateness* of all those choices, merely about their *effects*.) tq vm, (burley) >From craig@jcb-sc.com Mon Jul 12 00:24:00 1999 From: craig@jcb-sc.com To: law@cygnus.com Cc: craig@jcb-sc.com Subject: Re: Bug with g77 and -mieee on Alpha Linux Date: Mon, 12 Jul 1999 00:24:00 -0000 Message-id: <19990712072342.28771.qmail@deer> References: <4048.931760012@upchuck.cygnus.com> X-SW-Source: 1999-07/msg00430.html Content-length: 2422 >The difference between these two cases is in the -f[no]emulate-complex we >aren't even sure *what* the compiler should be doing, much less *how* to >get it done. Ah, okay, I didn't realize that the problem went that deep. >There's a rather serious design issue that needs to be investigated before we >can even begin to look at solutions. Worse yet, the investigation phase will >probably require looking at a variety of other Fortran compilers to see how >they handle passing of complex values -- we should not insert a gratuitous ABI >incompatibility for passing complex values. Agreed. Though, for g77's purposes, the ABI for complex is currently *always* the ABI for struct { float; float; };. I'd be interested in knowing about any ABI's for which that was not the case, because they'd be systems on which g77 -fno-emulate-complex might not even *work*, if implemented to follow the native ABI. (That's because g77 would be telling the back end to pass/accept __complex__ across calls, but the other end might be f2c-compiled, or g77-emulating-complex, or other, code that uses the struct method.) Put another way, g77 is presently architected (in terms of options it provides, the way it works internally, etc.) to assume the ABI doesn't make __complex__ different from the equivalent struct. We'd at least need to understand and document such differences, e.g. explain that users of pertinent systems not combine g77 -fno-emulate-complex with code from certain types of other sources. (-fno-f2c is related to this, as another example.) >Letting the release out with -fno-emulate-complex without resolving these >issues >makes it much more likely that we will need to break binary compatibility >again for the Fortran compiler once we figure out how to properly pass complex >values. Note that I'm not aware there were ever any problems, in *this* area at least, back when -fno-emulate-complex was the only choice, though that was a long time ago, and I might have forgotten. >I haven't made a final decision on the complex stuff, but I'll have to make one >in the very near future (next 24hrs). Whew, well, good luck! I *still* don't know what to recommend, other than to say that, if we change the default again and don't respin/retest for at least a month, we're risking some pretty serious regressions. Wish I could put a number on that risk, as that might help you. tq vm, (burley) >From law@cygnus.com Mon Jul 12 00:59:00 1999 From: Jeffrey A Law <law@cygnus.com> To: craig@jcb-sc.com Cc: egcs-bugs@egcs.cygnus.com Subject: Re: Bug with g77 and -mieee on Alpha Linux Date: Mon, 12 Jul 1999 00:59:00 -0000 Message-id: <4241.931766333@upchuck.cygnus.com> References: <19990712072342.28771.qmail@deer> X-SW-Source: 1999-07/msg00431.html Content-length: 2171 In message < 19990712072342.28771.qmail@deer >you write: > >The difference between these two cases is in the -f[no]emulate-complex we > Agreed. Though, for g77's purposes, the ABI for complex is currently > *always* the ABI for struct { float; float; };. OK. That's good to know. If this is indeed the ABI we need to use after investigating vendor compilers, then we've probably got some work to do in the backends which pass parameters in registers since I do not believe all are prepared to handle complex modes in the various FUNCTION_ARG macros. Having it as a struct does help with some issues since structs are usually not passed in FP registers, even when their members are strictly floats, strictly doubles or strictly long doubles. Treating it as an aggregate has some performance impacts, so I wouldn't be totally surprised if some vendor treated it as two independent float args for parameter passing purposes. But that's something we'll have to investigate. > I'd be interested in > knowing about any ABI's for which that was not the case, because they'd > be systems on which g77 -fno-emulate-complex might not even *work*, Yup. I doubt we've ever done any serious work at looking at how vendor compilers handle complex and interoperability between g77 and vendor compiled fortran libraries (or even libf2c/libg2c compiled with the vendor compiler). On systems like HPs incompatibilities in this area could also be hidden by the linker for double complex values -- in the event of a caller/callee mismatch for register types, the linker will insert a trampoline to shuffle arguments from one register file to the other. Ick. > Whew, well, good luck! I *still* don't know what to recommend, other > than to say that, if we change the default again and don't respin/retest > for at least a month, we're risking some pretty serious regressions. > Wish I could put a number on that risk, as that might help you. I doubt we'd need a month to respin/retest. I bet we could get all the testing we needed by lapack in a week. lapack looks to stress the complex stuff a hell of a lot more than our regression testsuite. jeff ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Bug with g77 and -mieee on Alpha Linux 1999-07-11 23:54 ` craig @ 1999-07-12 1:24 ` Jeffrey A Law 1999-07-31 23:33 ` Dave Love 0 siblings, 1 reply; 36+ messages in thread From: Jeffrey A Law @ 1999-07-12 1:24 UTC (permalink / raw) To: craig, d.love; +Cc: egcs-bugs Folks, I'm seeing some personal barbs go back and forth. Can everyone in this discussion please count to 10 slowly before sending out the next message? On a technical note, while we certainly can not switch the default to -mieee for this release, we can consider adding an -mieee multilib to the alpha port for this release (assuming the libraries will successfully build with -mieee). While it is not a perfect solution, it would provide the user with a more IEEE complaint environment if requested *and* by making it at least an option with this release -mieee will get more testing. jeff ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Bug with g77 and -mieee on Alpha Linux 1999-07-12 1:24 ` Jeffrey A Law @ 1999-07-31 23:33 ` Dave Love 1999-07-31 23:33 ` Toon Moene 0 siblings, 1 reply; 36+ messages in thread From: Dave Love @ 1999-07-31 23:33 UTC (permalink / raw) To: egcs-bugs >>>>> "Jeff" == Jeffrey A Law <law@cygnus.com> writes: Jeff> Folks, I'm seeing some personal barbs go back and forth. Can Jeff> everyone in this discussion please count to 10 slowly before Jeff> sending out the next message? My lip is already quite bitten, but apologies for the contribution I've made. I'm unsubscribing anyhow, belatedly. I don't feel I should be getting into fights with steering committee people one way or another. Jeff> On a technical note, while we certainly can not switch the Jeff> default to -mieee for this release, we can consider adding an Jeff> -mieee multilib to the alpha port for this release (assuming Jeff> the libraries will successfully build with -mieee). Yes, I built multilibbed (on OSF). Jeff> While it is not a perfect solution, It's perfect as far as the canonical test goes. Jeff> it would provide the user with a more IEEE complaint Jeff> environment if requested *and* by making it at least an option Jeff> with this release -mieee will get more testing. Someone should document multilibs as not only applicable to libgcc and look for any other cases where they might be needed for the language runtimes but weren't for libgcc. ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Bug with g77 and -mieee on Alpha Linux 1999-07-31 23:33 ` Dave Love @ 1999-07-31 23:33 ` Toon Moene 0 siblings, 0 replies; 36+ messages in thread From: Toon Moene @ 1999-07-31 23:33 UTC (permalink / raw) To: Dave Love; +Cc: egcs-bugs Dave Love wrote: > >>>>> "Jeff" == Jeffrey A Law <law@cygnus.com> writes: > Jeff> Folks, I'm seeing some personal barbs go back and forth. Can > Jeff> everyone in this discussion please count to 10 slowly before > Jeff> sending out the next message? > My lip is already quite bitten, but apologies for the contribution > I've made. I'm unsubscribing anyhow, belatedly. I don't feel I > should be getting into fights with steering committee people one way > or another. Note that Craig didn't want to be a member of the steering committee already months ago. You are not in a fight with me, if you think so. -- Toon Moene (toon@moene.indiv.nluug.nl) Saturnushof 14, 3738 XG Maartensdijk, The Netherlands Phone: +31 346 214290; Fax: +31 346 214286 GNU Fortran: http://world.std.com/~burley/g77.html ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Bug with g77 and -mieee on Alpha Linux 1999-07-31 23:33 ` Bug with g77 and -mieee on Alpha Linux Dave Love 1999-07-11 23:54 ` craig @ 1999-07-31 23:33 ` Toon Moene 1999-07-11 13:12 ` Toon Moene 1999-07-31 23:33 ` Jeffrey A Law 1 sibling, 2 replies; 36+ messages in thread From: Toon Moene @ 1999-07-31 23:33 UTC (permalink / raw) To: Dave Love; +Cc: egcs-bugs, craig Dave Love wrote: > > >>>>> "JCB" == <craig@jcb-sc.com> writes: > > JCB> Hardly. it's a *precise* description of what Toon constantly > JCB> advocates: the idea that any program written to exploit the full > JCB> range of IEEE 754 *values* (not even using *features* like > JCB> signalling NaNs, trapping on inexact, etc.) is inherently > JCB> *wrong*, > > I don't recall so, though perhaps that's what he thinks; it's > obviously silly. Whoops, I hope I didn't say this - as Dave writes: It's obviously silly. What I meant was what he was writing later: > JCB> Yet, programs *aren't* working, when compiled with g77. Toon says > JCB> they're buggy programs > Most of the time they are, and I say ``read `Working Programs'''. The > one in question is likely buggy, given that it's > optimization-dependent, regardless of the problem printing the > results. The hard problem, of course, is to separate the real bugs from the "read `working programs'" type of problems. However, g77 -mieee not working on Alpha's because lib[fg]2c isn't multilibbed is a bug, in my dictionary. Cheers, -- Toon Moene (toon@moene.indiv.nluug.nl) Saturnushof 14, 3738 XG Maartensdijk, The Netherlands Phone: +31 346 214290; Fax: +31 346 214286 GNU Fortran: http://world.std.com/~burley/g77.html ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Bug with g77 and -mieee on Alpha Linux 1999-07-31 23:33 ` Toon Moene @ 1999-07-11 13:12 ` Toon Moene 1999-07-31 23:33 ` craig 1999-07-31 23:33 ` Jeffrey A Law 1 sibling, 1 reply; 36+ messages in thread From: Toon Moene @ 1999-07-11 13:12 UTC (permalink / raw) To: Dave Love, egcs-bugs, craig I wrote: > Dave Love wrote: > > >>>>> "JCB" == <craig@jcb-sc.com> writes: > > JCB> Hardly. it's a *precise* description of what Toon constantly > > JCB> advocates: the idea that any program written to exploit the full > > JCB> range of IEEE 754 *values* (not even using *features* like > > JCB> signalling NaNs, trapping on inexact, etc.) is inherently > > JCB> *wrong*, > > I don't recall so, though perhaps that's what he thinks; it's > > obviously silly. > Whoops, I hope I didn't say this - as Dave writes: It's obviously > silly. You know what - I actually wrote what Craig said above (at least, some of it): - - - - - - - 8< - - - - - - - - - - - 8< - - - - - - - - - - - - Of course, I *still* think that a program generating denormals (and getting underflow to zero) is wrong: All of a sudden there's a number in the algorithm that's treated as "normal" (while it is _de_normal) - and now you can't divide by it. I cannot glean inside Martin's nonlinear equations, but the following description: <QUOTE> Perhaps, but while solving highly nonlinear sets of equations, like in analog circuit simulators nearly anything can appear. Nobody knows, where newton will bring you. You can decide to make smaller newton corrections only a f t e r you have the bad ones and thus you have to deal with these bad numbers somehow. </QUOTE> to *me* sounds like a grave mis-use of Newton-Raphson root finding. - - - - - - - 8< - - - - - - - - - - - 8< - - - - - - - - - - - - I hope it's clear from this excerpt that I was commenting on Martin Kahlert's problem - not on "Programs generating denormals" in general. Bweh - perhaps I should take a course in Strunk and White. :-/ [ To make matters worse - it wasn't even a problem in Martin's code - it turned out NINT(X) was wrongly generated :-( ] -- Toon Moene (toon@moene.indiv.nluug.nl) Saturnushof 14, 3738 XG Maartensdijk, The Netherlands Phone: +31 346 214290; Fax: +31 346 214286 GNU Fortran: http://world.std.com/~burley/g77.html >From klaas@kite.rhein-main.de Sun Jul 11 13:46:00 1999 From: Klaas Teschauer <klaas@kite.rhein-main.de> To: egcs-bugs@egcs.cygnus.com Subject: C++: Instantiation of abstract classes possible Date: Sun, 11 Jul 1999 13:46:00 -0000 Message-id: <19990710232708.A3041@kite.compuserve.com> X-SW-Source: 1999-07/msg00424.html Content-length: 1025 Description C++ allows it to create unnamend temporary objects via a direct call to a constructor, as if part of of a new construct. When using this to instantiate an abstract class, egcs fails to spot that the class is abstract. class Test { public: virtual int f() = 0; }; void func( Test& t ) { t.f(); } int main() { func( Test() ); } Compiling and running this gives the following results: kite:~/project/egcs-bugs/pure_func$ g++ -g -Wall pure_func.cc pure_func.cc: In function `int main()': pure_func.cc:9: warning: initialization of non-const reference `class Test &' from rvalue `Test' pure_func.cc:7: warning: in passing argument 1 of `func(Test &)' kite:~/project/egcs-bugs/pure_func$ ./a.out pure virtual method called kite:~/project/egcs-bugs/pure_func$ Environment Operating system: Debian Linux 2.1 (slink) on Intel i386 architecture, Kernel version 2.0.36, output of g++ --version: egcs-2.91.0. The compiler was installed as part of the Debian system and not modified in any way. Klaas Teschauer >From Gabriel.Dos_Reis@sophia.inria.fr Sun Jul 11 17:21:00 1999 From: Gabriel Dos_Reis <Gabriel.Dos_Reis@sophia.inria.fr> To: egcs-bugs@egcs.cygnus.com Subject: [C++] g++ isn't checking for class abstractness at instanciation time Date: Sun, 11 Jul 1999 17:21:00 -0000 Message-id: <xaj908m67kw.fsf@korrigan.inria.fr> X-SW-Source: 1999-07/msg00425.html Content-length: 407 The following is a test case, adapted from a post on news:fr.comp.lang.c++ , demonstrating a bug in g++'s template instanciation machinery. The call g<int>() is ill-formed and should be rejected. -- Gaby template<typename T> struct X { virtual void f() =0; }; template<typename T> void g(X<T> x) {} struct A : X<int> { void f() {} }; int main() { A a; g(a); // ERROR } ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Bug with g77 and -mieee on Alpha Linux 1999-07-11 13:12 ` Toon Moene @ 1999-07-31 23:33 ` craig 0 siblings, 0 replies; 36+ messages in thread From: craig @ 1999-07-31 23:33 UTC (permalink / raw) To: toon; +Cc: craig >[ To make matters worse - it wasn't even a problem in Martin's code - > it turned out NINT(X) was wrongly generated :-( ] Now, I wonder how much *sooner* we might have found that out if we'd made -mieee the default long, long ago, leading to more people (with less numerical-analysis experience, arguably trying to get "buggy" code to run) to conclude that g77 was at least *trying* to behave in a way they could predict, and therefore continue working with it, perhaps even doing more testing of EGCS snapshots over the past year or so? tq vm, (burley) ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Bug with g77 and -mieee on Alpha Linux 1999-07-31 23:33 ` Toon Moene 1999-07-11 13:12 ` Toon Moene @ 1999-07-31 23:33 ` Jeffrey A Law 1999-07-11 22:47 ` craig 1 sibling, 1 reply; 36+ messages in thread From: Jeffrey A Law @ 1999-07-31 23:33 UTC (permalink / raw) To: Toon Moene; +Cc: Dave Love, egcs-bugs, craig In message < 3788EDDA.6B5EDDDA@moene.indiv.nluug.nl >you write: > However, g77 -mieee not working on Alpha's because lib[fg]2c isn't > multilibbed is a bug, in my dictionary. It seems to me that whatever we do we should have the capability to provide either an ieee or no-ieee set of libraries via multilibs. As to which mode should be the default, I'll leave that to y'all to sort out. jeff ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Bug with g77 and -mieee on Alpha Linux 1999-07-31 23:33 ` Jeffrey A Law @ 1999-07-11 22:47 ` craig 0 siblings, 0 replies; 36+ messages in thread From: craig @ 1999-07-11 22:47 UTC (permalink / raw) To: law; +Cc: craig >It seems to me that whatever we do we should have the capability to provide >either an ieee or no-ieee set of libraries via multilibs. Richard Henderson pointed out that, probably, the default for *libraries* should be -mieee, with multlibbed -mno-ieee versions being provided only *after* we find, via profiling or whatever, to be necessary to obtain expected performance on real code. (Well, I've enhanced the wording on his position a bit -- hope I haven't misstated it as a result.) >As to which mode should be the default, I'll leave that to y'all to sort out. It's too late to make -mieee the default for 2.95, unless we significantly slip the schedule. I've seen too much evidence (in the form of bug reports) that codes either hit ICEs or miscompile with -mieee that don't otherwise, or at least they did in the past. It stands to reason, in the abstract, that -mieee makes for sufficient differences in FP code that latent bugs might be exposed, certainly. Therefore, the only way to offer a fully-working -mieee environment in 2.95 is to *not* make it the default. Which also means it won't get nearly as thoroughly tested in the future. As with -fno-emulate-complex, when and if we ever try to make it the default, we're therefore quite likely to find "show-stopper" bugs in the release that is intended to accomplish that default change, due to the upwards curve in worldwide testing of the default as we near the actual release. And, as with -fno-emulate-complex, unless one of *the* most important purposes of such a release is to change the default over and let the field shake out the bugs, the immediate response among GCC management to the reports of those bugs, during the latter part of the release cycle, will to be to change the default *back*, on the theory that we'll avoid show-stopper bugs... ...thus leading to six months, a year, or two, of the default not having been changed, therefore the option a *larger* portion of the user base *wants* as the default to run their code *not* being tested. (Though we can, I suspect, reduce the testing differential by finding more and more ways to a) test -mieee ourselves, b) tell everyone how committed we are to supporting -mieee, and c) ask them to use it even when they think they don't need it.) In case anybody is wondering why I mention -fno-emulate-complex, the issue here is, for me, again, *not* performance per se. And I disagree what ISTR Toon said about his making some kind of mistake by recommending that it be turned on -- I think Toon did us all a service, which led to us finding this new complex bug *sooner* than would otherwise had been possible. Yes, gcc back-end support for complex *was* known to be buggy, hence all the work I did making -femulate-complex support work, which amounted to putting all sorts of code into the g77 *front* end to transform COMPLEX expressions into lower-level forms that back end understands as being merely `float' and `double' expressions. That happened years ago now, I think. But, once GBE complex support was *believed* to no longer be buggy, and Toon recommended we make -fno-emulate-complex the default, I *jumped* at the chance (for some arbitrary definition of "jump", I suppose; perhaps I waited until I didn't see Jim Wilson or somebody say "whoa, no way is that ready to try, even in the development version" ;-). The reasoning I used was simple: while -fno-emulate-complex as a default might destabilize *g77* over some period of time, it would accomplish many of the same things I also believe having made -mieee, or 80-bit spills, the default would have achieved: - Much wider, "effortless", no-brainer-type testing of the "new" code (the GBE's complex support, new in the sense that it had recently been declared "finally ready" and yet had not been widely tested, not since g77 had -fno-emulate-complex as the (only) default and many bugs in the code thus exposed). - Much wider *effect* of that additional testing, in that, while *g77* might expose whatever problems remained in the new code, the benefits of *fixing* that code would include *gcc*'s __complex__ support (which I suspect is rarely used) working better; perhaps more likelihood that GNAT might someday use it instead of doing its *own* transformations (a la g77, but using completely *different* code); ditto for gpc, aka GNU Pascal; and so on. That is, the more we commit to making the gcc *back* end (GBE) do complex arithmetic right, the more we are able to "centralize" our testing. Right now, a complex bug found/fixed in GNAT doesn't help gcc, g++, g77, or gpc at all. Thanks to -fno-emulate-complex being the default, thanks to g77 taking the "hit", we now at least know *gcc* has known bugs in *its* __complex__ support -- and a *real* bug-fix (not switching to -femulate-complex!) to g77 therefore fixes gcc as well. So, while it's now clear that making -fno-emulate-complex the default means we're going to have to swallow new bugs in g77 in the *short* run, it's *still* the case that the *only* way we get long-term, solid code-generation for complex arithmetic across *all* languages and *all* systems we want to support is to bite this particular bullet. Note that none of the above analysis takes either numerical-analysis expertise *or* performance issues into account. I believe it need not, unless such issues threatened to *overwhelm* the other analysis. (For example, if we were now using the old, naive complex-divide method, and people showed how that would break lots of code, and we couldn't just switch that single method back by itself, then that might overwhelm the factors towards making -femulate-complex the default. Or if, say, we discovered that although new LAPACK exposed the recently discovered complex bug, we discovered that lots of *other* code that did *not* expose it would suffer a 20x slowdown under -femulate-complex, that might overwhelm in the other direction, towards swallowing/documenting the known bug.) tq vm, (burley) >From craig@jcb-sc.com Sun Jul 11 22:47:00 1999 From: craig@jcb-sc.com To: toon@moene.indiv.nluug.nl Cc: craig@jcb-sc.com Subject: Re: Bug with g77 and -mieee on Alpha Linux Date: Sun, 11 Jul 1999 22:47:00 -0000 Message-id: <19990711221516.27579.qmail@deer> References: <199907062042.WAA00509@keksy.linux.provi.de> <19990707140435.1429.qmail@deer> <19990707194012.A291@keksy.linux.provi.de> <3783B4B1.89DC2124@moene.indiv.nluug.nl> <19990708135500.12573.qmail@deer> <rzqoghls9j6.fsf@djlvig.dl.ac.uk> <19990710033831.20409.qmail@deer> <rzqu2rbqb8f.fsf@djlvig.dl.ac.uk> <3788EDDA.6B5EDDDA@moene.indiv.nluug.nl> <3788F9F5.188D2DAC@moene.indiv.nluug.nl> X-SW-Source: 1999-07/msg00427.html Content-length: 566 >[ To make matters worse - it wasn't even a problem in Martin's code - > it turned out NINT(X) was wrongly generated :-( ] Now, I wonder how much *sooner* we might have found that out if we'd made -mieee the default long, long ago, leading to more people (with less numerical-analysis experience, arguably trying to get "buggy" code to run) to conclude that g77 was at least *trying* to behave in a way they could predict, and therefore continue working with it, perhaps even doing more testing of EGCS snapshots over the past year or so? tq vm, (burley) >From law@cygnus.com Sun Jul 11 23:14:00 1999 From: Jeffrey A Law <law@cygnus.com> To: craig@jcb-sc.com Cc: toon@moene.indiv.nluug.nl, d.love@dl.ac.uk, egcs-bugs@egcs.cygnus.com Subject: Re: Bug with g77 and -mieee on Alpha Linux Date: Sun, 11 Jul 1999 23:14:00 -0000 Message-id: <4048.931760012@upchuck.cygnus.com> References: <19990711224024.27602.qmail@deer> X-SW-Source: 1999-07/msg00428.html Content-length: 1860 In message < 19990711224024.27602.qmail@deer >you write: > Richard Henderson pointed out that, probably, the default for *libraries* > should be -mieee, with multlibbed -mno-ieee versions being provided only > *after* we find, via profiling or whatever, to be necessary to obtain > expected performance on real code. (Well, I've enhanced the wording on > his position a bit -- hope I haven't misstated it as a result.) Interesting way to look at the problem. I'm not sure if I agree, but it is interesting and worth some thought. > It's too late to make -mieee the default for 2.95, unless we significantly > slip the schedule. I agree. > As with -fno-emulate-complex, when and if we ever try to make it the > default, we're therefore quite likely to find "show-stopper" bugs in > the release that is intended to accomplish that default change, due > to the upwards curve in worldwide testing of the default as we near > the actual release. The difference between these two cases is in the -f[no]emulate-complex we aren't even sure *what* the compiler should be doing, much less *how* to get it done. There's a rather serious design issue that needs to be investigated before we can even begin to look at solutions. Worse yet, the investigation phase will probably require looking at a variety of other Fortran compilers to see how they handle passing of complex values -- we should not insert a gratuitous ABI incompatibility for passing complex values. Letting the release out with -fno-emulate-complex without resolving these issues makes it much more likely that we will need to break binary compatibility again for the Fortran compiler once we figure out how to properly pass complex values. I haven't made a final decision on the complex stuff, but I'll have to make one in the very near future (next 24hrs). jeff ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: fortran integer sizes on linux AXP 1999-03-31 23:54 ` Dave Love 1999-03-31 23:54 ` craig @ 1999-03-31 23:54 ` Martin Kahlert 1999-03-07 3:35 ` Dave Love 1 sibling, 1 reply; 36+ messages in thread From: Martin Kahlert @ 1999-03-31 23:54 UTC (permalink / raw) To: Dave Love; +Cc: egcs-bugs Quoting Dave Love (d.love@dl.ac.uk): > >>>>> "MK" == Martin Kahlert <martin.kahlert@mchp.siemens.de> writes: > > MK> I was told to use Richard Henderson's patch (integer sizes for libf2c) > MK> but that didn't work either. > > If you look in config.log from the libf2c configure and see cpp error > messages concerning libiberty.h and/or gansidecl.h (?), then it's due > to a problem with libf2c/configure.in for which there's a fix still > awaiting approval. There are no explicit error messages in any config.log below libf2c, only a lot of messages concerning: macro `PROTO' used with just one arg. I don't believe, you mean those. grep gansidecl `find obj/alphaev56-unknown-linux-gnu/libf2c -name config.log` produces nothing as does the grep for libiberty. There must be another problem. Thanks for your reply, Martin. -- Your mouse has moved, Windows must be restarted for changes to take affect - restart now? ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: fortran integer sizes on linux AXP 1999-03-31 23:54 ` fortran integer sizes on linux AXP Martin Kahlert @ 1999-03-07 3:35 ` Dave Love 0 siblings, 0 replies; 36+ messages in thread From: Dave Love @ 1999-03-07 3:35 UTC (permalink / raw) To: egcs-bugs >>>>> "MK" == Martin Kahlert <martin.kahlert@provi.de> writes: MK> There are no explicit error messages in any config.log below libf2c, only MK> a lot of messages concerning: macro `PROTO' used with just one arg. MK> I don't believe, you mean those. They probably are caused by what I mean -- picking up (old) versions of the includes from /usr/include or whereever rather than not finding them at all. >From jsm28@cam.ac.uk Sun Mar 07 07:29:00 1999 From: "Joseph S. Myers" <jsm28@cam.ac.uk> To: egcs-bugs@egcs.cygnus.com Subject: egcs 19990307 -Wreturn-type bug Date: Sun, 07 Mar 1999 07:29:00 -0000 Message-id: <Pine.SOL.3.95q.990307152409.24719A-100000@red.csi.cam.ac.uk> X-SW-Source: 1999-03/msg00220.html Content-length: 332 With the following one line test case, egcs snapshot 19990307 on i686-pc-linux-gnu fails to give the `control reaches end of non-void function' warning when compiling with -O -Wreturn-type. This is a regression relative to egcs 1.1.1, which does give the warning. Testcase: int foo(void) {} -- Joseph S. Myers jsm28@cam.ac.uk ^ permalink raw reply [flat|nested] 36+ messages in thread
* Bug with g77 and -mieee on Alpha Linux @ 1999-07-06 13:40 martin.kahlert 1999-07-31 23:33 ` craig 0 siblings, 1 reply; 36+ messages in thread From: martin.kahlert @ 1999-07-06 13:40 UTC (permalink / raw) To: egcs-bugs Hi, There seems to be an error on Linux Alpha with egcs-19990629 (gcc-2.95 prerelease:) Can anyone confirm this bug: t.f: SUBROUTINE PRT(X) REAL*8 X WRITE(*,*) X RETURN END h.c: int main(int argc,const char *argv[]) { union { int i[2]; double d; } x; x.i[0]=0xd3a34200; x.i[1]=0x6; prt_(&x); return 0; } gcc -c -mieee -c h.c g77 -c -mieee -c t.f g77 -o t t.o h.o ./h Floating point exception I am sorry that i cannot provide a real world test, i got these number from a big simulation tool and it was most easily to put into g77 this way. Perhaps i have done something wrong, but i thought, -mieee should prevent these FPE's from occuring? Thanks, Martin. >From oliva@dcc.unicamp.br Tue Jul 06 13:45:00 1999 From: Alexandre Oliva <oliva@dcc.unicamp.br> To: Jason Merrill <jason@cygnus.com> Cc: law@cygnus.com, egcs-bugs@egcs.cygnus.com, egcs-patches@egcs.cygnus.com Subject: Re: [patch] C++ -fno-rtti regression on sparc-sun-solaris2.[75] Date: Tue, 06 Jul 1999 13:45:00 -0000 Message-id: <oryagttsoj.fsf@cupuacu.lsd.dcc.unicamp.br> References: <orr9mn757e.fsf@cupuacu.lsd.dcc.unicamp.br> <u9btdpczxf.fsf@yorick.cygnus.com> X-SW-Source: 1999-07/msg00226.html Content-length: 480 On Jul 6, 1999, Jason Merrill <jason@cygnus.com> wrote: > This is OK for the main branch and 2.95. Jeff? Thanks, installed in mainline; waiting for Jeff's approval for the release branch. -- Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il {oliva,Alexandre.Oliva}@dcc.unicamp.br aoliva@{acm.org,computer.org} oliva@{guarana.com,{gnu,kaffe,samba}.org,{egcs,sourceware}.cygnus.com} *** E-mail about software projects will be forwarded to mailing lists ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Bug with g77 and -mieee on Alpha Linux 1999-07-06 13:40 Bug with g77 and -mieee on Alpha Linux martin.kahlert @ 1999-07-31 23:33 ` craig 1999-07-31 23:33 ` Martin Kahlert 1999-07-31 23:33 ` Martin Kahlert 0 siblings, 2 replies; 36+ messages in thread From: craig @ 1999-07-31 23:33 UTC (permalink / raw) To: martin.kahlert; +Cc: craig >Perhaps i have done something wrong, but i thought, -mieee should >prevent these FPE's from occuring? I don't know, it might/should, though I don't know offhand what the FP value you're trying to print actually is. (It seems unlikely to be a signaling NaN, but, if that *was* what you're trying to print, I could understand why you got an FPE.) There are two things that might be working, together or separately, to give you trouble: 1. You're supplying your own main(), but not running the libg2c initialization code libg2c's main() normally runs. See the g77 docs for more info. (Though in your example you wouldn't need to call the routine to set up command-line info, you might in the product code from which you derived the example. And, in both examples, setting up the signal stuff might be necessary.) 2. You're using libg2c to print the FP value, but libg2c *itself* has (presumably) not been compiled with -mieee. I had assumed (erroneously, as I recently discovered) that gcc automatically used multilibs to produce -mieee-compiled libraries for Alpha targets, because, without that, libraries can crash (and libg2c apparently *will* crash doing, e.g., output of floating-point values that require -mieee). 3. You're not supplying `-mieee' when linking the object files, so even if there *was* a libg2c.a built with -mieee available (and properly configured, whatever that means), you'd pick up the default one and, if #2 is correct, crash anyway. My own opinion is that this sort of thing is insanely painful to deal with, and that the default should have been -mieee all along (both for gcc and for Digital's compilers, but I assume the latter have all-along offered easier ways to get the -mieee behavior), with an option (-mno-ieee) being needed to get -mno-ieee performance. But the philosophy of most software designers these days seems to be "make it fast, then offer the user a variety of tweaks to make it work more slowly". (The same philosophy is why gcc won't ever default to 80-bit spills of 80-bit FP registers on the x86, I'm afraid.) tq vm, (burley) ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Bug with g77 and -mieee on Alpha Linux 1999-07-31 23:33 ` craig @ 1999-07-31 23:33 ` Martin Kahlert 1999-07-31 23:33 ` craig 1999-07-31 23:33 ` Martin Kahlert 1 sibling, 1 reply; 36+ messages in thread From: Martin Kahlert @ 1999-07-31 23:33 UTC (permalink / raw) To: craig; +Cc: egcs-bugs Quoting craig@jcb-sc.com (craig@jcb-sc.com): > >Perhaps i have done something wrong, but i thought, -mieee should > >prevent these FPE's from occuring? > > I don't know, it might/should, though I don't know offhand what the > FP value you're trying to print actually is. (It seems unlikely to > be a signaling NaN, but, if that *was* what you're trying to print, > I could understand why you got an FPE.) It prints out the value without any problem from C. (try printf("%e\n",x.d)) No exception occurs from C. I'am not at home where my alpha is, but i think it was something around 1e-314. > There are two things that might be working, together or separately, to > give you trouble: > > 1. You're supplying your own main(), but not running the libg2c > initialization code libg2c's main() normally runs. See the > g77 docs for more info. (Though in your example you wouldn't > need to call the routine to set up command-line info, you might > in the product code from which you derived the example. And, > in both examples, setting up the signal stuff might be necessary.) Wouldn't it be useful to provide an option -fnomain like other compilers have? So the initialization could be performed (by a crt*file ?) before main() is called. > 2. You're using libg2c to print the FP value, but libg2c *itself* > has (presumably) not been compiled with -mieee. > > I had assumed (erroneously, as I recently discovered) that gcc > automatically used multilibs to produce -mieee-compiled libraries > for Alpha targets, because, without that, libraries can crash (and > libg2c apparently *will* crash doing, e.g., output of floating-point > values that require -mieee). So -mieee should be added to the compile options on Alpha (even in the upcoming release, i think). > 3. You're not supplying `-mieee' when linking the object files, so > even if there *was* a libg2c.a built with -mieee available (and > properly configured, whatever that means), you'd pick up the default > one and, if #2 is correct, crash anyway. O.k. i could check this at home. > My own opinion is that this sort of thing is insanely painful to deal with, > and that the default should have been -mieee all along (both for gcc and > for Digital's compilers, but I assume the latter have all-along offered > easier ways to get the -mieee behavior), with an option (-mno-ieee) being > needed to get -mno-ieee performance. > > But the philosophy of most software designers these days seems to be > "make it fast, then offer the user a variety of tweaks to make it work > more slowly". (The same philosophy is why gcc won't ever default to > 80-bit spills of 80-bit FP registers on the x86, I'm afraid.) > > tq vm, (burley) Is it possible to just ignore the FPE's? That means, does the Alpha fpu produce NaN's if i don't suppy -mieee and does it deal with them correctly then? Thanks for your suggestions, Martin. (These FPEs are a pain in the a* on Alphas for my kind of simulation) -- esa$ gcc -Wall -o ariane5 ariane5.c ariane5.c: 666: warning: long float implicitly truncated to unsigned type esa$ ariane5 ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Bug with g77 and -mieee on Alpha Linux 1999-07-31 23:33 ` Martin Kahlert @ 1999-07-31 23:33 ` craig 0 siblings, 0 replies; 36+ messages in thread From: craig @ 1999-07-31 23:33 UTC (permalink / raw) To: martin.kahlert; +Cc: craig >Quoting craig@jcb-sc.com (craig@jcb-sc.com): >> >Perhaps i have done something wrong, but i thought, -mieee should >> >prevent these FPE's from occuring? >> >> I don't know, it might/should, though I don't know offhand what the >> FP value you're trying to print actually is. (It seems unlikely to >> be a signaling NaN, but, if that *was* what you're trying to print, >> I could understand why you got an FPE.) >It prints out the value without any problem from C. (try printf("%e\n",x.d)) >No exception occurs from C. I'am not at home where my alpha is, but >i think it was something around 1e-314. That makes sense -- I'm told libc (glibc?) uses unsigned integer arithmetic to do its FP I/O. I know libf2c compares FP values it's about to output (for some formats) to, e.g., `.1', using normal FP arithmetic, as I recently located some code that did this, to show to Richard Henderson in a private email discussion on this general topic. >> There are two things that might be working, together or separately, to >> give you trouble: >> >> 1. You're supplying your own main(), but not running the libg2c >> initialization code libg2c's main() normally runs. See the >> g77 docs for more info. (Though in your example you wouldn't >> need to call the routine to set up command-line info, you might >> in the product code from which you derived the example. And, >> in both examples, setting up the signal stuff might be necessary.) >Wouldn't it be useful to provide an option -fnomain like other compilers have? >So the initialization could be performed (by a crt*file ?) >before main() is called. Well, yes, I think, in the long run, the best thing is to have g77 simply generate main() for a main program unit, among other things. In the meantime, there are just way too many other things to work on, especially since we do not have a good handle on all the requirements, platforms, etc., to improve this area of g77/libg2c. (For example, I considered my changing libg2c by turning main() into a small routine that invokes subroutines representing breakings-out of code in libf2c's main() to be a "safe" improvement, one that I thought would properly address the complaints about link-time errors due to people trying to link their own main() in with code that called GETARG, among other things. I've since heard rumors, from Dave Gay, netlib libf2c maintainer, that my doing that broken some things, but I don't recall ever getting bug reports along those lines. The upshot is, he's now quite unlikely to integrate my changes into libf2c, and I'm no longer interested in experimenting with changes to libg2c, if people are going to complain to him, rather than submit decent bug reports to us. So, if anything, libg2c is going to "regress" over time back to libf2c, not be incrementally "improved" vis-a-vis better handling of main(). That way, we can ask people who want run-time improvements in libF77 or libI77 to convince Dave Gay, and simply scoop them up when and if they appear in netlib libf2c.) >> 2. You're using libg2c to print the FP value, but libg2c *itself* >> has (presumably) not been compiled with -mieee. >> >> I had assumed (erroneously, as I recently discovered) that gcc >> automatically used multilibs to produce -mieee-compiled libraries >> for Alpha targets, because, without that, libraries can crash (and >> libg2c apparently *will* crash doing, e.g., output of floating-point >> values that require -mieee). >So -mieee should be added to the compile options on Alpha (even in the upcoming >release, i think). If I'd had my Alpha up and running for the past few months, I might have been able to make that happen. It's too late now, I see zero likelihood of this making it into any 2.95 release. But 3.0, or if a 2.96 happens, maybe/probably. Alpha users will have to proactively push for it, though, I would think. >> 3. You're not supplying `-mieee' when linking the object files, so >> even if there *was* a libg2c.a built with -mieee available (and >> properly configured, whatever that means), you'd pick up the default >> one and, if #2 is correct, crash anyway. >O.k. i could check this at home. I should note that I'm still new to this "multilib" stuff, especially since my currently-running systems don't default to building any multilibs. So I *think* I'm right, but my info is based on a combination of what I've read and been told by others, it's not like I've done any of this stuff myself (yet). >Is it possible to just ignore the FPE's? That means, does the Alpha fpu produce NaN's >if i don't suppy -mieee and does it deal with them correctly then? My understanding has been that the Alpha (cores prior to EV6, aka 21264, if I have this terminology correct) traps when it executes FP instructions involving operands having certain values (NaNs; denormals -- your case, I think; maybe Infs). The OS (these days -- Linux didn't always) has code to handle the trap by emulating the instruction for the operands and resuming the code after the FP instruction. *However*, this code cannot succeed if the trapping FP instruction is executed while another, potentially trapping, FP instruction is in its "trap shadow" (the terminology I recall the Alpha book using). That is, the Alpha might be executing two or more FP instructions when one of them traps, and does not have the silicon built in to be able to handle the general case where any number of them require software emulation to complete. (That's a blurry way to put it -- having worked on VLIW machines, this actually does make perfect sense to me, but I'm sure I haven't explained it well, and would rather not try in this thread.) Avoiding this problem is what -mieee accomplishes, by placing TRAPB (Trap Barrier), or maybe EXB (EXception Barrier) instructions, in the instruction stream between/around FP instructions that might trap, among other things. The result is code that executes more slowly, but, if it does hit one of these FP traps, the trap handler can safely do the emulation and then resume executing the code stream. I don't know how the trap handler tells the difference between an emulatable and a non-emulatable FP trap. Maybe the instruction stream itself has the necessary hints; maybe the hardware knows enough to tell the trap handler "sorry, I've got another FP instruction in this trapping instruction's shadow, you won't be able to resume". But, if I'm right, I think it means you can't just disable FP exceptions and expect things to work. >(These FPEs are a pain in the a* on Alphas for my kind of simulation) Yep. I think you're expected to be grateful for the speed at which they happen. ;-) tq vm, (burley) P.S. I'm a bit worried that I have this all wrong now, due to the private email Richard Henderson recently sent me. I'm *really* hoping he just got a bit confused or forgetful, because the alternative is that I've been *hugely* confused/forgetful about this. It's hard to guess which is the case: he's hugely brilliant, but he's also been working a lot harder on a lot more machines lately than I have, so it'd be understandable if he lost track of a few (un-)exeptional details here and there. ;-) ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Bug with g77 and -mieee on Alpha Linux 1999-07-31 23:33 ` craig 1999-07-31 23:33 ` Martin Kahlert @ 1999-07-31 23:33 ` Martin Kahlert 1999-07-31 23:33 ` Toon Moene 1 sibling, 1 reply; 36+ messages in thread From: Martin Kahlert @ 1999-07-31 23:33 UTC (permalink / raw) To: craig; +Cc: egcs-bugs Quoting craig@jcb-sc.com (craig@jcb-sc.com): > >Perhaps i have done something wrong, but i thought, -mieee should > >prevent these FPE's from occuring? > > I don't know, it might/should, though I don't know offhand what the > FP value you're trying to print actually is. (It seems unlikely to > be a signaling NaN, but, if that *was* what you're trying to print, > I could understand why you got an FPE.) The value is 1.448625e-313. > There are two things that might be working, together or separately, to > give you trouble: > > 1. You're supplying your own main(), but not running the libg2c > initialization code libg2c's main() normally runs. See the > g77 docs for more info. (Though in your example you wouldn't > need to call the routine to set up command-line info, you might > in the product code from which you derived the example. And, > in both examples, setting up the signal stuff might be necessary.) That's not the case (i changed that with no success). > > 2. You're using libg2c to print the FP value, but libg2c *itself* > has (presumably) not been compiled with -mieee. This must be the reason. It has problems with 'if(n<0)' in lwrite.c: l_g. Here it generates an FPE. So i ask you to incorporate -mieee into the flags for libg2c. > I had assumed (erroneously, as I recently discovered) that gcc > automatically used multilibs to produce -mieee-compiled libraries > for Alpha targets, because, without that, libraries can crash (and > libg2c apparently *will* crash doing, e.g., output of floating-point > values that require -mieee). > > 3. You're not supplying `-mieee' when linking the object files, so > even if there *was* a libg2c.a built with -mieee available (and > properly configured, whatever that means), you'd pick up the default > one and, if #2 is correct, crash anyway. This didn't make any difference, either. > My own opinion is that this sort of thing is insanely painful to deal with, > and that the default should have been -mieee all along (both for gcc and > for Digital's compilers, but I assume the latter have all-along offered > easier ways to get the -mieee behavior), with an option (-mno-ieee) being > needed to get -mno-ieee performance. I have to agree heavily on that. Thanks, Martin. -- Your mouse has moved, Windows must be restarted for changes to take affect - restart now? ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Bug with g77 and -mieee on Alpha Linux 1999-07-31 23:33 ` Martin Kahlert @ 1999-07-31 23:33 ` Toon Moene 1999-07-08 0:09 ` Martin Kahlert 1999-07-31 23:33 ` craig 0 siblings, 2 replies; 36+ messages in thread From: Toon Moene @ 1999-07-31 23:33 UTC (permalink / raw) To: martin.kahlert, egcs-bugs Martin Kahlert wrote: > > Quoting craig@jcb-sc.com (craig@jcb-sc.com): > > My own opinion is that this sort of thing is insanely painful to deal with, > > and that the default should have been -mieee all along (both for gcc and > > for Digital's compilers, but I assume the latter have all-along offered > > easier ways to get the -mieee behavior), with an option (-mno-ieee) being > > needed to get -mno-ieee performance. > I have to agree heavily on that. I'm sorry, but I am going to respectfully disagree. Full IEEE comformance is very expensive on the Alpha's and the reason you need it very uncommon. Martin provoked it by passing a denormal to libg2c, but *in normal programming* running into denormal should point to some error in the logic of your algorithms. [ Unless you're in cosmology and try to express everything in 32-bit REALs using SI units - my point is that nobody *does* that. ] -- Toon Moene (toon@moene.indiv.nluug.nl) Saturnushof 14, 3738 XG Maartensdijk, The Netherlands Phone: +31 346 214290; Fax: +31 346 214286 GNU Fortran: http://world.std.com/~burley/g77.html ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Bug with g77 and -mieee on Alpha Linux 1999-07-31 23:33 ` Toon Moene @ 1999-07-08 0:09 ` Martin Kahlert 1999-07-08 15:58 ` Dave Love 1999-07-31 23:33 ` craig 1 sibling, 1 reply; 36+ messages in thread From: Martin Kahlert @ 1999-07-08 0:09 UTC (permalink / raw) To: Toon Moene; +Cc: egcs-bugs Quoting Toon Moene (toon@moene.indiv.nluug.nl): > Martin Kahlert wrote: > > > > Quoting craig@jcb-sc.com (craig@jcb-sc.com): > > > > My own opinion is that this sort of thing is insanely painful to deal with, > > > and that the default should have been -mieee all along (both for gcc and > > > for Digital's compilers, but I assume the latter have all-along offered > > > easier ways to get the -mieee behavior), with an option (-mno-ieee) being > > > needed to get -mno-ieee performance. > > I have to agree heavily on that. > > I'm sorry, but I am going to respectfully disagree. Full IEEE > comformance is very expensive on the Alpha's and the reason you need it > very uncommon. Martin provoked it by passing a denormal to libg2c, but > *in normal programming* running into denormal should point to some error > in the logic of your algorithms. > [ Unless you're in cosmology and try to express everything in 32-bit > REALs using SI units - my point is that nobody *does* that. ] Perhaps, but while solving highly nonlinear sets of equations, like in analog circuit simulators nearly anything can appear. Nobody knows, where newton will bring you. You can decide to make smaller newton corrections only a f t e r you have the bad ones and thus you have to deal with these bad numbers somehow. But anyway, egcs-2.95 (19990629-snapshot) seems to have a problem in its optimizer on Alphas, since these problems disappear when i compile without optimization - strange, but it's very hard even to tell which file was compiled wrongly. Perhaps i can find anything useful. Thanks for your reply, Martin. -- esa$ gcc -Wall -o ariane5 ariane5.c ariane5.c: 666: warning: long float implicitly truncated to unsigned type esa$ ariane5 >From ian@zembu.com Thu Jul 08 00:23:00 1999 From: Ian Lance Taylor <ian@zembu.com> To: egcs-bugs@egcs.cygnus.com Cc: ian@airs.com Subject: demangler bug Date: Thu, 08 Jul 1999 00:23:00 -0000 Message-id: <19990708072251.30814.qmail@daffy.airs.com> X-SW-Source: 1999-07/msg00286.html Content-length: 674 This c++ file, when compiled by fairly recent CVS sources, produces a symbol which the current c++filt program can not demangle. ================================================== namespace n { class c { public: int m (); }; }; int fn (n::c *ca, int (n::c::* pfn) ()) { return (ca->*pfn) (); } ================================================== The symbol is fn__FPQ21n1cPMQ21n1cFPQ21n1c_i The symbol looks more or less correct, and I think it should demangle to something like fn (n::c *, int (n::c::*) (n::c *)) The bug appears to be that cplus-dem.c does not expect to see 'Q' after 'M'. It only expects to see a digit, 'X', 'Y', or 't'. Ian >From eek@escape.ca Thu Jul 08 01:56:00 1999 From: Tony Mantler <eek@escape.ca> To: egcs-bugs@egcs.cygnus.com Subject: Cross-compile failure. yay. Date: Thu, 08 Jul 1999 01:56:00 -0000 Message-id: <v04003a02b3aa03669108@[216.81.6.124]> X-SW-Source: 1999-07/msg00287.html Content-length: 1908 Abstract: Compilation of i386-linux hosted ppc-linux target cross compiler fails with an incorrect option passed to 'as' by the newly compiled gcc. Versions: Host compiler = egcs-2.91.66 (debian package gcc 2.91.66-2) Host binutils = 2.9.1.0.25 (debian package binutils 2.9.1.0.25-2) Target compiler = egcs 1.1.2 core source + egcs 1.1.2 c++ source Target binutils = 2.9.1.0.25 (debian package binutils-multiarch 2.9.1.0.25-2) Make = GNU Make 3.77 (debian package make 3.77-4) Host system: ti-486/40 16M/420M, Debian 2.1/2.2, 2.2.10 kernel Target system: PPC-603e/75 (Mac Performa 5200), will run linux later. Setup: ../egcs-1.1.2/configure \ ppc-linux \ --with-cpu=603e \ --host=i386-linux \ --with-headers=/usr/include make cross Results: [happy compiling stuff deleted] for name in _muldi3 _divdi3 _moddi3 _udivdi3 _umoddi3 _negdi2 _lshrdi3 _ashldi3 _ashrdi3 _ffsdi2 _udiv_w_sdiv _udivmoddi4 _cmpdi2 _ucmpdi2 _floatdidf _floatdisf _fixunsdfsi _fixunssfsi _fixunsdfdi _fixdfdi _fixunssfdi _fixsfdi _fixxfdi _fixunsxfdi _floatdixf _fixunsxfsi _fixtfdi _fixunstfdi _floatditf __gcc_bcmp _varargs __dummy _eprintf _bb _shtab _clear_cache _trampoline __main _exit _ctors _pure; \ do \ echo ${name}; \ /usr/src/egcs-bin/gcc/xgcc -B/usr/src/egcs-bin/gcc/ -O2 -DCROSS_COMPILE -DIN_GCC -g -O2 -I./include -fPIC -g1 -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -mstrict-align -I. -I../../egcs-1.1.2/gcc -I../../egcs-1.1.2/gcc/config -c -DL${name} \ ../../egcs-1.1.2/gcc/libgcc2.c -o ${name}.o; \ if [ $? -eq 0 ] ; then true; else exit 1; fi; \ ppc-linux-ar rc tmplibgcc2.a ${name}.o; \ rm -f ${name}.o; \ done _muldi3 as: unrecognized option `-ppc' make[3]: *** [libgcc2.a] Error 1 [make recursion collapse deleted] -- Tony Mantler Renaissance Nerd Extraordinaire eek@escape.ca Winnipeg, Manitoba, Canada http://www.escape.ca/~eek ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Bug with g77 and -mieee on Alpha Linux 1999-07-08 0:09 ` Martin Kahlert @ 1999-07-08 15:58 ` Dave Love 0 siblings, 0 replies; 36+ messages in thread From: Dave Love @ 1999-07-08 15:58 UTC (permalink / raw) To: martin.kahlert; +Cc: Toon Moene, egcs-bugs >>>>> "MK" == Martin Kahlert <martin.kahlert@mchp.siemens.de> writes: MK> But anyway, egcs-2.95 (19990629-snapshot) seems to have a problem MK> in its optimizer on Alphas, since these problems disappear when i MK> compile without optimization That's a non sequitur. There may be an optimizer bug biting, but the odds are against it. You _have_ taken note of the `Working Programs' node of the manual, I hope. >From khan@xraylith.wisc.EDU Thu Jul 08 16:05:00 1999 From: Mumit Khan <khan@xraylith.wisc.EDU> To: Eric Dumas <dumas@gandalf.freenix.org> Cc: egcs-bugs@egcs.cygnus.com Subject: Re: egcs1.2, template access Date: Thu, 08 Jul 1999 16:05:00 -0000 Message-id: <Pine.LNX.3.96.990708180133.27231A-100000@mercury.xraylith.wisc.edu> References: <19990708122835.A11247@gandalf.freenix.org> X-SW-Source: 1999-07/msg00323.html Content-length: 1639 On Thu, 8 Jul 1999, Eric Dumas wrote: > [Please note I am not on the egcs-bugs list] > > Hello. > > I have a problem porting code compiling with SunWspro 4.0 (and > MSC++). The problem is locating in the use of template, and to the > access to the member of this template. SunWspro 4.0 and MSC++ are in error. > The error is "Parse error before ;". > Egcs v1.1.2 release (2.91.66), linux 2.2.5 - Redhat6.0 See "typename" below. > > > template <class ITERATED_CONTAINER, class INDEXED_CONTAINER, class > +BINARY_TRANSFORM> I assume the '+' is a typo. > inline void foo(ITERATED_CONTAINER &destContainer, > const INDEXED_CONTAINER &srcContainer, > SizeT srcLength, > BINARY_TRANSFORM transform) What is SizeT. Please post complete code for bug reports. Let's say we typedef that to unsigned int for now. > { > for (SizeT iSource(0) ; > iSource != srcLength ; > ++iSource) { > > // This line is not compiling > ITERATED_CONTAINER::value_type elem; typename ITERATED_CONTAINER::value_type elem; ^^^^^^^ Need this. Please see the C++ standard or search for "typename" in any C++ forum for more info. > > transform(elem, srcContainer[iSource]); > destContainer.push_bask(elem); > } > } > > -- > Eric Dumas (dumas@Linux.EU.Org, dumas@freenix.org) > http://www.freenix.org/~dumas/ > -- Linux -- Linux -- Linux -- Linux -- Linux -- Linux -- Linux -- Linux -- > Regards, Mumit ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Bug with g77 and -mieee on Alpha Linux 1999-07-31 23:33 ` Toon Moene 1999-07-08 0:09 ` Martin Kahlert @ 1999-07-31 23:33 ` craig 1999-07-08 8:01 ` Richard Hadsell ` (2 more replies) 1 sibling, 3 replies; 36+ messages in thread From: craig @ 1999-07-31 23:33 UTC (permalink / raw) To: toon; +Cc: craig >Martin Kahlert wrote: >> >> Quoting craig@jcb-sc.com (craig@jcb-sc.com): > >> > My own opinion is that this sort of thing is insanely painful to deal with, >> > and that the default should have been -mieee all along (both for gcc and >> > for Digital's compilers, but I assume the latter have all-along offered >> > easier ways to get the -mieee behavior), with an option (-mno-ieee) being >> > needed to get -mno-ieee performance. >> I have to agree heavily on that. > >I'm sorry, but I am going to respectfully disagree. Full IEEE >comformance is very expensive on the Alpha's and the reason you need it >very uncommon. Martin provoked it by passing a denormal to libg2c, but >*in normal programming* running into denormal should point to some error >in the logic of your algorithms. First, I realize that you're a huge advocate for fast-programs-more-important- than-working-programs stance, so I'm not really going to debate that with you. (Note carefully that I'm *not* saying you're an advocate for the "fast-programs-are-more-important-than-working-*compilers*" stance. You want the compiler to work. You just figure that making *programs* and *applications* work should involve shifting however much of a burden to the applications programmer is necessary to make nearly-perfectly-correct code run as fast as the available iron permits. I understand that perspective, but happen to disagree with it, because IMO it leads to planes falling from the sky -- there are too few good programmers, better to put them to work *optimizing* compilers and programs that *default* to correctness, than have them run around trying to stamp out subtle coding bugs in all the Fortran, C, C++, etc. code ever written, because the default for that code is "run it fast".) Second, the issue is not what *usually* happens in IEEE. The issue is, what happens when the program computes the wrong values, due to bugs, ill-conditioned inputs, etc. If the behavior seen on Alphas is also seen on other systems, then, perhaps, -mno-ieee is a reasonable default. That would mean, I gather, that *other* systems normally crash when encountering underflows (that'd require denormals for IEEE) in a way that could not be simply and easily overridden by installing a signal handler or some such thing. I'm not aware, offhand, of such a system. And my impression is, once a denormal crashes a running Alpha program, you *cannot* simply resume it from the point of the crash with a NaN, Inf, or zero value computed as the result. (If you could do *that*, you could just emulate the actual computation, correct? But maybe the Alpha itself assists with those sorts of resumptions in a way it doesn't with resuming with an arbitrary result value.) So, my impression is, the Alpha is the only widely deployed system that defaults to crashing *and burning* whenever a program happens to compute a floating-point value that underflows or overflows, and that avoiding the "burning" part (the inability to continue execution) requires recoding and/or recompilation (and, with GCC through 2.95, *rebuilding* the *compiler* suite so libraries get compiled with -mieee). *That*, if stated correctly, is why -mno-ieee is a bug, from a usability perspective. tq vm, (burley) ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Bug with g77 and -mieee on Alpha Linux 1999-07-31 23:33 ` craig @ 1999-07-08 8:01 ` Richard Hadsell 1999-07-31 23:33 ` Dave Love 1999-07-09 16:12 ` Dave Love [not found] ` <3784BE26.D14F95CD@blueskystudios.com> 2 siblings, 1 reply; 36+ messages in thread From: Richard Hadsell @ 1999-07-08 8:01 UTC (permalink / raw) To: craig; +Cc: egcs-bugs [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 4033 bytes --] Sorry, I forgot to cc: the list. craig@jcb-sc.com wrote: > > Second, the issue is not what *usually* happens in IEEE. > > The issue is, what happens when the program computes the wrong values, > due to bugs, ill-conditioned inputs, etc. I agree with you, and it's nice to hear a regular contributor to this list espouse robustness in a compiler's default product. For instance, optimizations that may produce dangerous code come with adequate warnings and are never the default. I just want to point out a very normal calculation that has nothing to do with bugs or ill-conditioned input. The library function exp(), when you are using the libm that comes with most systems, can easily produce a denormal. If you want exp() to force denormals to 0, I think you need to use a different library. It makes sense to me that the compiler should generate code compatible with the standard version of libm. It should be an option, not a default, that you want faster code and that you will link to a nonstandard (perhaps faster, too) math library like libffm. I also received this suggestion from Mark Davis at Digipaq (I don't recall whether it was before or after the merger). You might consider putting it into an application's start-up code when no -mieee option is given, or at least you could you add it to your docs about handling floating-point problems on alphas: See "man ieee", and #include <machine/fpu.h>. When the program starts up, make a call to ieee_set_fp_control(IEEE_MAP_UMZ); , which sets the fp control to cause underflow to map to zero. [Note, fpu.h has the line: #define IEEE_MAP_UMZ 0x002000 /* infinities map to largest num */ but the comment is WRONG - UMZ means Underflow Maps to Zero!] -- Dick Hadsell 914-381-8400 x5446 Fax: 914-381-9790 Reply-to: hadsell@blueskystudios.com Blue Sky Studios http://www.blueskystudios.com 1 South Road, Harrison, NY 10528 >From uddeborg@carmen.se Thu Jul 08 08:15:00 1999 From: Göran Uddeborg <uddeborg@carmen.se> To: egcs-bugs@egcs.cygnus.com Subject: Re: Too many warnings. Date: Thu, 08 Jul 1999 08:15:00 -0000 Message-id: <199907081515.RAA03252@gibraltar.carmen.se> References: <199907021435.KAA17593@jaj.com> <199907021536.RAA00632@gibraltar.carmen.se> <or908x4p9k.fsf@cupuacu.lsd.dcc.unicamp.br> <19990705210849.2329.qmail@deer> <199907071629.SAA07799@gibraltar.carmen.se> <19990707175936.2030.qmail@deer> <199907080909.LAA17610@gibraltar.carmen.se> <19990708140921.12705.qmail@deer> X-SW-Source: 1999-07/msg00300.html Content-length: 324 > After all, it's unwise to define a macro thusly: > > #define macro(l,m) l++ && (m += 5) Oh yes, a macro should always have parentheses everywhere. And indeed, you would probably not put parentheses around a zero level expression. So your suggestion might be a reasonable compromise between complexity and precision. >From ford@vss.fsi.com Thu Jul 08 08:22:00 1999 From: Brian Ford <ford@vss.fsi.com> To: Tony Mantler <eek@escape.ca> Cc: egcs-bugs@egcs.cygnus.com Subject: Re: Cross-compile failure. yay. Date: Thu, 08 Jul 1999 08:22:00 -0000 Message-id: <Pine.SGI.4.03.9907081016320.583995-100000@iscream.vss.fsi.com> References: <v04003a02b3aa03669108@[216.81.6.124]> X-SW-Source: 1999-07/msg00301.html Content-length: 745 On Thu, 8 Jul 1999, Tony Mantler wrote: > Setup: > > ../egcs-1.1.2/configure \ > ppc-linux \ Use --target=ppc-linux > --with-cpu=603e \ > --host=i386-linux \ You should almost never specify the host. Let configure guess. > --with-headers=/usr/include > > make cross > > > Results: > > [happy compiling stuff deleted] > > as: unrecognized option `-ppc' > make[3]: *** [libgcc2.a] Error 1 > xgcc is using the wrong as. This may be a gcc Makefile bug that I have seen before. It works best if you do a one tree build with binutils in the gcc tree. See http://www.objsw.com/CrossGCC/ for details. -- Brian Ford Software Engineer Vital Visual Simulation Systems FlightSafety International Phone: 314-551-8460 Fax: 314-551-8444 ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Bug with g77 and -mieee on Alpha Linux 1999-07-08 8:01 ` Richard Hadsell @ 1999-07-31 23:33 ` Dave Love 0 siblings, 0 replies; 36+ messages in thread From: Dave Love @ 1999-07-31 23:33 UTC (permalink / raw) To: egcs-bugs >>>>> "RH" == Richard Hadsell <hadsell@blueskystudios.com> writes: RH> The library function exp(), when you are using the libm that RH> comes with most systems, can easily produce a denormal. If you RH> want exp() to force denormals to 0, I think you need to use a RH> different library. For instance, with g77 on an OSF Alpha, exp(-92.0) gives 0 by default. With -mieee it gives 1.10894557E-40 and the crash if you print it. (Obviously we should the i/o problem should be fixed.) RH> I also received this suggestion from Mark Davis at Digipaq (I RH> don't recall whether it was before or after the merger). You RH> might consider putting it into an application's start-up code RH> when no -mieee option is given, or at least you could you add it RH> to your docs about handling floating-point problems on alphas: RH> See "man ieee", and #include <machine/fpu.h>. When the program RH> starts up, make a call to ieee_set_fp_control(IEEE_MAP_UMZ); , RH> which sets the fp control to cause underflow to map to zero. I agree that we should have a consistent framework for such things -- see the x86 FPE example in the g77 manual. The exact recipe above is OSF-specific, FWIW. (I did a certain amount of work on that several years ago but it's been rejected.) I think we should also have (as far as possible in f77) the F2000 intrinsics for IEEE control -- another abandoned project. ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Bug with g77 and -mieee on Alpha Linux 1999-07-31 23:33 ` craig 1999-07-08 8:01 ` Richard Hadsell @ 1999-07-09 16:12 ` Dave Love 1999-07-09 21:10 ` craig [not found] ` <3784BE26.D14F95CD@blueskystudios.com> 2 siblings, 1 reply; 36+ messages in thread From: Dave Love @ 1999-07-09 16:12 UTC (permalink / raw) To: egcs-bugs >>>>> "JCB" == craig <craig@jcb-sc.com> writes: JCB> First, I realize that you're a huge advocate for JCB> fast-programs-more-important- than-working-programs stance, That sounds like a rather insulting caricature of real world scientific computing. I probably basically agree with Toon as a fellow professional in the field. Programs have to work, with good performance, in adverse circumstances of various kinds. JCB> If the behavior seen on Alphas is also seen on other systems, JCB> then, perhaps, -mno-ieee is a reasonable default. Effectively, yes. JCB> That would mean, I gather, that *other* systems normally crash when JCB> encountering underflows They might, but that's not what the actual behaviour is here; underflows give zero. Not that experimental results seem to carry much weight. JCB> So, my impression is, the Alpha is the only widely deployed JCB> system that defaults to crashing *and burning* whenever a JCB> program happens to compute a floating-point value that JCB> underflows or overflows That impression is simply wrong. Note that gcc's default is the same as Digital's. >From d.love@dl.ac.uk Fri Jul 09 16:53:00 1999 From: Dave Love <d.love@dl.ac.uk> To: egcs-bugs@egcs.cygnus.com Subject: Re: Bug with g77 and -mieee on Alpha Linux Date: Fri, 09 Jul 1999 16:53:00 -0000 Message-id: <rzqlncps7mj.fsf@djlvig.dl.ac.uk> References: <199907062042.WAA00509@keksy.linux.provi.de> <19990707140435.1429.qmail@deer> <19990707194012.A291@keksy.linux.provi.de> <3783B4B1.89DC2124@moene.indiv.nluug.nl> <19990708135500.12573.qmail@deer> <3784BF19.742E2E63@blueskystudios.com> X-SW-Source: 1999-07/msg00376.html Content-length: 1403 >>>>> "RH" == Richard Hadsell <hadsell@blueskystudios.com> writes: RH> The library function exp(), when you are using the libm that RH> comes with most systems, can easily produce a denormal. If you RH> want exp() to force denormals to 0, I think you need to use a RH> different library. For instance, with g77 on an OSF Alpha, exp(-92.0) gives 0 by default. With -mieee it gives 1.10894557E-40 and the crash if you print it. (Obviously we should the i/o problem should be fixed.) RH> I also received this suggestion from Mark Davis at Digipaq (I RH> don't recall whether it was before or after the merger). You RH> might consider putting it into an application's start-up code RH> when no -mieee option is given, or at least you could you add it RH> to your docs about handling floating-point problems on alphas: RH> See "man ieee", and #include <machine/fpu.h>. When the program RH> starts up, make a call to ieee_set_fp_control(IEEE_MAP_UMZ); , RH> which sets the fp control to cause underflow to map to zero. I agree that we should have a consistent framework for such things -- see the x86 FPE example in the g77 manual. The exact recipe above is OSF-specific, FWIW. (I did a certain amount of work on that several years ago but it's been rejected.) I think we should also have (as far as possible in f77) the F2000 intrinsics for IEEE control -- another abandoned project. >From jim@ergotech.com Fri Jul 09 16:54:00 1999 From: Jim Redman <jim@ergotech.com> To: egcs-bugs@egcs.cygnus.com Subject: Private & Multiple Inheritance Date: Fri, 09 Jul 1999 16:54:00 -0000 Message-id: <99070915595400.09068@jimslaptop.ergotech.los-alamos.net> X-SW-Source: 1999-07/msg00377.html Content-length: 934 My apologies if this is already known or is simply my ignorance of C++. gcc -v Reading specs from /usr/lib/gcc-lib/i386-linux/egcs-2.91.66/specs gcc version egcs-2.91.66 19990314 (egcs-1.1.2 release) class Thread { public: void run() {} }; class Timer : private Thread { }; /* reported warning: "direct base `Thread' inaccessible in `Threaded' due to ambiguity" I think that this should not be the case since Thread in Timer is not accessible. With only one accessible Thread there is no ambiguity. If you create an intermediate object this error goes away (reasonable) but the error below remains. */ class Threaded : public Timer, public Thread { public: Threaded () { /*reported error: "request for method `run' is ambiguous" It isn't logically ambiguous since Thread in Timer is not accessible. */ run(); } }; -- Jim Redman ErgoTech Systems, Inc. (505) 662 5156 http://www.ergotech.com >From bpriest@comspacecorp.com Fri Jul 09 17:09:00 1999 From: Bill Priest <bpriest@comspacecorp.com> To: khan@xraylith.wisc.EDU Cc: egcs-bugs@egcs.cygnus.com Subject: Re: egcs 2.95 (19990623) ICE w/ c++ on Solaris 5.5.1 Date: Fri, 09 Jul 1999 17:09:00 -0000 Message-id: <199907100009.TAA01291@bandit.comspacecorp.com> References: <199907092254.RAA01539@mercury.xraylith.wisc.edu> X-SW-Source: 1999-07/msg00378.html Content-length: 5095 Mumit, We the previous 2.95 snapshot 19990623 of egcs I tested this on Linux i686 and it did not have this problem; however, I haven't take the time yet to build 19990629 on Linux yet so I edited out this note from the previous message as I had not tested it. For completeness here is the full machine description. SunOS comspace2 5.5.1 Generic_103640-12 sun4u sparc cc1plus segvs w/ the following bt from gdb #0 0x1d5c2c in mark_vtable_entries (decl=0x2b9548) at decl2.c:2420 #1 0x1d617c in finish_vtable_vardecl (t=0x2b6578, data=0x0) at decl2.c:2670 #2 0x1a2968 in walk_globals_r (namespace=0x0, data=0x770e28) at decl.c:1947 #3 0x1a2868 in walk_namespaces_r (namespace=0x2b4e30, f=0x1a291c <walk_globals_r>, data=0xefffe718) at decl.c:1884 #4 0x1a2914 in walk_namespaces (f=0x1a291c <walk_globals_r>, data=0xefffe718) at decl.c:1915 #5 0x1a29b0 in walk_globals (p=0x1a279c <vtable_decl_p>, f=0x1d60dc <finish_vtable_vardecl>, data=0x0) at decl.c:1973 #6 0x1d7388 in finish_file () at decl2.c:3594 #7 0x215b18 in finish_translation_unit () at semantics.c:1163 #8 0x1ea5d8 in yyparse () at parse.y:343 #9 0x134ac in compile_file (name=0xeffffacd "DAE.ii") at toplev.c:3265 #10 0x171a8 in main (argc=14, argv=0xeffff92c) at toplev.c:5441 2420 if (DECL_LANG_SPECIFIC (fn) && DECL_ABSTRACT_VIRTUAL_P (fn)) p fn $1 = 0x2b9548 p *fn {common = {chain = 0x0, type = 0x2b6b68, code = INTEGER_CST, side_effects_flag = 0, constant_flag = 1, permanent_flag = 1, addressable_flag = 1, volatile_flag = 0, readonly_flag = 0, unsigned_flag = 0, asm_written_flag = 0, used_flag = 0, raises_flag = 0, static_flag = 0, public_flag = 0, private_flag = 0, protected_flag = 0, lang_flag_0 = 0, lang_flag_1 = 0, lang_flag_2 = 0, lang_flag_3 = 0, lang_flag_4 = 0, lang_flag_5 = 0, lang_flag_6 = 0}, int_cst = {common = "\000\000\000\000\000+kh\031p\000", rtl = 0x0, int_cst_low = 0, int_cst_high = 0}, real_cst = {common = "\000\000\000\000\000+kh\031p\000", rtl = 0x0, real_cst = {r = {0, 0, 0, 2856328, 425721856}}}, string = { common = "\000\000\000\000\000+kh\031p\000", rtl = 0x0, length = 0, pointer = 0x0}, complex = { common = "\000\000\000\000\000+kh\031p\000", rtl = 0x0, real = 0x0, imag = 0x0}, identifier = { common = "\000\000\000\000\000+kh\031p\000", length = 0, pointer = 0x0}, decl = { common = "\000\000\000\000\000+kh\031p\000", filename = 0x0, linenum = 0, uid = 0, size = 0x0, mode = VOIDmode, external_flag = 0, nonlocal_flag = 0, regdecl_flag = 1, inline_flag = 0, bit_field_flag = 1, virtual_flag = 0, ignored_flag = 1, abstract_flag = 1, in_system_header_flag = 1, common_flag = 0, defer_output = 0, transparent_union = 1, static_ctor_flag = 0, static_dtor_flag = 1, artificial_flag = 0, weak_flag = 1, lang_flag_0 = 1, lang_flag_1 = 0, lang_flag_2 = 0, lang_flag_3 = 0, lang_flag_4 = 1, lang_flag_5 = 0, lang_flag_6 = 0, lang_flag_7 = 0, non_addr_const_p = 0, no_instrument_function_entry_exit = 0, no_check_memory_usage = 0, comdat_flag = 1, frame_size = {i = 0, u = 0, f = NOT_BUILT_IN}, name = 0x0, context = 0x0, arguments = 0xfe9, result = 0x0, initial = 0x2ba568, abstract_origin = 0x2b8590, assembler_name = 0x0, section_name = 0x0, machine_attributes = 0x7200000, rtl = 0x0, live_range_rtl = 0x2b6708, saved_insns = {r = 0x2b6720, i = 2844448}, vindex = 0x0, pointer_alias_set = 41, lang_specific = 0x20060000}, type = {common = "\000\000\000\000\000+kh\031p\000", values = 0x0, size = 0x0, size_unit = 0x0, attributes = 0x0, uid = 2856328, precision = 25 '\031', mode = 96, string_flag = 0, no_force_blk_flag = 0, needs_constructing_flag = 0, transparent_union_flag = 0, packed_flag = 0, restrict_flag = 0, lang_flag_0 = 0, lang_flag_1 = 0, lang_flag_2 = 0, lang_flag_3 = 0, lang_flag_4 = 0, lang_flag_5 = 0, lang_flag_6 = 0, align = 0, pointer_to = 0x0, reference_to = 0x0, symtab = { address = 4073, pointer = 0xfe9 <Address 0xfe9 out of bounds>}, name = 0x0, minval = 0x2ba568, maxval = 0x2b8590, next_variant = 0x0, main_variant = 0x0, binfo = 0x7200000, noncopied_parts = 0x0, context = 0x2b6708, obstack = 0x2b6720, alias_set = 0, lang_specific = 0x29}, list = {common = "\000\000\000\000\000+kh\031p\000", purpose = 0x0, value = 0x0}, vec = {common = "\000\000\000\000\000+kh\031p\000", length = 0, a = {0x0}}, exp = {common = "\000\000\000\000\000+kh\031p\000", complexity = 0, operands = { 0x0}}, block = {common = "\000\000\000\000\000+kh\031p\000", handler_block_flag = 0, abstract_flag = 0, live_range_flag = 0, live_range_var_flag = 0, vars = 0x0, type_tags = 0x0, subblocks = 0x0, supercontext = 0x2b9588, abstract_origin = 0x19600000, end_note = 0x0, live_range_start = 0, live_range_end = 0}} I don't know if any of the above is useful to anyone but I know nothing about g++ and don't know if the above looks valid or completely broke. Regards, Bill PS. I can provide more of the above if someone can point me in the right direction. >From mrs@wrs.com Fri Jul 09 17:16:00 1999 From: mrs@wrs.com (Mike Stump) To: egcs-bugs@egcs.cygnus.com, jim@ergotech.com Subject: Re: Private & Multiple Inheritance Date: Fri, 09 Jul 1999 17:16:00 -0000 Message-id: <199907100016.RAA01959@kankakee.wrs.com> X-SW-Source: 1999-07/msg00379.html Content-length: 16 Welcome to C++. >From wilson@cygnus.com Fri Jul 09 18:58:00 1999 From: Jim Wilson <wilson@cygnus.com> To: Felix Lee <flee@cygnus.com> Cc: gcc-local@cygnus.com, egcs-bugs@egcs.cygnus.com Subject: Re: gcc/config/i960.c, asm label clash Date: Fri, 09 Jul 1999 18:58:00 -0000 Message-id: <199907100158.SAA14516@rtl.cygnus.com> References: <199907010245.TAA11989@cygnus.com> X-SW-Source: 1999-07/msg00380.html Content-length: 38 Thanks. I checked the patch in. Jim >From khan@xraylith.wisc.EDU Fri Jul 09 19:04:00 1999 From: Mumit Khan <khan@xraylith.wisc.EDU> To: egcs-bugs@egcs.cygnus.com Subject: (C++) bug in explicit template specialization Date: Fri, 09 Jul 1999 19:04:00 -0000 Message-id: <199907100204.VAA04243@mercury.xraylith.wisc.edu> X-SW-Source: 1999-07/msg00381.html Content-length: 576 According to 14.7.3 [temp.expl.spec], the following code is legal. gcc-2.95-19990704-CVS doesn't agree however. namespace N { template <class T> class X { }; template <class T> class Y { }; template <> class Y<int> { }; } template <> class N::X<int> { }; $ /usr/local/gcc-2.95-19990704/bin/gcc -c temp-expl-spec.cc x.cc:11: specializing `class N::X<int>' in different namespace x.cc:3: from definition of `template <class T> class N::X<T>' It does work as expected if I wrap the specialization of X<T> in namespace N. Regards, Mumit ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Bug with g77 and -mieee on Alpha Linux 1999-07-09 16:12 ` Dave Love @ 1999-07-09 21:10 ` craig 0 siblings, 0 replies; 36+ messages in thread From: craig @ 1999-07-09 21:10 UTC (permalink / raw) To: d.love; +Cc: craig >>>>>> "JCB" == craig <craig@jcb-sc.com> writes: > > JCB> First, I realize that you're a huge advocate for > JCB> fast-programs-more-important- than-working-programs stance, > >That sounds like a rather insulting caricature of real world >scientific computing. Hardly. it's a *precise* description of what Toon constantly advocates: the idea that any program written to exploit the full range of IEEE 754 *values* (not even using *features* like signalling NaNs, trapping on inexact, etc.) is inherently *wrong*, and it's best to make those programs behaves *less*, not *more*, predictably across all architectures, if doing so makes Toon's sort of program run as fast as possible. >I probably basically agree with Toon as a >fellow professional in the field. Programs have to work, with good >performance, in adverse circumstances of various kinds. Yet, programs *aren't* working, when compiled with g77. Toon says they're buggy programs -- my impression is, users are concluding *g77* is buggy, in droves. I'm coming to the same conclusion myself, that g77 is fatally buggy, by design, because of its refusal to offer even basic, predictable behavior. > JCB> If the behavior seen on Alphas is also seen on other systems, > JCB> then, perhaps, -mno-ieee is a reasonable default. > >Effectively, yes. So other systems crash on overflow (instead of generating Inf)? > JCB> That would mean, I gather, that *other* systems normally crash when > JCB> encountering underflows > >They might, but that's not what the actual behaviour is here; >underflows give zero. Not that experimental results seem to carry >much weight. No, the *actual* behavior appears to be that, depending on where the number comes from, a denormal *crashes* a "working" program, while other sorts of underflow (below the denormal range, I expect) don't. And, I gather, overflow *also* crashes a working program. > JCB> So, my impression is, the Alpha is the only widely deployed > JCB> system that defaults to crashing *and burning* whenever a > JCB> program happens to compute a floating-point value that > JCB> underflows or overflows > >That impression is simply wrong. > >Note that gcc's default is the same as Digital's. If only that were the case, we'd have few of the problems we have now. The statement I'll make, based on my experiences with g77/Alpha and Digital's Fortran offerings, is as follows, and I invite contradiction only in the form of actual experience with evidence: Digital Fortran offers a fully-working environment based on what we call -mno-ieee *and* offers a fully-working environment based on what we call -mieee as well. It happens to offer the first as a default. g77 offers neither choice. Remember, my original statement was to the effect that -mno-ieee as a default was a poor choice because we didn't bother to properly implement it, whereas, at least with -mieee, we'd have had plenty of *existing* code (coming from other, IEEE-754-conforming, environments), such as library routines, test suites, and so on, to just "plug in" for ordinary use. I have yet to see *any* legitimate contradiction of this assertion. The assertions so far amount to "but any code that doesn't work with g77 is inherently broken", or some Gatesian approximation thereof. What Digital understands, or understood, that not one *single* proponent of Toon's view (*including* Toon) understands, is that, when *Digital* decided to effectively invent its own floating-point type (its limited version of IEEE 754), it did two things *very* well: - Carefully researched, developed, implemented, and maintained its own types, so they'd work throughout the product range. (Heck, the *old* VAX types were implemented in early Alpha *chips*, that's how much Digital cares about getting stuff like this right.) - Made sure the industry-wide types (full IEEE 754) worked just as well, if not as fast. gcc (and g77) did neither. Had we chosen -mieee for Alpha from the outset, I contend that the *default* model for gcc/g77 behavior would, *now*, be much more robust and complete than *either* -mieee or -mno-ieee is at this point, because we've lost *man-years* of willing, voluntary testing (at the very least) of the IEEE 754 facilities gcc and g77 -- and we are likely to *continue* losing it, since -mieee is not the default (even for the libraries!) for GCC 2.95 -- due to the fact that it hasn't worked anywhere near well enough for widespread use in past releases. (And, clearly, if we'd made -mieee the default, we -- the gcc team as a whole -- would have more rapidly fixed bugs exposed by widely used FP codes.) Yes, it's true, that the result, assuming the *same* amount of resources (i.e. that the extra IEEE 754 testing and code-exploitation would be perfectly offset by the extra enthusiasm people had for gcc/g77, due to its defaulting to high performance, on Alpha), -mno-ieee might be in *worse* shape than it is now. But, instead of discussing how to fix up -mno-ieee so people can get better performance with fewer bugs, having already gotten -mieee in such great shape that it was considered "rock solid"... ...we're still arguing about the default, and we offer *no* decent, working, robust FP environment on the Alpha *at all*. My bringing up the issue of picking the right default was not really about revisiting the performance vs. correctness debate, but more about reminding people that when you choose a *home-grown* solution over an industry-standard one, you had better be prepared to home-grow *everything*, from the R&D to the implementation to the testing, to get anywhere near on par with what the industry already chose. I feel it's fairly safe to say Digital understood that. And, unlike the IEEE 754 types, the Digital types did not have widely available test suites and source-code-level implementations kicking around back in 1994 or whenever Alpha support for gcc (and then g77) first started being worked on. Which meant that, to merely *equal* what Digital had done for its home-grown types, we *would* have had to create lots of our own tests, library routines, and so on, compared to just using IEEE-754 stuff off the shelf (though it appears we didn't bother doing the former in many cases). Yet, I've heard rumors that the 21264 architecture doesn't implement these home-grown types anymore. It now implements full IEEE 754, perhaps without inexact traps as a default (but apparently nobody uses those anyway -- besides, no standard-conforming Fortran code makes use of exceptions). If that's true, it seems that even Digital, after (as I am assuming it did) fully implementing these home-grown types, something we have yet to do, has abandoned them. Yet, I find it hard to believe that even 21264 couldn't have run faster if it had continued supporting the home-grown types rather than IEEE 754 in its native mode. Another aspect of the lesson: when a *project* like gcc takes its cue from people like Toon who argue against bothering to cater to users who exploit the fringes of "correct behavior", that project will take vastly longer to ever make those fringes work correctly *or* even be clearly documented as not working, because people like Toon don't *care* to make sure that happens, and people who, like myself, really *do* want to get all the i's dotted and t's crossed, learn quickly to not bother with projects who ignore our concerns outright. I don't mind those mistakes having been made in the past. What I *do* mind is the fact that various players in this industry have been making these mistakes for *decades*, and too many people in the Open Source arena, driving the design for new and improved products, refuse to learn from these mistakes, prefering instead to continue insisting on all new and improved products to be limited in scope to their own areas of concern. tq vm, (burley) >From drow@false.org Sat Jul 10 01:25:00 1999 From: Daniel Jacobowitz <drow@false.org> To: egcs-bugs@egcs.cygnus.com Subject: g++ gives gratuitous "will use a temporary" warnings in CVS 19990611 Date: Sat, 10 Jul 1999 01:25:00 -0000 Message-id: <19990710042745.A29341@drow.res.cmu.edu> X-SW-Source: 1999-07/msg00385.html Content-length: 1261 Date: Sat, 10 Jul 1999 04:21:25 -0400 From: Daniel Jacobowitz <drow@false.org> To: egcs-bugs@lists.cygnus.com Subject: g++ gives gratuitous "will use a temporary" warnings in CVS 19990611 Mail-Followup-To: egcs-bugs@lists.cygnus.com X-Mailer: Mutt 0.94.12i The attached test program shows a warning regression in g++: $ g++ -v Reading specs from /usr/lib/gcc-lib/powerpc-linux/egcs-2.91.66/specs gcc version egcs-2.91.66 Debian GNU/Linux (egcs-1.1.2 release) $ g++ -c temptest.cc $ $ /usr/lib/gcc-ss/bin/g++ -v Reading specs from /usr/lib/gcc-ss/lib/gcc-lib/powerpc-debian-linux-gnu/gcc-2.95/specs gcc version gcc-2.95 19990611 (prerelease) $ /usr/lib/gcc-ss/bin/g++ -c temptest.cc test.cc: In function `void g()': test.cc:5: initializing non-const `const char *&' with `char *' will use a temporary test.cc:1: in passing argument 1 of `f(const char *&)' $ This also happens on i386-*-linux-gnu. Dan /--------------------------------\ /--------------------------------\ | Daniel Jacobowitz |__| SCS Class of 2002 | | Debian GNU/Linux Developer __ Carnegie Mellon University | | dan@debian.org | | dmj+@andrew.cmu.edu | \--------------------------------/ \--------------------------------/ >From vinni@phtd.tpu.edu.ru Sat Jul 10 01:45:00 1999 From: Vitaliy Ababiy <vinni@phtd.tpu.edu.ru> To: egcs-bugs@egcs.cygnus.com Subject: Internal compiler error Date: Sat, 10 Jul 1999 01:45:00 -0000 Message-id: <Pine.LNX.4.04.9907101641250.29177-100000@interact.phtd.tpu.edu.ru> X-SW-Source: 1999-07/msg00386.html Content-length: 769 Hi! I have just tried to compile ROOT (version 2.22) using g++ Linux 2.0.36 Debian 2.0 and got an internal compiler error when compiling the method int TGenerator::ImportParticles(class TClonesArray *, const char * = "") in EG_Generator.cxx. I try -O2 -O and etc but it do not work Is tere any solve of problem? g77 -g -mcpu=i686 -Wall -fPIC -DR__GLIBC -c EG_Generator.cxx EG_Generator.cxx: In method `int TGenerator::ImportParticles(class TClonesArray *, const char * = "")': EG_Generator.cxx:205: warning: value computed is not used EG_Generator.cxx:226: warning: value computed is not used EG_Generator.cxx:230: Internal compiler error. EG_Generator.cxx:230: Please submit a full bug report to `egcs-bugs@cygnus.com'. make: *** [EG_Generator.o] Error 1 Thanks ^ permalink raw reply [flat|nested] 36+ messages in thread
[parent not found: <3784BE26.D14F95CD@blueskystudios.com>]
[parent not found: <19990708155845.13652.qmail@deer>]
[parent not found: <19990708111645.A6051@cygnus.com>]
[parent not found: <37850FE1.94D5B63D@moene.indiv.nluug.nl>]
[parent not found: <19990709021223.16356.qmail@deer>]
[parent not found: <3785E797.F6809570@moene.indiv.nluug.nl>]
[parent not found: <19990709152312.18370.qmail@deer>]
[parent not found: <37863D4F.287AF653@moene.indiv.nluug.nl>]
* Re: Bug with g77 and -mieee on Alpha Linux [not found] ` <37863D4F.287AF653@moene.indiv.nluug.nl> @ 1999-07-31 23:33 ` Martin Kahlert 1999-07-31 23:33 ` Toon Moene 0 siblings, 1 reply; 36+ messages in thread From: Martin Kahlert @ 1999-07-31 23:33 UTC (permalink / raw) To: Toon Moene; +Cc: craig, egcs-bugs Quoting Toon Moene (toon@moene.indiv.nluug.nl): > craig@jcb-sc.com wrote: > > > >> Perhaps, but, as I pointed out earlier, almost *any* program can generate > > >> denormals if it is compiled to randomly spill 80-bit values as 32-bit > > >> or 64-bit values and tries to compare them to (nearly) identically > > >> computed results to see if they're approximately equal. > > > >I'm pretty sure that ours don't - in spite of the fact that they perform > > >somewhere between 10^10 and 10^11 floating point operations per run. > > > But *yours* isn't the only code on the planet, correct? > > No, but our code runs 7 x 24 hours in 7 operational meteorological sites > in Europe - if I knew how, I would immediately enable > "trap-on-denormals", like we would run with -fbounds-check [too large a > performance dip for operational use] on, because it would point us at > problems in our algorithms. Please correct my if i am wrong, but meteorological simulation usually deals with elliptic partial differential equations in each time step (i don't think you have shocks). Since there is the maximum principle, i assume, you can theoretically prove that all of your floating point values are within good boundaries. Electrical circuit simulation is by a big amount more nasty thing than this! Each transistor has about 3 operation modes: One, where it doesn't do a lot, since the voltages are a bit too low, one rather linear part in the voltage- current graph (where amplification happens) and a saturation part. This graph has rather sharp edges and you don't know anything about, where the designer wants the transistor to work - and this has not neccessarily anything to do with where they actually work ;-). This might be rather simple to solve in the case of toy problems with less then 100 transistors, but our simulation tool is inteded more in the range between 10000 and 100000 of them. Unfortunatly transient time simulation is the simpler part. A great deal of effort (and computation time) is put into finding an initial consistent solution. > > > I mean, c'mon, you *constantly* write about how people *shouldn't* (or > > "don't", despite substantial evidence on these lists to the contrary) > > write floating-point code, as if it applied to the entire planet's > > past, present, *and* future use of Fortran. > > The evidence on these lists prove that people are still forced to write > programs without getting a decent course in numerical analysis. > > Why do you think I quote "Numerical Recipes" ? This stuff is so well > known that it is equivalent to pointing out an error in gcc wrt to the > Dragon Book. > > Why do you think I put a $200 / hour premium on this ? If people are > forced to deal with badly written software in such large IT firms like > Siemens, they'd better be prepared to pay up, or shut up. Do you really think, that at Siemens people with no numerical skills are allowed to spend their time writing analog circuit simulators? This (inhouse) simulation tool has been developed during 10 years, where an average of 5 people (all numerical focused mathematicians) tried to improve the solver for a large (>100000) set of highly nonlinear equations (among other tasks of course). While in meteorological simulations the linear sets of equations are so well behaved, that usually iterative solvers converge, i don't know of any successful use of an iterative linear solver in analog circuit simulation. Thus i think, that analog cicuit simulation belongs to the most nasty parts of numerics in DAEs. I think, you didn't read Num. Rec. exactly: Can you tell me any globally convergent method for nonlinear methods, which can be coded to not produce FPEs? The rather trivial improvements of newton's method in NR, all suggest to calculate F(x_new) first (to ensure quadratical convergence near the solution). But this is not possible, if x_new has bad values inside it. Even something like if(x_new(i) .GT. 1D10) can throw an exception! The only thing you can savely do with these values is to not use them. Bye, Martin. -- esa$ gcc -Wall -o ariane5 ariane5.c ariane5.c: 666: warning: long float implicitly truncated to unsigned type esa$ ariane5 ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Bug with g77 and -mieee on Alpha Linux 1999-07-31 23:33 ` Martin Kahlert @ 1999-07-31 23:33 ` Toon Moene 0 siblings, 0 replies; 36+ messages in thread From: Toon Moene @ 1999-07-31 23:33 UTC (permalink / raw) To: martin.kahlert; +Cc: craig, egcs-bugs First of all, I want to - belatedly - apologize to Martin and his colleagues for the following insinuation: > If people are > forced to deal with badly written software in such large IT firms like > Siemens, they'd better be prepared to pay up, or shut up. It was uncalled for and wrong. This will not happen again. Martin Kahlert wrote: > Please correct my if i am wrong, but meteorological simulation > usually deals with elliptic partial differential equations in each time > step (i don't think you have shocks). Since there is the maximum principle, > i assume, you can theoretically prove that all of your floating point values > are within good boundaries. Possibly (numerically, the partitioning of PDEs in hyperbolic, parabolic and elliptic is not very useful), but I am not sure these properties still hold after discretization. We tend to approach the issue from the other direction: Given that the atmospheric quantities stay within certain limits, our differential equations after discretization should also stay within those limits. Because weather forecasting is an initial/boundary-value problem, and all forecast times are useful (up to a certain limit), we want this to hold for the entire evolution from initial state to final state. Hence, if our discretization gives rise to unboundedly growing errors, we have to control them - we dissipate these waves by filters. > Electrical circuit simulation is by a big amount more nasty thing than this! > Each transistor has about 3 operation modes: One, where it doesn't do a lot, > since the voltages are a bit too low, one rather linear part in the voltage- > current graph (where amplification happens) and a saturation part. > This graph has rather sharp edges and you don't know anything about, where > the designer wants the transistor to work - and this has not neccessarily > anything to do with where they actually work ;-). > This might be rather simple to solve in the case of toy problems with less then 100 > transistors, but our simulation tool is inteded more in the range between > 10000 and 100000 of them. Unfortunatly transient time simulation is the simpler > part. A great deal of effort (and computation time) > is put into finding an initial consistent solution. And for this you use the Newton-Raphson root finder, if I understand correctly. > While in meteorological simulations the linear sets of equations are so well > behaved, that usually iterative solvers converge, i don't know of any successful > use of an iterative linear solver in analog circuit simulation. The PDEs of atmospheric motion are non-linear, although not spectacularly so - we also do not use iterative solvers (why do you think so ? - we're not trying to calculate an equilibrium solution, but a time evolution). > I think, you didn't read Num. Rec. exactly: Can you tell me any globally convergent > method for nonlinear methods, which can be coded to not produce FPEs? > The rather trivial improvements of newton's method in NR, all suggest to calculate > F(x_new) first (to ensure quadratical convergence near the solution). > But this is not possible, if x_new has bad values inside it. Even something > like if(x_new(i) .GT. 1D10) can throw an exception! The only thing you can > savely do with these values is to not use them. Yes, obviously, I didn't read it far enough. Sorry for my rant. -- Toon Moene (toon@moene.indiv.nluug.nl) Saturnushof 14, 3738 XG Maartensdijk, The Netherlands Phone: +31 346 214290; Fax: +31 346 214286 GNU Fortran: http://world.std.com/~burley/g77.html ^ permalink raw reply [flat|nested] 36+ messages in thread
[parent not found: <4048.931760012@upchuck.cygnus.com>]
* Re: Bug with g77 and -mieee on Alpha Linux [not found] <4048.931760012@upchuck.cygnus.com> @ 1999-07-31 23:33 ` craig 1999-07-31 23:33 ` Jeffrey A Law 0 siblings, 1 reply; 36+ messages in thread From: craig @ 1999-07-31 23:33 UTC (permalink / raw) To: law; +Cc: craig >The difference between these two cases is in the -f[no]emulate-complex we >aren't even sure *what* the compiler should be doing, much less *how* to >get it done. Ah, okay, I didn't realize that the problem went that deep. >There's a rather serious design issue that needs to be investigated before we >can even begin to look at solutions. Worse yet, the investigation phase will >probably require looking at a variety of other Fortran compilers to see how >they handle passing of complex values -- we should not insert a gratuitous ABI >incompatibility for passing complex values. Agreed. Though, for g77's purposes, the ABI for complex is currently *always* the ABI for struct { float; float; };. I'd be interested in knowing about any ABI's for which that was not the case, because they'd be systems on which g77 -fno-emulate-complex might not even *work*, if implemented to follow the native ABI. (That's because g77 would be telling the back end to pass/accept __complex__ across calls, but the other end might be f2c-compiled, or g77-emulating-complex, or other, code that uses the struct method.) Put another way, g77 is presently architected (in terms of options it provides, the way it works internally, etc.) to assume the ABI doesn't make __complex__ different from the equivalent struct. We'd at least need to understand and document such differences, e.g. explain that users of pertinent systems not combine g77 -fno-emulate-complex with code from certain types of other sources. (-fno-f2c is related to this, as another example.) >Letting the release out with -fno-emulate-complex without resolving these >issues >makes it much more likely that we will need to break binary compatibility >again for the Fortran compiler once we figure out how to properly pass complex >values. Note that I'm not aware there were ever any problems, in *this* area at least, back when -fno-emulate-complex was the only choice, though that was a long time ago, and I might have forgotten. >I haven't made a final decision on the complex stuff, but I'll have to make one >in the very near future (next 24hrs). Whew, well, good luck! I *still* don't know what to recommend, other than to say that, if we change the default again and don't respin/retest for at least a month, we're risking some pretty serious regressions. Wish I could put a number on that risk, as that might help you. tq vm, (burley) ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Bug with g77 and -mieee on Alpha Linux 1999-07-31 23:33 ` craig @ 1999-07-31 23:33 ` Jeffrey A Law 1999-07-31 23:33 ` craig 0 siblings, 1 reply; 36+ messages in thread From: Jeffrey A Law @ 1999-07-31 23:33 UTC (permalink / raw) To: craig; +Cc: egcs-bugs In message < 19990712072342.28771.qmail@deer >you write: > >The difference between these two cases is in the -f[no]emulate-complex we > Agreed. Though, for g77's purposes, the ABI for complex is currently > *always* the ABI for struct { float; float; };. OK. That's good to know. If this is indeed the ABI we need to use after investigating vendor compilers, then we've probably got some work to do in the backends which pass parameters in registers since I do not believe all are prepared to handle complex modes in the various FUNCTION_ARG macros. Having it as a struct does help with some issues since structs are usually not passed in FP registers, even when their members are strictly floats, strictly doubles or strictly long doubles. Treating it as an aggregate has some performance impacts, so I wouldn't be totally surprised if some vendor treated it as two independent float args for parameter passing purposes. But that's something we'll have to investigate. > I'd be interested in > knowing about any ABI's for which that was not the case, because they'd > be systems on which g77 -fno-emulate-complex might not even *work*, Yup. I doubt we've ever done any serious work at looking at how vendor compilers handle complex and interoperability between g77 and vendor compiled fortran libraries (or even libf2c/libg2c compiled with the vendor compiler). On systems like HPs incompatibilities in this area could also be hidden by the linker for double complex values -- in the event of a caller/callee mismatch for register types, the linker will insert a trampoline to shuffle arguments from one register file to the other. Ick. > Whew, well, good luck! I *still* don't know what to recommend, other > than to say that, if we change the default again and don't respin/retest > for at least a month, we're risking some pretty serious regressions. > Wish I could put a number on that risk, as that might help you. I doubt we'd need a month to respin/retest. I bet we could get all the testing we needed by lapack in a week. lapack looks to stress the complex stuff a hell of a lot more than our regression testsuite. jeff ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Bug with g77 and -mieee on Alpha Linux 1999-07-31 23:33 ` Jeffrey A Law @ 1999-07-31 23:33 ` craig 1999-07-31 23:33 ` Jeffrey A Law 0 siblings, 1 reply; 36+ messages in thread From: craig @ 1999-07-31 23:33 UTC (permalink / raw) To: law; +Cc: craig >I doubt we'd need a month to respin/retest. I bet we could get all the testing >we needed by lapack in a week. lapack looks to stress the complex stuff a >hell of a lot more than our regression testsuite. That's almost certainly the case, and I heartily applaud your commitment to making sure at least *some* amount of pertinent testing will occur in support of such a last-minute change. What concerns me, in summary (as versus my earlier emails on this topic), is all the testing of *other* codes -- neither LAPACK nor our test suite -- that has clearly been going on during the prerelease period. I don't have a clue how significant that testing and/or those codes are compared to our test suite plus LAPACK. But we've certainly gotten good, solid bug reports during this period from people who didn't find the bugs via our test suite (though we did add new tests for many of them, thankfully) nor, I believe, entirely via LAPACK. It's the amount and usefulness of *that* testing I want us to all think carefully about before we effectively discard it vis-a-vis this release, by switching back to -femulate-complex and running only LAPACK and our test suite on some number of "support" platforms. (Remember, some of that testing might have been of things like LAPACK or our test suite on less-popular platforms that users are desperately trying to maintain despite their status. If they get burnt by having g77 suddenly ICE or generate bad code on them as of 2.95, after all their prerelease testing convinced them to tell colleagues "this FOO machine is going to be well-supported by 2.95", they might be *very* unforgiving.) I *am* willing to assert that changing to -femulate-complex requires testing only codes *using* COMPLEX support, however. In other words, it's conceivable a bug in non-COMPLEX codes might be introduced, but I think it's safe to assume such a bug is latent, involving f771 reading its own memory inappropriately or something, and I'm willing to accept that risk (since it could just as easily happen due to changing the contents of version.c). (-femulate-complex isn't *quite* as simple as a mere "1" vs. "0" in memory, as, IIRC, various initialization routines set things up differently, when f771 starts compiling, depending on that flag. But if there's a new bug *there*, well, by golly...anyway, it seems *very* unlikely that testing LAPACK wouldn't uncover it. The vast majority of what -femulate-complex would change, however, is in how f771 compiles code actually using the COMPLEX feature of Fortran.) Oh well, so much for the short email. ;-) tq vm, (burley) P.S. f771 is the program that actually compiles Fortran code to assembler. It is, to g77, what cc1 is to gcc. See the g77 docs for more explanation. (I realize Jeff and many others already knows this.) ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Bug with g77 and -mieee on Alpha Linux 1999-07-31 23:33 ` craig @ 1999-07-31 23:33 ` Jeffrey A Law 1999-07-12 9:55 ` craig 0 siblings, 1 reply; 36+ messages in thread From: Jeffrey A Law @ 1999-07-31 23:33 UTC (permalink / raw) To: craig; +Cc: egcs-bugs In message < 19990712152038.30172.qmail@deer >you write: > What concerns me, in summary (as versus my earlier emails on this topic), > is all the testing of *other* codes -- neither LAPACK nor our test suite -- > that has clearly been going on during the prerelease period. There's only so much one person can do at a time. Nobody really jumped on getting lapack testing going, so it never happened other than for a few isolated targets (which is still a step forward since no lapack testing occurred for previous releases). People have been running our testsuite regularly. But it is still in its infancy and doesn't have anywhere near good coverage. Now that I know what's needed to test lapack I can sit down, write something up so that for the next release we'll have instructions to give to the testers for testing lapack, which should help. But in the end, a lot of this stuff simply comes down to time -- and it is precisely why we need to get one or more of the other key developers intimately involved with releases, there's just too much for one person to do. > But we've certainly gotten good, solid bug reports during this period > from people who didn't find the bugs via our test suite (though we did > add new tests for many of them, thankfully) nor, I believe, entirely via > LAPACK. Yes. And that's precisely how we're going to have to improve our own test coverage over time. I'm all too aware of the dangers in last minute changes and issues around testing. We are *not* in a particularly good situation right now because of these issues and I am not particularly happy about it. jeff ^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: Bug with g77 and -mieee on Alpha Linux 1999-07-31 23:33 ` Jeffrey A Law @ 1999-07-12 9:55 ` craig 0 siblings, 0 replies; 36+ messages in thread From: craig @ 1999-07-12 9:55 UTC (permalink / raw) To: law; +Cc: craig >People have been running our testsuite regularly. But it is still in its >infancy and doesn't have anywhere near good coverage. I'm not sure if you're referring to g77's testsuite specifically. I *hope* you are, because, surely, g77's is *vastly* lower in coverage than either gcc's or g++'s. >Now that I know what's needed to test lapack I can sit down, write something up >so that for the next release we'll have instructions to give to the testers >for testing lapack, which should help. Hugely, I'd imagine! >But in the end, a lot of this stuff simply comes down to time -- and it is >precisely why we need to get one or more of the other key developers intimately >involved with releases, there's just too much for one person to do. Right, though there were (presumably) other people running LAPACK -- as well as other codes -- before. It's a difficult judgement call to make. >I'm all too aware of the dangers in last minute changes and issues around >testing. We are *not* in a particularly good situation right now because of >these issues and I am not particularly happy about it. Nor I. Entwining a bit with my decision (over the last few days), it strikes me that, if I want to do something for the next couple of months vis-a-vis g77, but that actually contributes *incrementally* to it without risking lots of people arguing with me about whether I was doing things the right way (which is all the rewrite would have accomplished)... ...I ought to spend it improving the g77 test suite, by: - More aggressively moving tests out of my "private" suite (after determining copyright status, etc., by looking through my email archives as necessary) into g77.f-torture - Writing new tests based on both my black-box and white-box understandings of Fortran, the GNU Fortran language, and g77 and libf2c in particular, for g77.f-torture - Finding out what is already "out there" in terms of tests of IEEE 754/854 conformance, things like LAPACK, and get them into g77.f-torture - Perhaps help design and implement a multi-tiered testing/benchmarking structure for GCC to accommodate larger things (like LAPACK), so not everyone doing "make -k bootstrap install check" has to wait days for completion (which might begin to happen more and more as we add tests) Not sure if this is how I *want* to spend my time, as there are plenty of interesting, new things I'd like to work on...but maybe I could do it part-time or something. Realistically, it's probably the case that if I did this even one day a week over the summer, by late August I'd be having to help fix bugs exposed by the testing two or three of the *other* days of the week. But, at least, g77 would get (perhaps only slowly) better, and some of those efforts would help make implementing decisions (such as the ones Richard Henderson recently made regarding 80-bit spills and -mieee) easier by having more tests available to reduce exposure to regressions. tq vm, (burley) >From ghazi@caip.rutgers.edu Mon Jul 12 10:46:00 1999 From: "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu> To: Gilles.Zunino@hei.fupl.asso.fr, egcs-bugs@egcs.cygnus.com Subject: Re: [egcs 2.95 current CVS] Bootstrap failure for mips-sgi-irix6.5 Date: Mon, 12 Jul 1999 10:46:00 -0000 Message-id: <199907121746.NAA07278@caip.rutgers.edu> X-SW-Source: 1999-07/msg00444.html Content-length: 993 > From: Gilles Zunino <Gilles.Zunino@hei.fupl.asso.fr> > > The current CVS (egc-2.95) fails to create a library called > "tlibstdc++.a.2.10.0" because the file "vfork" can't be found. > [...] > ar rc tlibstdc++.a.2.10.0 `cat stdlist` > ar: ../libiberty/vfork: No such file or directory > make[2]: *** [libstdc++.a.2.10.0] Error 1 This problem stems from the same bug that I reported in: http://egcs.cygnus.com/ml/egcs-bugs/1999-07/msg00436.html Because of the bug, libstdc++ attempts to link in files without a .o extension. In your case, `ar' died when it couldn't find `vfork' (when it should have retrieved vfork.o.) In my case, `ar' went looking for the file `memmove' and simply ignored it when it wasn't found. The bootstrap continued and it showed up as testsuite failures for me on sunos4. I'm hoping to submit a corrective patch in a day or two. --Kaveh -- Kaveh R. Ghazi Engagement Manager / Project Services ghazi@caip.rutgers.edu Qwest Internet Solutions >From Prince_Tim_C@solarturbines.com Mon Jul 12 11:28:00 1999 From: Tim C Prince <Prince_Tim_C@solarturbines.com> To: egcs-bugs@egcs.cygnus.com (IPM Return requested) (Receipt notification requested), tprince@computer.org (IPM Return requested) (Receipt notification requested) Subject: egcs-19990629/g77/x86 skipping steps at -Os Date: Mon, 12 Jul 1999 11:28:00 -0000 Message-id: <378A3262.6E8C.6B93.000*/c=US/admd=> </prmd=Cat/o=GWise/s=Prince/g=Tim/i=C/"@MHS> X-SW-Source: 1999-07/msg00445.html Content-length: 951 The attached gzipped tar file contains source and makefile for a version of the paranoia benchmark. Results have been as expected when run on Irix6.5 and hpux10.20 at full optimization, and on x86 platforms at -O without unrolling. On the target i586-pc-cygwin32, when compiled with -Os, the calculation at line 300 of subroutine overf is skipped, leaving the variable x containing its previous value. I will be trying this on a linux target when I get the opportunity. Except for this bug, the error indications returned by this program are inherent in the target architecture and are not due to g77; in fact, g77 is the only compiler available to me which comes close to working correctly on x86. Changing the rounding mode on p6 processors will improve compliance with IEEE-754 but has no effect on the bug reported above. Dr. Timothy C. Prince Consulting Engineer Solar Turbines, a Caterpillar Company alternate e-mail: tprince@computer.org >From Prince_Tim_C@solarturbines.com Mon Jul 12 11:38:00 1999 From: Tim C Prince <Prince_Tim_C@solarturbines.com> To: egcs-bugs@egcs.cygnus.com (IPM Return requested) (Receipt notification requested), tprince@computer.org (IPM Return requested) (Receipt notification requested) Subject: egcs-19990629/g77/x86 skipping steps at -Os Date: Mon, 12 Jul 1999 11:38:00 -0000 Message-id: <378A34D9.6E8C.6C1A.000*/c=US/admd=> </prmd=Cat/o=GWise/s=Prince/g=Tim/i=C/"@MHS> X-SW-Source: 1999-07/msg00446.html Content-length: 951 The attached gzipped tar file contains source and makefile for a version of the paranoia benchmark. Results have been as expected when run on Irix6.5 and hpux10.20 at full optimization, and on x86 platforms at -O without unrolling. On the target i586-pc-cygwin32, when compiled with -Os, the calculation at line 300 of subroutine overf is skipped, leaving the variable y containing its previous value. I will be trying this on a linux target when I get the opportunity. Except for this bug, the error indications returned by this program are inherent in the target architecture and are not due to g77; in fact, g77 is the only compiler available to me which comes close to working correctly on x86. Changing the rounding mode on p6 processors will improve compliance with IEEE-754 but has no effect on the bug reported above. Dr. Timothy C. Prince Consulting Engineer Solar Turbines, a Caterpillar Company alternate e-mail: tprince@computer.org >From ByrneJB@Harte-Lyne.ca Mon Jul 12 11:49:00 1999 From: "James B. Byrne" <ByrneJB@Harte-Lyne.ca> To: law@cygnus.com Cc: egcs-bugs@egcs.cygnus.com Subject: egcs-2.95-19990629 on HP-UX 11 Date: Mon, 12 Jul 1999 11:49:00 -0000 Message-id: <199907121846.OAA29689@hahp9k02.harte-lyne.ca> X-SW-Source: 1999-07/msg00447.html Content-length: 5232 I have done the following things for egcs on hpux11 1. Create new gcc/pa/pa-hpux11.h file with the following changes from pa-hpux10.h #define SIZE_T unsigned long #define PTRDIFF_T long 2. Modify gcc/configure.in to handle hpux-11. 3. Hand include alteration to configure.in to gcc/configure. I have not run autoconfig against the new configure.in file. 4. Modified gcc/po/POTFILES.in to add reference to pa-hpux11.h 5. #CC=cc egcssrc/.configure --with-gnu-as 6. make bootstrap-lean and this is what happens In file included from include/stdlib.h:9, from ../egcsrc/gcc/libgcc2.c:41: include/sys/types.h:344: size of array `r' is too large include/sys/types.h:345: size of array `val' is too large include/sys/types.h:365: size of array `lbl_s' is too large include/sys/types.h:366: size of array `lbl_ss' is too large include/sys/types.h:367: size of array `lbl_sf' is too large include/sys/types.h:377: size of array `lk_pad' is too large In file included from include/sys/types.h:412, from include/stdlib.h:9, from ../egcsrc/gcc/libgcc2.c:41: /usr/include/sys/_fd_macros.h:61: variable-size type declared outside of any fun ction /usr/include/sys/_fd_macros.h:61: size of array `fds_bits' is too large In file included from /usr/include/sys/time.h:15, from /usr/include/sys/resource.h:26, from /usr/include/sys/wait.h:83, from include/stdlib.h:221, from ../egcsrc/gcc/libgcc2.c:41: /usr/include/sys/sigevent.h:70: size of array `__sigev_reserved' is too large In file included from /usr/include/sys/resource.h:26, from /usr/include/sys/wait.h:83, from include/stdlib.h:221, from ../egcsrc/gcc/libgcc2.c:41: /usr/include/sys/time.h:398: size of array `tzname' is too large /usr/include/sys/time.h:484: size of array `amtimes' is too large In file included from /usr/include/sys/signal.h:16, from /usr/include/sys/wait.h:123, from include/stdlib.h:221, from ../egcsrc/gcc/libgcc2.c:41: /usr/include/sys/siginfo.h:72: size of array `__pad' is too large In file included from /usr/include/sys/signal.h:17, from /usr/include/sys/wait.h:123, from include/stdlib.h:221, from ../egcsrc/gcc/libgcc2.c:41: /usr/include/sys/newsig.h:26: size of array `sigset' is too large In file included from /usr/include/sys/newsig.h:43, from /usr/include/sys/signal.h:17, from /usr/include/sys/wait.h:123, from include/stdlib.h:221, from ../egcsrc/gcc/libgcc2.c:41: /usr/include/machine/save_state.h:420: size of array `ss_reserved' is too large /usr/include/machine/save_state.h:429: size of array `ss_reserved' is too large /usr/include/machine/save_state.h:550: size of array `ss_reserved2' is too large /usr/include/machine/save_state.h:650: size of array `ss_xor' is too large In file included from /usr/include/sys/signal.h:17, from /usr/include/sys/wait.h:123, from include/stdlib.h:221, from ../egcsrc/gcc/libgcc2.c:41: /usr/include/sys/newsig.h:80: size of array `uc_spares' is too large In file included from /usr/include/sys/wait.h:123, from include/stdlib.h:221, from ../egcsrc/gcc/libgcc2.c:41: /usr/include/sys/signal.h:545: size of array `sm_arg' is too large /usr/include/sys/signal.h:619: size of array `sc_args' is too large In file included from /usr/include/pwd.h:79, from include/stdlib.h:317, from ../egcsrc/gcc/libgcc2.c:41: include/stdio.h:61: size of array `__smbuf' is too large In file included from /usr/include/unistd.h:11, from ../egcsrc/gcc/libgcc2.c:42: /usr/include/sys/unistd.h:197: size of array `type name' is too large make[4]: *** [libgcc2.a] Error 1 make[4]: Leaving directory `/usr/local/opt/gnu/gcc/obj/egcs-19990629/gcc' make[3]: *** [stmp-multilib-sub] Error 2 make[3]: Leaving directory `/usr/local/opt/gnu/gcc/obj/egcs-19990629/gcc' make[2]: *** [stmp-multilib] Error 1 make[2]: Leaving directory `/usr/local/opt/gnu/gcc/obj/egcs-19990629/gcc' make[1]: *** [bootstrap-lean] Error 2 make[1]: Leaving directory `/usr/local/opt/gnu/gcc/obj/egcs-19990629/gcc' make: *** [bootstrap-lean] Error 2 # Now I presume that this is due to the fact that HP-UX 11 is running on a 32 bit machine, so that while size_t and ptrdiff_t are set to 64 bit integers, the physical address space is still only 32 bit. So my questions are: one. How does one determine if the hardware is actually 64 bit native? Is this given by the hppa number (hppa-2.?) two. How do I handle the 32 bit limitation when the OS supports 64 bits? three. If I was building on a 64 bit architecture, would these errors go away? A bit of guidence would be appreciated here. Regards, Jim -- James B. Byrne ByrneJB@Harte-Lyne.ca Harte & Lyne Limited http://www.harte-lyne.ca 9 Brockley Drive Hamilton, Ontario fax:+1 905 561 0757 Canada L8E 3C3 vox:+1 905 561 1241 >From rth@twiddle.net Mon Jul 12 12:15:00 1999 From: Richard Henderson <rth@twiddle.net> To: axp-list@redhat.com Cc: egcs-bugs@egcs.cygnus.com, egcs@egcs.cygnus.com Subject: Re: an evil memcpy() optimizer bug! (egcs-1.1.2, alphaev6, linux) Date: Mon, 12 Jul 1999 12:15:00 -0000 Message-id: <19990712121423.B4898@twiddle.net> References: <m3aet29c62.fsf@vermis.bfr.co.il> X-SW-Source: 1999-07/msg00448.html Content-length: 195 On Mon, Jul 12, 1999 at 05:26:45PM +0300, Alexander L. Belikoff wrote: > When optimized, memcpy() function IN SOME CASES doesn't properly copy > the data. This has been fixed for gcc 2.95. r~ >From mvishnu@fore.com Mon Jul 12 12:24:00 1999 From: Meenaradchagan Vishnu <mvishnu@fore.com> To: egcs-bugs@egcs.cygnus.com Subject: ECGS bug report Date: Mon, 12 Jul 1999 12:24:00 -0000 Message-id: <199907121924.PAA01853@columbia.fore.com> X-SW-Source: 1999-07/msg00449.html Content-length: 496 I got the following error message when compiling the attached file. [columbia:~/BFS] g++ -c event_manager.cc In file included from event_manager.cc:2: event_manager.hh:11: Internal compiler error 290. event_manager.hh:11: Please submit a full bug report to `egcs-bugs@egcs.cygnus.com'. event_manager.hh:11: See <URL: http://egcs.cygnus.com/faq.html#bugreport > for details. [columbia:~/BFS] which g++ g++: aliased to /us/swswbld/Compilers/egcs/release/1.1.2/sparc-sun-solaris2.6/bin/g++ >From gram@xiexie.org Mon Jul 12 13:26:00 1999 From: Gilbert Ramirez <gram@xiexie.org> To: "Putney, Jeff" <jputney@networkmanagementinc.com> Cc: egcs-bugs@egcs.cygnus.com Subject: Re: C++ bug: pointer to overloaded function Date: Mon, 12 Jul 1999 13:26:00 -0000 Message-id: <19990712152554.D21139@tivoli.com> References: <6D64634DB1513ECA062567A9007E84DA.0078F448862567A9@tivoli.com> X-SW-Source: 1999-07/msg00450.html Content-length: 1941 On Fri, Jul 09, 1999 at 05:01:08PM -0500, Putney, Jeff wrote: > > > This would seem to work. Thanks, it did --- on my test case. However, I just noticed the difference between the test case I posted and my real-world case... in the real-world case, the overloaded functions are defined 'static' inside the template class. Now I present my new test case, in which I try to take the pointer to an overloaded static member function of a template class. The test case simpler, too. I'm using egcs-2.95 19990629 on Linux 2.2.5 on an i686 machine. Here's the output from g++ -c test.cpp $ g++ -c test.cpp test.cpp: In method `void cb<char,int>::func(char, int)': test.cpp:50: instantiated from here test.cpp:39: initialization to `void (cb<char,int>::*)(void *)' from `void (*)(void *)' test.cpp:42: no matches converting function `overloaded_non_template' to type `void (cb<char,int>::*)(int)' test.cpp:12: candidates are: static void cb<char,int>::overloaded_non_template(int) test.cpp:13: static void cb<char,int>::overloaded_non_template(void *) test.cpp:43: no matches converting function `overloaded_template' to type `void (cb<char,int>::*)(char, int) test.cpp:14: candidates are: static void cb<char,int>::overloaded_template(char, int) test.cpp:15: static void cb<char,int>::overloaded_template(char, void *) test.cpp:44: no matches converting function `overloaded_template_2' to type `void (cb<char,int>::*)(int, cb<char,int> *)' test.cpp:16: candidates are: static void cb<char,int>::overloaded_template_2(int, cb<char,int> *) test.cpp:17: static void cb<char,int>::overloaded_template_2(cb<char,int> *, cb<char,int> *) And attached is test.cpp. I'm not sure if taking a pointer to a static member function of a template class is legal or not. This type of code does work with gcc (2.5.8... don't ask why), MSVC, and IBM VisualAge C++ (OS/2). thanks for any help, --gilbert >From jason@cygnus.com Mon Jul 12 13:45:00 1999 From: Jason Merrill <jason@cygnus.com> To: law@cygnus.com Cc: "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu>, egcs-bugs@egcs.cygnus.com Subject: Re: gcc-2.95, new libstdc++ testsuite failures due to libiberty change Date: Mon, 12 Jul 1999 13:45:00 -0000 Message-id: <u9wvw5wq9s.fsf@yorick.cygnus.com> References: <5166.931795470@upchuck.cygnus.com> X-SW-Source: 1999-07/msg00451.html Content-length: 1473 >>>>> Jeffrey A Law <law@cygnus.com> writes: >> Also, a second possible problem could arise. The current list >> only contains functions needed for ANSI. However some of them are >> implemented in terms of other libiberty exported functions. I think this is only true of the mem* functions. I suggest just adding the b* functions to NEEDED for the branch. For the long term, it seems to me that the b* fns should be written in terms of the mem* fns, not the other way around. Jason Index: Makefile.in =================================================================== RCS file: /egcs/carton/cvsfiles/egcs/libiberty/Makefile.in,v retrieving revision 1.26 diff -c -p -r1.26 Makefile.in *** Makefile.in 1999/07/08 02:43:10 1.26 --- Makefile.in 1999/07/12 20:45:31 *************** install_to_tooldir: all *** 159,165 **** # can't use anything encumbering. NEEDED = atexit calloc memchr memcmp memcpy memmove memset rename strchr \ strerror strrchr strstr strtol strtoul tmpnam vfprintf vprintf \ ! vfork waitpid mkstemps needed-list: Makefile rm -f needed-list; touch needed-list; \ for f in $(NEEDED); do \ --- 159,165 ---- # can't use anything encumbering. NEEDED = atexit calloc memchr memcmp memcpy memmove memset rename strchr \ strerror strrchr strstr strtol strtoul tmpnam vfprintf vprintf \ ! vfork waitpid mkstemps bcmp bcopy bzero needed-list: Makefile rm -f needed-list; touch needed-list; \ for f in $(NEEDED); do \ >From jason@cygnus.com Mon Jul 12 14:04:00 1999 From: Jason Merrill <jason@cygnus.com> To: "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu> Cc: law@cygnus.com, egcs-bugs@egcs.cygnus.com Subject: Re: gcc-2.95, new libstdc++ testsuite failures due to libiberty change Date: Mon, 12 Jul 1999 14:04:00 -0000 Message-id: <u9hfn9wpe6.fsf@yorick.cygnus.com> References: <199907121519.LAA00086@caip.rutgers.edu> X-SW-Source: 1999-07/msg00452.html Content-length: 440 >>>>> Kaveh R Ghazi <ghazi@caip.rutgers.edu> writes: > it looks like the shell code in libiberty/Makefile switched from > building a list of .o files to building a list of function names. > However the corresponding code in libstdc++/Makefile still expects > object files. Oops. I fixed that logic error in the mainline without sending mail to egcs-patches, and I didn't realize Jeff had applied it to the branch. Propagated. Jason >From ghazi@caip.rutgers.edu Mon Jul 12 14:20:00 1999 From: "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu> To: jason@cygnus.com, law@cygnus.com Cc: egcs-bugs@egcs.cygnus.com Subject: Re: gcc-2.95, new libstdc++ testsuite failures due to libiberty change Date: Mon, 12 Jul 1999 14:20:00 -0000 Message-id: <199907122120.RAA25237@caip.rutgers.edu> X-SW-Source: 1999-07/msg00453.html Content-length: 1034 > From: Jason Merrill <jason@cygnus.com> > > >>>>> Jeffrey A Law <law@cygnus.com> writes: > > >> Also, a second possible problem could arise. The current list > >> only contains functions needed for ANSI. However some of them are > >> implemented in terms of other libiberty exported functions. > > I think this is only true of the mem* functions. I suggest just adding the > b* functions to NEEDED for the branch. For the long term, it seems to me > that the b* fns should be written in terms of the mem* fns, not the other > way around. > Jason You are probably right about only needing the b* functions. However, I'd rather you applied the b* fix to both branches, not just the 2.95 branch. This is because right now SVR3 is probably broken since it has neither memmove nor bcopy. If someone wants to implement your long term solution suggestion, its better to handle that separately. --Kaveh -- Kaveh R. Ghazi Engagement Manager / Project Services ghazi@caip.rutgers.edu Qwest Internet Solutions >From jputney@networkmanagementinc.com Mon Jul 12 14:22:00 1999 From: "Putney, Jeff" <jputney@networkmanagementinc.com> To: "'Gilbert Ramirez'" <gram@xiexie.org>, "Putney, Jeff" <jputney@networkmanagementinc.com> Cc: egcs-bugs@egcs.cygnus.com Subject: RE: C++ bug: pointer to overloaded function Date: Mon, 12 Jul 1999 14:22:00 -0000 Message-id: <76EBA0999931D311926C009027557B5634962F@iris.nmsmn.com> X-SW-Source: 1999-07/msg00454.html Content-length: 2183 With the static case, this seems to work with no warnings (unless you use -Wall and get unused variable warnings) template<class T, class K> void cb<T, K>::func(T a, int n) { /* works, with warning */ void (* ptr_not_overloaded)(void*) = &cb<T,K>::not_overloaded; /* these three fail */ void (* ptr_overloaded_non_template)(int) = &cb<T,K>::overloaded_non_template; void (* ptr_overloaded_template)(T, int) = &cb<T,K>::overloaded_template; void (* ptr_overloaded_template_2)(K, cb<T,K>*) = &cb<T,K>::overloaded_template_2; val = a; } --jeff -----Original Message----- From: Gilbert Ramirez [ mailto:gram@xiexie.org ] Sent: Monday, July 12, 1999 3:26 PM To: Putney, Jeff Cc: egcs-bugs@egcs.cygnus.com Subject: Re: C++ bug: pointer to overloaded function Here's the output from g++ -c test.cpp $ g++ -c test.cpp test.cpp: In method `void cb<char,int>::func(char, int)': test.cpp:50: instantiated from here test.cpp:39: initialization to `void (cb<char,int>::*)(void *)' from `void (*)(void *)' test.cpp:42: no matches converting function `overloaded_non_template' to type `void (cb<char,int>::*)(int)' test.cpp:12: candidates are: static void cb<char,int>::overloaded_non_template(int) test.cpp:13: static void cb<char,int>::overloaded_non_template(void *) test.cpp:43: no matches converting function `overloaded_template' to type `void (cb<char,int>::*)(char, int) test.cpp:14: candidates are: static void cb<char,int>::overloaded_template(char, int) test.cpp:15: static void cb<char,int>::overloaded_template(char, void *) test.cpp:44: no matches converting function `overloaded_template_2' to type `void (cb<char,int>::*)(int, cb<char,int> *)' test.cpp:16: candidates are: static void cb<char,int>::overloaded_template_2(int, cb<char,int> *) test.cpp:17: static void cb<char,int>::overloaded_template_2(cb<char,int> *, cb<char,int> *) And attached is test.cpp. I'm not sure if taking a pointer to a static member function of a template class is legal or not. This type of code does work with gcc (2.5.8... don't ask why), MSVC, and IBM VisualAge C++ (OS/2). thanks for any help, --gilbert >From ghazi@caip.rutgers.edu Mon Jul 12 14:36:00 1999 From: "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu> To: jason@cygnus.com Cc: egcs-bugs@egcs.cygnus.com, law@cygnus.com Subject: Re: gcc-2.95, new libstdc++ testsuite failures due to libiberty change Date: Mon, 12 Jul 1999 14:36:00 -0000 Message-id: <199907122136.RAA25676@caip.rutgers.edu> X-SW-Source: 1999-07/msg00455.html Content-length: 1114 > From: Jason Merrill <jason@cygnus.com> > > >>>>> Kaveh R Ghazi <ghazi@caip.rutgers.edu> writes: > > > it looks like the shell code in libiberty/Makefile switched from > > building a list of .o files to building a list of function names. > > However the corresponding code in libstdc++/Makefile still expects > > object files. > > Oops. I fixed that logic error in the mainline without sending mail to > egcs-patches, and I didn't realize Jeff had applied it to the branch. > Propagated. > Jason Thanks, I'll test it tonight. BTW, your tweak on both branches not only fixes the logic, but it also adds mkstemps (which is LGPL'ed) to the NEEDED list. Doesn't this break the purpose of the original change, which was to clean out the LGPL stuff? Also if it matters, strtol.c and strtoul.c are under the BSD license. Most of the other files in the NEEDED list are public domain, but some don't have copyrights or are copyright FSF but don't state redistribution terms. --Kaveh -- Kaveh R. Ghazi Engagement Manager / Project Services ghazi@caip.rutgers.edu Qwest Internet Solutions >From geoffk@ozemail.com.au Mon Jul 12 15:50:00 1999 From: Geoff Keating <geoffk@ozemail.com.au> To: egcs-bugs@egcs.cygnus.com Cc: craig@jcb-sc.com Subject: Re: Bug with g77 and -mieee on Alpha Linux Date: Mon, 12 Jul 1999 15:50:00 -0000 Message-id: <m3zp12w82p.fsf@geoffk.wattle.id.au> References: <4048.931760012@upchuck.cygnus.com> <19990712072342.28771.qmail@deer> X-SW-Source: 1999-07/msg00456.html Content-length: 1107 craig@jcb-sc.com writes: > Agreed. Though, for g77's purposes, the ABI for complex is currently > *always* the ABI for struct { float; float; };. I'd be interested in > knowing about any ABI's for which that was not the case, because they'd > be systems on which g77 -fno-emulate-complex might not even *work*, > if implemented to follow the native ABI. (That's because g77 would be > telling the back end to pass/accept __complex__ across calls, but the > other end might be f2c-compiled, or g77-emulating-complex, or other, > code that uses the struct method.) The obvious other possibility is to treat a complex value as two successive floats. This makes these differences: - the structure may have higher alignment requirements than the individual members - on machines where function arguments are passed in registers, structures get passed in integer registers but FP arguments go in FP registers. Similarly for return values. So there may be good reasons for doing it differently. I don't know of any ABI that does it either way, though. -- Geoffrey Keating <geoffk@ozemail.com.au> >From martin@mira.isdn.cs.tu-berlin.de Mon Jul 12 15:58:00 1999 From: "Martin v. Loewis" <martin@mira.isdn.cs.tu-berlin.de> To: mvishnu@fore.com Cc: egcs-bugs@egcs.cygnus.com Subject: Re: ECGS bug report Date: Mon, 12 Jul 1999 15:58:00 -0000 Message-id: <199907122251.AAA00648@mira.isdn.cs.tu-berlin.de> References: <199907121924.PAA01853@columbia.fore.com> X-SW-Source: 1999-07/msg00457.html Content-length: 202 > I got the following error message when compiling the attached file. Thanks for your bug report. Unfortunately, it is incomplete. Please see http://egcs.cygnus.com/faq.html#bugreport Regards, Martin >From d.love@dl.ac.uk Mon Jul 12 16:01:00 1999 From: Dave Love <d.love@dl.ac.uk> To: egcs-bugs@egcs.cygnus.com Subject: Re: Bug with g77 and -mieee on Alpha Linux Date: Mon, 12 Jul 1999 16:01:00 -0000 Message-id: <rzqyagllbfj.fsf@djlvig.dl.ac.uk> References: <4305.931767820@upchuck.cygnus.com> X-SW-Source: 1999-07/msg00458.html Content-length: 1197 >>>>> "Jeff" == Jeffrey A Law <law@cygnus.com> writes: Jeff> Folks, I'm seeing some personal barbs go back and forth. Can Jeff> everyone in this discussion please count to 10 slowly before Jeff> sending out the next message? My lip is already quite bitten, but apologies for the contribution I've made. I'm unsubscribing anyhow, belatedly. I don't feel I should be getting into fights with steering committee people one way or another. Jeff> On a technical note, while we certainly can not switch the Jeff> default to -mieee for this release, we can consider adding an Jeff> -mieee multilib to the alpha port for this release (assuming Jeff> the libraries will successfully build with -mieee). Yes, I built multilibbed (on OSF). Jeff> While it is not a perfect solution, It's perfect as far as the canonical test goes. Jeff> it would provide the user with a more IEEE complaint Jeff> environment if requested *and* by making it at least an option Jeff> with this release -mieee will get more testing. Someone should document multilibs as not only applicable to libgcc and look for any other cases where they might be needed for the language runtimes but weren't for libgcc. >From toon@moene.indiv.nluug.nl Mon Jul 12 16:18:00 1999 From: Toon Moene <toon@moene.indiv.nluug.nl> To: Dave Love <d.love@dl.ac.uk> Cc: egcs-bugs@egcs.cygnus.com Subject: Re: Bug with g77 and -mieee on Alpha Linux Date: Mon, 12 Jul 1999 16:18:00 -0000 Message-id: <378A775A.DA65635D@moene.indiv.nluug.nl> References: <4305.931767820@upchuck.cygnus.com> <rzqyagllbfj.fsf@djlvig.dl.ac.uk> X-SW-Source: 1999-07/msg00459.html Content-length: 811 Dave Love wrote: > >>>>> "Jeff" == Jeffrey A Law <law@cygnus.com> writes: > Jeff> Folks, I'm seeing some personal barbs go back and forth. Can > Jeff> everyone in this discussion please count to 10 slowly before > Jeff> sending out the next message? > My lip is already quite bitten, but apologies for the contribution > I've made. I'm unsubscribing anyhow, belatedly. I don't feel I > should be getting into fights with steering committee people one way > or another. Note that Craig didn't want to be a member of the steering committee already months ago. You are not in a fight with me, if you think so. -- Toon Moene (toon@moene.indiv.nluug.nl) Saturnushof 14, 3738 XG Maartensdijk, The Netherlands Phone: +31 346 214290; Fax: +31 346 214286 GNU Fortran: http://world.std.com/~burley/g77.html >From law@cygnus.com Mon Jul 12 16:42:00 1999 From: Jeffrey A Law <law@cygnus.com> To: Dave Love <d.love@dl.ac.uk> Cc: egcs-bugs@egcs.cygnus.com Subject: Re: Bug with g77 and -mieee on Alpha Linux Date: Mon, 12 Jul 1999 16:42:00 -0000 Message-id: <9226.931822664@upchuck.cygnus.com> References: <rzqyagllbfj.fsf@djlvig.dl.ac.uk> X-SW-Source: 1999-07/msg00460.html Content-length: 1130 In message < rzqyagllbfj.fsf@djlvig.dl.ac.uk >you write: > Jeff> On a technical note, while we certainly can not switch the > Jeff> default to -mieee for this release, we can consider adding an > Jeff> -mieee multilib to the alpha port for this release (assuming > Jeff> the libraries will successfully build with -mieee). > > Yes, I built multilibbed (on OSF). > > Jeff> While it is not a perfect solution, > > It's perfect as far as the canonical test goes. Right. But I believe folks have stated that -mieee has some problems on the alpha. I don't read all the alpha stuff closely, so maybe I've got the wrong thread. > > Jeff> it would provide the user with a more IEEE complaint > Jeff> environment if requested *and* by making it at least an option > Jeff> with this release -mieee will get more testing. > > Someone should document multilibs as not only applicable to libgcc and > look for any other cases where they might be needed for the language > runtimes but weren't for libgcc. Yup. This kind of suggestion started making the rounds a couple weeks ago. jeff ^ permalink raw reply [flat|nested] 36+ messages in thread
end of thread, other threads:[~1999-07-31 23:33 UTC | newest] Thread overview: 36+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1999-03-04 0:05 fortran integer sizes on linux AXP Martin Kahlert 1999-03-31 23:54 ` Dave Love 1999-03-31 23:54 ` craig [not found] ` <craig@jcb-sc.com> 1999-03-09 4:18 ` Dave Love 1999-07-31 23:33 ` Bug with g77 and -mieee on Alpha Linux Dave Love 1999-07-11 23:54 ` craig 1999-07-12 1:24 ` Jeffrey A Law 1999-07-31 23:33 ` Dave Love 1999-07-31 23:33 ` Toon Moene 1999-07-31 23:33 ` Toon Moene 1999-07-11 13:12 ` Toon Moene 1999-07-31 23:33 ` craig 1999-07-31 23:33 ` Jeffrey A Law 1999-07-11 22:47 ` craig 1999-03-31 23:54 ` fortran integer sizes on linux AXP Martin Kahlert 1999-03-07 3:35 ` Dave Love 1999-07-06 13:40 Bug with g77 and -mieee on Alpha Linux martin.kahlert 1999-07-31 23:33 ` craig 1999-07-31 23:33 ` Martin Kahlert 1999-07-31 23:33 ` craig 1999-07-31 23:33 ` Martin Kahlert 1999-07-31 23:33 ` Toon Moene 1999-07-08 0:09 ` Martin Kahlert 1999-07-08 15:58 ` Dave Love 1999-07-31 23:33 ` craig 1999-07-08 8:01 ` Richard Hadsell 1999-07-31 23:33 ` Dave Love 1999-07-09 16:12 ` Dave Love 1999-07-09 21:10 ` craig [not found] ` <3784BE26.D14F95CD@blueskystudios.com> [not found] ` <19990708155845.13652.qmail@deer> [not found] ` <19990708111645.A6051@cygnus.com> [not found] ` <37850FE1.94D5B63D@moene.indiv.nluug.nl> [not found] ` <19990709021223.16356.qmail@deer> [not found] ` <3785E797.F6809570@moene.indiv.nluug.nl> [not found] ` <19990709152312.18370.qmail@deer> [not found] ` <37863D4F.287AF653@moene.indiv.nluug.nl> 1999-07-31 23:33 ` Martin Kahlert 1999-07-31 23:33 ` Toon Moene [not found] <4048.931760012@upchuck.cygnus.com> 1999-07-31 23:33 ` craig 1999-07-31 23:33 ` Jeffrey A Law 1999-07-31 23:33 ` craig 1999-07-31 23:33 ` Jeffrey A Law 1999-07-12 9:55 ` craig
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).