fortran integer sizes on linux AXP

fortran integer sizes on linux AXP

[Martin Kahlert]

[-- 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<-----

Re: fortran integer sizes on linux AXP

[Dave Love]

>>>>> "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

Re: fortran integer sizes on linux AXP

[Dave Love]

>>>>> "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

Re: fortran integer sizes on linux AXP

[Martin Kahlert]

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?

Re: fortran integer sizes on linux AXP

[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)

Re: fortran integer sizes on linux AXP

[Dave Love]

>>>>> "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.

Bug with g77 and -mieee on Alpha Linux

[martin.kahlert]

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

Re: Bug with g77 and -mieee on Alpha Linux

[Martin Kahlert]

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

Re: Bug with g77 and -mieee on Alpha Linux

[Richard Hadsell]

[-- 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

Re: Bug with g77 and -mieee on Alpha Linux

[Dave Love]

>>>>> "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

Re: Bug with g77 and -mieee on Alpha Linux

[Dave Love]

>>>>> "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

Re: Bug with g77 and -mieee on Alpha Linux

[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

Re: Bug with g77 and -mieee on Alpha Linux

[Toon Moene]

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
}

Re: Bug with g77 and -mieee on Alpha Linux

[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

Re: Bug with g77 and -mieee on Alpha Linux

[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

Re: Bug with g77 and -mieee on Alpha Linux

[Jeffrey A Law]

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

Re: Bug with g77 and -mieee on Alpha Linux

[Dave Love]

>>>>> "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.

Re: Bug with g77 and -mieee on Alpha Linux

[Martin Kahlert]

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

Re: Bug with g77 and -mieee on Alpha Linux

[Toon Moene]

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

Re: Bug with g77 and -mieee on Alpha Linux

[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.  ;-)

Re: Bug with g77 and -mieee on Alpha Linux

[Toon Moene]

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

Re: Bug with g77 and -mieee on Alpha Linux

[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)

Re: Bug with g77 and -mieee on Alpha Linux

[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)

Re: Bug with g77 and -mieee on Alpha Linux

[Martin Kahlert]

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

Re: Bug with g77 and -mieee on Alpha Linux

[Toon Moene]

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

Re: Bug with g77 and -mieee on Alpha Linux

[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)

Re: Bug with g77 and -mieee on Alpha Linux

[Martin Kahlert]

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?

Re: Bug with g77 and -mieee on Alpha Linux

[Toon Moene]

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

Re: Bug with g77 and -mieee on Alpha Linux

[Dave Love]

>>>>> "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.

Re: Bug with g77 and -mieee on Alpha Linux

[Jeffrey A Law]

  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

Re: Bug with g77 and -mieee on Alpha Linux

[Dave Love]

>>>>> "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.

Re: Bug with g77 and -mieee on Alpha Linux

[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)

Re: Bug with g77 and -mieee on Alpha Linux

[Jeffrey A Law]

  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

Re: Bug with g77 and -mieee on Alpha Linux

[Jeffrey A Law]

  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

Re: Bug with g77 and -mieee on Alpha Linux

[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.)

Re: Bug with g77 and -mieee on Alpha Linux

[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