public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* single precision complex bug in g77 - was Testing g77 with LAPACK 3.0
@ 1999-07-07 5:31 Billinghurst, David (RTD)
1999-07-31 23:33 ` Toon Moene
0 siblings, 1 reply; 21+ messages in thread
From: Billinghurst, David (RTD) @ 1999-07-07 5:31 UTC (permalink / raw)
To: 'egcs-bugs@egcs.cygnus.com'; +Cc: 'egcs@egcs.cygnus.com'
Here is a test case.
############################################################
program labug3
implicit none
* This program gives the wrong answer on mips-sgi-irix6.5
* when compiled with g77 from egcs-19990629 (gcc 2.95 prerelease)
*
* Works with: -femulate-complex
* egcs-1.1.2
*
* Originally derived from LAPACK 3.0 test suite.
*
* David Billinghurst, (David.Billinghurst@riotinto.com.au)
* 7 July 1999
*
complex one, z
real a,cabs1
CABS1( Z) = ABS( REAL( Z)) + ABS( AIMAG(Z))
one = (1.,0.)
a = cabs1(one)
if ( abs(a-one) .gt. 1.0e-5 ) then
write(6,*) 'A should be 1.0'
call abort()
end if
end
###############################################################
> -----Original Message-----
> From: Billinghurst, David (RTD) [SMTP:David.Billinghurst@riotinto.com.au]
> Sent: Wednesday 7 July 1999 9:40
> To: 'Toon Moene'
> Cc: 'egcs@egcs.cygnus.com'
> Subject: RE: Testing g77 with LAPACK 3.0
>
> Sorry for the lack of detail - I was running for the door last night.
>
> Compiles OK, with trivial patch.
> A couple of test cases seem to run forever - certainly much longer than
> they
> should so I killed them
> Some massive test failures - orders of magnitude wrong.
>
> All recent snapshots, up to egcs-19990629 pass LAPACK 2.0 testsuite with
> "-O3 -funroll-loops"
>
> I plan to run the testsuite with increasing levels of optimisation,
> starting
> with
> -O0
> -O1
> -O2
> then I will throw in -funroll-loops and -femulate-complex
>
> Good chance I can generate a simple test case when I can get a free
> evening.
>
>
> > -----Original Message-----
> > From: Toon Moene [SMTP:toon@moene.indiv.nluug.nl]
> > Sent: Wednesday, 7 July 1999 5:58
> > To: Billinghurst, David (RTD)
> > Cc: 'egcs@egcs.cygnus.com'
> > Subject: Re: Testing g77 with LAPACK 3.0
> >
> > Billinghurst, David (RTD) wrote:
> >
> > > Here are some preliminary results of some g77 testing against LAPACK
> 3.0
> > > ( http://www.netlib.org/lapack/ ), which was released last week, on
> > > mips-sig-irix6.5
> >
> > > Results from egcs-19990629 are not so good. Seem to be some single
> > > precision
> > > complex problems. May not have time to investigate further for a few
> > days.
> >
> > NOOOO !!! We don't want to go back to -femulate-complex.
> >
> > You didn't say what problems: Problems compiling, running, or getting
> > good test results ? What if you rerun the stuff compiled with the
> > additional flag -femulate-complex ?
> >
> > --
> > 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 markus@lufmech.rwth-aachen.de Wed Jul 07 05:52:00 1999
From: Markus Werle <markus@lufmech.rwth-aachen.de>
To: egcs-bugs@egcs.cygnus.com
Subject: Re: internal error: template member template
Date: Wed, 07 Jul 1999 05:52:00 -0000
Message-id: <37834D6D.5CBDA3A6@lufmech.rwth-aachen.de>
References: <378339A2.1B9B35E3@lufmech.rwth-aachen.de>
X-SW-Source: 1999-07/msg00248.html
Content-length: 2337
Maybe my previous code is not valid, but I run into some crazy error messages
when changing :-(
First: This code fragment compiles fine:
-----------------------------------------------------
#include <iostream>
template<int m> void f1(){ cerr << m << endl;}
template<int m> class f2 {
public:
static inline void Exec() { f1<m>(); }
};
template<int i, template<int> class f> void ff() { f<i>::Exec(); }
int main() { ff<5,f2>(); return(0);}
-----------------------------------------------------
Now if I would like to omit the template arguments of f, e.g.
template<int i, template<> class f> void ff() { f<i>::Exec(); }
I get an internal compiler error.
But maybe ANSI forbids such stuff - one day the compiler will catch such
a garbage :-)
So I inserted argument "int" into the example of my previous message
and modified the call inserting keyword template
ending up with a file that compiles fine, but does not create the
expected loop: (a correct running version without member templates is attached
but I wanted this special calling syntax)
Please take a look at it.
------------------------------------------------------
#include <iostream>
template<int m> void f1(){ cerr << m << endl;}
template<int m> class f2 {
public:
static inline void Exec() { f1<m>(); }
};
template<int i, template<int> class f> void ff() {
f<i>::Exec();
}
template <int i, int j, bool b=(i<=j)>
class LoopFromTo {
public:
template<template<int> class f> static void Exec() {
cerr << "You are wrong here" << endl;
}
};
template <int i, int j>
class LoopFromTo<i, j, true> {
public:
template<template<int> class f> static void Exec() {
f<i>::Exec();
// *******************************************************************
// here is a problem: next line leads to nothing !!!!!!!!!
// no warnings, no error messages ... no execution :-( !!!!!!!!!
LoopFromTo<i+1, j>::template Exec<f>(); // is this here forbidden?
// *******************************************************************
}
};
template <int i, int j>
class LoopFromTo<i, j, false> {
public:
template<template<int> class f> static void Exec() { }
};
int main() {
LoopFromTo<1,4>::template Exec<f2>();
cerr << endl;
ff<5,f2>();
return(0);
}
-----------------------------------------------------------
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: single precision complex bug in g77 - was Testing g77 with LAPACK 3.0
1999-07-31 23:33 ` Jim Wilson
@ 1999-07-08 13:55 ` Toon Moene
1999-07-31 23:33 ` Jim Wilson
1999-07-31 23:33 ` Jeffrey A Law
1 sibling, 1 reply; 21+ messages in thread
From: Toon Moene @ 1999-07-08 13:55 UTC (permalink / raw)
To: Jim Wilson
Cc: Billinghurst, David (RTD), 'egcs-bugs@egcs.cygnus.com', craig
Jim Wilson wrote:
[ Sigh ]
> Without optimization, it is a calling convention problem. We try to pass
> a single precision complex to the function cabs1.0, which requires loading
> two SFmode values.
...
> which emits two loads into the same register when x is a register big
> enough to hold the entire complex value. This code can work for registers
> only if the register is equal to or smaller than one half the size of the
> complex type.
In other words, for 32-bit targets.
> The problem can probably be fixed in either area. It isn't clear which is
> best. We need to make sure that we emit correct ABI compliant code for this
> case which may constrain the possible solutions.
Do you think it can be fixed in time for the release (of gcc-2.95) ?
This is clearly a show-stopper ... Not being able to run the LAPACK
tests successfully on 64-bit targets will make us the laughing stock of
the Galaxy (at least the Fortran Galaxy).
If not, we *have* to revert to -femulate-complex in the Fortran
Frontend.
[ Another Sigh ]
--
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 martin.kahlert@provi.de Thu Jul 08 14:36:00 1999
From: martin.kahlert@provi.de
To: egcs-bugs@egcs.cygnus.com
Subject: Showstopper in g77 in prerelease on Linux-Alpha
Date: Thu, 08 Jul 1999 14:36:00 -0000
Message-id: <199907082138.XAA00190@keksy.linux.provi.de>
X-SW-Source: 1999-07/msg00320.html
Content-length: 2811
I found a big bug in g77 on Linux Alpha in gcc-2.95 19990629 (prerelease):
Try this fortran File:
t.f:
REAL*8 X
X=90D0
DO I=90,110
X=X+1D0
WRITE(*,*) NINT(X)
ENDDO
END
And compile it by: g77 -O2 -o t t.f
result: a lot of zeros. With -O1 you get correct results.
This is clearly a show stopper for me, since my program relies heavily on NINT.
Bye,
Martin.
g77 -v:
martin@alpha: ~$ g77 -v
g77 version gcc-2.95 19990629 (prerelease) (from FSF-g77 version 0.5.25 19990628 (prerelease))
Driving: g77 -v -c -xf77-version /dev/null -xnone
Reading specs from /usr/local/lib/gcc-lib/alphaev56-unknown-linux-gnu/gcc-2.95/specs
gcc version gcc-2.95 19990629 (prerelease)
/usr/local/lib/gcc-lib/alphaev56-unknown-linux-gnu/gcc-2.95/cpp -lang-c -v -D__GNUC__=2 -D__GNUC_MINOR__=95 -D__linux__ -D__unix__ -D_LONGLONG -D__alpha__ -D__ELF__ -D__linux -D__unix -Asystem(linux) -D_LANGUAGE_FORTRAN -traditional -D__LANGUAGE_C__ -D__LANGUAGE_C -DLANGUAGE_C -Acpu(alpha) -Amachine(alpha) -D__alpha -D__alpha__ -D__alpha_ev5__ -Acpu(ev5) -D__alpha_bwx__ -Acpu(bwx) /dev/null /dev/null
GNU CPP version gcc-2.95 19990629 (prerelease) (Alpha GNU/Linux for ELF)
#include "..." search starts here:
#include <...> search starts here:
/usr/local/include
/usr/local/lib/gcc-lib/alphaev56-unknown-linux-gnu/gcc-2.95/../../../../alphaev56-unknown-linux-gnu/include
/usr/local/lib/gcc-lib/alphaev56-unknown-linux-gnu/gcc-2.95/include
/usr/include
End of search list.
The following default directories have been omitted from the search path:
/usr/local/lib/gcc-lib/alphaev56-unknown-linux-gnu/gcc-2.95/../../../../include/g++-2
End of omitted list.
/usr/local/lib/gcc-lib/alphaev56-unknown-linux-gnu/gcc-2.95/f771 -fnull-version -quiet -dumpbase g77-version.f -version -fversion -o /tmp/cc7l6gQr.s /dev/null
GNU F77 version gcc-2.95 19990629 (prerelease) (alphaev56-unknown-linux-gnu) compiled by GNU C version gcc-2.95 19990629 (prerelease).
GNU Fortran Front End version 0.5.25 19990628 (prerelease)
as -o /tmp/ccYykWPO.o /tmp/cc7l6gQr.s
ld -m elf64alpha -O1 -dynamic-linker /lib/ld-linux.so.2 -o /tmp/ccLX7Xvf /tmp/ccYykWPO.o /usr/lib/crt1.o /usr/lib/crti.o /usr/local/lib/gcc-lib/alphaev56-unknown-linux-gnu/gcc-2.95/crtbegin.o -L/usr/local/lib/gcc-lib/alphaev56-unknown-linux-gnu/gcc-2.95 -L/usr/local/alphaev56-unknown-linux-gnu/lib -L/usr/local/lib -lg2c -lm -lgcc -lc -lgcc /usr/local/lib/gcc-lib/alphaev56-unknown-linux-gnu/gcc-2.95/crtend.o /usr/lib/crtn.o
/tmp/ccLX7Xvf
__G77_LIBF77_VERSION__: 0.5.25 19990503 (prerelease)
@(#)LIBF77 VERSION 19990503
__G77_LIBI77_VERSION__: 0.5.25 19990628 (prerelease)
@(#) LIBI77 VERSION pjw,dmg-mods 19990503
__G77_LIBU77_VERSION__: 0.5.25 19990507 (prerelease)
@(#) LIBU77 VERSION 19980709
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: single precision complex bug in g77 - was Testing g77 with LAPACK 3.0
1999-07-31 23:33 ` craig
@ 1999-07-09 9:24 ` Jeffrey A Law
1999-07-09 10:47 ` craig
1999-07-09 11:21 ` Toon Moene
1 sibling, 1 reply; 21+ messages in thread
From: Jeffrey A Law @ 1999-07-09 9:24 UTC (permalink / raw)
To: craig; +Cc: wilson, toon, egcs-bugs
In message < 19990709153122.18406.qmail@deer >you write:
> I think not, because ISTR seeing a few bug reports involving crashes
> with -femulate-complex in effect that we basically handwaved as no
> longer pertinent because of our changing the default. They might have
> been on popular machines like IA32, but I don't recall clearly.
We're basically changing one set of bugs for another. I suspect using
-fno-emulate-complex is going to add more bugs than it fixes.
> However, I think it's better to ship with -fno-emulate-complex in effect
> and say "it still isn't quite working on Alphas, e.g. compiling LAPACK
> and maybe other code, try -femulate-complex" -- hardly different from
> what we've said in the past.
This is not just an alpha problem. This is not just a 64bit problem. This
is a potential problem on every system that has registers which are the width
of a SCmode variable. So for example, the PA is a 32bit target, which has
64bit wide FP registers. I'd bet with a little work I could expose the same
bug
on the PA. I'd make the same bit for other 32bit targets which have 64bit
wide FP registers, particularly those which pass parameters in registers.
> If we make -femulate-complex the default, we might well break (perhaps
> by virtue of exposing, or re-exposing, latent bugs) lots of code on
> other, e.g. 32-bit, platforms (IA32, m68k, SPARCv8, etc.) -- code that,
> we hope at least, has already been thoroughly tested during this release
> cycle.
But I would bet we have problems with -fno-emulate-complex on all the targets
noted above.
> Given my serious reservations concerning g77's viability on the Alpha
> (see my other emails), and the fact that g77 still has known problems
> with 64-bit systems (e.g. it doesn't work with `-mabi=64', supported
> by some configuration(s)), I think it's best to document what we've
> found to date (i.e. swallow it).
Do not confuse the -mabi64 option with g77 not working on 64bit targets. That
problem is strictly due to the sizes of internal types changing due to
compiler flags.
I've seen quite a few people using g77 on alpha with success. Do we want to
screw them over?
I'll also repeat -- I believe this bug can effect our 32bit targets such as
ia32, hppa, m68k, etc etc etc.
This is a pretty fundamental issue with how complex types work, particularly
when passing them as parameters to functions.
jeff
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: single precision complex bug in g77 - was Testing g77 with LAPACK 3.0
1999-07-09 9:24 ` Jeffrey A Law
@ 1999-07-09 10:47 ` craig
1999-07-31 23:33 ` Jeffrey A Law
0 siblings, 1 reply; 21+ messages in thread
From: craig @ 1999-07-09 10:47 UTC (permalink / raw)
To: law; +Cc: craig
> In message < 19990709153122.18406.qmail@deer >you write:
> > I think not, because ISTR seeing a few bug reports involving crashes
> > with -femulate-complex in effect that we basically handwaved as no
> > longer pertinent because of our changing the default. They might have
> > been on popular machines like IA32, but I don't recall clearly.
>We're basically changing one set of bugs for another. I suspect using
>-fno-emulate-complex is going to add more bugs than it fixes.
Okay.
>This is not just an alpha problem. This is not just a 64bit problem. This
>is a potential problem on every system that has registers which are the width
>of a SCmode variable. So for example, the PA is a 32bit target, which has
>64bit wide FP registers. I'd bet with a little work I could expose the same
>bug
>on the PA. I'd make the same bit for other 32bit targets which have 64bit
>wide FP registers, particularly those which pass parameters in registers.
Okay.
>But I would bet we have problems with -fno-emulate-complex on all the targets
>noted above.
Okay.
> > Given my serious reservations concerning g77's viability on the Alpha
> > (see my other emails), and the fact that g77 still has known problems
> > with 64-bit systems (e.g. it doesn't work with `-mabi=64', supported
> > by some configuration(s)), I think it's best to document what we've
> > found to date (i.e. swallow it).
>Do not confuse the -mabi64 option with g77 not working on 64bit targets. That
>problem is strictly due to the sizes of internal types changing due to
>compiler flags.
Indeed.
>I've seen quite a few people using g77 on alpha with success. Do we want to
>screw them over?
No.
>I'll also repeat -- I believe this bug can effect our 32bit targets such as
>ia32, hppa, m68k, etc etc etc.
Okay.
>This is a pretty fundamental issue with how complex types work, particularly
>when passing them as parameters to functions.
Okay.
Then the only fundamental question remains: do we release 2.95 with
g77 defaulting to -fno-emulate-complex, in which case we have to document
whatever bugs we've learned as the result of several months' testing?
Or do we release it with g77 defaulting to -femulate-complex, in which
case we release a largely *untested* product, *without* documentation
of bugs that are likely to be present (but which we've pretty much ignored
since switching to -fno-emulate-complex)?
Or do we delay the release of 2.95 for a few months, during which we
encourage everyone to respin all their testing, using a prerelease we
make (which we can do by the end of the day, or thereabouts) with
-femulate-complex the default?
All the evidence you provided was helpful, but what it convinces *me*
is that I'm even less sure what is the right path than I was when
I wrote *my* email. (That is, I thought it was the case that the
status quo was, at least, well-tested, well-understood in terms of the
few bugs we have, and known to not work only on a few systems. Turns
out I'm wrong about the last item, and maybe the second, but surely
I'm not wrong about the first.)
So I have no suggestion to make whatsoever. It's up to you, the Steering
Committee, or whatever.
tq vm, (burley)
>From law@cygnus.com Fri Jul 09 10:57:00 1999
From: Jeffrey A Law <law@cygnus.com>
To: craig@jcb-sc.com
Cc: wilson@cygnus.com, toon@moene.indiv.nluug.nl, egcs-bugs@egcs.cygnus.com
Subject: Re: single precision complex bug in g77 - was Testing g77 with LAPACK 3.0
Date: Fri, 09 Jul 1999 10:57:00 -0000
Message-id: <6559.931543030@upchuck.cygnus.com>
References: <19990709174723.18881.qmail@deer>
X-SW-Source: 1999-07/msg00362.html
Content-length: 1466
In message < 19990709174723.18881.qmail@deer >you write:
> Then the only fundamental question remains: do we release 2.95 with
> g77 defaulting to -fno-emulate-complex, in which case we have to document
> whatever bugs we've learned as the result of several months' testing?
It's one option. but (IMHO) the more risky option.
> Or do we release it with g77 defaulting to -femulate-complex, in which
> case we release a largely *untested* product, *without* documentation
> of bugs that are likely to be present (but which we've pretty much ignored
> since switching to -fno-emulate-complex)?
Well, -fno-emulate-complex was the default until the last few months -- so
while it has not had a lot of formal testing _recently_, it has been tested
extensively over the years. We know where it is likely to fall down. I
believe
we can effectively get this stuff tested to verify we haven't botched the
-fno-emulate-complex support over the next few days by having folks build &
test lapack across a good mix of targets. We *know* lapack will beat on the
complex code :-)
> Or do we delay the release of 2.95 for a few months, during which we
> encourage everyone to respin all their testing, using a prerelease we
> make (which we can do by the end of the day, or thereabouts) with
> -femulate-complex the default?
I do not think any of our g77 tests really stress complex anyway -- so I
suspect that would be mostly a wasted effort.
jeff
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: single precision complex bug in g77 - was Testing g77 with LAPACK 3.0
1999-07-31 23:33 ` craig
1999-07-09 9:24 ` Jeffrey A Law
@ 1999-07-09 11:21 ` Toon Moene
1 sibling, 0 replies; 21+ messages in thread
From: Toon Moene @ 1999-07-09 11:21 UTC (permalink / raw)
To: craig; +Cc: law, wilson, egcs-bugs
craig@jcb-sc.com wrote:
>
> >I'm leery of trying to get either change into the release branch this late in
> >the game. As painful as it may be, I suspect we may be better off using
> >-femulate-complex for gcc-2.95.
> I think not, because ISTR seeing a few bug reports involving crashes
> with -femulate-complex in effect that we basically handwaved as no
> longer pertinent because of our changing the default. They might have
> been on popular machines like IA32, but I don't recall clearly.
No - it means that my initial enthousiasm about the 64-bit-target
COMPLEX problems being solved was premature.
I should have (done | organized) more testing.
It's just *me* to blame - we shouldn't argue about it, but document it.
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
>From mrs@wrs.com Fri Jul 09 12:02:00 1999
From: mrs@wrs.com (Mike Stump)
To: BCAMERON@tuc.com, egcs-bugs@egcs.cygnus.com
Subject: Re: egcs 1.1.2 seems to generate bloated object code
Date: Fri, 09 Jul 1999 12:02:00 -0000
Message-id: <199907091902.MAA01711@kankakee.wrs.com>
X-SW-Source: 1999-07/msg00364.html
Content-length: 521
Please learn what `size' is and does. Please learn what -S does.
Please read the stabs spec and the dwarf spec to learn more about
debugging information.
In short, -g does not bloat the object code. What it bloats is the
debugging information and it is supposed to do that! The fact that
ours is bigger, does matter.
Also, I wonder if you are comparing apples to apples, be sure that
both compilers are statically linking or both are dynamically linking.
Comparing size differences bwteen the two isn't interesting.
>From rth@cygnus.com Fri Jul 09 12:16:00 1999
From: Richard Henderson <rth@cygnus.com>
To: Jeffrey A Law <law@cygnus.com>
Cc: martin.kahlert@provi.de, egcs-bugs@egcs.cygnus.com
Subject: Re: Showstopper in g77 in prerelease on Linux-Alpha
Date: Fri, 09 Jul 1999 12:16:00 -0000
Message-id: <19990709121611.A11918@cygnus.com>
References: <19990709020751.A11264@cygnus.com> <5148.931511341@upchuck.cygnus.com>
X-SW-Source: 1999-07/msg00365.html
Content-length: 352
On Fri, Jul 09, 1999 at 03:09:01AM -0600, Jeffrey A Law wrote:
> In message < 19990709020751.A11264@cygnus.com >you write:
> > That and the fact that the 2.95 prerelease won't build a
> > working glibc on alpha.
> ?!?! WHAT? I tested this a few weeks ago. What have we broken?
I don't know, but the newly built dynamic linker segfaults.
r~
>From Franz.Sirl-kernel@lauterbach.com Fri Jul 09 12:32:00 1999
From: Franz Sirl <Franz.Sirl-kernel@lauterbach.com>
To: Richard Henderson <rth@cygnus.com>
Cc: Jeffrey A Law <law@cygnus.com>, martin.kahlert@provi.de, egcs-bugs@egcs.cygnus.com
Subject: Re: Showstopper in g77 in prerelease on Linux-Alpha
Date: Fri, 09 Jul 1999 12:32:00 -0000
Message-id: <4.2.0.58.19990709212851.03b75770@mail.lauterbach.com>
References: <5148.931511341@upchuck.cygnus.com> <19990709020751.A11264@cygnus.com> <19990709121611.A11918@cygnus.com>
X-SW-Source: 1999-07/msg00366.html
Content-length: 3543
At 21:16 09.07.99 , Richard Henderson wrote:
>On Fri, Jul 09, 1999 at 03:09:01AM -0600, Jeffrey A Law wrote:
> > In message < 19990709020751.A11264@cygnus.com >you write:
> > > That and the fact that the 2.95 prerelease won't build a
> > > working glibc on alpha.
> > ?!?! WHAT? I tested this a few weeks ago. What have we broken?
>
>I don't know, but the newly built dynamic linker segfaults.
You might try the attached patch for glibc-2.1.x. It helped on PPC. The
patch would be cleaner if there was a __noinline__ attribute.
Franz.
Index: elf/rtld.c
===================================================================
RCS file: /glibc/cvsfiles/libc/elf/rtld.c,v
retrieving revision 1.148
diff -u -p -r1.148 rtld.c
--- rtld.c 1999/05/11 13:00:10 1.148
+++ elf/rtld.c 1999/07/05 18:52:44
@@ -129,6 +129,10 @@ static hp_timing_t relocate_time;
static hp_timing_t load_time;
extern unsigned long int _dl_num_relocations; /* in dl-lookup.c */
+static ElfW(Addr)
+_dl_start_final (void *arg, struct link_map *bootstrap_map_p,
+ hp_timing_t start_time);
+
#ifdef RTLD_START
RTLD_START
#else
@@ -140,7 +144,6 @@ _dl_start (void *arg)
{
struct link_map bootstrap_map;
hp_timing_t start_time;
- ElfW(Addr) start_addr;
/* This #define produces dynamic linking inline functions for
bootstrap relocation instead of general-purpose relocation. */
@@ -175,7 +178,22 @@ _dl_start (void *arg)
/* Now life is sane; we can call functions and access global data.
Set up to use the operating system facilities, and find out from
the operating system's program loader where to find the program
- header table in core. */
+ header table in core. Put the rest of _dl_start into a separate
+ function, that way the compiler cannot put accesses to the GOT
+ before ELF_DYNAMIC_RELOCATE. */
+
+ return _dl_start_final (arg, &bootstrap_map, start_time);
+}
+
+static ElfW(Addr)
+_dl_start_final (void *arg, struct link_map *bootstrap_map_p,
+ hp_timing_t start_time)
+{
+ /* The use of `alloca' here looks ridiculous but it helps. The goal
+ is to avoid the function from being inlined. There is no official
+ way to do this so we use this trick. gcc never inlines functions
+ which use `alloca'. */
+ ElfW(Addr) *start_addr = alloca (sizeof (ElfW(Addr)));
if (HP_TIMING_AVAIL)
{
@@ -188,10 +206,10 @@ _dl_start (void *arg)
}
/* Transfer data about ourselves to the permanent link_map structure. */
- _dl_rtld_map.l_addr = bootstrap_map.l_addr;
- _dl_rtld_map.l_ld = bootstrap_map.l_ld;
+ _dl_rtld_map.l_addr = bootstrap_map_p->l_addr;
+ _dl_rtld_map.l_ld = bootstrap_map_p->l_ld;
_dl_rtld_map.l_opencount = 1;
- memcpy (_dl_rtld_map.l_info, bootstrap_map.l_info,
+ memcpy (_dl_rtld_map.l_info, bootstrap_map_p->l_info,
sizeof _dl_rtld_map.l_info);
_dl_setup_hash (&_dl_rtld_map);
@@ -203,7 +221,7 @@ _dl_start (void *arg)
file access. It will call `dl_main' (below) to do all the real work
of the dynamic linker, and then unwind our frame and run the user
entry point on the same stack we entered on. */
- start_addr = _dl_sysdep_start (arg, &dl_main);
+ start_addr[0] = _dl_sysdep_start (arg, &dl_main);
if (HP_TIMING_AVAIL)
{
@@ -219,7 +237,7 @@ _dl_start (void *arg)
if (_dl_debug_statistics)
print_statistics ();
- return start_addr;
+ return start_addr[0];
}
/* Now life is peachy; we can do all normal operations.
>From wilson@cygnus.com Fri Jul 09 12:36:00 1999
From: Jim Wilson <wilson@cygnus.com>
To: law@cygnus.com
Cc: "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu>, egcs-bugs@egcs.cygnus.com
Subject: Re: gcc-2.95 19990627 irix6 bootstrap fails with "-O3 -funroll-all-loops"
Date: Fri, 09 Jul 1999 12:36:00 -0000
Message-id: <199907091936.MAA12141@rtl.cygnus.com>
References: <4538.931502124@upchuck.cygnus.com>
X-SW-Source: 1999-07/msg00367.html
Content-length: 164
Perhaps the way to go is to use this patch for gcc-2.95 since it's nice and
isolated, but fix delete_insn for the mainline sources?
That sounds reasonable.
Jim
>From craig@jcb-sc.com Fri Jul 09 13:05:00 1999
From: craig@jcb-sc.com
To: law@cygnus.com
Cc: craig@jcb-sc.com
Subject: Re: single precision complex bug in g77 - was Testing g77 with LAPACK 3.0
Date: Fri, 09 Jul 1999 13:05:00 -0000
Message-id: <19990709200442.19339.qmail@deer>
References: <6559.931543030@upchuck.cygnus.com>
X-SW-Source: 1999-07/msg00368.html
Content-length: 14759
> In message < 19990709174723.18881.qmail@deer >you write:
> > Then the only fundamental question remains: do we release 2.95 with
> > g77 defaulting to -fno-emulate-complex, in which case we have to document
> > whatever bugs we've learned as the result of several months' testing?
>It's one option. but (IMHO) the more risky option.
It apparently had *zero* risk until this week, when a bug in (a new
version of?) LAPACK was finally found and reported.
So it can't be *that* risky. I've seen *many* reasonably-well-respected
products released under similar circumstances. I'd say GCC 2.95 could
well be fairly released so, given all the wonderful improvements in it
and the fact that, apparently, this new bug is *not* showing up as a
regression per se (though I concede there is reason to assume that it
will, once released to the user community, now that Jim has provided a
diagnosis of the problem).
I've also seen at least one nearly-useless version of gcc released,
made useless by the application of last-minute patches that had a major
effect on code generation, even though those effects were deemed "safe".
(Though I'm a bit hazy on the history, the point is, last-minute
changes carry great risk. What is being proposed here is probably
riskier than any previous last-minute change to gcc. The upside is
that it'll affect only g77, which is not the case with any attempt we
make at *fixing* the problem Jim identified.)
> > Or do we release it with g77 defaulting to -femulate-complex, in which
> > case we release a largely *untested* product, *without* documentation
> > of bugs that are likely to be present (but which we've pretty much ignored
> > since switching to -fno-emulate-complex)?
>Well, -fno-emulate-complex was the default until the last few months -- so
>while it has not had a lot of formal testing _recently_, it has been tested
>extensively over the years. We know where it is likely to fall down. I
>believe
>we can effectively get this stuff tested to verify we haven't botched the
>-fno-emulate-complex support over the next few days by having folks build &
>test lapack across a good mix of targets. We *know* lapack will beat on the
>complex code :-)
Okay, then, let's take a look at the relevant ChangeLog entries, shall we?
Here's the one where we changed the default (in g77):
Sat Apr 3 23:29:33 1999 Craig Burley <craig@jcb-sc.com>
* bugs.texi, g77.texi, lang-options.h, news.texi, top.c:
Make -fno-emulate-complex the default, as COMPLEX support
in the back end is now believed to be working.
Now, what has happened *in g77 alone* since then? Hmm, how about
*this* little change:
Sat Apr 17 13:53:43 1999 Craig Burley <craig@jcb-sc.com>
Rewrite to use block/scope structure of GBE and to ensure
variables (especially those going on stack/reg) are declared
before executable code generated:
* bld.c (ffebld_new_item, ffebld_new_one, ffebld_new_two):
Support new hooks.
* bld.h (ffebld_item_hook, ffebld_item_set_hook,
ffebld_nonter_hook, ffebld_nonter_set_hook): Ditto.
* bld.h (ffebld_basictype, ffebld_kind, ffebld_kindtype,
ffebld_rank, ffebld_where): New convenience macros (used
by rest of this patch).
* com.c, com.h (ffecom_push_calltemps, ffecom_pop_calltemps,
ffecom_push_tempvar, ffecom_pop_tempvar): Remove temp-var-
handling mechanism.
* com.c (ffecom_call_, ffecom_call_binop_, ffecom_tree_divide_,
ffecom_call_gfrt): Support passing hooks for temp-var info.
(ffecom_expr_power_integer_): Takes opPOWER expression, instead
of its left and right operands, so it can get at the hook.
(ffecom_prepare_let_char_, ffecom_prepare_arg_ptr_to_expr,
ffecom_prepare_end, ffecom_prepare_expr_, ffecom_prepare_expr_rw,
ffecom_prepare_expr_w, ffecom_prepare_return_expr,
ffecom_prepare_ptr_to_expr): New functions supporting expression
pre-scanning.
(bison_rule_compstmt_): Return the tree, as in the CFE.
(delete_block): New function, from CFE.
(kept_level_p): New function, from CFE, modified.
(ffecom_start_compstmt, ffecom_end_compstmt): New functions,
replacing ffecom_start_compstmt_ and ffecom_end_compstmt_ macros,
and they do real work.
(struct binding_level): Add prep_state member. Initialize to 0.
(ffecom_get_invented_identifier): Now takes either or both a
string and an integer, using -1 to denote no integer.
(ffecom_do_entry_): Disallow temp-var generation via expressions
in body of function, since the exprs aren't prescanned.
(ffecom_expr_rw): Now takes destination tree.
(ffecom_expr_w): New function, now used in some places
ffecom_expr_rw had been used.
(ffecom_expr_intrinsic_): Move huge f2c-related comment to bottom
of source file, to avoid annoying problems editing com.c using
Emacs C-mode.
(ffecom_expr_power_integer_): Make a temp var for division, if
necessary.
Handle expanded statement expression as does CFE.
(ffecom_start_progunit_): Disallow temp-var generation in body
of function, since expressions are not prescanned at this level.
(ffecom_sym_transform_): Transform ASSIGN variables as well,
so these are all transformed up front, before code-generation
begins.
(ffecom_arg_ptr_to_const_expr, ffecom_const_expr,
ffecom_ptr_to_const_expr): New functions to transform expressions
only if the results will surely be constants.
(ffecom_arg_ptr_to_expr): Precompute size, for convenience
obtaining temp vars.
(ffecom_expand_let_stmt): Guess at usability of destination
pre-expansion, to provide better prescan preparation (fewer
spurious temp vars).
(ffecom_init_0): Disallow temp-var generation in global scope.
(ffecom_type_expr): New function, returns just the type tree
for the expression.
(start_function): Disallow temp-var generation in parm scope.
(incomplete_type_error): Fix introductory comment.
(poplevel): Update (somewhat) from CFE.
(pushlevel): Update (somewhat) from CFE.
* stc.c (ffestc_R838): Mark ASSIGNed variable as so.
* std.c (ffestd_stmt_pass_, ffestd_R803, ffestd_R804, ffestd_R805,
ffestd_R806): Remember and pass through the ffestw block info
for these (IFTHEN, ELSEIF, ELSE, and ENDIF) statements.
* ste.c (ffeste_end_iterdo_): Now takes ffestw block argument.
(ffeste_io_inlist_): Add prototype.
(ffeste_f2c_*): Macros rewritten, new ones added.
(ffeste_start_block_, ffeste_end_block_, ffeste_start_stmt_,
ffeste_end_stmt_): New macros/functions, depending on whether
checking is enabled, to keep track of symmetry of other ste.c code.
(ffeste_begin_iterdo_, ffeste_end_iterdo_, ffeste_io_impdo_,
ffeste_io_dofio_, ffeste_io_dolio_, ffeste_io_douio_,
ffeste_io_ialist_, ffeste_io_cilist_, ffeste_io_cllist_,
ffeste_icilist_, ffeste_io_inlist_, ffeste_io_olist_,
ffeste_subr_beru_, ffeste_do, ffeste_end_R807, ffeste_R737A,
ffeste_R803, ffeste_R804, ffeste_R805, ffeste_R806, ffeste_R807,
ffeste_R809, ffeste_R810, ffeste_R811, ffeste_R819A, ffeste_R819B,
ffeste_R837, ffeste_R838, ffeste_R839, ffeste_R840, ffeste_R904,
ffeste_R907, ffeste_R909_start, ffeste_R909_item, ffeste_R909_finish,
ffeste_R910_start, ffeste_R910_item, ffeste_R910_finish,
ffeste_R911_start, ffeste_R911_item, ffeste_R911_finish,
ffeste_R923A, ffeste_R1212, ffeste_R1227): Prescan/prepare
all pertinent expressions, update to new com.c interface, etc.
(ffeste_io_impdo_): Relocate.
(ffeste_R834, ffeste_R835, ffeste_R836, ffeste_R1226): Don't
bother calling clear_momentary, nothing was generated.
(ffeste_R842, ffeste_R843): Update to new com.c interface.
(ffeste_R1226): Don't try to stuff error_mark_node's DECL_INITIAL.
(ffeste_terminate_2): When checking enabled, make sure all blocks
and statements have been ended.
* ste.h (ffeste_R803, ffeste_R804, ffeste_R805, ffeste_R806):
These now take ffestw block argument.
(ffeste_terminate_2): When checking enabled, it's a function, not
a macro.
* stw.h (struct _ffestw_): New variable for IFTHEN.
(ffestw_ifthen_fake_else, ffestw_set_ifthen_fake_else): New
accessor macros.
* symbol.c, symbol.h: Support new ASSIGN'ed-to info.
* com.c: Clean up commentary per GNU coding standards.
* bld.h (ffebld_size, ffebld_size_known): Canonize.
Hmm, okay, not bad, hardly *anything* changed there, eh?
Seriously, though, let's assume all that was a nearly *perfect* effort
on my part, in that there were no new bugs introduced -- certainly nothing
that would cause options relating to purely-code-gen issues to interact
unexpectedly with those changes.
Well, let's not make *too* quick an assumption. For example, again,
in *normal* chronological order:
Mon Apr 19 21:36:48 1999 Craig Burley <craig@jcb-sc.com>
* ste.c (ffeste_R819B): Start the loop before expanding
the termination expression.
Sun May 2 16:53:01 1999 Craig Burley <craig@jcb-sc.com>
Fix compile/19990502-1.f:
* ste.c (ffeste_R819B): Don't overwrite tree for temp
variable when expanding the assignment into it.
Okay, so I blew some statement-level issues, hardly a level likely
to interact strongly with -femulate-complex, I would tend to think.
But, surely there were no pertinent changes to COMPLEX code *per se*
since we changed the default, right?
Well, think again:
Sun Apr 25 20:55:10 1999 Craig Burley <craig@jcb-sc.com>
Fix 19990325-0.f and 19990325-1.f:
* com.c (ffecom_possible_partial_overlap_): New function.
(ffecom_expand_let_stmt): Use it to determine whether to assign
to a COMPLEX operand through a temp.
* news.texi: Document fix.
Wow, a whole new function, invoked for assignments to COMPLEX! And
probably 1% of the testing of that new code has been with -femulate-complex,
assuming anybody has been testing g77 with that option since we changed
the default.
But, still, surely, there's little likelihood of a bug still *lurking*
in that big rewrite, which would be exposed by this change? I mean,
if there were newly introduced latent bugs exposed by specific command-
line options, we would have noticed them by now, correct?
Oh, again, I spoke too soon:
Mon Jun 28 10:43:11 1999 Craig Burley <craig@jcb-sc.com>
* com.c (ffecom_prepare_expr_): A COMPLEX intrinsic needs
a temp even if -fno-f2c.
Yup, that's right, a *regression* (IIRC) due to that big rewrite up above,
a bug not noticed (since it didn't occur) until someone tried -fno-f2c.
(-fno-f2c makes simple changes to how COMPLEX values are returned by
functions, mainly. Just like -femulate-complex makes simple changes to
how COMPLEX values are represented to the back end. Well, not as simple
as the changes made by -fno-f2c, ISTR.)
Well, at least there's no worries with regard to *arrays* of COMPLEX,
which surely is the big area of concern. I mean, it's not like there
have been many changes to how g77 handles *arrays* since we changed
the default, have there?
Uh oh:
Fri Apr 23 01:48:28 1999 Craig Burley <craig@jcb-sc.com>
Support new -fsubscript-check and -ff2c-subscript-check options:
* com-rt.def (FFECOM_gfrtRANGE): Describe s_rnge, in libf2c/libF77.
* com.c (ffecom_subscript_check_, ffecom_arrayref_): New functions.
(ffecom_char_args_x_): Use new ffecom_arrayref_ function for
FFEBLD_opARRAYREF case.
Compute character name, array type, and use new
ffecom_subscript_check_ function for FFEBLD_opSUBSTRING case.
(ffecom_expr_): Use new ffecom_arrayref_ function.
(ffecom_ptr_to_expr): Use new ffecom_arrayref_ function.
* g77.texi, news.texi: Document new options.
* top.c, top.h: Support new options.
Thu May 13 12:23:20 1999 Craig Burley <craig@jcb-sc.com>
Fix INTEGER*8 subscripts in array references:
* com.c (ffecom_subscript_check_): Convert low, high, and
element as necessary to make comparison work.
(ffecom_arrayref_): Do more of the work.
Properly handle subscript expr that's wider than int,
if pointers are wider than int.
(ffecom_expr_): Leave more work to ffecom_arrayref_.
(ffecom_init_0): Record sizes of pointers and ints for
convenience.
Use set_sizetype etc. as done by gcc front end.
(ffecom_ptr_to_expr): Leave more work to ffecom_arrayref_.
* expr.c (ffeexpr_finished_): Don't convert INTEGER subscript
expressions in run-time contexts.
(ffeexpr_token_elements_, ffeexpr_token_substring_1_): Cope with
non-default INTEGER subscript expressions.
* news.texi: Announce.
Sigh, well, given what I know about those changes, they should *generally*
not involve much of the new code triggering unless the user does something
outside of "regression" range, i.e. specifies -fbounds-check or uses
an INTEGER*8 subscript. Still, there's *some* changes in there that
at least test for these things....
How about basic math operations, nothing big changed there, right?
Oops:
Tue May 18 03:52:04 1999 Craig Burley <craig@jcb-sc.com>
Support use of back end's improved open-coding of complex divide:
* com.c (ffecom_tree_divide_): Use RDIV_EXPR for complex divide,
instead of run-time call to [cz]_div, if `-Os' option specified.
Okay, let's hope *that* correctly has no effect when -femulate-complex,
at least...presumably if it did, anyone trying any real COMPLEX code
with that option would have stumbled across it already.
Now, that's all work done by *me*, by my lonesome, on g77, in the past
few months since making that change. Pretty much without breaking a
sweat, working 80-hour weeks, or anything like that.
Given that *far* more people have been making *far* more changes in the
gcc back end since that change...
...are you *still* confident that making -femulate-complex the default
at the last moment and running the few g77 tests we can will be sufficient
to avoid any *significant* new regressions as experienced by the field?
I sure as heck am not.
> > Or do we delay the release of 2.95 for a few months, during which we
> > encourage everyone to respin all their testing, using a prerelease we
> > make (which we can do by the end of the day, or thereabouts) with
> > -femulate-complex the default?
>I do not think any of our g77 tests really stress complex anyway -- so I
>suspect that would be mostly a wasted effort.
Right, *our* g77 tests are not worth much (yet), and *mine* aren't worth
much more in a case like this (as they don't involve running, or even
linking, code -- they just make it easy to spot new ICEs and, when changes
are believed to not affect assembly code generation, spot unexpected
occurrences of that).
So a last-minute change followed by a bit of testing (which, I agree,
including LAPACK would be crucial), hardly gives me confidence we won't
discover some *very* embarrassing revelations.
Still, as I say, it's your call. I don't mind the performance hit (since
people are used to -femulate-complex anyway, in official releases) much,
so that's not nearly as important a factor (to me) as minimizing regressions
in 2.95 vis-a-vis EGCS 1.1.2.
tq vm, (burley)
>From ByrneJB@Harte-Lyne.ca Fri Jul 09 13:32:00 1999
From: "James B. Byrne" <ByrneJB@Harte-Lyne.ca>
To: law@cygnus.com
Cc: egcs-bugs@egcs.cygnus.com
Subject: Re: make of egcs2.95-19990629 on HPUX 11.00
Date: Fri, 09 Jul 1999 13:32:00 -0000
Message-id: <199907092029.QAA01107@hahp9k02.harte-lyne.ca>
References: <199907091648.MAA26489@hahp9k02.harte-lyne.ca> <6362.931541004@upchuck.cygnus.com>
X-SW-Source: 1999-07/msg00369.html
Content-length: 602
On 9 Jul 99, at 11:23, Jeffrey A Law wrote:
> These are symptoms of gcc-2.95 not supporting hpux11.
>
Yes. I was aware of that. The same problem occurred in gcc 2.8.1.
However, is it "required" that the builtin functions of egcs/gcc
always be used? Can't the native HP-UX 11 memcmp, memcpy, and memset
be used instead?
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 gram@xiexie.org Fri Jul 09 14:12:00 1999
From: Gilbert Ramirez <gram@xiexie.org>
To: egcs-bugs@egcs.cygnus.com
Subject: C++ bug: pointer to overloaded function
Date: Fri, 09 Jul 1999 14:12:00 -0000
Message-id: <19990709161147.A17687@tivoli.com>
X-SW-Source: 1999-07/msg00370.html
Content-length: 1818
I seem to have found a bug regarding pointers to overloaded
functions that are members of template classes.
I have tried both egcs-2.91.66 and egcs-2.95(19990629), and they both fail
to compile this simple file. The later egcs is more verbose about it.
My platform is Linux 2.2.5 on an i686 machine.
Output from egcs-2.91.66
------------------------
$ gcc -c test.cpp
test.cpp: In method `void tree<char>::func<char>(char, int)':
test.cpp:99: instantiated from here
test.cpp:85: warning: converting from `void (cb<char>::*)(void *)' to `void (*)(void *)'
test.cpp:88: no compatible member functions named `overloaded_template'
test.cpp:89: no compatible member functions named `overloaded_non_template'
Output from egcs-2.95(19990629)
-------------------------------
$ gcc -c test.cpp
test.cpp: In method `void tree<char>::func(char, int)':
test.cpp:99: instantiated from here
test.cpp:85: converting from `void (cb<char>::*)(void *)' to `void (*)(void *)'
test.cpp:88: no matches converting function `overloaded_template' to type `void (*)(char, int)'
test.cpp:31: candidates are: void cb<char>::overloaded_template(char, int)
test.cpp:37: void cb<char>::overloaded_template(char, void *)
test.cpp:89: no matches converting function `overloaded_non_template' to type `void (*)(int)'
test.cpp:44: candidates are: void cb<char>::overloaded_non_template(int)
test.cpp:50: void cb<char>::overloaded_non_template(void *)
In my test.cpp file, I have one template class with some member functions.
In my second class, I try to take a pointer to those functions. The arguments
match, but the compiler can't decide which overloaded function to use.
However, when I take a pointer to an overloaded function that is *not*
a member of a class, (line 92 of test.cpp) it works.
--gilbert
>From jputney@networkmanagementinc.com Fri Jul 09 15:01:00 1999
From: "Putney, Jeff" <jputney@networkmanagementinc.com>
To: "'Gilbert Ramirez'" <gram@xiexie.org>, egcs-bugs@egcs.cygnus.com
Subject: RE: C++ bug: pointer to overloaded function
Date: Fri, 09 Jul 1999 15:01:00 -0000
Message-id: <76EBA0999931D311926C009027557B5634962E@iris.nmsmn.com>
X-SW-Source: 1999-07/msg00371.html
Content-length: 2460
This would seem to work.
template<class T>
void tree<T>::func(T a, int n)
{
/* works, with warning */
void (cb<T>::* ptr_not_overloaded)(void*) = &cb<T>::not_overloaded;
/* these two fail */
void (cb<T>::* ptr_overloaded_template)(T, int) =
&cb<T>::overloaded_template;
void (cb<T>::* ptr_overloaded_non_template)(int) =
&cb<T>::overloaded_non_template;
/* works */
void (*ptr_overloaded_not_class_member)(int) = &f;
val = a;
}
--jeff
-----Original Message-----
From: Gilbert Ramirez [ mailto:gram@xiexie.org ]
Sent: Friday, July 09, 1999 4:12 PM
To: egcs-bugs@egcs.cygnus.com
Subject: C++ bug: pointer to overloaded function
I seem to have found a bug regarding pointers to overloaded
functions that are members of template classes.
I have tried both egcs-2.91.66 and egcs-2.95(19990629), and they both fail
to compile this simple file. The later egcs is more verbose about it.
My platform is Linux 2.2.5 on an i686 machine.
Output from egcs-2.91.66
------------------------
$ gcc -c test.cpp
test.cpp: In method `void tree<char>::func<char>(char, int)':
test.cpp:99: instantiated from here
test.cpp:85: warning: converting from `void (cb<char>::*)(void *)' to `void
(*)(void *)'
test.cpp:88: no compatible member functions named `overloaded_template'
test.cpp:89: no compatible member functions named `overloaded_non_template'
Output from egcs-2.95(19990629)
-------------------------------
$ gcc -c test.cpp
test.cpp: In method `void tree<char>::func(char, int)':
test.cpp:99: instantiated from here
test.cpp:85: converting from `void (cb<char>::*)(void *)' to `void (*)(void
*)'
test.cpp:88: no matches converting function `overloaded_template' to type
`void (*)(char, int)'
test.cpp:31: candidates are: void cb<char>::overloaded_template(char, int)
test.cpp:37: void cb<char>::overloaded_template(char, void
*)
test.cpp:89: no matches converting function `overloaded_non_template' to
type `void (*)(int)'
test.cpp:44: candidates are: void cb<char>::overloaded_non_template(int)
test.cpp:50: void cb<char>::overloaded_non_template(void *)
In my test.cpp file, I have one template class with some member functions.
In my second class, I try to take a pointer to those functions. The
arguments
match, but the compiler can't decide which overloaded function to use.
However, when I take a pointer to an overloaded function that is *not*
a member of a class, (line 92 of test.cpp) it works.
--gilbert
>From bpriest@comspacecorp.com Fri Jul 09 15:21:00 1999
From: Bill Priest <bpriest@comspacecorp.com>
To: egcs-bugs@egcs.cygnus.com
Cc: bpriest@comspacecorp.com
Subject: Re: egcs 2.95 (19990623) ICE w/ c++ on Solaris 5.5.1
Date: Fri, 09 Jul 1999 15:21:00 -0000
Message-id: <199907092219.RAA01211@bandit.comspacecorp.com>
References: <199906242142.QAA02413@bandit.comspacecorp.com>
X-SW-Source: 1999-07/msg00372.html
Content-length: 38391
All,
This previously reported ICE still occurs w/ snapshot 19990629.
Here are the relevent details:
c++ -c -I. -I.. -I../liboctave -I../src -I../libcruft/misc -I../glob -I../glob -DHAVE_CONFIG_H -fno-rtti -fno-exceptions -fno-implicit-templates -g -O2 -Wall DAE.cc
MArray.h:119: Internal compiler error.
MArray.h:119: Please submit a full bug report to `egcs-bugs@egcs.cygnus.com'.
MArray.h:119: See <URL: http://egcs.cygnus.com/faq.html#bugreport > for details.
As per instruction I capture the preprocessed output
c++ -c -I. -I.. -I../liboctave -I../src -I../libcruft/misc -I../glob -I../glob -DHAVE_CONFIG_H -fno-rtti -fno-exceptions -fno-implicit-templates -g -O2 -Wall DAE.cc -E > DAE.ii
Reproduce the problem w/ the pre-processed file
c++ -c -I. -I.. -I../liboctave -I../src -I../libcruft/misc -I../glob -I../glob -DHAVE_CONFIG_H -fno-rtti -fno-exceptions -fno-implicit-templates -g -O2 -Wall DAE.ii
MArray.h:119: Internal compiler error.
MArray.h:119: Please submit a full bug report to `egcs-bugs@egcs.cygnus.com'.
MArray.h:119: See <URL: http://egcs.cygnus.com/faq.html#bugreport > for details.
FYI,
Bill
PS. If the format for the attached file is not acceptable; please recommend
an alternate format.
via anonymous FTP in ftp.andrew.cmu.edu:pub/mpack/
---
Content-Type: application/octet-stream; name="DAE.ii.gz"
Content-Transfer-Encoding: base64
Content-Disposition: inline; filename="DAE.ii.gz"
Content-MD5: LezNdoRWRrTiL4Ga46EFbQ==
H4sICBZ3cjcCA0RBRS5paQDtvft34zaSMPqz9VegOyceSZZsS+1+WbbzZTKZmdyTntlNevbc
e7I5/GiJstktkQpJ+bEd52+/qMIbBPiQJSeZTXanLQL1QqFQKLw/IyPy/C9ffn04nT7vkI77
v89WWXi1DEm8XC2iZZQUYRGnCeYA+uHh0TRN5vHV4fVzMqJUKB0kRfB/xPxH/+n5n8In9QQE
cKdTSjOwFKqWqcgRjxBOYqQOoGOWoDGpbf+P7IRgtcyksQAt6LgV/qRqe1xNEbdqXE3uMzJ+
IxslGct2Bim8hXn/k001KaJsHk4jDfmv62RaR2C6CPOcvAuLLL6b8K+v0sV6mfxXNC3SbKLD
dTjRzqfOan25iKentEgkL7L1tCA07/8Jp/SbkE/4L+FkSX82n93N0mLiSGZpDxMgVNyvolk0
N/iTbp8S/u7v3wPfHulSx5MXBsQ+uRt09uh/jLgTgDIfkFlKZY56E6LzYlIzLvRHPZd6+kCe
K4p0b9J41sMynpL5OiHd496AfACOxz3yiTwYwKqkZG4gzRsiDYgqBvngJvGhTIKViX/uk9BA
DA/pH4EcHtI/NoF9kq6iLITaOvcREyYRz0m3uI5z8uyc7NO8vU8dWnHA6Jwgpwl8Ay/4pn/p
9wPHzaJinSWkD/jcbkCKX0xla8JJvdB/oAcTEEzET4IgcLUKlEdFoLDK9SKKwwSfT6ol1Csl
nKaXcZgENTJByR0yOdDLNS6EY1r8UCncKksLasXR7LSss0lJ9EnnYSL7OupnXhxLLzXmfucy
zKPhLKrzOwg7o82ItaHN/dy7L7MsvNcikcbogkIjAlUiHK3z7GiRTsPF0SK+PLqaTofwN1+F
2XSYr5Nhni7CLM7Hhy8PR5g9Pnz78oiGUfL/42S6WM+io6uDg+H4aEp9bZQVVCLyQsi0LU4e
WCEA44zaIC/IiaYPKsDbp5UA+HNri+6ozhPy/Kvn1Lr5B7QbEgTRKqM1MheOZ3odZqQ/IObX
OsnjqySamemsuQRBWNAO6XJdREFAut0kZS2lR135g2W0L8e/igo+I692aWZjambYnPXWMN6Z
defFjFLwWLeAZUC6IfL4iZiNcUaHJ3vP/0/3s57A2Bsdjl/vURGO3xzRwOr7d98833NyuM+P
5lFIqzoKiigv8jbMLETKk7I8ORqNj45fIcuOZbQdy7U88GK/8JZ7LBtAp0yMxy97PPiivSht
BHs/rSHKwp9ZtKTmS2bxTUCTBDxR8Is0uRII+JtjLASKB4fYiMTAVuiKgGh94DqhxeXx/0Q2
DBJZxzORLv7T88kttFsBwTUiiUPeXhBMAeOHHycaCIvMCI1Q5oaXoA2cQ4BgNDv2ZCNzDrPw
wHAmVFlFOrOdEf51EUTwhRt8ABAKRxbURF7XYOtFzMJkxuKNieFFc8zQq6k3McwOofrUB1BH
0GXVN+DVaJGaZ1HUZeBWTn+po9uZWcRy2ZdG3AALL9OssErA6iW6i1kGjeV7DMJigRCGRpmm
rqIiSm4qDIM6iiJa2gCm+Jd5RP3hNQcShTC/TL0NsJ2itH4kuww/5aL8jyBoKO4yN3WCzRf+
hWTLAqXhLQANvrQ8hgh/MGdAeL7ObXlZpLfTLm/G5W7aNg2Gs4iSbj3cLY0jl5ddAcJ5aAIw
JEovByHy5lJwRIoDHPKuGWJoZJTNlp3PDJrYyRvLdnlmxDNlC8yvaT2XPNCHWjCs5AUV7Kqe
2sIpEWYt/VlJrQx2Th5FDYTOOV3TqqBiV+uK9slwo+JjdF9qoCUHlt+Gl05nOXC4PCxt+Opk
UeEZZuvV2NFOGGg0vSm6rIIxH//hvHRCDHreCvonJI4iNseZb4Bz5caxlSE96fR21vW1Iwm0
SK/ixOHFaVa6KroaB6Z6q4WWkPL1JeDJjs/GtXtflkBRwuzKoEWT4oQOEujfKMvwL/3/cgFW
NHLuVoq0uu1iMONVVam6XYTinA5N7l2d1uLVSWi1Fd7JRrSbpQ3N20sz/OVH2qWtum7hoC9e
hcV112wlNhgVLQmXkSkeiE0z8kVauCKN/o07CGAUV0XupkiuqHsoVoUjZ51Qeh9lltl+WSOm
EdaiKrJj/8hOjVg9m+jaZN9GVAdnwfLKWRQpjc10WD9fFgFuEgIq9HVDfJa6FvKVyQ1M9/kZ
Gb9+5R2g8OHJww5HqGKoyEao5SkY8lyA6EOkgwM2SOp04mQRJxErHyGygu96e3tyqu2OXJyT
Y/IF/XFKhnds2o0WC5aIYFA8NgfFfJI8nt0FN2KKXM4b4Q9oWQsakZIzBvr+guMgGZg8z+Ib
mn/K1qKIlvldtOqwCTxtgp2Q96Q/C4uQzdphABYl6mOarpNiwiAFFdecrMoLexY46QIL1gks
elQPwI50Z70BsCLdRW/A2JDuSM6w6uhsElPgHQu84zo8YJgoxCS6pYX9IflREEjqCJSLxqc7
LZLhIaUnyeKXTlpMRMOKA3peqrbjCf1zhrom8cFBr4NLDED1h/hHnJ/mv3GOGtn+YmvkE5lF
CzrAID/8iJgTUQJei1fFtWcGGNly4Pf7hFJZSnVJIBQg+VEBmnAWSRtaDSkYRpf2mUvaWCO5
BOIeQnANU42dnnJ0II26ZR1OOqcWhfpl9MQcNEzls8UepLUMP0bBOol/Wkf6Uom+WJBFq+EF
q6YLIutpOFTpuGJAP2mNQF2rGqD92Kon1w/ATRGt2ZJ+zJafcJAR3gW054+nUS6SAFK0LGua
XLIADhOZYjYioyQu8SjkAv0sL+zsDm2Of2oS0eTRREExqRisnMZX3oKLUtamS4Zt8ZdsmeHV
8k12w1gYKm0vNM7o6VWj+Ymz9xeldSkmZHiIFSqTuIUdHChpTfHCQ8tyHKJapdQWrvSqUrKi
eB7vzUVHYHT94SqcxsW9x4dgEYSX6U2w+dU6njISiAz/ULXeuf0Q4rCshPN5b8G6uOgYyET8
jzGbXkfTjzqRkndIqH8+Jj//TBLoxE3Jqa8QvMLkKgpoRA/e/TklLHR5eipZPB+QRLqpaJFH
3NMYLqrHfQ2LG6T0mosp+WpDZJuYsTCn0RP+itOTxtDtlVVv6BD1XlIb0/12lNdQd94y1fVR
d2Z5GIJLARaerQbsX7IIOiOBMnEmu3wGT2FRV1Uz0bp0Ck2jh4KqCzoYd6vetK/12Y/uqTht
1eNWr0m/NytWHz3MpwnrxISWJ8wMmyBMlPJhvVr3lljsZQymazrRZcxViGjTRRRmkBvd6UqU
JHkO46+6830SK7eIMNwHu2tP9e6MtR4XXAGX2Z0fUxd3Gd5fRgEL8oKIbZeDspYFE2YAZibj
HTOHl81EFnWAa+/22OLb9wM+fviODjNwRjeHQR3pMqLfgtktrnNhViz1O0jNrvOeuZpvLKeP
zWWY0piGiL1DiGGIBiswMI4HqHfK+juyGR/QXk3LCLU2iDK1IDXcHimfVFra5Zaka0lSF1KY
/iMKrQu4XXL97ZI72i45qTtAdVRFuKHutkOuv11yR9slV2l3m5vzcKtk6TBtBkvV26QJK91x
lBRPWH7Wi1ZMJDFgcspniWQHgnNL+kj1nWNgStGkIGwQyuZVxBgSQ/B3+tjEwGDQCkLO4CiQ
xAljBVomxoClIZqG6NCNgRfKOaFfTIl56ruqEdU772hQxbg6Vtir2eeH45Z5Rq1l5uRMO5iz
C1LZX1XiD+vxHymFZcgbS2M3CI9UmlCMVq23r6Ix3AKN/hZoHDWk0VIrFX68sVY2pNHfAo2j
hjS2YCtl63uE0TQgJrqddpQchGRf8xQF7IndvNr6XOcqi1dRkKQJnPBJs2WoOj6xajrgS6Wj
AKd72ccYPrDf+oyM3oy1gYS9X9jc9DsWm/+Wd8NZNM/rNgIT35EFOKp0ZyaCwCLFebTBwLVO
PfBBVXrrBNbSecZf4vDKKZOeIdaBvv6PP3/57Zf/+OprC1bP4Dl/Kyd99fd/fmsLj0lClK/f
2zJACk/6+pu/yd9///r77y1QlsTTvv/q7//6zgLgaQLiv/5i50MKT/r2X1YmJPCU/7QJQwJb
QEODSKfFcEoz7hptJd/+0iMTytiluiNWeTET7MTOa30HavmH/NaPFD3h9vRlWFz/GpvTg78F
2sFDtlOXlLeKyv/YdlOKRX+8CQpzp3e3GwTLdAa/guA/vwmCHuyNc29ZpSTW7WmYcjAxRq8q
afy9Ug4uRlsaLjlejCtpfN9EjrY0XHK8Oqmk8ZcmcjSl0QkC6OoohTQJAmLsLMZ/KL0F/Jh4
IB3bL0AEjuPcsQwmC/tTYNOymwyFmEU3er5Inq/S3JV+xXZJe8nFSVqZj5qpAoBNEx9dnNP5
3JW8ktu2RQ6vnVWRzWITR7ZJyhOmc008u3rFTnGbYxEvnelrUzVywyrNMvaOOzaYC442S1uk
W/pXz2cT9ZBzEwaLOC9zeJx/1PbdUHbK88l46HEnc8rkOXGijiwwJq9GW2ei0XcEeuoMN5yT
2Al3Rvvt8W7Ux+mPX29fdjgz/GJnGnkxer19jfhCuM/Im1dPHj2MpR5f7S5Cwl1r22j7QM5s
+eXjTCYM8ZwbchxlYoh7lDUemhofHb9+brdE5QzhzGlwTX3dAmfL9qzOI/5hDNuh+L72YAZn
ghi4tjWTjSc5lSC4Xl9FAsLnEPTjGJTfVbicSMgoWS/JTZRBb00+Ub0ugziKInJOhiM6Yg7i
PF9HwcmAhFTWgCblNFCYFgF8PpTEMqhRh34Z8A/GkB+GovEFVRuNEqbRCs/h8iNYGCtQBbDB
Msz8Km2E2dXI+BqrrywqUAMPk07Vf6R8qGma5nR4zw+fE2IfLQjzOKnML8La/LEEkKfcy4A1
ctSIUZKiTP26hvx1Df3rSgbR3aoKf57pAGK3fBluMSvBuaDSqypmNHt0XAVAI7h5qU64PBbo
Kr1tUnv5T1lRXQFRvKhUUHhZWf/zRZpmlQC0UG5JnXZPx7hV1Gj2tCqfOhDqBSsAru9XaVGp
ObZBP6luPh8q6/HDqDIXKOPZAL+l1JbjvlKA+0oB7l0CeL3QdZ0buq7zM5UA00vbQkuN5rIq
P6Gf4ZymNGkOWbQMYTNGI+CcduuXHtN1GO7daunWOhpUXTHAN1R6qgxHWF1vjbHtrsV1lEHh
vN1Z3yc/dL/xPJ6GycxiU4adpqt73I3SVIuJw3Vq0YDGgfqTsEBHCH4AvwY8kYteDpEwO06u
Viml7T3t3SBksgjR2OmEvD05On51dPz2uRb7OwaAWngcp24ZiH3hhHHGHbD2Rocv3kK0BufN
T8QRd88Zdz4sdcSGDgYSmLJ4tfeWFmh0NBYn2kk5IJNKIic1vHnkag6bg9KgWZyLf+PTlzwW
b0lQPk0u5k8cQSVxD0Rch10YV/0ofpv/zDP0e6TDRMUj+nvBNCkmNG3PPMPeh3kTSC9nwO0q
DoxgvgivnOnxAuEfyF+/+fZrLdaFTypAEKeXP4yPiXFcnuX1g0WYF5fr+cR90p4Ks55HyawI
L/G0vROIBHlMwX74cUB/pfhrYsXzcHNAehP5j9NRADwU5r/fQ4Gj6P1iuYKCW+fPmNQ0j1Lr
6secNFbz6SLNoy6QsaWYzxfr/LqUxTjO01XpkHKVhDScrMEYEJsTlGYvj6BKuBTOQ4MAclOG
4acM5bk7YpSN3aGiUAxBDg8PSwjUWyct4Dn9WjhGth5M0HMqzoXgIuzC0nBuqrUiXZeF5Syq
D7i6IB6sOZyzLRkiM2/IUyfUscqdxrxaUxKV2Xm32hwBzimIyKB4zhaoSWgiVcsEuUDSPgG6
V5LVzF4nKKWTLmsNe7Q1hjPfrQpepNssLqJu5RUPbuXC8eA0l2bFuqkSVB5FHyUMO5tZKjoF
MkgxYcoEWXdYRItF1+lVsuiWRrvuPNyPTYNFt1OM0rknA7aJuymuWJ7nPg3ADqDjUj7MJE0z
FzlkmlVqRW/cz87QzbID1k4TYTY5pb+X8cxpltCVJKkSRU6Ij1+cVIcLpCzQqnFHwQVb51Hm
EIx3ZhHvzRrQ482y4QF7C6vxCXtTvvIR+72aI/ac323X4wJuKxyE1XezHScv3jSpo6r/KJG3
49q48EHwqxtzqJlnV8AME5fzVTlWd4TqApSOPl7D6GM0YqMP571TOKs5XwWzOIvw4sAAIlPy
CWJGmpxAG8+LvXNyPMCEIv2fKEvp94h9U5cSF/FNRFPGA45yFfKUFzhtKVisKIc4L7HABdVZ
NFM8cqqWRaR4sIGf4qAIvSgxkSNVk0lMR/nhVCvHLL5BEorLGob1tFZuFSMafoqUFwNO5yZc
xCDricG2yELKOwmpnCZjzChxx9SyCJjskAPTy8Jw2qZEsGxSbUDSzMbjBnCihLglR5SNFw5N
Qau39WUCW8MWqkTyeyz0N48TOJdIiCrHT+s4AuWciOq/SmiRaM90Tl6yMolG9LJpI3It4lK6
81UUTHGVG2bjYSRlDDu7fQ5zHSazRZQhWK/bQ0jNZTugeBrMnFhsBi5wNYEhBGBTFMz0J3t7
e87Vb9FWfnjx48TeUcCnS35ah7NsvVqYxZMUjCYyj6PFLOArE3BTrhoCC0T04DPa3mg1BrA+
klz98HI0pgPDPYFSvg7OYTPzFX7wS+hAGP4zululSYSntU02ZJYzvSPYMs1ALeKb7CWz+Cou
OMiDFJG6hjSbiZYpUmHHIgg2j++iGX4NOC1hQZiIaQ+TqiJZfpKyEnrYK3OczdloHbe5C3lx
1C3AYMuFLSwrPpcZCPMmruTeu72mIWa+CqcRTySibLAJQcHJtFla2JA0aZ6FUweBco5QkqJO
9sxkk4HIqKRkZGIx55rowlNoSQncb6t/aZpCtVqXr7HGRLusgKsWWyekQWyiV4H+zSyIpmC9
etqLucaD3Fj7M7mJBZjtcxOewOQnUh0ckX6JK2nOUToWk6VM3hZPU6kcmbLkNbfTKlTceM3t
sgo1brLedluFGkdVbbuuQt5IDaPRbyHi/7i16XWM2uDCLiVcgb07dgxQXKiI8xjGVWmQCuPx
slix3XS2L5YY76tVaPOGp5ySTWgcWRjNqHTbm5w/1MrACcwfS+CqioAfTxPce0mdH3v+KOwr
P7Yf6SdNYqOBtWD803wLNK5qaBio5ZsKq1TmUnRbjCsHhi4Qcd/XS8zTJ651Q7xwlxDPlbts
AZQPLMajsWfX1Lg0kn+5tV1b+mDlM/J6x/vN3LekIUD5jjQ61nqzO3leqBvY2LAHbmDji7WE
3GmXmODuke4du72DowgrgBz+24sCeh3ttCD6TXK6ZHqCVzx5l9zJExwf4VagbqqjLSSC/XLs
MxWfti3Yp42Dv377/oJfLsHpT3xALPsMv/Y7cKf+LA1XC3Ydiczpk0LdRGHikKzXjvgy3iXx
XUo+u2lJ3E29Y9SM9iQPEWmkC4AEzi4fDxCJXWvXO6VGSroZBDRwD484rc3RzKPCXUOsfTy3
WAYcNgXsNwU8cgOyEkU0ruo6buRhN0+xki7DKwdMvAQYeQGjJAiq0A9SSoG4JZ9dyErTZst1
yZyIy3hTxE05zm7qEPH+PdN6ztAlX0ysVObWSsmay7vwWif3l1YT2MQvdGCfMQUYXlCrpRaZ
HdKKFknUgDEJak8/l5/D2x1tJDM+tXP/pSZgCcZZyoLBlQADbLYPG6impVczVDMsq2a4U9UM
W6gGCvZI1WxgNdi459TnCR31UUVkKDXUlwoSKSYw2JcBrCk4i8TbTztQbr+Nch9jdz4BjloI
AF1avQCECwAfHeafnQxoGGW/yYNwPW9f2JyyLvrdIe8kGorMup1diFxJ2RSZ9331Iht0HPf4
2Hw8Lel+45JtTQBdAUYm3A4L2qDaP+BBwT0GNVCrmMh+3vd2oi/0Lk+pH86wmT7ulSIeVXpk
+pTWUcOwovR3DjN4TN0Pf+22MtxJWxm62spwt/raTVsZbqWtDLfTVoZP3VaGj2sruhlso/b7
v3Zr6e+ktfSlmqSWMFUoDGfk8U4wiSCyZAdkkNmJhnfTvvpbaV99vX3B16M08LRtrP+4NtbX
2tidZhlVGvBIcrT9yt+YU5NaPzJq/egxtX6w9ai7NSMjCN9+B/lkHWNV1Q1F3dH+oEV3eJmm
C8X5/PzJuoFHM9Z1Ie32/Fw5/P19ZcE0XbTeberkkY67NSNfme/twh5vUsodOefWjIzm6q7S
+81K+ezXsu9nW7LvZ5oyfv5ZVfmzze372VPZ97MN7fsZ2LdV2I1q/kns+1lb+3ZW6b1WSqLv
CTcOuJfO5T5mGguXPHcxP1ZFWFcFL5Pqx1p0Y4xRtqNJySrCegnYdRtdIfdA2nDr6GkFy8hi
CZA3j2JLcYabdlVUSGNfuCCkW0CR6AdcB9It2peKivvBX0PbKV01jwaxb7v4Ce0DNtDvxvIq
KTu9ZZ9o04ilEe9dj7uURoMKQuqGFW4fV1Hm9mwhbUds0Kh3Rfl6R6ThiprdUIaLbXZDGe6x
eUr7qeAHf3dJHy++2Ab5Hdo9+u9dUd6V3eMlR21J+1ws20al7Vi5oD2ASB3Y9H0ipiUyZ2ek
m2pkHMJO2IYysssLieecp/NC4k2vJCbPBVnHXkTXjhT3tia2gZDva2IflRubqL+jJOJCUTDV
yveysN1W9eD6/he+Q8uxg6m8d4qCqo1I5Q0j7j1YwwZkjM0VbjL9JmTqpTlqQMbYDMAexuAV
Vr1ti1dkw31bguT/oo1bWinNuJV4JzBxZMxUdc+fOBEalXYKbCnUPa/zeg6Mnj043d8Wh2H7
Mgxbc2hbhpYc+u3L0G/NoW0ZWnI4al+Go9Yc2pahmgPMoxD/bGiDEpyft2TQtgCtGDzboATP
2jJoWwKLAewnlfvb3756qg3uu4t8ZruJfGZNIx8eWbhDH3HJH4t9+FeTXd12EMPiK+i+OZ7Y
WcbxM7E5rmkQ9UdU1DYqkndNVoZFoo4bxkWS6B+BUW1gJK453VpkJM4BPWloVFOK9rFR61Js
IziqKUX76Kh1KbYRHtWUon181LoUjw+QasrQOkJqXYQthEg1ZWgdI7UugyNIsvffsx749LR+
UqJT10V3oItWQdjr338QtthRFLZoHIbp8Yw7FtOPfvKATE96kqis3ngaEfojVKsO1Yyqro7X
DBNoGLSZ5P+I3GojN11h2wvfjLPcTxrDNSlP+0Bus/JsI5prUp72Id1m5dlGXNekPO2Du83K
8/gIr0lpWod5mxVmC7Fek9K0Dvg2K83joz57FqVZ6Gcz4QS2zEUFmG+e7hqLHV2YIl53ZVys
QBBCSHkxolFvbO41UNdhWFBcp+KSOC+cXgFowIGNwS41Gb+yHsId63c2Wky/Erjai8uvx8bT
yuP6W0E0Btz+u/1ZMAvehStq5T3x4sfEBTWVUMzevlI9vYD+Slhkf1oF3jGejR67no0uv+hM
TgkL08U71yp8F/GJ8Xa0kag/6SyCfdrKDfrsHjDKxqQPIR4Lx01ovA/SBZ5UwMvB6024cOIO
WI6LgPHIt2zfoYtMWEVBT6vGtwho+xjOfcSY6+ywp2BNstrx83NgMeFQ6nx9nLM05Ozr60ri
Y/KkhPGsFkM8Rm/mx0keqZ0kFi67AYvPf5t583ixkHMJUImTWhBObcT/jstkSV6E048NCiIN
nBRZmOSrNI+EQSsg3iQMBvrpdMdj6ewpeTeqfhbfi+pSMlx8mYXTgjUKrfzVNeO4tsMlqgdp
WIEk+LlKWY6FmYdBa3ARvGxNUL0i34ioQW0ZrqhJSRdO5roSrZKuVot7C3iirVUsYduXYTMq
K7wrm5NewuqtTjTbXSzDuKp3XREYszuqTo60S+5O3Po5Y/bldLg0j7vbB6Nrhb4Z3uOhnSvv
knA6bMaqqe7Vev977Yz/WBAgLfAFiWYUmhCpoUG18PJEgep99okuhlAODcRo4DbN1vPiaBnn
UxrUDfE1iFp1WZfa6zduUoo0RgpvomAeFtpFGuymwmXB3nYp7fAL4NZy7FjgfXAyKV0Sruii
iOJi7x5xPlADwovnNtyIZLrOsigpAk++faFq5IWk4xNPBjZXdoWhqoqXVlWIEHB2F9yIkMex
n1veMcaQVXTFGsh7nBbN0oKSiGbYuDhg971sUQn7s4SGJdCwSSX9pRkJzEa0z09Ejz8b06+l
+AJVUP8SxMksnkY56Y57MgzQYjUi/9dhj8zPRhPxazzRBRRxnBLJIcyxIcxxE2EUB3/ht1Zy
NzPhRd/viwjSYM2ixy3zZxzZ19l7EXIqvqGDYXjIakfypAnjjdkyrlU2F26r0L+YRvRJlwnF
KIfAhmYMMeI5m2uGWHQ/hNOJWbSCj5COxVe9zt6nzh6RpSjHx3uGNvcMVe6hYBXxMzaMeDky
+m01q0Ep4giBg419YOOJIpelt3kDctN0kVeSk2C0s87rGGN7p/Z+Fy2iJWsNMbOBD9rcvlIi
h5uN+h8OYj4h9N6NbbGsomE7ICrQ9DqafnSQLZlATM7IMZzd+yB+xOTiHKoW0+DnWBgDHTlX
9yM9gKJwz6kE0vJOTzVhPqcO+PMZLA2FyRU8lkuxnw9Avg/MpuiYoqCO/j2ZpykmiFtN8fOB
Sx4t8qizV1KNqRllblSchhVU1m2HE5D2T4fcPjqcCRYGcaF2fVXBavipKmTT+uAle483f22s
f9LKwn2VUFUHFjFnTWAZmYKsUG3KPbdFb8KqvgUe9vUYRGURPMVmdceTqlyr/5xYzt0c++uO
nQ9R2Z8pX9xCNsvw/jIKZlQbNPQEnVBboU5NxV/7KLr2+cHiC6KsxXDdyoJ3iu8savoYrBrS
5isRHxxHX/A4EZstw/sEC0J/w/u+Xc4EjxUu1LWMPPk7vDfwOu8ZA6gX5mBnbD6c6gtGOYYh
HQTu8EYohRL5WCcdYz7gnVlbsprzXktiw20S80qmJ15uTcTWVInjepRHFZ44rinZFsH+tgke
bZug1CHguiol3FSH2yLY3zbBo20TrLbDx1j4cNuU6fh4Bk9LbZnsT+u0iKOkeGJFsE6t3jlb
UwVj11zBuwaTBWM5WzCA1E/WeP+dczjPkMTyxrvKATmDVdQ98J4xtcI21mTeNRgWj/mY1I3y
rh4HBqLvnCPRd5VD0Xf+sagWm7ZahtEneZ3MaRd3dkGq+8xqCsMGFB4tid1eHiFSqen5ZNP3
HyG5+t6mkspwK1T6W6Fy1JRKW+1U9SPNtbMxlf5WqBw1pbIV22lg222MyGHfZXqi79uGbLLD
24pkDUrKH0owpuQ7V1m8ioIkTSgCPMwVqh6YDUXTFesx0tUoSDLt9xSuCWWzC5g01rLpbzZc
/IyM3oz1MZExWjo21pbEiso7WBl8/IpRcyrbWHqikG+PNVhr3cgU5nFrR5+Rk5NqXGulpMTc
vVri/j9/ZKTIetZR1BLle3IV8YXvuGr+Uk47iuUizZvIrQNIwYFKe3YKwwkwEf8jS+/uOywe
0FdVWAbpqiJAG+pn0dya8uBhwimJ2Y53uEWJ/kkvP0RTvJZrjkEKYVSZrEjbFaiIWEvNz4Fk
e2xy7vwcZlH3MEVM2TE2fK6NcK7DC9QLUwebS3vo7LGJszYzd/xtVj7fARM4pEhJOp8PZ1Qr
aRIuqA6I/B2Cmp5Do94rB00ibFKFfi83iZsF5ZqDOwtVkcWeQ14+ZitQNFEqrhN9Dpd0j1nh
rZlcQh50kXQr5DPZ8l/88x5cHBN6X9/Y3uUhaLdLjkmPfEH/PSXdIIgoxaSgJXn+eX76+fqU
zMN4EaEaowwelST/9/P8T/+dPB9QUaymN6D83r6FP8+PnxNqR8c9Auu0ogQwcOiRYzH1zqx9
In9+YD0nsayWqQ3zwL8bW8DQFnG/gD5QwYFAJhYSkynias1ZG8DIlmCvdmbkjEypWmCL2tSM
uhOw+UxYRjKlX9OW6566MHUrm8ju2GDXcGVT5+Iv7A5K6mddtdZpCOJY9dyONKUlyMpFR+SJ
rMLDRZRcFdc4ob8ZU8OwG3EODxOzwDShYZl/KdvYJ1swz4izJGfFAmijBU+tLHtGQWoWPCG8
sqOLToN1UMqoyToolaDROqhOrmIdlJFrsg7KGXdER61Wecye+ZOpHN6r85NOA1yykPXNMq1F
Mzc5qMFMrJJNxY8M1shoTWEa/Jw2Xy6j3YW+EGYsgXGpj6XI7tWwBoUrLWP97ov3wGNec6lP
+Wm1muatWR3GryB7h5+59q4tgVnr6i4CW1yme8Ri20N5Zco9CnnE7jzwPy+s4Z2+xb3MsdF6
mMLyT/GaPthafLIdtBxKWxlVc8g+BsOdMHCu+Pi41CzS+Agf7Yqwe32l1Es2JOxaFWmhb9KW
y3ATLg2Z2Islu7QbfznqFzlcY3mzJKXFjvrxgikoDhrAr5uLHjgae+eK9y10ubBQFbVbOIpf
BV455HZQMZdDauNli0JYgekKelugv2uOjwss3qj3XW3Y+6467jVyWy64SOB3Ro2XdzJp+ZTU
DeyNhmnHhFYQzDkc9/j0Mh8y0yEJwajmDKLqL+DXqRjwwn9zcUgJrzaYENgkRXHoj4ODHsYm
lMXhndz1g7NM+ufEis8Zhm8pyepTiGMZp5WHaEJ5uCFlv+C+VZWaXqWW2lEbaptIWNs9VdE0
aquRpO7OqQH54abkq6i71i62Qbqp2DIkhajx5Ss7OLSDVXNhgEWq2rHPitnxN690SJ3sCzfZ
WViEQyr1Td2Rjd1cDjNdxMu4yLVLYR7HSVBnZPltM+QECRNxDHUbDPL73MVjt+JT0qOTLRIH
0obEfv7qah59ODSjo7G95/+n+1lPYOyNDsdv996+OjoeHY1G5Pt33zzfc7KgCjyK8zCQRq3r
0MVBAVMer/fenhyNjo/Gr5BFp2p9axf/WeeXlNxkPKorKdO6wHAKTko/HnhFnXhraiyq05Kt
iWbIxpnV5dD/24OHFUspmCZ/NOaqVwKevg+olmEZFwKa3mSvLJVBT2hz9HqLrUlWwKNuOXA6
GEEaRN6JxEw96h/lLEtVQQwQS8HEZRykylg+I6922a+wGyHY8U6jr1Mdazi9HsbJPP11esCc
dsnJlegAd8lndnQZMm5bvYVtd7EBFZn6zK3HBoys6nPKLleZrdYMqKFuk7fRCxC/YyVeVyjO
t8IQblVks3g+D4qJo/EJzb15vXX5rUYO7ezNTpiYRV4nsG4fzbDs5Jb+K0ouHtJ4MdpFYYmn
Z9yRExMNQDgx2NCyc8ew46sgKaNQxZYbuSDiugrSpG0GaeweIHsGEPZ40dEhRYKhIVNAAIkB
I4PzLvJ2HgAmLJcmTfgWCviH78zA5QpxgEYC7pPpSF44pSWOxZ1TUzjvOeWnJDkpvNck+knf
jNaMmNhLAUSBaq9MNok2Jvusiu6ieJS4ZyWqEoNE8CqXtnVK5nQBAydRdUniHNaLVBWQUMM9
ZjxIR53s5LhsZXZJjbusoT7JyyWhieMBgbWsAC4GMqbqeGo8Meba1DxbMiEHB3GP7QuCKslH
P8Q/Umpj+qenbwwCvRqZ5AsyHJFTMrKn347FzBvf5sPLxUURGxTKhXBKvtB3ktxex3AlFMjZ
zw8OBrxGQM6Dg4U1valPANpVCc8Gru615tFasajICUmGwwmh7EV7oxpKmIaSH+351nxUKdEy
vYkeI5FmZ5T5pK0BiBKEWhU3RuKGEepIzUrN9hdWFnofZv43qYWpXxaYBau+sWxHseQUSuQJ
JQUowrSZ9OAIe6PD0ds9yv94dDR+I+c8yrMEpaErzr7n4SJZL9nA1c5YXYeujGlSZAtXxiy+
igtXxlUWrq5dGYv0NspcGbjXz5mxTqbODFo908iVsYa7h1wZdx55i9QjVpHqtMqazKdx7MLy
ZAReRkGJE8+UoSe0k70gQBv44cdJoxkLfQKvZHU8yHzYYUDJW4GIJ0fHL3cf5e0wnpyag2d7
+KzieG3Q26hhCwxo2a+xZb9p2bIxGuwvo+V0dd9lH8LBii/mWpXZSRTokRrisHMKVFxgI24w
0o8wOEATH6xGvkw/LJrT98A66OPmH6qk5aprFrS62IAGQkm0atEEeLpYtIFPqumXxeKdJUW9
m2fLpjpQpnKdWVqgglTVuYQXtA03pqSZ5qukUcEl6dVl9rEdRnNpWgtD/78dQpF+9Bmrq4nS
WKjbTOO4xa/rKReNsLsNuE39HsFkbvgTKcJsverW6Yt2UKEjPJjPc45aysIWnkctG1RSj2OW
B/q/t17vbHaAr3fZYYge8O3JLrnwK49Hx6+eqJutmMw4g4+L0pyGNqXxtHMZ5FeezACyz379
uYzjMvfK+Qu46BCjOHJARr0fSEh+pJo8HsE5nYkx2NvOfIbgyzppGOINECwxC9h0kkGOCNFd
UnIePT1iokDVhATrERaIecXfxnSAjy8jWM94wxG5jy2SQxqCKYy9YfvJ2907I+qK8Hr5z8iL
V081Zf3IjR1+buGCUlPz1U+1LLgIYD07vvJzNpcidvV/nYr0UpJUycmbnSvlhW+I/frX4m3d
pfvi5EnkoJxOfgsl1izFnQOrcq9+G4JKWWFZdJc+Q757sSsnUeGdSJ2j2KH/ivmEbgPv5bx/
YGebLahMl+t5E6fqkguXjKzpn92ISrHjtJnvd/iely93KRLzOq9e75qH15BhTHXyVNwrtO/M
4WOw4Jt/Bh/Wy1VQTCDck2l//ebbryc8Wnn9VIWAUNG4Dx0koUw/yh0jxBB8GWYfowxHi+XU
fpDQBjDplIpFc3LauCZiZZXwA6/BKs1hZWd8vGuTgRjXFuqTkGK+CK/yCdtoqG73hbi5j9DU
N8yCVZHB9sFSepTMnOnwZoCdcZvFRVSR4+DBMhxMqD6dlCBdgossWgE0K4dDqohjZVyG04/r
lchyIAFBsShernX2I590nDVPScXJpCOVHdMBXiruWQguFx9h4MLOZZLgb0EKu5XoL/qXDlV4
OogkF1jy6zSjmNN1FrAT0xMhcLBO1nk0U98ISjXyw+jHiXTSbKfnxNM0QepgtVjnaibPkYlf
dLgRJ8FA/E7XhfqIsiyQLUi0MEap84mVNOcjNtLtg8X06I+S9gZyDlBDoJCTEgk0FA8NczbR
SWlOmyIjlEfRRw8dWT1sDpchQzV2+9NFmrvZI9gDJkzT9GMcBXEazGGtMKZioZ8hegVwILCT
zieHRUEG1rBWqJsivGSp7JvRwKL52BL907oFynp+Ag2V2hat1PkivaWFtEpnwjWAoUP/Miml
VN+OZkSm8FdRMTVQA1p/JS40d7VGQMZ0OiD1GPMonTciPWdXNDtBS2JQk5pit0KbrxuD2FPi
yANQoL696lSg66QWWIpeZPd+4CrF38zzaZjMrWoz57VpI7kJg0Wc82biluFmzu/MaUhKp6E3
fFRvOEvKllRu6Bq6hp1Ta7LRdVehEdBVovkMpEKrmPoGi47pMJSB+2nQzzINDqQ3kFL9Z1Ek
+rGQulNXvfIFhB1NPWkjCBzcPVRG585HqcXeF9pPmbtf+M1Fkom+q0B0LqrvZGD0Y6JnCk2z
XIy89GxpUSyfd8qljbXsUEUwXxYsaipDsJ43gIFeWERa3EVTqFePFrO884nfNyULBBFikYkY
UZSbRjQFc+M8WriNZ8U1+1YyiACOUcTgAMOMhQDkotBwgElkpUZ302jFuwHJaZVF0ziniXw3
HWsRAd74lUMFPUwcg4/xya5N64W6qY62FHkuXVMui2vTXJ1WPu/CZ4+HdoAnlvt4snYTnD4g
0FSs6lsHwM01qaZVPYNyT5bpzJGjWxjeeZKsl9Ads/r41Nm7StPZZVzABjcy6OzRLol9jeAL
7hZjn2P4vAw56Ale9SXpAfsA+OMta4nApkGawARmgAY/Vyv68w38pMaKdw2NXsFXkk6prAj4
YswSsmi1gJ3F5+QV4l4y4uM3cIcZfobZPU8xJAL3FsxiOnoil9HVAN6JGtCc2YOpIRMWftC/
E+2SNgT4RPKP8eo2pyrCctH0RTQv6CcVk2Tx1TX8PmE+k3qacHGOq0EMdBZNAZJ+knSKgPDz
OrpDIAFF29ItjAkQFAAgYZVSgoghwHA/1JTBUWQFmDNESW4KV3vG83jK0AFwHt9FM44n6SUx
xOwcGcnRQDvlSMfo+ABO1+0nVD2VAdvAOS3fAS3YAS0RWAy85ooZtFqUFAfIHGp/9mGdSwBQ
4wEq8ECojm1SZMskr18/RRM3nCD1geXX5dEz8k29BqT84JczyG8YyZ0zNPj3HC+GFOtuNE9e
sUd0TwqO1MEd/Stnr0Py30l0O4erkvhnupjNqWo5Fv6BKwgokJQAQCaMnvI68K+LOboi4oSW
n5R6wFRALUAkUi6QiLIwIuwvkybQVcJBBRs8TSM6BYdMqsNwIuClRtHtCsWxhrKUE7gfnYT6
DVdFmPA9oDORl0QBdkkXdOg8V6pwqeESFv+lGjp7XA8/8wtDFXEArKc/UHnLMP/YlB0tHP+1
T35hiD/jPZ70Gz9rJaG6MWRpw33/nDH1MYFKw5DDUd8sFCkBwi/e8LCro+0KGHNo9peYOpZt
r6OFGkFxnaW3AXR260xv/g8a0HQRhVlXBDLs33O4QJMWPxCfPLAiX3CAU/b3Z9ZxTthRAw69
r0dDvZIQorjiJlrJGtQJReZkqBFByqNoI1IdA/D67VlAxUCI4ahVrrRzeR4EgWkA4oXdhwjo
9JTFKDoSsK3A6iIaq4Sf8TcPbAwxaX4dZ16PAokrLJsxBXqQZc8h7qkAtffL0LwQX7B7cfo9
vPCV/ewOR4aogtQzHxVbRFVVDim1oFw3DA1Hkklg7ofZvMqmhs8yWhuhOTDpU03SP0494nhF
9IE2gjG06aljNFpyivGGJCQaKiRNWNuGe0MlQwquySf38uT3yZT6leIa5yNT9EBpwo9a6Pu2
bEBoT3aaqlKOKb0otTFcUuyalIHbnZGB1rFPVrdpNuN7DWWylqquICQ4qKTWbGHgUDMuIRhr
FyxUYQOib2jcyPWsj2YIy5B3ZbFIDu9+EVd3MRNexEkExtnV6jK/BIc6MCKsoEjRy050vJs4
K9a02/oFCFhZoPyYymASNolyinxUKUdL0MDlWCAQvyad0gFIfYKAT8yfioue7ZUbeWlNaVZB
d8B8Bp7ZE/5EBwwTNOc8gdmKrmxdAL0J5JdcJ78YED014qa9YJxc6VvgyEh3L7NoUYRdHXtf
w2a5XIFqsyNnr4bJcu2HW46hiDjl41szVZxAKuWk3hxdzIl2DTqbRdgP2Hy1Xti+tsO7T52r
nL3q9/DeXNjVx9Vt2q3YaKdMCycMYf1/wgspSe2TO1yN0Rnz9RndyQbrhNJIPuotmmBKALi8
QLjidLUqMvtSczNMJ7AN8Q4GlbQXMVahaLUYq2tcBEZ4pRHWSBpLZQZCtKkoUGun5nqeSbhO
lBLGCkpXhcEW2gwmMHW5DUUiaZ2yXxa5gmhJ4uzttJVFPTyBve1VwGToZIUWdbdaF7gVme3J
x0sJ+0YNHxzgdd0awzsxJLSV4wDCIIxC4l815CNyzEeT1PhzvpjossGgwqAikX5GLD8sv7kW
hiGyIhXDrqpMNd6Zq9GORvfqcr1csYFjmZJmC13DGA7Ok95pV29YkKKXbaXRBYq6xuHOvcQO
xS+73JQG0kZYIcPz457Zaaw46EqCrjTZjQZwbjA+p2NYo0mdRytbjquuYs/dz4CvlURXPeMq
Z1tNPeciAd6sDBfQMUSjEUEAeTkxPBRNupoYngKArvT2Q3s6vuRs2KhINF8xSLgsDnMWcgva
ROPwN96kJY5OqM41OOhFf2MOro6e31Hq1P5cL53S8Smx9iXomvyzJVZpp4KjKH+uLYqsulNi
bm/QWf/DLkSFmNE/HHLaZKG+rxl+qcaN+npG3VSQrBcLUkLl2ywMXJ7mQMNGUzJ4vbmuk9wg
K8IFnLiirhkmzz2m+UYzTQze6BBiek0DY1ia5oiTjppKFMEJ85BAhnsOM3aUI4r5Yp1fQwjT
dYxjZCaEJNBdzaMsmin5ZSiu2Ipi8xwMafkSPIoEE/4wniUlIpArV/677mx/1gp0j6NfeVW6
AaNWQmgvQnWuHxTrw72cGkBiFcLAhTXcbnMsCOL5im1XrhYO1ACD92G0Hs9xCBInbIoiXReV
9FZy9AQp9H+KENWwg5RmHoixviyJRVJNMDKrEq0UOGkL0/wWfUqMkgD0njl019i3LIWPKyBz
rkjDwzR/XEVYhFrXQLky2fg0wk5M9ub84mBHQ4IpBFcDm6U4LYCTUBPV64GQ4HLMoRyBvwM1
lDMG2BSJtg1oSlMRKmpZ6wS2w+hDyXWinILDfY0haIKbUow5PtOXOL3emMVbBir3pBKTPcbV
2fvE3pfvETWvPqYuE553INrs89j014YQFaSYLGVyIl0VS9UBWyMDUrxz+/lnQ1M97b4YfGRK
fBsVaXS67DggZIqARyN/LrukniDBXLFeYCNDj4zCGzbzaLQq2XcPnSNHdOu047oN48KaSzCD
3KFnLKb5zXpvrIhz152rU1wGKdiew+yW/vISERt5hMcAUCe5Kl9vOSGEZPQM4VDHV7CUrU23
4aw47b3ZnkpjakalWrNzwAFsVgwQ1nN9zxC84oHlpk06Xg5EYAENOcAkq4VPeS9pKQUypgPC
Y3Ut6IBxzNSuZXQGZVjmI/TzkgQpEtIbXhhB/gUNBVx5YHf7+8ZGQAUH1o4BBIzH8O8p6XfN
PTH9HvExhQ1KurSwjxrF5ZPXlnwVMrGiS3H0G6MwwWrbxjjxYCD0ZI68ijTPp7J5G8KcGbL0
LHp6mW5g5xx339iq+vNlcWzscSMhdDRp3udGTZQH0QzFRYYcHh5qMDfwamctLw3BCc+JymW5
ctyV3+dYWt389Wz6jz9oA2R0QbqX0fH9kRbFhG7UGTE4e+g8wP25XU8mRNd8VWfC90g/8Ocv
+cQybJU0ZlLV5Oqn8pykmvH2BfnyugHcpwPoInzmnISo4hNraeZMFJMBRpTCK+0XN7k+CYsi
nF47yfZRJuPuAty0Hi4jc4MmC+gao7Kgi++KwoiMu0Raeoh3Xr06cdSPPvhoPIhRXj4PUCLn
Bo4oScGbGGHQ3LHeqIh8IfFOuTsRy/Gi/F47M8PB3Q9JGkSxm4y+Nht1mXGyai2EdIheV+BM
rMhFzAw/OxdT3OZ8LRyDsCc9dEJfEDFJf8on1csTJ32sP5sMnxeyQr7tecG2ruwRvtPj6Cod
pfCCxioes7zqpbygSLHnVlsw8ktaDYgrdjaemmv32qL0OYTfe3wt+Dy/ZJu1KBFGWewhoWBs
H9X5n8if4AFavqeFNQ62N5A1kFk0nbBb1dWmovNXFJvtZSXcAXTUAigtor0K6iohX9OkeTyp
RIYthvKb8K2nZuXOA/aG2w8/0siCSQSrePKagF2fQWXncKt3Y1urfdri7D7p9oNgGSbxqsc3
2apsBs9AYgHDEzW4VIdLOVyq4OTJAQF3m0sytApydfuOpIQzZJIGjIlcUDRgWzQByktA5u50
asyiEfHggGqi88keJ87SIM3nd+WQgJPRFuhFSoUJzlyxYboC+iJqfsb2+JTHtTyOpVR62LiG
F0xh4BPketBo8qAHwUx0GENP8Il3oCDWosRmHr5xlTU73E8BN6Hyh6pV8c1CitrqTcxU2h9p
62LcHwwv2DhpqraFsFejxKOQBgnbQ5K+u5dyIlhjFxvTnvRiqLo77rEh54Ofxc4ZsOX2bVHG
6TU1uWYrT8929mOq1yuixWJVqnE2CNFDR5oQFtrYRoLeeGCtIU52JV6FUqjC756dmXNpLgDT
BvSBebfPxplnZ+yCmd60ZNYane1QMQy5Qmq3/eJEmouvXu317HdClNnpqqJMbLW2QU3VAeK0
TSNKEpKfl4GeIYHgIQj8lA3y9TgmM5Oj05BwvzTMc4kNuyoP56bKrdbFrZKMrkpGz0sQr+W6
1AzaFudS7Sh04c9S2g1GldWBZxeMmT2dByPQYzN7nU51rUtuTWj5KIkQhcDZWaMpYwJvBFUm
z+MlQcBGNLq1CpciQwMWqpcukK6OSqwJC/1I5NU0XSeFtmIRQDQd3OblyCUWkcupQIPXFmUY
E1eHMc4oRhSVDi3FsLXI5MBVn0+lgfuf/jv5kwvR8H31FDQnBtiMbw+xEIPP1ZqlUiLuq/UY
rxD7ht+XXPZ7UyddbU65ffER+VEqQApt1GCXtEVRu09UVVimp9KJnA6gvRrAOoJOE9bqrctI
dtCGWLo4iUeKXdHlffZWCKIZCCexj06iiaHnXMUQ4XrhYWIJhkXsAFI0kwdEjCHSJ3GcQz+G
oF9FyUdOePAOX7IXQyhYf+gywnBc8+efxYb54YW2jHeGvHv2eEsQeoYEgJIaU2kTGWoMp/ti
iqsvZYxoyoP20oUo+bG+9LmFAvvK4Jb8EYKPtiw46NdVN+doEeVCecRjE2FqOKwfqqGSiWWi
Z7wIPXv5SY7BYcr6Wh2AoGNbvqA3kYNmpARAYmZbFZ4duNFh5SswMu1BP4oHs4wiMFXdPeu2
jUVEHgDYjVQtmJLkfCT3KmCDs6fdYa6XdO0mC+PBq9IA0pndYAB5VaLP11b5uO5atnJ+1gkW
CvVpBLGhQlstVCfKxNxkTx001EMyyRN3X3QrWYkNGo9hw1b9qsbGEvTGA+seG8tZk9gOMi8u
uNeeePPtIMMRWVMo4fzLfl8D0gk9ho4nIPMJzeIyDy8MWRqJ/BgytL3sV4iLZ4Pco1AfOBE4
zVDKg1DJz1lsGDzuN1FwTckMvo0AJWsvKIxIKwFwPFnFjA0D62qE1IOR9gM9Fxkxd95swOms
MH2oqI0T1fS1GCCyhIH45gA4aDSGfeUZ6zhtN9ZTYsCOCc4YD+Lx29VtoaiDVSK4cYwLP9T6
QRNwH0R2bV/QLXHgpi9Yyg+mYV6cCX4XpAs48l5pVca0ooypp4xppdCpXca0tozpY8qYesoo
LjNyV+QULr8jOpBDEzTioP3TNMoyk54LdJFeQZ/lWBiCO608S0Naf10BlRqU6paGOKnS4hA/
fveNED7Gc5k0GMMLaLQFwn24hwSXzWCfI40ID/Eov1i15Dsm6C+2onId3fEl/6kW88ZQDTpN
CuahCbeBbEYznRYemjSnBU1c1ex8Rk5e7vrW37F2y+cuHsf9jLw4GW/7JdXPyMsXT6SYbV3O
64EVAtBGG2VF+R17FODt00qgPVZr3HNoXKUWRPxeusq3W0REYr0DwwOusCiy+HJdRDTg6nZh
1AQtoIfr+tZ1xONfRQWU8aunbIDs3Zo3u2aJ76m9ef0kbN4+DZvR6OUT8LHfnzeuqlfPA7Nr
NGmPWVyIwIaGuECHUQsk6KdOh5+9P7Vez+mT4PsgTZccsStfQXJD0Q4UwTDReDPJPBPV7duy
APZ1mMwWUdZj25lEbGWzkvvy+JwIjVKhJX/Srm0IqCD5egHbFLncAMRjf+orjtlufwbU08HN
0iosMdnCISHxwS7ULJKiCTFW8p0TomSEU26UNFs/fSiVL6skI39R2aLbIP+firKL2kACEr6F
GqoINNEIVjNsx+dVzSu4yzODYN6D53e7ZhkYWrqY9WASpsJQxIjZl4/Ic13cLqPLhX3g91K6
m4zHUAXwGYc7Pa20ZPb+cBWPfqeeg6MNMru3tba8t3TdM+450aqrox7AnajDyMRFo0ElWCZV
FgOe1aLjBdhu8BwuNUzn8LpPmt0/hyTY2zUh0V1cdLVduvAfbljzFooJ7G/s8ny1NHJpBzxB
vuhbWUWkaRUZDtBouX9UV6m6bPeyUaXJyz/dFXR8QfSMiarmM94nvofD/+znlwAiOss8pnAR
Q8MesnwsgOJ6+yNjiM71nJAvCF5JBYg9zu/0VFIAiD4aTDpHoJ59v5HJEYykxMtHvIqs3X8h
m5L1CkbMctgZbsVIR+cVWlMYH1ftCgYP7RJVcf6D/Z9qya6KnUWX6yutXrXIh13OSdsyHWRk
cKrzzcNE7gN2/VeRs1kAw19GUI2ET6M7beWACFF5k+hzmhRe68yDxNlla+jt4xmP0OEiWGlC
04+hwYR6CGa1cKLNlJahsmbSkw1FDfCef56ffr4+xdvZInzWkY6S4MbJ//t5/qf/Tp4P9siu
Y+8BlX/86gX8fe4V/jnpDWCFstcjPEBxGTFDYa3EqsaWISGGNDQuq4gMt1w/jN9vupJeH1dW
EitBqaZ8jU9cuMIrMnNXJFeLqk0VMzdvqQjesLkad3pXvn3nevbOGi3i5sDiGvZ/8EP45siR
drIhlaJq6Cgeo9HuOQ6+/Pabv/2DOVI9+d2X/2/w5//v/dffs5unzcx//PW7r7/+9pvv30Ou
Aj1ixB70F16ZEmFC/fsgS9fJLFivlF+9vC8ie7a8C0+PsgzQKJKEVd598kuXSzskI9ariKKR
U3zQBew4+OflBy38UonUbt6xG3vwPjO4fkyFM+yS+XfBdAG3OQezsAjhjRfRhdAiqV6oY1yZ
yEhj+STxHzQN/ahrQ3oABoyCxMksurNVopWgWi1HmkqkbyKO0X8WsfuUVe8w0R4n0p4JRejp
9Tr5GFjDGfiBlgcnhJP08oPYDe4gQL+zAgs5ceTS+NTOU5q5jsJVIB/xMSe9Xrx5+yTzN/IS
yODbdPpRqw3zJkjudgDG3L0i/vvFkffguOAPwSZGSEJahSXcDPmYRVriRM+0Rysshk/IBRHT
RlpjLptgV4/TzUCnJyN+OeSRIrDZCvV54LB+bWxh/CvamuaC+64C6qMRvv9ISS9HakwS3hB0
f6SVwPTreqn65WIJjsMLn2+RIb8+MnqYOOq3RTTHvVnwE97/Bh8QKEyq7aBdjZtV7Rg5lNS1
PQNQlf6TU7M+I3BV0E/KqrYWtU3g0WH9sRNP13tGgyzYmkZDmAvCB7e1OIiCGHmcXNHhLe+R
xOC44xhDYWQQBEZsIOeVweV2vOw0LH2mxO/+/eOpBv8ZXUfHNZ7iG9MEyyItaPCGvR5WJ+6J
7QsSFjCCBfDcArM40cmwCFrvkLS2oCHBRRg6R3MWR596NTs3DqEnw7WHBi27tZSmStgOTrdM
eADZEAaLD60fDoUYGEccXJ/PaaLFJyykKohVdey6N3IOm0XHKKAu+YERQupxArm4ICdaiYk1
S6Xr0+waKjwmFcNnxg28mWIpNk/JCTjhsXVV9lo5OvFf2eG5aCucB089ymGUnJ7V66PnmpE0
hTcVKms1njRRNO4NVp3aykQijb9w7pUylSY+ARHImT5CYUlgtxg125Jv2nfFvYmDzqqu/pRK
capu5RLH17GtKoIOh726arusawUvfee53ebL9Wo3erP7EMMG4fZ7bmTSMNUMrx+47RgCH/O3
Skkja3eEsx7rb26ORkNTbgr9pU7ccKyVKndjtdI4zsa3ih3E4le72KE80OQ9PSMtuq7xsTml
gyVgZTcLkwy00WbDoY4ZToi06TrLIJaitMwMuB5LpXIVaGHCiM8cohCqc0M55bbgzUJefbhj
TGyJuB6ZiCp3eQIhvEISoqHlqEhdc5CjCUFXeHBgxhWahgzaeozg4Ccdisw7cC4XsbofEq7P
uNQVGwJ4usRjs0VeUhPU/F4pxmhM11Va0ZAfOu6o5qHJBF1NM9IwsAk5RyUbhd32SOZxRMSc
9Sfn8qcBOk1X9zhLqgXafPLVOfJkd87xmdimsxHuvQ/GRARyNsb5TIoej2H0CQCOrip5JVu2
bJT6lIe+1UKWWJsipuUQ7L5Qc8+n1hTyMlpOV/fSpAaEl4bT4/TL429ejonfLu2Zs1fH46eY
OaOMnmaKrsXwl7Ttwoxo4XiyW2ZG5NKUlWxq7XipWKQNs3ZcWO/cBomgbGr2nLUpNYXe+ZGK
++l4QFr9/8PEXEkpLcEYRiT3GogFFd7iUvbEjZi3YYvSbJ1pood+al5YPs7ON4RJx0jTJ1r+
qshmMXtgF/5GtH+alqFwyZ1PPaf4fqSey3bLIgz+DBwwNHdfek7Oxkljn9NwQtF8OZ8aLtZC
UIAo63B0IV5Zz6JLGu1w520oEe9dYLBpcc1EZhOjMrvbg3WhByOJSSu/9yWIWwwvImOt0H8p
ce1IjZNwNqOuNe9KzVDLvStda7hPE9kcv1EXEtvSbiUNbWnGtYeFKpJgZKw98kO0aW85g53A
0PKYv9UnDp4AxYtu5eYWtnGj54wYTlkIJoW0Z69FubXZVC6vWOlrsiNFbR3paA2ILMM7dGDy
Vklirh4ySDwWeqRT4oTYM4eACOZpiqo1hIC/9AlPbGIoAMldlsqqmBea0knvdTJ4uVawGl78
Ahhy64v0fiX3cgaULgwno3mOWtdR5TuYWdQ4Dwbk9R5Yzqdo+A8Tpz8eyb1f78cX4gwNdlby
VNW5o23Tpi0qVE8e0xaPASy3FiprZEXxzRk/ewRjnOZHzkaP5FCpvfdNvH4emB0UyxY3Ny/u
4+RKrhm4LKvGrv6X9UiaNtE0B0Lddt+kAareSU/ksqsUcCZhj7upU0cFUbcSHpaTexXdWh1P
swyPlOAXR5l/C33jFvpF2b05+8eSQg4bdZVb6B7LnP/39ZTuraG6kQNh1VD/V3SgzfyUU43l
nqSyM7U4mc5k5J1KaoA8NjpCoObwPWyCMBwfujq0h87G5Xv2Wynfs5rylQICNZ9YU2/ubfaI
ul9bripkd+TkOZVRo/zKwxqbiinQPZFW0+mOGv02ntaoL0ZzUrW6b1ugZ7+lArnrqIW30k4M
nIm2WCOsC4WFCRVabuFgdiGSpifv7mH/DuN6n4kXnMgRxpesErMwLthFl8ZbG8zgvsfqDGnn
uaBhHDyAykRUXRb8hfcqNBanpxiKQf8G7vPi9BR7L0050r3yzrJRj8ak16XTS6A7aoTESUdd
+kmtkjD2dqmHEbeHtxeNtcZsTQ9g1NEmjfaF5GoFKgbnC6f6fEUzZpW9RatxuVstai0vnxbK
3XItJZem3HqqnI2v0FvzWfDt6rANX22ltLFmN6PfXN/uWY+yhh1Oc6uadNJvrCc3trt91juf
hlbn7mUcY4fa5vHv36x15aom/ihFlzXdYOG9ukFpjekJ3cRgdx5isBXngLXW1FGU7d/dOH+P
zqN83QjpfEbGu3jspnzx0cnxLtm8MIr0Yjd7C2ZHlyG1HDoG3/ANn63d/2S9LFSwUQVe92Qs
ZTv+240IsPEiixbpKue3TlWJod1741xarx6JsvnEO2t+8d4YAj3rUgg2O3Tf8yzdeBhdtOFD
v+ExyuCuHY+z1oXhbNqWZQOlnSmdEaNN7dZyx/zmpd/LlXEvxrtXx47bq+DWrsXyrjNOVutC
kgiK8Ip8on0Mz03XRVX2PM1uw2xm5qu7RytJX8azOIumcBo9XHgoOOlrNLIwmaXLIJxOaRft
oVHB55N+TUVl6PGXmIUCcr7eLJuxHOEotvyAJZ2rNLv3rGy6Vg40QCGFAmy2cEv8ixra4iwp
L9I+qPs4LUswSuyyksoi66sk1WV2QdYs4ZD6UrvArGK3sgbbTg3tOI24rUW0sIm2VtHULkoq
aqcjdzs0NFXRVNvrq7XWNtNdOw0+3tTcLs9QY4VX/HdW42fk7Zsn6GFfdJzrFt9wEDkmVXrH
UalRQ2qWXKCdnpaqprqyXCRULVXXmwvXqrDqKnQREGv9lbXpQlTbQJq3D5+W2WaOXbcGj1r1
bQbbaQ8tG8RjFKd2cv3O1KdtQWuiPm3cVKe+ysU0sF85WJNmXTJHBHM07k4QlNLEGA9w+Ipp
qd00ZkCCr7RaEcNckdb1DEDblcqqFTz1xHsETHAUSOxG0vZftWZz0T3eivjKDEFy9bUlsTXy
25K4bEbVRsRP3alZjjI4HmcmD53tG4PfFEpimaBSpC3Wr6d2S5JocEozOHofv3z7RNFFudgw
ohQdZjk0NN6YV8rsmnhw926c5XDozE6n9ArvqoXks8/2WpaHt6yJ3F7HiwiO/iEXtuMJCIN6
Dw548gR/JhP7hldepO+ws/kS+5oNyutCV8X2FtCDhlohTdXi7yeZevBiQaETuKOEK8TtFVpU
eG11e9YHnUZgFUuIrnhIGxLwaBIOr4Jw8tL+6hI2adIGfMnbdDY2e689bywLVjU/uFzRKLBa
Sg2jww6zqp3Lk8YNpYEWnWjVyqxuU5VtRze8iuZhzsO3bh5bMJ7NTKdHGkZoFvdyqMZOQLri
taqWp2K5+lZW60TD2Y2lAewbNYfg9f7E8P7JcNhDW47lueSSWH/W53ka+3kpohPdLa7He/sn
mlhp5MVpcJgAaTjLxx7itPLhkoXhsLL8G3Vzsvgu7Falr2uL4tIcn/Np0zuV7conruAtMRDC
173EPU9A/VWaFCFln4kzBPBOJSzlR5kxe2084a2wcGs/+zlxnPJVgMZuTpZUGpr+u82Lg8Hf
rahK4sKp1q5Szz4703OqtNPdxxQ8ZORCPtOqbp/CqKfXWMCupo4knB7i74vgHeLNjlEvw4vV
Or8O8HFTAWTc18geEeRdb61sUrK+/u4ro9GSwsHBNkjArXAOKmxO9MXrN7/WsEVrimJRu6ZY
OkDkMCctUqgj1fWvspdcxDyjKX/4iK37CKdeGzsJJ/bOvQRybeAm6qWr9RMtSHgdRTsalZ7i
ZPT6t+MpastlQNT4ilpibZzFZm6CuC1TUomLP5yJ05nUeI9BjV5xfo8fhba8DAssu2wG8KHM
auuuBgiTc93jMI7dGEdops85OIgL8TyQy/88yvM8zudsx9v8etOpUlw5dinNJXSqPI/P5wwU
IbQ79wqOz0x5bYv3Xqud1YBjaCOhtsNsbZPBd3IF9hxXxoyRozW8oyByoe6CbSdjEFl0E2V5
FDTY51ENeuYTHEVufqudKtZA30dBgu+jxXxieW0nS8LvEXQ55n+vvSrfldbg3d64uua63JHK
ALAG3KN1cM7CZbMK6Kqo0INzGebq6gPpc0T9odvSCqn7R47C5uB8AhVLuN5XmoPulGGuh2bL
SyDEPgjBY3hRlmu/q0kgrmBAu7TdL7IaDp2c9e4AkcvOl5UK80QhJJqPrlacklDDYVdNXbcU
iuI2EcpNVxOK9R8vXx7/Wv3Hn2NjStV0pAO/6/Seau6oQ8H1rpHxZmdcgJ9Gn/dC2yR3b11v
cHfIWxrbk8+/+FRn1dVGqos1uwvZQXTsQLqJF65eA/ZNuGtV1GyPVRV15bU7da68ET17caKR
u29EmXumTrMdWlWUZKfQ8XUUsmf5Rh/haOeYytGAskrJSfTVWs3b0N4+RwIYjOWMg9WxuCjz
jQLMA5bxDvlvge/ZreAl7C43a8SO/o83NcEN7/cxi9agD8zqu8An7fX+6PYad3vl0nYdC89m
ZQoqgNfl9HFxNel5Snpw7qbKX28RJMqvWFZpYENBD6oEHTYS9KBG0HJ7+OHHSmkllS7SETKS
B9oeHybOx05Lg0v3pSYVblDv173XidTg2+fdKjryliU4e2wBNpJfSMzO07UTX/ZxFTzLHbEy
5w3K+7gyDtuXsapX7SgXspEqcFm2beHMKdkKYK2zk77qAUL+N8cvnyjkb3QezJoJMU4Mm/Me
/O0/q92TswtCuC3ZaPutb+/30OlZEx0cAF/HFKeZ8XJFSMCoFb7ZCfh3eFn5Msw+shCRbUR4
B0+szmR/aEDBIxF9SRkepIVD8+RU3RPE91boSD2iUOBtJ12Q1vQfHIMEx4G89nM0FZMzj9ur
3nCPujUrbtVzF2JTqZju/jROegNTd13UkZjqtvF5AjTU3KKFKZ9UxTeIJKULE1X5yKkRW1x+
xQMovzxhLcxGSOufQq+gWoopublX4jjCOiVH5WzGm1cnv9ZshuuwWXWkUqEDbRqi08pRuWiY
3SF2C8pR8LBFJezv69eWMFjdc0h43fP8/HOnGoe96YgPltx7cv1H+Y1bI7wrhqnTJTM18Tcm
MCNOrlxTIP+Ga362xrpptXcaKA11j7mHq6QxMNUbTOUaYQVlBHMTx3vY9ksrhOrKXG0VUOvs
zs5ErtE1Mn49G1IZgc+h1YjlWw2sQXOvA5JGiO4lQCLOax6/frKATr8B482TXPkg2J2cPNkl
Np+Rl6+egNmLTvm9eubroEG9F/0JP/h6ThhmAJnyuCEAXgzgQT8GLG9qFA8vEbWBM4+n3PZx
klg+b8+PMn4XrXjvzG+CXkRwICPK4Z85ay7Yk+XRYh7n1/yhKhShT+Dxd6JbeBahy1rRT3bS
CwFJ/6LLR/yjnnjbG3P2tbkD8ZgVyTWCgsMP+Y8GYp9cZeEl4w1Nn4vXkzN3i5T2wRDCHBxA
QSx6QOszMjp+8zQ1Lp4Bo1IsIjo6U3IPh1Q6/g73jGZScxDOhT8JxqIJ/fnrvlQaXCUu1CZu
SO9NfHgSizPqMmpOBGoXfTKlHgrgDMJc/VLBhpj8KvTVvZJK9RbUDtxCItYyvYnaY+URHUK4
sAbSpC0ReQHRqKM73MadL9JVIzVyA51n6SV7G6qrs9BaF8GGtS87NTFWxVT5srkMSFQPD490
sma+t8f++tcrWP7pKfMNNHXPGYoASekh9vbsS9HKl8Fv/uAFb9MVT1VwiIrHKrh9eYd2wv58
t8iLgZLoVEoU5IsK7MsFB6s01hxLLGeA7KwaRJPLhSx6mYhxkZ56nSBZpawjUOdnZeYFPEoA
lqRMD0ysn9F/yuPDkndG2IsudYowXTTSXiGgBNaUBAKsmD8GisML5cEm4ExhImd4oXlVLco2
6ks4ckw0n1cQpAFEDJFV8WmHdFVc16BSIBuPtc+2WNNwFU7j4r4Gk3aQNqZ4RMKD2cVqpEru
HbEXJNjbuu+hvHv4Ci/zSMuVl7mgDr0FG9zjbnfVw2tRtHA4Zjb9y1/O6KjHRvdpKpyug36n
uqYp4KHI5d3vRD78aQfVfN1FO/SgJKGIp0izm8QLamOHnBqwf7AK5S8JJ+GQqhUd/WkRWkf6
J5xFhHoTS4oekWmkFV8lKMmAkUh6E68AvEGYjJpyaEa6KTUnKU2qAe+Bpw0JAoKYd5K3mLJI
1Dp3iHGlxrZrnhK8jK5iSsxMjJJZr8PDolpROAXA4QL9YlmgbFxlc1fPuuS3Ic02MPexlfDQ
ZEYthEoiW8ghfuAfyOGkTJsLVyuY0m5oj3Aclsb6e3s+s9Sd0yKc0hJIl4mvO1ZbpS1OhXXW
MmrHwSIqgCgVEdgI8nmvkqzfYOsk3txeBXfLbvk5UzMRD7wKwy2LhOsbIJD8wakgntuCuJHv
zIJAN8wX1hmPIUkr41E82hG37Ua5xqZ2IzBa2I0U9lEmg4y3YTLo3VoaTSk2qFOoU3k6FafK
BPpIU5SbxIEnSsmufb4BcqqEOjhv6mTqybgLx/H9hWObz3XjomYzEkPTclM12yWFHWNzJc3b
KqOvOfqxrz05ZRuQDdou4lW5/EasLOoCRziFhs3Zw6pN6xbFkY1bLXIS7ZwJfq9K1PSX6VIY
ENEwX7bQiYi0ReH0zAHhhsSnrzR4oRMBirtl0nrZqor9GEGT9oI28pAYZTnKsYmTFLU5AAK1
/pBSySPLbDZoe6gaRaVH8fnI7tg2JeSolbKqXlCdupY5RwqBVuPlWFNDHkuyRJurmwPIwifm
XFqIT87FcO6XtIWgpbqTbGw3q1VdjdMlNV53LKp+0pC7m7l0qxbPZLwlwtWmOWrjSZux18ug
XMxGhWnmmBPpJitEVj5xpNluPPYagY9lPDIdXzyG7xF2r48ToVUP6xfD1+W2lqM96035tqly
L/fHRN6cul9EbJ1W//JhZPc4H6DR4n/GShqbtsViRbQP0RfERMtj6doE6zqJf1prC0FqGmJO
Lsioxxfy9AEr7NfSSSgHSmlIehM5oyHy+fMr1uQsiltefePN1JiA1CYLsY88V5Oyvc4eLykv
oenK+azvDxTtR21S0LV12BZAdDqql5BTqXx6m5O1SYaFmxSXrIvLXj36lzzrYp9/oZWHwP99
QY7JKXRhEa3mpKDFfv55fvr5GvbKxYtoBmMcGq/EaUL+7+f5n/47eT6gxrP7lURY03oxPoa/
z591bdF7zwnMatAC9Aix6oHtuDbrgdirMA7NOazgd6+/lxvoz2nHmg/A9ki9xDJOcMXUnL8X
TkAMjZUBS+Y/DngDqlxEQYdmU4dmqfTPlpK52M+fTwypXMvgcsFHX9C0XPWkAkr5cZaVGCVR
eFF2oyOyKXpz7QXXjZ29pGNGiythYtKYx+1mVp0LLYwIrCuwJSk+AwYJTNGycG7GriLYoY8U
vyWROqG5rN6Ir8SMVXFjBWctNZzYbkR2+JtoOduKmrNmeq4Vvbmusxpla6wcBs2uLwxwzfDx
lq1Ra2/iJVEeZetNqTUuTzvr19nXNQNXY5siOxGTWrRh4qFdlXntzaS3QaVZsjyuzpoRa1Ge
lpWm+DdoTc6GW1lvzCaSdNvtTVDcuM2ZIm2j3TWi2KpsG7U/KUbLrkhZQ+vaamCaj6gvh0xb
aHJNa6tN2TZperXVZXdmxup5vr7EGLbZtKurGOYyPg5sjCVKvGWJKihd0oFD1GqR1C8CBv1u
yi2rtjkFb8uT6DX1p0/wyul555B6XwwQj3+0J4ZxebEGSw1jJtbASM2xSAFKh5bkaKjEnC9u
VqDYnM1xU1AuvkVKLX9oI2K78DYOS5YTD9ZlHHzgKCaxP/mObZIuo2OwLgFJOk47cKKYdH3y
weaFSumEZmrkY3RaSGfQLQ2i+bSXuY+PPzidhzfsijdjOy4uSDgi+hW0cYeTurMaJzWhHmuY
6tzW9DqafoTTZyVpjK5I7pUmbCPSRE6s9WEfkPulN8c+/4G9kf+idCOGNcVpOMEzTlIQU2T2
SUPA09NOg3ncBvOjbHr0k5y5MPRMtOkWs5tj7s6c+zUhkhEAsMlgKweWaj5AzocR1otjigq5
/9bnpk5evNHnptAy7UkpmO2hqmAFGqrpTVSPTJuUtMCyEFPfqToE7f3m9XIy4nqpKEVJU3w3
exLdSstjuAcUmp0ExijGaOkMumdOGbNd0JQE/XF6Kk5FcFAxU7gaXrAJLBpG8Ok1PsywAaBy
D3DxTGyKPiA8jbYoJqYAGvUk/hyc54TaOGzW/TCGky3QAg8O0Ab2ypOMKzZfOSD9DyN9gRY2
dq96ahpYXsT/ScHgAgI7kvFU4uqT+rrMrBOTO7YhLkPN80v19F3HDxt6W3XHdiNnqe6AcEWX
le54cZ3jwS3SEg/3RH2yg2k/BsEge3Gd8/4yOzT2UOnPcmW/ot54Vw1a+UMjGDg8nSqg8f7W
7aNVuzLXSv5NW0xLjaBNbU8V1GZ2og0ac3e021029qobtxyxTkopHcrhNeSyBbWdFXEbDlDI
numyL3Yv+zYa59Pq/dkT6f3ZTmXfrd53IfvZb6pFn+2wgLu1q4vfStW0tqod6PziaXS+S8l3
q/NdWMsTOdCL813KvmNT34HsF0+k993KvmNz/+10urvquXbRN188/RzGr+SyfhvBx2+nhe2q
iKohGvd6Tohxp9tkw4URcduiKj21YJE4aFyQ3qb8U5v/GQ2hUsm/nTp7j9bCVVSgQWygAjE9
MIsW8ZKckz/9d/In2N8O9zHD7Ui7nt2fTp9TJi/YjbHa+wfWDzurE90VEWxu/erg4Dn59Lh2
xC9UarxKhisAHdf9S2r5nlABs9BoJZLE6Sm/fyfqwoQ5QlL+5pUgW/APWK5NS2XeDwULqaww
WilmkSzHSuylSOdwX0yPHMBhCt9dM0AM708hfXH0dasF51XQsuilG50I93L8K6bNY/RKe5U8
puMC6upi0j8nY/3tqSebGkTRqRJbltS800s3VWaL5/rtViwJb23raMtgaPUMk/BV7xWr03NG
RabMQW/8Sx1HkTcOc6WtHqE0vtzetsLF9WVYcvf6nljccy7saZlydVEvkboTaStdfdviOS42
0/xTZvimMdUedUZnYOHkC/jnlOC4N3tq2TvWYqyOeHpa3oTBWig8VGBdqaStGPqtzj5yBeHQ
zz8TWHjXboHiqahWU6sDHexRrquds+7UacfaMNMRr7I/c21r4UvdTCe4pOpuDQgrV80ZYX3N
2NdK+NkabRHcsQ/EWoeWQMd8jVcuWW+s4qYxUWeD/TKVZ5Cp/TTbgGgekxz3SntoQGVjfguX
pr2OPJg3wjlzuHAZNkjoh7JoEjvjLPLHPH+s175+twcednXupRmzvSe/4V0jEFfCtpHR+JXa
TiPEtraJiB01slS4fYarBdWtpeo7DqzrNxJ2QPjQ2CIBF3GMf6VgTr+Es3T3BumrziBRDoKf
5ZL3SiIJo0Ti+PGvUiT9htANi8RIbLlIT+Zbam4YqPEfnj14v7vNcrJ5v3z1x245t2Le/rFd
zsBnbXz89JvgBBGPJE+4tW0ThwuXK3v97dR2t8LHsiuZLR87fSIfS7btY923nTiDs38fz/p2
/IdndSvm5R+elc3lQBuXLftX9KweSZ7Cs7YctlfesIAOxWwpiWVbv/nWMZZXk1iie8ZczHmI
e2Sg1sQ2Q6hz7eIbdgGFtCN+cdtT9CfavEqL6L35RRb6RJanu/it36sia//FC7vTcN6r4qp9
owPRu1HRi3TsUWluuQsWXsimnfxWTWPD+yv0tYg7dlaK9678mMUd95AwjauCEHJwcCcVC1qX
11H9pCK0H+74iQs4lrG/rymaL+oqRd+p8TLbn2neknPHZRKVgJ9PthyySXU89twg1oteBWe4
EFCpd0pf6nza26kKn8KUnafAdbMV7/YxeBmRTPnZZX2O+LdZ0OwxjdbT0xn1W2rbuv9LRLR9
x/yqtCvdDwgrZHbHbHE4hO00E/L7bP1PUqO1tgtaGz2m9kZPU3u/dz/ymGuFmvWNZ1XdYiAv
dLIVe4zW/ky/Bfh3q+PNbwGSbUHce6K1f6P0j24K/pbwv622HnnpzxO0ivN/Rz3XdgmP06lw
4kn0b+jEH3fv0e/LyZz/+3QJzW3/N1M7v2Izgvub2kwFtbqFytsufueTQy/evm06OST2qFkL
Kmo9AW/LhtwLcfksh02sXGOjjAFpbaFhl3JleFG2d/Qj736TI9hM3hwEPNnhDL09ZIY84DCM
7GN9L5o9FUb/WEL+Ogbb1n//zu30ZPTmqey0qcU1tLMKQ2KToRubD39G3XngguzD5XtNrxXY
55uqoey3cJtTfngbz0DaY1k+mhav5nfHssmqVaMryjTKCON8uZ6Tfn7JqGQz+FS3z9MUvthy
LNP4xu1Rr7P3CTZ14j18sC80vxxe5Jfr5WqKFPbEchy0WHhelfTYQZlP7A8BhnlUwOVfsBE8
xdv955dxwZDx8QEq4Uf+9QB/YO3C6LjiPJhFC2DTs8mjPOvkKiqkQE6abOOr9iosexccacpi
DIe3UI4RZyKIPKi7+EHh+fxOOELY3HloXSfecZca2isrtrb//TFda1oyNe1sDdlPW594NI8q
pYe3WYx7WZUP18r6KB/rO47TqoHsk9w4k6O2sfFWMSq1iuBvAXdEVDfrpGCbZrkhtW0ou20p
XD4qIHtsg/YEhh39rDclDnJKGrQv+HtwgOQnHVMqrkbd9uubjiBhtYP8UD7hW+sQVNNwt16t
/RFxs6jWDrfUntps9zGAq2DZTYfUGj7BSOgY3+bBrfX4pPmGhzjaNOuNhjt8qhaOtn1GXr0c
P8HNdWPyAnpdym4nzICNYGKfiOOvkZe1g0Ex/aLtnx3zo+KNqXzLcHo9jJN5ioJ3+MnNTjot
AsgKIIs6I3G9KqzGJ+slmS/SsAjocG0Zmo+EJLRp3UQD/rVOPibpbSI+4yiKgkVcFIsoiJJZ
HJo5l/GVlXwT3gUz/eNKfEyz8J41JWw0hrzs/FpPv6lTl5fLGBhpZRQ8R3GbZrNcE6waziha
nRSsPoIitQThm8vYSNFA5/WpgwdhLi9E1tONp+EVBVNN/ZhyCpNpNJGvHsdJXHgVw986Scxy
5joI+LMKXS8LCcUOCFHFTq/jaM6TyzXJtGEkcqWYafIIAzn3IuGlrHCOlFn/G/IcooEhhb4R
1s8yS/+pRgEYAWA4GgXmoXfSW8SsCKxmQFOgSWqfufW9tvOv06zQ8+0E2lPr2ebnIk2u9Fzr
G+tG+56ltFyRDRDAOGUR3ZUARYbWGrm1SX1otq7STEOHJ8awglCTcMpIaJLp8dvvg38FX/39
y+8G6vP7v//zu/fa9zf/UF8GqAmog/31239+qb7+8s9//fnbrzusGNy1gm13ZqkoLG92YAFR
lsNYtcty8OLfcIAxE40e+LtixLJTGiDorYM2iF6ZldHAdU6Y4WPUkg8NS2a8ULk6Q04gaDUL
JOuCwD86X/FsaIGPpQ8aSKALgCG5kkAcpCdqu3EjOXpGo37xkjbqdyG1qTvepPE4u9HLjXyt
/DPy+rUJq1N+ZVPmlxywNBqwMndA3n2Z0b5pfMakv6B+Yp7hxeEM/CvWWhjWxMz78uv/+POX
31qJX/39n3bS31xwf//6+++tpG//ZSX853elhP+wUr7/6u//sqG+/6+/TDq6u+Nl5lM+p3aZ
2b3xDxogTnqwOps6EWDnTRWStMqbcOElMGC5JhVmSxb8PgmdVEIPNn61RPouvf2vaEq7pH2S
3eDAy8z/Kl2sl4kAmTIQUgL7SxxeKf6TTgkA+gongKtTVIBGJ2WV6fRUxwztx/34/lk5ksG+
XGE4mKlXEEzYZxWwIiIQOeJ9YgueGYg0rokXQ6uP5khmJTXHM2qthKWhzePFQvYhYL6TikxO
aMQp8b/ZmH+PDfMQe2r9deEE1NVUB2tppw7cNGWtnjk0jRumHxsIbMBVy2uA1oprQNdJS0eb
SU5Hl5HwgwqCe08OCFv7lQia+2ft1QaPl+FVBbjZLNi1C9OCe0u/ZditSqqNZOktw441hVjZ
4GNgp5hGRVcmTYaPMhknkIOYKDrGOrZCy9mUDTS4edoERnQd1A1T4BnTCA1LppH9whAnscqj
NQ3DJCXe/grquCjCIZ8wM6qG0lvTSsxKkptQsRvMR208a0ivBEgh//I1TCbyRyCTokSplO9S
qh/I0qqrNaeLm8huzZeORueEw2ryVXItSoV0pgYNSlZru/TqvRLLLflmBCrLoTUti57u5i59
zbEKx1eG9uj1NVFFtQTgrJW2FCpr6BHE1KCvrm0s8qatwwdZ2T4aIPGftA/76G8dFp3G7aMG
r0kLaU6Cad1TGq0uSxQbtZJqrAbtpDGB6hqpprlBO2lEo3lLaUtOtRXiLreMb1bLcudWGuAc
OAYSExfg0AlYTdIeglWSdYzX9HhNDX3KpSLl2FGC970jklIYfNmrpXbgGafwUCd3hKWqqPW4
9dwFsBC/rGI/9zrcpmXXZC8Tumykgs1J9BuT2LAq7Z5lgxptQaLfmERTO29EhGMvwxU1i2AW
vIMBZ0bmLl9Bsxb3FthETl+EyX0QLaJllBRBnAdJdIUrF6Ww2QVM/VmQZkEiF31s8MVCgOdB
mEUwXQ8ITfDgMsUrOg4RZr+P52txLkAmxEmAE18mdpGmwSLMrnDSmk0q22y0gTpMNLhHXbSw
PgdMpuvlKktnPlSana+XvtwqzAo0mpX/5BX2MncNrrSOahbD8Lo0rCpBwCjRH0zQUXGwjJNq
QggU3tUIJEnhHNwZ5XsBXeQsuqul68cwhvBs4O2UtwzkktdNqkpeN91KeXWvoFYDhF/QL9vV
1gicfUZcwtavCsY1Dqu/wMmSKJxZUJCc8Hm7ZMpWOOQK4OmpWsyaFXw9BFdDPsZ1qyELXAxV
vPn+JKOAVcwUn06DVSbFTV8TFrPIcpnFmqZ0TXVTGDVTr62ScVp/ox4zka5KeKheCe77exoq
4p4+09lbtWp9anRcEeh//s+Nmmer7j20VeDX5PllmEfDWWTugIDEYBbP50H0U2Iu9hpZahHk
DveVUR8LU0SooDKsK4S7u5OxU1FwQnd3jBQkVFEyEvn6BEUPDzl+eKgI3MRZsaYa+sUpv4uL
awGhxNFYR8CdjtdxDhP7+6HYR3ZH0alIuAuqwN+F3IroXVQgwiUQTXbTT6esd8xw+5VQYU9e
H0m0/wkC3ABNVFetOOgIGrgPAicQg4xacZjJftXEqJLdJbj5iq4pYiFeHW5C0Wllx8rKtJ9W
9SVxEYcL3BcICMWxvfRTkqq8n81SdaVcbUrdlrZdZjHgrJBiG2owrESnVCuhKQQ0mju5pROa
TXGsPbGpG5/OHjsG5Kd14kq/d4fa3bVcueaMF9vM6EbmCELieOmDLPgTz2lBqUaz0xKbu4lG
x96a82JEnv/ly69Nh0wT1CK74YUGIpWC/HWdTE1vDXhMSFTSqe1IqaPkePj7bpYWYv1aYDtr
TlWcJLBPRxRuJhS60BnNJSejQgZE7zuqeLs7EkpR7M9xSzex6NKf0oeXhA51iUMpMfXk9K8u
pauf0ClX9w4G1/LK8x4RQpTzsHMBobB/oT/qu5VflD2IEpTtP5hFGChpA0DVCIANb+qNmrjm
bCdtsCqqGB2ZTrWqpaFa3A0MTr+IPTKHh7BDdZqt58XRMs6nR4t0GGVZmtXsmTk5qcbV2Y4N
ttCkT083tPI94m1/bVofmrLcbX+nbfymNgqZ9kGyCe2HaOXjFiaUv7YmdQNQnBqy0m6/stqJ
0UlhCSftBau2sQZiN5BbtP4G8vOej7XoO2a5rOU+CCv6/wFSNFKkZ6kCAA==
-----
>From khan@xraylith.wisc.EDU Fri Jul 09 15:54:00 1999
From: Mumit Khan <khan@xraylith.wisc.EDU>
To: Bill Priest <bpriest@comspacecorp.com>
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 15:54:00 -0000
Message-id: <199907092254.RAA01539@mercury.xraylith.wisc.edu>
References: <199907092219.RAA01211@bandit.comspacecorp.com>
X-SW-Source: 1999-07/msg00373.html
Content-length: 794
Bill Priest <bpriest@comspacecorp.com> writes:
> All,
> This previously reported ICE still occurs w/ snapshot 19990629.
>
> Here are the relevent details:
>
> c++ -c -I. -I.. -I../liboctave -I../src -I../libcruft/misc -I../glob -I../glo
> b -DHAVE_CONFIG_H -fno-rtti -fno-exceptions -fno-implicit-templates -g -O2 -W
> all DAE.cc
> MArray.h:119: Internal compiler error.
> MArray.h:119: Please submit a full bug report to `egcs-bugs@egcs.cygnus.com'.
> MArray.h:119: See <URL: http://egcs.cygnus.com/faq.html#bugreport > for details
> .
You missed an important detail -- the host information. I can't reproduce
this on a i686-pc-linux-gnu and i686-pc-cygwin using gcc-2.95 branch. I
tend to use Octave as a testcase whenever I build gcc snapshots on a few
different hosts.
Regards,
Mumit
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: single precision complex bug in g77 - was Testing g77 with LAPACK 3.0
1999-07-31 23:33 ` Jim Wilson
@ 1999-07-23 13:07 ` Toon Moene
0 siblings, 0 replies; 21+ messages in thread
From: Toon Moene @ 1999-07-23 13:07 UTC (permalink / raw)
To: Jim Wilson
Cc: Billinghurst, David (RTD), 'egcs-bugs@egcs.cygnus.com', craig
Jim Wilson wrote:
> I haven't looked at this problem yet.
Did you manage to provoke an ICE with it (now that Jeff has made changes
to abort the compiler for certain accesses to components of complex
numbers) ?
See his patch at:
http://egcs.cygnus.com/ml/gcc-patches/1999-07/msg00353.html
[ Hmmm, as far as the ChangeLog for gcc-2.95 goes, this doesn't seem
to be applied ... ]
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
>From KCook@IBM.net Fri Jul 23 14:45:00 1999
From: "R. Kelley Cook" <KCook@IBM.net>
To: "egcs-bugs@egcs.cygnus.com" <egcs-bugs@egcs.cygnus.com>
Subject: Re: single precision complex bug in g77 - was Testing g77 with LAPACK 3.0
Date: Fri, 23 Jul 1999 14:45:00 -0000
Message-id: <xpbbxvozarg.ffcf3f0.pminews@news3.ibm.net>
X-SW-Source: 1999-07/msg00768.html
Content-length: 727
On 23 Jul 1999 22:07:49 +0200, Toon Moene wrote:
>Jim Wilson wrote:
>
>> I haven't looked at this problem yet.
>
>Did you manage to provoke an ICE with it (now that Jeff has made changes
>to abort the compiler for certain accesses to components of complex
>numbers) ?
>
>See his patch at:
>
> http://egcs.cygnus.com/ml/gcc-patches/1999-07/msg00353.html
>
>[ Hmmm, as far as the ChangeLog for gcc-2.95 goes, this doesn't seem
> to be applied ... ]
My current ChangeLog does have:
Wed Jul 14 23:28:06 1999 Jeffrey A Law (law@cygnus.com)
* emit-rtl.c (gen_realpart): Issue an error for cases GCC can not
handle at this time instead of silently generating incorrect code.
(gen_imagpart): Likewise.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: single precision complex bug in g77 - was Testing g77 with LAPACK 3.0
1999-07-31 23:33 ` Toon Moene
@ 1999-07-31 23:33 ` Jim Wilson
1999-07-08 13:55 ` Toon Moene
1999-07-31 23:33 ` Jeffrey A Law
0 siblings, 2 replies; 21+ messages in thread
From: Jim Wilson @ 1999-07-31 23:33 UTC (permalink / raw)
To: Toon Moene; +Cc: Billinghurst, David (RTD), 'egcs-bugs@egcs.cygnus.com'
Using current egcs development sources, it works if I compile with -O, and
fails without.
Without optimization, it is a calling convention problem. We try to pass
a single precision complex to the function cabs1.0, which requires loading
two SFmode values. We generate RTL to load them both into the same register
and this code obviously doesn't work.
(insn 26 24 28 (set (reg:SF 4 a0)
(mem/f:SF (reg:SI 77) 0)) -1 (nil)
(nil))
(insn 28 26 30 (set (reg:SF 4 a0)
(mem/f:SF (plus:SI (reg:SI 77)
(const_int 4 [0x4])) 0)) -1 (nil)
(nil))
This has always been a problem with the complex support. There was some
discussion last year about trying to fix this in the alpha port, but I don't
know what came of that.
The bad code comes from emit_move_insn_1 in the CONCAT case. It does
=> emit_insn (GEN_FCN (mov_optab->handlers[(int) submode].insn_code)
(gen_realpart (submode, x), gen_realpart (submode, y)));
emit_insn (GEN_FCN (mov_optab->handlers[(int) submode].insn_code)
(gen_imagpart (submode, x), gen_imagpart (submode, y)));
which emits two loads into the same register when x is a register big
enough to hold the entire complex value. This code can work for registers
only if the register is equal to or smaller than one half the size of the
complex type.
The single register was chosen by the mips FUNCTION_ARG macro.
The problem can probably be fixed in either area. It isn't clear which is
best. We need to make sure that we emit correct ABI compliant code for this
case which may constrain the possible solutions.
Jim
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: single precision complex bug in g77 - was Testing g77 with LAPACK 3.0
1999-07-09 10:47 ` craig
@ 1999-07-31 23:33 ` Jeffrey A Law
1999-07-31 23:33 ` craig
0 siblings, 1 reply; 21+ messages in thread
From: Jeffrey A Law @ 1999-07-31 23:33 UTC (permalink / raw)
To: craig; +Cc: wilson, toon, egcs-bugs
In message < 19990709174723.18881.qmail@deer >you write:
> Then the only fundamental question remains: do we release 2.95 with
> g77 defaulting to -fno-emulate-complex, in which case we have to document
> whatever bugs we've learned as the result of several months' testing?
It's one option. but (IMHO) the more risky option.
> Or do we release it with g77 defaulting to -femulate-complex, in which
> case we release a largely *untested* product, *without* documentation
> of bugs that are likely to be present (but which we've pretty much ignored
> since switching to -fno-emulate-complex)?
Well, -fno-emulate-complex was the default until the last few months -- so
while it has not had a lot of formal testing _recently_, it has been tested
extensively over the years. We know where it is likely to fall down. I
believe
we can effectively get this stuff tested to verify we haven't botched the
-fno-emulate-complex support over the next few days by having folks build &
test lapack across a good mix of targets. We *know* lapack will beat on the
complex code :-)
> Or do we delay the release of 2.95 for a few months, during which we
> encourage everyone to respin all their testing, using a prerelease we
> make (which we can do by the end of the day, or thereabouts) with
> -femulate-complex the default?
I do not think any of our g77 tests really stress complex anyway -- so I
suspect that would be mostly a wasted effort.
jeff
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: single precision complex bug in g77 - was Testing g77 with LAPACK 3.0
1999-07-08 13:55 ` Toon Moene
@ 1999-07-31 23:33 ` Jim Wilson
1999-07-23 13:07 ` Toon Moene
0 siblings, 1 reply; 21+ messages in thread
From: Jim Wilson @ 1999-07-31 23:33 UTC (permalink / raw)
To: Toon Moene
Cc: Billinghurst, David (RTD), 'egcs-bugs@egcs.cygnus.com', craig
I haven't looked at this problem yet.
Jim
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: single precision complex bug in g77 - was Testing g77 with LAPACK 3.0
1999-07-07 5:31 single precision complex bug in g77 - was Testing g77 with LAPACK 3.0 Billinghurst, David (RTD)
@ 1999-07-31 23:33 ` Toon Moene
1999-07-31 23:33 ` Jim Wilson
0 siblings, 1 reply; 21+ messages in thread
From: Toon Moene @ 1999-07-31 23:33 UTC (permalink / raw)
To: Billinghurst, David (RTD); +Cc: 'egcs-bugs@egcs.cygnus.com', wilson
Billinghurst, David (RTD) wrote:
> Here is a test case.
Thanks for trimming this down. Unfortunately (as was to be expected) it
doesn't fail on my i686-pc-linux-gnu system - it prints nothing, and not
just because I called the executable `test' :-)
> ############################################################
> program labug3
> implicit none
>
> * This program gives the wrong answer on mips-sgi-irix6.5
> * when compiled with g77 from egcs-19990629 (gcc 2.95 prerelease)
> *
> * Works with: -femulate-complex
> * egcs-1.1.2
> *
> * Originally derived from LAPACK 3.0 test suite.
> *
> * David Billinghurst, (David.Billinghurst@riotinto.com.au)
> * 7 July 1999
> *
> complex one, z
> real a,cabs1
> CABS1( Z) = ABS( REAL( Z)) + ABS( AIMAG(Z))
> one = (1.,0.)
> a = cabs1(one)
> if ( abs(a-one) .gt. 1.0e-5 ) then
> write(6,*) 'A should be 1.0'
> call abort()
> end if
> end
> ###############################################################
Could someone with an Alpha at hand try this example (it might be that
the problem is "Single precision COMPLEX on 64-bit target").
Some explanation:
CABS1( Z) = ABS( REAL( Z)) + ABS( AIMAG(Z))
is a "statement function" (sort of macro: the rhs is subsituted with z
replaced with whatever is the argument of cabs1). Note that both abs's
in this expression are REAL ones, because REAL(Z) and AIMAG(Z) are
REALS. Therefore, CABS1 (in spite of its name) is a REAL valued
statement function, as is expressed by the declaration "real cabs1".
Contrast this with the `abs' in "if ( abs(a-one) ...". The promotion
rules of Fortran make the expression `a-one' (which is of the type
REAL+COMPLEX) of type COMPLEX, so `abs(a-one)' is COMPLEX absolute value
of the result of CMPLX(a, 0.) - (1., 0.) = (0., 0.)
Even with gcc-2.95[-pre], g77 still codes a call to the libg2c routine
"c_abs" for computing the absolute value of a complex expression (I
didn't have the time to open code that one, in addition to complex
division - at least not before April 21).
I hope someone with an Alpha can help out (or a MIPS guru - if the above
explanation is sufficiently clear. Jim ?).
Thanks in advance,
--
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
The very last thing we want to do for this release is reinstate
-femulate-complex as the default.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: single precision complex bug in g77 - was Testing g77 with LAPACK 3.0
1999-07-31 23:33 ` Jeffrey A Law
@ 1999-07-31 23:33 ` craig
0 siblings, 0 replies; 21+ messages in thread
From: craig @ 1999-07-31 23:33 UTC (permalink / raw)
To: law; +Cc: craig
> In message < 19990709174723.18881.qmail@deer >you write:
> > Then the only fundamental question remains: do we release 2.95 with
> > g77 defaulting to -fno-emulate-complex, in which case we have to document
> > whatever bugs we've learned as the result of several months' testing?
>It's one option. but (IMHO) the more risky option.
It apparently had *zero* risk until this week, when a bug in (a new
version of?) LAPACK was finally found and reported.
So it can't be *that* risky. I've seen *many* reasonably-well-respected
products released under similar circumstances. I'd say GCC 2.95 could
well be fairly released so, given all the wonderful improvements in it
and the fact that, apparently, this new bug is *not* showing up as a
regression per se (though I concede there is reason to assume that it
will, once released to the user community, now that Jim has provided a
diagnosis of the problem).
I've also seen at least one nearly-useless version of gcc released,
made useless by the application of last-minute patches that had a major
effect on code generation, even though those effects were deemed "safe".
(Though I'm a bit hazy on the history, the point is, last-minute
changes carry great risk. What is being proposed here is probably
riskier than any previous last-minute change to gcc. The upside is
that it'll affect only g77, which is not the case with any attempt we
make at *fixing* the problem Jim identified.)
> > Or do we release it with g77 defaulting to -femulate-complex, in which
> > case we release a largely *untested* product, *without* documentation
> > of bugs that are likely to be present (but which we've pretty much ignored
> > since switching to -fno-emulate-complex)?
>Well, -fno-emulate-complex was the default until the last few months -- so
>while it has not had a lot of formal testing _recently_, it has been tested
>extensively over the years. We know where it is likely to fall down. I
>believe
>we can effectively get this stuff tested to verify we haven't botched the
>-fno-emulate-complex support over the next few days by having folks build &
>test lapack across a good mix of targets. We *know* lapack will beat on the
>complex code :-)
Okay, then, let's take a look at the relevant ChangeLog entries, shall we?
Here's the one where we changed the default (in g77):
Sat Apr 3 23:29:33 1999 Craig Burley <craig@jcb-sc.com>
* bugs.texi, g77.texi, lang-options.h, news.texi, top.c:
Make -fno-emulate-complex the default, as COMPLEX support
in the back end is now believed to be working.
Now, what has happened *in g77 alone* since then? Hmm, how about
*this* little change:
Sat Apr 17 13:53:43 1999 Craig Burley <craig@jcb-sc.com>
Rewrite to use block/scope structure of GBE and to ensure
variables (especially those going on stack/reg) are declared
before executable code generated:
* bld.c (ffebld_new_item, ffebld_new_one, ffebld_new_two):
Support new hooks.
* bld.h (ffebld_item_hook, ffebld_item_set_hook,
ffebld_nonter_hook, ffebld_nonter_set_hook): Ditto.
* bld.h (ffebld_basictype, ffebld_kind, ffebld_kindtype,
ffebld_rank, ffebld_where): New convenience macros (used
by rest of this patch).
* com.c, com.h (ffecom_push_calltemps, ffecom_pop_calltemps,
ffecom_push_tempvar, ffecom_pop_tempvar): Remove temp-var-
handling mechanism.
* com.c (ffecom_call_, ffecom_call_binop_, ffecom_tree_divide_,
ffecom_call_gfrt): Support passing hooks for temp-var info.
(ffecom_expr_power_integer_): Takes opPOWER expression, instead
of its left and right operands, so it can get at the hook.
(ffecom_prepare_let_char_, ffecom_prepare_arg_ptr_to_expr,
ffecom_prepare_end, ffecom_prepare_expr_, ffecom_prepare_expr_rw,
ffecom_prepare_expr_w, ffecom_prepare_return_expr,
ffecom_prepare_ptr_to_expr): New functions supporting expression
pre-scanning.
(bison_rule_compstmt_): Return the tree, as in the CFE.
(delete_block): New function, from CFE.
(kept_level_p): New function, from CFE, modified.
(ffecom_start_compstmt, ffecom_end_compstmt): New functions,
replacing ffecom_start_compstmt_ and ffecom_end_compstmt_ macros,
and they do real work.
(struct binding_level): Add prep_state member. Initialize to 0.
(ffecom_get_invented_identifier): Now takes either or both a
string and an integer, using -1 to denote no integer.
(ffecom_do_entry_): Disallow temp-var generation via expressions
in body of function, since the exprs aren't prescanned.
(ffecom_expr_rw): Now takes destination tree.
(ffecom_expr_w): New function, now used in some places
ffecom_expr_rw had been used.
(ffecom_expr_intrinsic_): Move huge f2c-related comment to bottom
of source file, to avoid annoying problems editing com.c using
Emacs C-mode.
(ffecom_expr_power_integer_): Make a temp var for division, if
necessary.
Handle expanded statement expression as does CFE.
(ffecom_start_progunit_): Disallow temp-var generation in body
of function, since expressions are not prescanned at this level.
(ffecom_sym_transform_): Transform ASSIGN variables as well,
so these are all transformed up front, before code-generation
begins.
(ffecom_arg_ptr_to_const_expr, ffecom_const_expr,
ffecom_ptr_to_const_expr): New functions to transform expressions
only if the results will surely be constants.
(ffecom_arg_ptr_to_expr): Precompute size, for convenience
obtaining temp vars.
(ffecom_expand_let_stmt): Guess at usability of destination
pre-expansion, to provide better prescan preparation (fewer
spurious temp vars).
(ffecom_init_0): Disallow temp-var generation in global scope.
(ffecom_type_expr): New function, returns just the type tree
for the expression.
(start_function): Disallow temp-var generation in parm scope.
(incomplete_type_error): Fix introductory comment.
(poplevel): Update (somewhat) from CFE.
(pushlevel): Update (somewhat) from CFE.
* stc.c (ffestc_R838): Mark ASSIGNed variable as so.
* std.c (ffestd_stmt_pass_, ffestd_R803, ffestd_R804, ffestd_R805,
ffestd_R806): Remember and pass through the ffestw block info
for these (IFTHEN, ELSEIF, ELSE, and ENDIF) statements.
* ste.c (ffeste_end_iterdo_): Now takes ffestw block argument.
(ffeste_io_inlist_): Add prototype.
(ffeste_f2c_*): Macros rewritten, new ones added.
(ffeste_start_block_, ffeste_end_block_, ffeste_start_stmt_,
ffeste_end_stmt_): New macros/functions, depending on whether
checking is enabled, to keep track of symmetry of other ste.c code.
(ffeste_begin_iterdo_, ffeste_end_iterdo_, ffeste_io_impdo_,
ffeste_io_dofio_, ffeste_io_dolio_, ffeste_io_douio_,
ffeste_io_ialist_, ffeste_io_cilist_, ffeste_io_cllist_,
ffeste_icilist_, ffeste_io_inlist_, ffeste_io_olist_,
ffeste_subr_beru_, ffeste_do, ffeste_end_R807, ffeste_R737A,
ffeste_R803, ffeste_R804, ffeste_R805, ffeste_R806, ffeste_R807,
ffeste_R809, ffeste_R810, ffeste_R811, ffeste_R819A, ffeste_R819B,
ffeste_R837, ffeste_R838, ffeste_R839, ffeste_R840, ffeste_R904,
ffeste_R907, ffeste_R909_start, ffeste_R909_item, ffeste_R909_finish,
ffeste_R910_start, ffeste_R910_item, ffeste_R910_finish,
ffeste_R911_start, ffeste_R911_item, ffeste_R911_finish,
ffeste_R923A, ffeste_R1212, ffeste_R1227): Prescan/prepare
all pertinent expressions, update to new com.c interface, etc.
(ffeste_io_impdo_): Relocate.
(ffeste_R834, ffeste_R835, ffeste_R836, ffeste_R1226): Don't
bother calling clear_momentary, nothing was generated.
(ffeste_R842, ffeste_R843): Update to new com.c interface.
(ffeste_R1226): Don't try to stuff error_mark_node's DECL_INITIAL.
(ffeste_terminate_2): When checking enabled, make sure all blocks
and statements have been ended.
* ste.h (ffeste_R803, ffeste_R804, ffeste_R805, ffeste_R806):
These now take ffestw block argument.
(ffeste_terminate_2): When checking enabled, it's a function, not
a macro.
* stw.h (struct _ffestw_): New variable for IFTHEN.
(ffestw_ifthen_fake_else, ffestw_set_ifthen_fake_else): New
accessor macros.
* symbol.c, symbol.h: Support new ASSIGN'ed-to info.
* com.c: Clean up commentary per GNU coding standards.
* bld.h (ffebld_size, ffebld_size_known): Canonize.
Hmm, okay, not bad, hardly *anything* changed there, eh?
Seriously, though, let's assume all that was a nearly *perfect* effort
on my part, in that there were no new bugs introduced -- certainly nothing
that would cause options relating to purely-code-gen issues to interact
unexpectedly with those changes.
Well, let's not make *too* quick an assumption. For example, again,
in *normal* chronological order:
Mon Apr 19 21:36:48 1999 Craig Burley <craig@jcb-sc.com>
* ste.c (ffeste_R819B): Start the loop before expanding
the termination expression.
Sun May 2 16:53:01 1999 Craig Burley <craig@jcb-sc.com>
Fix compile/19990502-1.f:
* ste.c (ffeste_R819B): Don't overwrite tree for temp
variable when expanding the assignment into it.
Okay, so I blew some statement-level issues, hardly a level likely
to interact strongly with -femulate-complex, I would tend to think.
But, surely there were no pertinent changes to COMPLEX code *per se*
since we changed the default, right?
Well, think again:
Sun Apr 25 20:55:10 1999 Craig Burley <craig@jcb-sc.com>
Fix 19990325-0.f and 19990325-1.f:
* com.c (ffecom_possible_partial_overlap_): New function.
(ffecom_expand_let_stmt): Use it to determine whether to assign
to a COMPLEX operand through a temp.
* news.texi: Document fix.
Wow, a whole new function, invoked for assignments to COMPLEX! And
probably 1% of the testing of that new code has been with -femulate-complex,
assuming anybody has been testing g77 with that option since we changed
the default.
But, still, surely, there's little likelihood of a bug still *lurking*
in that big rewrite, which would be exposed by this change? I mean,
if there were newly introduced latent bugs exposed by specific command-
line options, we would have noticed them by now, correct?
Oh, again, I spoke too soon:
Mon Jun 28 10:43:11 1999 Craig Burley <craig@jcb-sc.com>
* com.c (ffecom_prepare_expr_): A COMPLEX intrinsic needs
a temp even if -fno-f2c.
Yup, that's right, a *regression* (IIRC) due to that big rewrite up above,
a bug not noticed (since it didn't occur) until someone tried -fno-f2c.
(-fno-f2c makes simple changes to how COMPLEX values are returned by
functions, mainly. Just like -femulate-complex makes simple changes to
how COMPLEX values are represented to the back end. Well, not as simple
as the changes made by -fno-f2c, ISTR.)
Well, at least there's no worries with regard to *arrays* of COMPLEX,
which surely is the big area of concern. I mean, it's not like there
have been many changes to how g77 handles *arrays* since we changed
the default, have there?
Uh oh:
Fri Apr 23 01:48:28 1999 Craig Burley <craig@jcb-sc.com>
Support new -fsubscript-check and -ff2c-subscript-check options:
* com-rt.def (FFECOM_gfrtRANGE): Describe s_rnge, in libf2c/libF77.
* com.c (ffecom_subscript_check_, ffecom_arrayref_): New functions.
(ffecom_char_args_x_): Use new ffecom_arrayref_ function for
FFEBLD_opARRAYREF case.
Compute character name, array type, and use new
ffecom_subscript_check_ function for FFEBLD_opSUBSTRING case.
(ffecom_expr_): Use new ffecom_arrayref_ function.
(ffecom_ptr_to_expr): Use new ffecom_arrayref_ function.
* g77.texi, news.texi: Document new options.
* top.c, top.h: Support new options.
Thu May 13 12:23:20 1999 Craig Burley <craig@jcb-sc.com>
Fix INTEGER*8 subscripts in array references:
* com.c (ffecom_subscript_check_): Convert low, high, and
element as necessary to make comparison work.
(ffecom_arrayref_): Do more of the work.
Properly handle subscript expr that's wider than int,
if pointers are wider than int.
(ffecom_expr_): Leave more work to ffecom_arrayref_.
(ffecom_init_0): Record sizes of pointers and ints for
convenience.
Use set_sizetype etc. as done by gcc front end.
(ffecom_ptr_to_expr): Leave more work to ffecom_arrayref_.
* expr.c (ffeexpr_finished_): Don't convert INTEGER subscript
expressions in run-time contexts.
(ffeexpr_token_elements_, ffeexpr_token_substring_1_): Cope with
non-default INTEGER subscript expressions.
* news.texi: Announce.
Sigh, well, given what I know about those changes, they should *generally*
not involve much of the new code triggering unless the user does something
outside of "regression" range, i.e. specifies -fbounds-check or uses
an INTEGER*8 subscript. Still, there's *some* changes in there that
at least test for these things....
How about basic math operations, nothing big changed there, right?
Oops:
Tue May 18 03:52:04 1999 Craig Burley <craig@jcb-sc.com>
Support use of back end's improved open-coding of complex divide:
* com.c (ffecom_tree_divide_): Use RDIV_EXPR for complex divide,
instead of run-time call to [cz]_div, if `-Os' option specified.
Okay, let's hope *that* correctly has no effect when -femulate-complex,
at least...presumably if it did, anyone trying any real COMPLEX code
with that option would have stumbled across it already.
Now, that's all work done by *me*, by my lonesome, on g77, in the past
few months since making that change. Pretty much without breaking a
sweat, working 80-hour weeks, or anything like that.
Given that *far* more people have been making *far* more changes in the
gcc back end since that change...
...are you *still* confident that making -femulate-complex the default
at the last moment and running the few g77 tests we can will be sufficient
to avoid any *significant* new regressions as experienced by the field?
I sure as heck am not.
> > Or do we delay the release of 2.95 for a few months, during which we
> > encourage everyone to respin all their testing, using a prerelease we
> > make (which we can do by the end of the day, or thereabouts) with
> > -femulate-complex the default?
>I do not think any of our g77 tests really stress complex anyway -- so I
>suspect that would be mostly a wasted effort.
Right, *our* g77 tests are not worth much (yet), and *mine* aren't worth
much more in a case like this (as they don't involve running, or even
linking, code -- they just make it easy to spot new ICEs and, when changes
are believed to not affect assembly code generation, spot unexpected
occurrences of that).
So a last-minute change followed by a bit of testing (which, I agree,
including LAPACK would be crucial), hardly gives me confidence we won't
discover some *very* embarrassing revelations.
Still, as I say, it's your call. I don't mind the performance hit (since
people are used to -femulate-complex anyway, in official releases) much,
so that's not nearly as important a factor (to me) as minimizing regressions
in 2.95 vis-a-vis EGCS 1.1.2.
tq vm, (burley)
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: single precision complex bug in g77 - was Testing g77 with LAPACK 3.0
1999-07-31 23:33 ` Jim Wilson
1999-07-08 13:55 ` Toon Moene
@ 1999-07-31 23:33 ` Jeffrey A Law
1999-07-31 23:33 ` craig
1 sibling, 1 reply; 21+ messages in thread
From: Jeffrey A Law @ 1999-07-31 23:33 UTC (permalink / raw)
To: Jim Wilson; +Cc: Toon Moene, craig, 'egcs-bugs@egcs.cygnus.com'
In message < 199907080032.RAA26170@rtl.cygnus.com >you write:
> Using current egcs development sources, it works if I compile with -O, and
> fails without.
>
> Without optimization, it is a calling convention problem. We try to pass
> a single precision complex to the function cabs1.0, which requires loading
> two SFmode values. We generate RTL to load them both into the same registe
> r
> and this code obviously doesn't work.
>
> (insn 26 24 28 (set (reg:SF 4 a0)
> (mem/f:SF (reg:SI 77) 0)) -1 (nil)
> (nil))
>
> (insn 28 26 30 (set (reg:SF 4 a0)
> (mem/f:SF (plus:SI (reg:SI 77)
> (const_int 4 [0x4])) 0)) -1 (nil)
> (nil))
Ouch.
> This has always been a problem with the complex support. There was some
> discussion last year about trying to fix this in the alpha port, but I
don't
> know what came of that.
I don't think it was ever resolved. There's quite a few issues with this
stuff.
> which emits two loads into the same register when x is a register big
> enough to hold the entire complex value. This code can work for registers
> only if the register is equal to or smaller than one half the size of the
> complex type.
>
> The single register was chosen by the mips FUNCTION_ARG macro.
Right. Note that FUNCTION_ARG is always going to return a single register
for a complex value since we only call FUNCTION_ARG for the complex value as
a whole, not its subcomponents.
Similarly for FUNCTION_ARG_ADVANCE, FUNCTION_ARG_PARTIAL_NWORDS, etc etc.
This is somewhat contrary to how we treat complex stuff elsewhere -- ie, in
most other places we try to treat the real and imag part independently. If
we followed that convention for arguments, then we would want to treat
an SCmode parameter as two independent SFmode parameters.
> The problem can probably be fixed in either area. It isn't clear which is
> best. We need to make sure that we emit correct ABI compliant code for
> this case which may constrain the possible solutions.
I think we should be splitting up the complex stuff into independent
parameters (assuming no external constraint which requires us to treat it as
a single parameter).
Consider an SCmode argument on a machine which passes FP args in FP regs and
has 64bit wide FP regs. Do we pack the two halfs of the SCmode argument into
the upper and lower half of a 64bit FP register? I hope not, that's a major
pain.
If we agree that we should not be "packing", then the question becomes do we
split up the SCmode parameter before calling the FUNCTION_* macros.
If we do not split it up, then all the targets which define FUNCTION_* macros
will need to be updated since most assume that if you have an argument of N
bits that it is a single argument of N bits, not two independent arguments of
N/2 bits. ie, we have to teach the FUNCTION_* macros that an SCmode parameter
may actually take up 2 64bit FP regs in the example cited above, even though an
SCmode is only 64bits wide.
I'm leery of trying to get either change into the release branch this late in
the game. As painful as it may be, I suspect we may be better off using
-femulate-complex for gcc-2.95.
jeff
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: single precision complex bug in g77 - was Testing g77 with LAPACK 3.0
1999-07-31 23:33 ` Jeffrey A Law
@ 1999-07-31 23:33 ` craig
1999-07-09 9:24 ` Jeffrey A Law
1999-07-09 11:21 ` Toon Moene
0 siblings, 2 replies; 21+ messages in thread
From: craig @ 1999-07-31 23:33 UTC (permalink / raw)
To: law; +Cc: craig
>I'm leery of trying to get either change into the release branch this late in
>the game. As painful as it may be, I suspect we may be better off using
>-femulate-complex for gcc-2.95.
I think not, because ISTR seeing a few bug reports involving crashes
with -femulate-complex in effect that we basically handwaved as no
longer pertinent because of our changing the default. They might have
been on popular machines like IA32, but I don't recall clearly.
And, we changed the default *months* ago, so, according to the rules
we normally employ about release cycles, bugs found this late must
not have been that important (else they'd have been found earlier).
In this case, I hesitate to "spin" *this* bug in that fashion, because
I believe it *is* important.
However, I think it's better to ship with -fno-emulate-complex in effect
and say "it still isn't quite working on Alphas, e.g. compiling LAPACK
and maybe other code, try -femulate-complex" -- hardly different from
what we've said in the past.
If we make -femulate-complex the default, we might well break (perhaps
by virtue of exposing, or re-exposing, latent bugs) lots of code on
other, e.g. 32-bit, platforms (IA32, m68k, SPARCv8, etc.) -- code that,
we hope at least, has already been thoroughly tested during this release
cycle.
Given my serious reservations concerning g77's viability on the Alpha
(see my other emails), and the fact that g77 still has known problems
with 64-bit systems (e.g. it doesn't work with `-mabi=64', supported
by some configuration(s)), I think it's best to document what we've
found to date (i.e. swallow it).
tq vm, (burley)
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: single precision complex bug in g77 - was Testing g77 with LAPACK 3.0
1999-07-31 23:33 ` Toon Moene
@ 1999-07-31 23:33 ` Jeffrey A Law
0 siblings, 0 replies; 21+ messages in thread
From: Jeffrey A Law @ 1999-07-31 23:33 UTC (permalink / raw)
To: Toon Moene; +Cc: R. Kelley Cook, egcs-bugs
In message < 37999EB8.81713919@moene.indiv.nluug.nl >you write:
> > Wed Jul 14 23:28:06 1999 Jeffrey A Law (law@cygnus.com)
>
> > * emit-rtl.c (gen_realpart): Issue an error for cases GCC can not
> > handle at this time instead of silently generating incorrect code
> .
> > (gen_imagpart): Likewise.
>
> You are right - I was searching for the keyword "complex" but the
> ChangeLog entry doesn't contain it ...
>
> The change is indeed in (just checked emit-rtl.c).
Phew. I saw this thread while I was on the road and didn't have time to
investigate. Thanks for checking it out.
jeff
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: single precision complex bug in g77 - was Testing g77 with LAPACK 3.0
1999-07-31 23:33 R. Kelley Cook
@ 1999-07-31 23:33 ` Toon Moene
1999-07-31 23:33 ` Jeffrey A Law
0 siblings, 1 reply; 21+ messages in thread
From: Toon Moene @ 1999-07-31 23:33 UTC (permalink / raw)
To: R. Kelley Cook; +Cc: egcs-bugs
R. Kelley Cook wrote:
> On 23 Jul 1999 22:07:49 +0200, Toon Moene wrote:
> >Did you manage to provoke an ICE with it (now that Jeff has made changes
> >to abort the compiler for certain accesses to components of complex
> >numbers) ?
> >See his patch at:
> > http://egcs.cygnus.com/ml/gcc-patches/1999-07/msg00353.html
> >[ Hmmm, as far as the ChangeLog for gcc-2.95 goes, this doesn't seem
> > to be applied ... ]
> My current ChangeLog does have:
> Wed Jul 14 23:28:06 1999 Jeffrey A Law (law@cygnus.com)
> * emit-rtl.c (gen_realpart): Issue an error for cases GCC can not
> handle at this time instead of silently generating incorrect code.
> (gen_imagpart): Likewise.
You are right - I was searching for the keyword "complex" but the
ChangeLog entry doesn't contain it ...
The change is indeed in (just checked emit-rtl.c).
--
Toon Moene (toon@moene.indiv.nluug.nl)
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
Phone: +31 346 214290; Fax: +31 346 214286
GNU Fortran: http://world.std.com/~burley/g77.html
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: single precision complex bug in g77 - was Testing g77 with LAPACK 3.0
@ 1999-07-31 23:33 R. Kelley Cook
1999-07-31 23:33 ` Toon Moene
0 siblings, 1 reply; 21+ messages in thread
From: R. Kelley Cook @ 1999-07-31 23:33 UTC (permalink / raw)
To: egcs-bugs
On 23 Jul 1999 22:07:49 +0200, Toon Moene wrote:
>Jim Wilson wrote:
>
>> I haven't looked at this problem yet.
>
>Did you manage to provoke an ICE with it (now that Jeff has made changes
>to abort the compiler for certain accesses to components of complex
>numbers) ?
>
>See his patch at:
>
> http://egcs.cygnus.com/ml/gcc-patches/1999-07/msg00353.html
>
>[ Hmmm, as far as the ChangeLog for gcc-2.95 goes, this doesn't seem
> to be applied ... ]
My current ChangeLog does have:
Wed Jul 14 23:28:06 1999 Jeffrey A Law (law@cygnus.com)
* emit-rtl.c (gen_realpart): Issue an error for cases GCC can not
handle at this time instead of silently generating incorrect code.
(gen_imagpart): Likewise.
^ permalink raw reply [flat|nested] 21+ messages in thread
* RE: single precision complex bug in g77 - was Testing g77 with LAPACK 3.0
@ 1999-07-31 23:33 Billinghurst, David (RTD)
0 siblings, 0 replies; 21+ messages in thread
From: Billinghurst, David (RTD) @ 1999-07-31 23:33 UTC (permalink / raw)
To: 'Toon Moene'; +Cc: 'egcs-bugs@egcs.cygnus.com', wilson
Precisely. On reading this I realised the error test should be real vs real
if ( abs(a-1.0) .gt. 1.0e-5 ) then
This doesn't change the result. Still get a == 0.0 but expect a == 1.0
> -----Original Message-----
> From: Toon Moene [SMTP:toon@moene.indiv.nluug.nl]
> Sent: Thursday, 8 July 1999 6:12
> To: Billinghurst, David (RTD)
> Cc: 'egcs-bugs@egcs.cygnus.com'; wilson@cygnus.com
> Subject: Re: single precision complex bug in g77 - was Testing g77
> with LAPACK 3.0
>
> Billinghurst, David (RTD) wrote:
>
> > Here is a test case.
>
> Thanks for trimming this down. Unfortunately (as was to be expected) it
> doesn't fail on my i686-pc-linux-gnu system - it prints nothing, and not
> just because I called the executable `test' :-)
>
> > ############################################################
> > program labug3
> > implicit none
> >
> > * This program gives the wrong answer on mips-sgi-irix6.5
> > * when compiled with g77 from egcs-19990629 (gcc 2.95 prerelease)
> > *
> > * Works with: -femulate-complex
> > * egcs-1.1.2
> > *
> > * Originally derived from LAPACK 3.0 test suite.
> > *
> > * David Billinghurst, (David.Billinghurst@riotinto.com.au)
> > * 7 July 1999
> > *
> > complex one, z
> > real a,cabs1
> > CABS1( Z) = ABS( REAL( Z)) + ABS( AIMAG(Z))
> > one = (1.,0.)
> > a = cabs1(one)
> > if ( abs(a-one) .gt. 1.0e-5 ) then
> > write(6,*) 'A should be 1.0'
> > call abort()
> > end if
> > end
> > ###############################################################
>
> Could someone with an Alpha at hand try this example (it might be that
> the problem is "Single precision COMPLEX on 64-bit target").
>
> Some explanation:
>
> CABS1( Z) = ABS( REAL( Z)) + ABS( AIMAG(Z))
>
> is a "statement function" (sort of macro: the rhs is subsituted with z
> replaced with whatever is the argument of cabs1). Note that both abs's
> in this expression are REAL ones, because REAL(Z) and AIMAG(Z) are
> REALS. Therefore, CABS1 (in spite of its name) is a REAL valued
> statement function, as is expressed by the declaration "real cabs1".
>
> Contrast this with the `abs' in "if ( abs(a-one) ...". The promotion
> rules of Fortran make the expression `a-one' (which is of the type
> REAL+COMPLEX) of type COMPLEX, so `abs(a-one)' is COMPLEX absolute value
> of the result of CMPLX(a, 0.) - (1., 0.) = (0., 0.)
>
> Even with gcc-2.95[-pre], g77 still codes a call to the libg2c routine
> "c_abs" for computing the absolute value of a complex expression (I
> didn't have the time to open code that one, in addition to complex
> division - at least not before April 21).
>
> I hope someone with an Alpha can help out (or a MIPS guru - if the above
> explanation is sufficiently clear. Jim ?).
>
> Thanks in advance,
>
> --
> 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
>
> The very last thing we want to do for this release is reinstate
> -femulate-complex as the default.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: single precision complex bug in g77 - was Testing g77 with LAPACK 3.0
1999-07-13 18:58 Billinghurst, David (RTD)
@ 1999-07-14 1:19 ` craig
0 siblings, 0 replies; 21+ messages in thread
From: craig @ 1999-07-14 1:19 UTC (permalink / raw)
To: David.Billinghurst; +Cc: craig
>I didn't rebuild the compiler or libg2c with "-femulate-complex". Does this
>matter?
No. g77 and libg2c are written in C, so they don't change when g77's
*code* is changed, with certain very specific exceptions (involving
type-mapping from g77's header files to libg2c's f2c.h).
tq vm, (burley)
^ permalink raw reply [flat|nested] 21+ messages in thread
* RE: single precision complex bug in g77 - was Testing g77 with LAPACK 3.0
@ 1999-07-13 23:13 Billinghurst, David (RTD)
0 siblings, 0 replies; 21+ messages in thread
From: Billinghurst, David (RTD) @ 1999-07-13 23:13 UTC (permalink / raw)
To: 'law@cygnus.com'; +Cc: 'egcs-bugs@egcs.cygnus.com'
Here is some more data, to add to the confusion.
mips-sgi-irix6.5 g77 from egcs-19990629 snapshot fails LAPACK 2.0 testsuite
with -femulate-complex, but it passes with new default -fnoemulate-complex.
Both set of tests run with -O3 -funroll-loops
Aborts in single precision complex test with complex divide by zero error
I can usually reduce the problem to a few lines of code, but it takes
several hours.
> -----Original Message-----
> From: Jeffrey A Law [SMTP:law@cygnus.com]
> Sent: Wednesday, 14 July 1999 15:01
> To: Billinghurst, David (RTD)
> Cc: 'egcs-bugs@egcs.cygnus.com'
> Subject: Re: single precision complex bug in g77 - was Testing g77
> with LAPACK 3.0
>
>
> In message < A9E96A79C068D211A6A90000C07BDF0D1DE8FB@CRTSMAIL >you write:
> > I didn't rebuild the compiler or libg2c with "-femulate-complex".
> Does
> > this matter? I am happy to do it if someone can tell me how.
> Err, ignore my last message. libg2c is compiled with the C compiler, not
> the Fortran compiler, so any -femulate-complex/-fno-emulate-complex args
> won't make any difference for the libg2c library.
>
> jeff
>
>
>From rth@cygnus.com Tue Jul 13 23:25:00 1999
From: Richard Henderson <rth@cygnus.com>
To: Jeffrey A Law <law@cygnus.com>
Cc: martin.kahlert@provi.de, egcs-bugs@egcs.cygnus.com
Subject: Re: Showstopper in g77 in prerelease on Linux-Alpha
Date: Tue, 13 Jul 1999 23:25:00 -0000
Message-id: <19990713231752.A6353@cygnus.com>
References: <199907082138.XAA00190@keksy.linux.provi.de> <4496.931501897@upchuck.cygnus.com> <19990709020751.A11264@cygnus.com>
X-SW-Source: 1999-07/msg00512.html
Content-length: 5873
On Fri, Jul 09, 1999 at 02:07:51AM -0700, Richard Henderson wrote:
> (insn 76 75 78 (set (reg:DI 92)
> (fix:DI (reg:DF 91))) 122 {fix_truncdfdi2} (insn_list 75 (nil))
> (expr_list:REG_DEAD (reg:DF 91)
> (nil)))
>
> (insn 78 76 79 (set (reg:SI 81)
> (subreg:SI (reg:DI 92) 0)) 283 {movdf+1} (insn_list 76 (nil))
> (expr_list:REG_DEAD (reg:DI 92)
> (nil)))
>
> In global, reg 92 gets allocated to $f10, and isn't fixed up in
> reload, despite CLASS_CANNOT_CHANGE_SIZE and the subreg.
Regclass is at fault for suggesting that FLOAT_REGS is a viable
class for reg 92. The following rather direct solution works for
the problem as presented.
Something that should be attended to in mainline is that NINT
can often be implemented in one insn, rather than
if (x > 0)
result = (int) (x + 0.5);
else
result = (int) (x - 0.5);
At minimum on those that don't, we should rewrite this to
if (x > 0)
tmp = +0.5;
else
tmp = -0.5;
result = (int) (x + tmp);
or, if available,
tmp = copysign(0.5, x);
result = (int) (x + tmp);
just to factor the code a bit better.
r~
* regclass.c (scan_one_insn): Notice subregs that change the
size of their operand.
(record_reg_classes): Use that to obey CLASS_CANNOT_CHANGE_SIZE.
Index: regclass.c
===================================================================
RCS file: /egcs/carton/cvsfiles/egcs/gcc/regclass.c,v
retrieving revision 1.54
diff -c -p -d -r1.54 regclass.c
*** regclass.c 1999/02/25 23:45:28 1.54
--- regclass.c 1999/07/14 05:59:19
*************** static int loop_cost;
*** 693,699 ****
static rtx scan_one_insn PROTO((rtx, int));
static void record_reg_classes PROTO((int, int, rtx *, enum machine_mode *,
! const char **, rtx));
static int copy_cost PROTO((rtx, enum machine_mode,
enum reg_class, int));
static void record_address_regs PROTO((rtx, enum reg_class, int));
--- 693,699 ----
static rtx scan_one_insn PROTO((rtx, int));
static void record_reg_classes PROTO((int, int, rtx *, enum machine_mode *,
! char *, const char **, rtx));
static int copy_cost PROTO((rtx, enum machine_mode,
enum reg_class, int));
static void record_address_regs PROTO((rtx, enum reg_class, int));
*************** scan_one_insn (insn, pass)
*** 757,762 ****
--- 757,763 ----
enum rtx_code pat_code;
const char *constraints[MAX_RECOG_OPERANDS];
enum machine_mode modes[MAX_RECOG_OPERANDS];
+ char subreg_changes_size[MAX_RECOG_OPERANDS];
rtx set, note;
int i, j;
*************** scan_one_insn (insn, pass)
*** 794,799 ****
--- 795,801 ----
constraints[i] = recog_constraints[i];
modes[i] = recog_operand_mode[i];
}
+ memset (subreg_changes_size, 0, sizeof (subreg_changes_size));
/* If this insn loads a parameter from its stack slot, then
it represents a savings, rather than a cost, if the
*************** scan_one_insn (insn, pass)
*** 881,887 ****
op_costs[i] = init_cost;
if (GET_CODE (recog_operand[i]) == SUBREG)
! recog_operand[i] = SUBREG_REG (recog_operand[i]);
if (GET_CODE (recog_operand[i]) == MEM)
record_address_regs (XEXP (recog_operand[i], 0),
--- 883,894 ----
op_costs[i] = init_cost;
if (GET_CODE (recog_operand[i]) == SUBREG)
! {
! rtx inner = SUBREG_REG (recog_operand[i]);
! if (GET_MODE_SIZE (modes[i]) != GET_MODE_SIZE (GET_MODE (inner)))
! subreg_changes_size[i] = 1;
! recog_operand[i] = inner;
! }
if (GET_CODE (recog_operand[i]) == MEM)
record_address_regs (XEXP (recog_operand[i], 0),
*************** scan_one_insn (insn, pass)
*** 910,921 ****
xconstraints[i] = constraints[i+1];
xconstraints[i+1] = constraints[i];
record_reg_classes (recog_n_alternatives, recog_n_operands,
! recog_operand, modes, xconstraints,
! insn);
}
record_reg_classes (recog_n_alternatives, recog_n_operands, recog_operand,
! modes, constraints, insn);
/* Now add the cost for each operand to the total costs for
its register. */
--- 917,928 ----
xconstraints[i] = constraints[i+1];
xconstraints[i+1] = constraints[i];
record_reg_classes (recog_n_alternatives, recog_n_operands,
! recog_operand, modes, subreg_changes_size,
! xconstraints, insn);
}
record_reg_classes (recog_n_alternatives, recog_n_operands, recog_operand,
! modes, subreg_changes_size, constraints, insn);
/* Now add the cost for each operand to the total costs for
its register. */
*************** regclass (f, nregs)
*** 1131,1141 ****
alternatives. */
static void
! record_reg_classes (n_alts, n_ops, ops, modes, constraints, insn)
int n_alts;
int n_ops;
rtx *ops;
enum machine_mode *modes;
const char **constraints;
rtx insn;
{
--- 1138,1150 ----
alternatives. */
static void
! record_reg_classes (n_alts, n_ops, ops, modes, subreg_changes_size,
! constraints, insn)
int n_alts;
int n_ops;
rtx *ops;
enum machine_mode *modes;
+ char *subreg_changes_size;
const char **constraints;
rtx insn;
{
*************** record_reg_classes (n_alts, n_ops, ops,
*** 1393,1398 ****
--- 1402,1417 ----
}
constraints[i] = p;
+
+ #ifdef CLASS_CANNOT_CHANGE_SIZE
+ /* If we noted a subreg earlier, and the selected class is a
+ subclass of CLASS_CANNOT_CHANGE_SIZE, zap it. */
+ if (subreg_changes_size[i]
+ && (reg_class_subunion[(int) CLASS_CANNOT_CHANGE_SIZE]
+ [(int) classes[i]]
+ == CLASS_CANNOT_CHANGE_SIZE))
+ classes[i] = NO_REGS;
+ #endif
/* How we account for this operand now depends on whether it is a
pseudo register or not. If it is, we first check if any
>From martin@mira.isdn.cs.tu-berlin.de Wed Jul 14 00:18:00 1999
From: "Martin v. Loewis" <martin@mira.isdn.cs.tu-berlin.de>
To: hockney@ns.altadena.net
Cc: egcs-bugs@egcs.cygnus.com
Subject: Re: interaction between namespaces, templates, and virtual functions
Date: Wed, 14 Jul 1999 00:18:00 -0000
Message-id: <199907140653.IAA00560@mira.isdn.cs.tu-berlin.de>
References: <199907132129.OAA01744@ns.altadena.net>
X-SW-Source: 1999-07/msg00513.html
Content-length: 208
> // An amusing interaction between namespaces, templates, and virtual
> functions
Thanks for your bug report. gcc-2.95 19990701 compiles it fine, so it
appears that the bug has been fixed.
Regards,
Martin
>From martin.kahlert@mchp.siemens.de Wed Jul 14 01:15:00 1999
From: Martin Kahlert <martin.kahlert@mchp.siemens.de>
To: Toon Moene <toon@moene.indiv.nluug.nl>
Cc: craig@jcb-sc.com, egcs-bugs@egcs.cygnus.com
Subject: Re: Bug with g77 and -mieee on Alpha Linux
Date: Wed, 14 Jul 1999 01:15:00 -0000
Message-id: <19990714101440.C17684@keksy.mchp.siemens.de>
References: <3783B4B1.89DC2124@moene.indiv.nluug.nl> <19990708135500.12573.qmail@deer> <3784BE26.D14F95CD@blueskystudios.com> <19990708155845.13652.qmail@deer> <19990708111645.A6051@cygnus.com> <37850FE1.94D5B63D@moene.indiv.nluug.nl> <19990709021223.16356.qmail@deer> <3785E797.F6809570@moene.indiv.nluug.nl> <19990709152312.18370.qmail@deer> <37863D4F.287AF653@moene.indiv.nluug.nl>
X-SW-Source: 1999-07/msg00514.html
Content-length: 4200
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
>From law@cygnus.com Wed Jul 14 01:17:00 1999
From: Jeffrey A Law <law@cygnus.com>
To: Alexandre Oliva <oliva@dcc.unicamp.br>
Cc: Richard Henderson <rth@cygnus.com>, egcs-bugs@egcs.cygnus.com, egcs-patches@egcs.cygnus.com
Subject: Re: shared libstdc++ is broken on alphaev56-dec-osf4.0d
Date: Wed, 14 Jul 1999 01:17:00 -0000
Message-id: <14182.931940172@upchuck.cygnus.com>
References: <orn1x0mbaq.fsf@cupuacu.lsd.dcc.unicamp.br>
X-SW-Source: 1999-07/msg00515.html
Content-length: 3096
In message < orn1x0mbaq.fsf@cupuacu.lsd.dcc.unicamp.br >you write:
> [Time passes...]
>
> I've just checked libstdc++.so again, and, to my surprise, it is
> indeed complete. I don't know what mistake I made when I verified it
> was not, just before submitting my patch, but now that I see it is
> indeed complete, I agree the patch I posted is not the way to go.
Weird. Real weird.
> How about linking the entire libgcc.a into libstdc++.so, with `-all
> -lgcc', so that g++ doesn't explicitly link with -lgcc? Would that be
> reasonable for 2.95.1?
Ewww. Actually, this is bad too since all code which uses libstdc++ will
then expect libstdc++ to provide all symbols from libgcc. Later if we fix
the problem we're going to gratuitiously break lots of code that did not
get its own copy of any libgcc routines because libstdc++ had all of libgcc
and exported everything.
> AFAICT, there are only three ways to prevent this: (i) link with
> `-hidden -lgcc', so that symbols from libgcc are made local to the
> shared library; this is a problem because then we can have multiple
> separate definitions of the same symbols; or (ii) arrange that libgcc
> is shared, so that symbols are not copied, but libstdc++ is noted to
> depend on libgcc; I know there are reasons to prefer not to do it. So
> I don't see any way out :-(
It really is a *(&@#$)(* mess and no matter what you do, you're just going to
trade one set of bugs for another. Thus my reluctance to do anything since
no solution is clearly better than the others. If I had to choose one, it
would be (i). I believe that is the one with the least amount of problems
(though it runs into the same problems as your suggestion of linking in
all of libgcc.a -- it's a huge binary compatibility issue problem.
> But wait! Instead of trying to hide the problem, I tried to find out
> why it happened. It turned out that, if I forced certain symbols from
> libgcc to be copied to libstdc++ (for example, __pure_virtual, used by
> nest21.C), the multiple-definition errors would stop being flagged!
> It appears that, when the linker gets to libgcc looking for
> __pure_virtual, other symbols referred in that object file become
> `undefined', even though they're present in libstdc++ that had already
> been scanned. But then, when it finds the symbols in libgcc.a, it
> ``remembers'' they were already defined in libstdc++.so, and reports
> them as duplicates. A linker bug. :-(
Then let's report it to dec/compaq/whomever, get it fixed and avoid the
issues entirely instead of trying to hack around it.
> Fortunately, the work around is straightforward. Attached is a
> candidate patch, that has produced good results in initial testing.
> I'm running check at this very moment, but I have to leave before it
> finishes, so it may turn out that one or two additional symbols would
> be needed. How does this look for 2.95?
Not for gcc-2.95. There's way too much risk, too many unknowns, etc etc.
No way. Sorry. *Maybe* for gcc-2.95.1. *MAYBE*.
jeff
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: single precision complex bug in g77 - was Testing g77 with LAPACK 3.0
@ 1999-07-13 22:02 Jeffrey A Law
0 siblings, 0 replies; 21+ messages in thread
From: Jeffrey A Law @ 1999-07-13 22:02 UTC (permalink / raw)
To: Billinghurst, David (RTD); +Cc: 'egcs-bugs@egcs.cygnus.com'
In message < A9E96A79C068D211A6A90000C07BDF0D1DE8FB@CRTSMAIL >you write:
> I didn't rebuild the compiler or libg2c with "-femulate-complex". Does
> this matter? I am happy to do it if someone can tell me how.
Err, ignore my last message. libg2c is compiled with the C compiler, not
the Fortran compiler, so any -femulate-complex/-fno-emulate-complex args
won't make any difference for the libg2c library.
jeff
^ permalink raw reply [flat|nested] 21+ messages in thread
* RE: single precision complex bug in g77 - was Testing g77 with LAPACK 3.0
@ 1999-07-13 18:58 Billinghurst, David (RTD)
1999-07-14 1:19 ` craig
0 siblings, 1 reply; 21+ messages in thread
From: Billinghurst, David (RTD) @ 1999-07-13 18:58 UTC (permalink / raw)
To: 'egcs-bugs@egcs.cygnus.com'
I see this problem has raised a real can of worms, and you are now
considering
changing the default behavior for g77 back to "-femulate-complex".
I have rerun the LAPACK-3.0 testsuite on mips-sig-irix6.5 with
-femulate-complex,
and get a similar number of failures in the single precision complex tests.
Consequently:
we pass the LAPACK-2.0 testsuite with -femulate-complex
we fail the (new) LAPACK-3.0 testsuite either way
I didn't rebuild the compiler or libg2c with "-femulate-complex". Does this
matter?
I am happy to do it if someone can tell me how.
+++++++++++++++++++++++++++++++++++++++++
(Mr) David Billinghurst
Comalco Research Centre
PO Box 316, Thomastown, Vic, Australia, 3074
Phone: +61 3 9469 0642
FAX: +61 3 9462 2700
Email: David.Billinghurst@riotinto.com.au
^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~1999-07-31 23:33 UTC | newest]
Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1999-07-07 5:31 single precision complex bug in g77 - was Testing g77 with LAPACK 3.0 Billinghurst, David (RTD)
1999-07-31 23:33 ` Toon Moene
1999-07-31 23:33 ` Jim Wilson
1999-07-08 13:55 ` Toon Moene
1999-07-31 23:33 ` Jim Wilson
1999-07-23 13:07 ` Toon Moene
1999-07-31 23:33 ` Jeffrey A Law
1999-07-31 23:33 ` craig
1999-07-09 9:24 ` Jeffrey A Law
1999-07-09 10:47 ` craig
1999-07-31 23:33 ` Jeffrey A Law
1999-07-31 23:33 ` craig
1999-07-09 11:21 ` Toon Moene
1999-07-13 18:58 Billinghurst, David (RTD)
1999-07-14 1:19 ` craig
1999-07-13 22:02 Jeffrey A Law
1999-07-13 23:13 Billinghurst, David (RTD)
1999-07-31 23:33 R. Kelley Cook
1999-07-31 23:33 ` Toon Moene
1999-07-31 23:33 ` Jeffrey A Law
1999-07-31 23:33 Billinghurst, David (RTD)
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).