public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* Internal compiler error 980711
@ 2000-07-27  7:37 Andy Henson
  0 siblings, 0 replies; 33+ messages in thread
From: Andy Henson @ 2000-07-27  7:37 UTC (permalink / raw)
  To: gcc-bugs

I got this error (Internal compiler error 980711) when compiling a simple 
class.  It appears to be the use of std::queue<> when the include file 
<queue> had not been included.

I've simplfied the program down to 4 lines and I can still reproduce it:
---------------------------cut here----------------------------------
class SerialStream
{
	std::queue<int*> q;
};
---------------------------cut here----------------------------------

Version stuff:

GNU C++ version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release) 
(i386-redhat-linux) compiled by GNU C version egcs-2.91.66 19990314/Linux 
(egcs-1.1.2 release).

actual error message:

tstie.cpp:3: Internal compiler error 980711.
class SerialStream
{
	std::queue<int*> q;
};


^ permalink raw reply	[flat|nested] 33+ messages in thread

* Internal compiler error 980711
@ 2000-05-19 14:49 Randolph Bentson
  0 siblings, 0 replies; 33+ messages in thread
From: Randolph Bentson @ 2000-05-19 14:49 UTC (permalink / raw)
  To: bug-gcc

[-- Attachment #1: Type: text/plain, Size: 121 bytes --]

egcs-2.91.66

Red Hat Linux release 6.2 (Zoot)
Kernel 2.2.14-5.0 on an i686

c++ -v --save-temps -O2 -w -c secshare.cpp


[-- Attachment #2: secshare.ii.bz2 --]
[-- Type: application/x-bzip2, Size: 50644 bytes --]

^ permalink raw reply	[flat|nested] 33+ messages in thread

* Internal compiler error 980711
@ 1999-12-31 20:54 Martin Trautmann
  1999-12-31 20:54 ` Martin v. Loewis
  0 siblings, 1 reply; 33+ messages in thread
From: Martin Trautmann @ 1999-12-31 20:54 UTC (permalink / raw)
  To: egcs-bugs

Hello,

I don't give a full bugreport here because I assume that this bug is
already known. In case it isn't please contact me.
I always get the "Internal compiler error 980711" when I use a class of
the STL-library (that is included in the ISO C++ Standard) and forget to
include the according Header-File. (for example std::list<MyClass> or
std::queue<Myclass*> ...)

This is the Version output:
martin@k6_2_300:~ > g++ --version
egcs-2.91.66
martin@k6_2_300:~ >

I have another question:
I have the german version of the Book "The C++ Programming Language"
from Bjarne Stroustup and I suppose that the content discribes the ISO
C++ Standard. The problem is that there is a little differance to my
compiler. I doesn't have an include-file called <sstream> so I cannot
use the classes istringstream and ostringstream.
Another minor problem is that the compiler doesn't mind when I forget
the namespace std by string for example. This is a problem because I
want to write portable programs and I would like to have a compiler that
at least warns me when I use nonstandard expressions.
What (gnu) compiler or library do I need to get a compiler that is most
compatible to the ISO C++ Standard? 

Thank you for your help.

virtually

Martin Trautmann

P.S: please excuse my bad english


^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: Internal compiler error 980711
  1999-12-31 20:54 Martin Trautmann
@ 1999-12-31 20:54 ` Martin v. Loewis
  0 siblings, 0 replies; 33+ messages in thread
From: Martin v. Loewis @ 1999-12-31 20:54 UTC (permalink / raw)
  To: martintrautmann; +Cc: egcs-bugs

> I don't give a full bugreport here because I assume that this bug is
> already known.

Thanks for your bug report. Most likely, this is fixed in gcc 2.95.2.

> I doesn't have an include-file called <sstream> so I cannot use the
> classes istringstream and ostringstream.

This is a known problem; g++ does not fully support the standard
library. You can use <strstream> meanwhile, which gives a stream class
operating on char* (instead of std::string).

> Another minor problem is that the compiler doesn't mind when I
> forget the namespace std by string for example.

This is essentially the same problem: The library is not inside
namespace std, yet. You can use -fhonor-std to enforce namespace std,
but that will make things worse.

> What (gnu) compiler or library do I need to get a compiler that is most
> compatible to the ISO C++ Standard? 

The most recent version is always recommended; that is 2.95.2 at the
moment. There is also a new C++ library underway, libstdc++ 3. It will
be much closer to the standard. You can try it if you want - it is
still 'incomplet and incorekt'.

Regards,
Martin


^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: Internal compiler error 980711
  1999-10-31 23:03 Diego Dainese
@ 1999-10-31 23:03 ` Martin v. Loewis
  0 siblings, 0 replies; 33+ messages in thread
From: Martin v. Loewis @ 1999-10-31 23:03 UTC (permalink / raw)
  To: ddainese; +Cc: egcs-bugs

>   test.cc:8: Internal compiler error 980711.
>   test.cc:8: Please submit a full bug report to `egcs-bugs@egcs.cygnus.com'.
>   test.cc:8: See <URL: http://egcs.cygnus.com/faq.html#bugreport > for details.

Thanks for your bug report. gcc-2.95.1 says

a.cc:8: syntax error before `;'

so the bug has been fixed.

Regards,
Martin


^ permalink raw reply	[flat|nested] 33+ messages in thread

* Internal compiler error 980711
@ 1999-10-31 23:03 Diego Dainese
  1999-10-31 23:03 ` Martin v. Loewis
  0 siblings, 1 reply; 33+ messages in thread
From: Diego Dainese @ 1999-10-31 23:03 UTC (permalink / raw)
  To: egcs-bugs

Hi,

this code lead to an internal compiler error:
--------------------------- test.cc ------------------------------------
#include <string>

struct field {
    std::string header;
    std::string body;
};

typedef std::vector<struct field> Headers;

int main(void)
{
    return 0;
}
--------------------------- test.cc ------------------------------------

  $ g++ --version
  egcs-2.91.66
  $ g++ test.cc 
  test.cc:8: Internal compiler error 980711.
  test.cc:8: Please submit a full bug report to `egcs-bugs@egcs.cygnus.com'.
  test.cc:8: See <URL: http://egcs.cygnus.com/faq.html#bugreport > for details.
  $ 

If I add the missing include (vector) the problem goes away.

+++

I'm using SuSE 6.2 (Linux 2.2.12) and libgpp-990708-6.rpm.  Sorry, but
I cannot test the problem with newer compilers.

I hope this will be useful, 

bye,

-- 
Diego Dainese


^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: Internal compiler error 980711
  1999-07-04 13:54 ` Martin v. Loewis
@ 1999-07-31 23:33   ` Mumit Khan
  1999-07-05 11:08     ` Thomas Maeder
  0 siblings, 1 reply; 33+ messages in thread
From: Mumit Khan @ 1999-07-31 23:33 UTC (permalink / raw)
  To: Martin v. Loewis; +Cc: maeder, egcs-bugs

"Martin v. Loewis" <martin@mira.isdn.cs.tu-berlin.de> writes:
> > I'm using egcs 1.1.2 (egcs-2.91.66) on 32bit Windows (NT Service Pack 4,
> > Intel). The attached compilation unit produces the following internal
> > error:
> 
> Thanks for your bug report. gcc-2.95 19990701 says
> 
> //h/Probase/Source/Pieces/Piece.h: At top level:
> //h/Probase/Source/Pieces/Piece.h:112: syntax error before `;'
> //h/Probase/Source/Pieces/Piece.h:114: syntax error before `;'
> 
> The reason is that std::auto_ptr is not available, which in turn seems
> to come from a missing #include <memory>.
> 

Including <memory> won't help much either since egcs-1.1.2 STL had
auto_ptr disabled.

Have to wait for gcc-2.95, the next release, sorry. Or, you can apply
the *untested and unsupported* patch to memory in the include/g++ dir.

Thu Mar 15 22:01:16 1999  Mumit Khan  <khan@xraylith.wisc.edu>

	* stl/memory (auto_ptr): Enable for egcs-1.1.2.

--- memory	Mon Mar 15 12:12:08 1999
+++ memory	Mon Apr 15 21:46:55 1999
@@ -26,8 +26,8 @@
 //  of the interface are still being discussed by the C++ standardization
 //  committee.  It will be included once the iterface is finalized.
 
-#if 0
-#if defined(_MUTABLE_IS_KEYWORD) && defined(_EXPLICIT_IS_KEYWORD) && \
+#if 1
+#if 1 || defined(_MUTABLE_IS_KEYWORD) && defined(_EXPLICIT_IS_KEYWORD) && \
     defined(__STL_MEMBER_TEMPLATES)
 
 __STL_BEGIN_NAMESPACE
@@ -73,7 +73,7 @@ public:
   X& operator*() const __STL_NOTHROW { return *ptr; }
   X* operator->() const __STL_NOTHROW { return ptr; }
   X* get() const __STL_NOTHROW { return ptr; }
-  X* release const __STL_NOTHROW { owns = false; return ptr }
+  X* release () __STL_NOTHROW { owns = false; return ptr; }
 };
 
 __STL_END_NAMESPACE

Regards,
Mumit


^ permalink raw reply	[flat|nested] 33+ messages in thread

* internal compiler error 980711
@ 1999-07-30  6:40 Olaf Seibert
  0 siblings, 0 replies; 33+ messages in thread
From: Olaf Seibert @ 1999-07-30  6:40 UTC (permalink / raw)
  To: egcs-bugs, rhialto

Hi,

I am encountering an internal compiler error 980711 in egcs-2.91.66 19990314
(egcs-1.1.2 release).

Here are the detail:

Script started on Fri Jul 30 15:22:42 1999
klei$ g++ -v
Reading specs from /usr/local/lib/gcc-lib/i386-unknown-netbsd1.3.3/egcs-2.91.66/specs
gcc version egcs-2.91.66 19990314 (egcs-1.1.2 release)

klei$ uname -a
NetBSD klei.intern.polderland.nl 1.3.3 NetBSD 1.3.3 (KLEI) #16: Tue May 18 18:08:15 CEST 1999     rhialto@klei.intern.polderland.nl:/usr/src/sys/arch/i386/compile/KLEI i386
klei:~/grammar/grammar/src$ g++ -v --save-temps filearray.cpp
Reading specs from /usr/local/lib/gcc-lib/i386-unknown-netbsd1.3.3/egcs-2.91.66/specs
gcc version egcs-2.91.66 19990314 (egcs-1.1.2 release)
 /usr/local/lib/gcc-lib/i386-unknown-netbsd1.3.3/egcs-2.91.66/cpp -lang-c++ -v -undef -D__GNUC__=2 -D__GNUG__=2 -D__cplusplus -D__GNUC_MINOR__=91 -Dunix -Di386 -D__NetBSD__ -D__unix__ -D__i386__ -D__NetBSD__ -D__unix -D__i386 -Asystem(unix) -Asystem(NetBSD) -Acpu(i386) -Amachine(i386) -D__EXCEPTIONS filearray.cpp filearray.ii
GNU CPP version egcs-2.91.66 19990314 (egcs-1.1.2 release) (80386, BSD syntax)
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/include/g++
 /usr/local/include
 /usr/local/i386-unknown-netbsd1.3.3/include
 /usr/local/lib/gcc-lib/i386-unknown-netbsd1.3.3/egcs-2.91.66/include
 /usr/include
End of search list.
 /usr/local/lib/gcc-lib/i386-unknown-netbsd1.3.3/egcs-2.91.66/cc1plus filearray.ii -quiet -dumpbase filearray.cc -version -o filearray.s
GNU C++ version egcs-2.91.66 19990314 (egcs-1.1.2 release) (i386-unknown-netbsd1.3.3) compiled by GNU C version egcs-2.91.66 19990314 (egcs-1.1.2 release).
In file included from filearray.cpp:13:
filearray.h:79: Internal compiler error 980711.
filearray.h:79: Please submit a full bug report to `egcs-bugs@egcs.cygnus.com'.
filearray.h:79: See <URL: http://egcs.cygnus.com/faq.html#bugreport > for details.
klei$ 
Script done on Fri Jul 30 15:23:35 1999

Source files follow, then uuencoded compressed filearray.ii file.

/*
 * $Id: filearray.h,v 1.4 1999/07/28 10:04:01 koos Exp $
 * $Log: filearray.h,v $
 * Revision 1.4  1999/07/28 10:04:01  koos
 * Added std:: for STL classes to make VC happy
 *
 * Revision 1.3  1999/07/27 15:49:40  rhialto
 * Introduce the FileArray for the full lexicon tree.
 *
 * Revision 1.2  1999/07/12 12:37:30  koos
 * Small changes for VC compilation errors.
 *
 * Revision 1.1  1999/07/09 13:13:52  rhialto
 * Don't read all of the wordinfos from disk anymore; they are
 * now cached in an LRU cache.
 *
 */

/*
 * Implement an array which is basically an LRU cache of a disk file.
 */

#ifndef FILEARRAY_H
#define FILEARRAY_H

#include <fstream>
#include <list>

#define DEBUGFILEARRAY	1

template <class T>
class FileArray
{
public:
    FileArray() {};
    FileArray(std::ifstream *s, long offset, int nitems)
	{ init (s, offset, nitems); }
    ~FileArray();

    void init(std::ifstream *s, long offset, int n)
	{ file_ = s; base_ = offset; arraySize_ = n; maxCacheSize_ = 3; }

    T operator [] (unsigned long);
    T &operator () (unsigned long);
    std::istream *file()
	{ return file_; }
    void file(std::ifstream *f)
	{ file_ = f; base_ = f->tellg(); }
    int maxCacheSize()
	{ return maxCacheSize_; }
    void maxCacheSize(int m)
	{ maxCacheSize_ = m; }
    int arraySize()
	{ return arraySize_; }
    void arraySize(int m)
	{ arraySize_ = m; }
    int base()
	{ return base_; }
    void base(int m)
	{ base_ = m; }

private:
    bool get(T *, int);

private:
    std::ifstream *file_;
    long base_;
    unsigned long arraySize_;
    unsigned int maxCacheSize_;
    static const int itemsPerBlock;
#if 0
    typedef unsigned long key;
    typedef std::pair<key, T *> LRUItem;
    typedef std::list<LRUItem> LRUList;
    typedef std::map<key, LRUList::iterator> CacheMap;
#else
    typedef std::pair<unsigned long, T *> LRUItem;
    typedef std::list<LRUItem> LRUList;
    typedef std::map<unsigned long, LRUList::iterator> CacheMap;
#endif
    LRUList lru;
    CacheMap cache;
};

template <class T>
const int FileArray<T>::itemsPerBlock = 1024 / T::file_sizeof();

template <class T>
FileArray<T>::~FileArray()
{
    // free everything in the LRU list
    while (!lru.empty()) {
	LRUList::iterator i = lru.begin();
	delete []i->second;
	lru.erase(i);
    }
}

template <class T>
T
FileArray<T>::operator [] (unsigned long index)
{
    if (index < 0 || index >= arraySize_) {
	return T();
    }
    
    return this->operator ()(index);
}

template <class T>
T &
FileArray<T>::operator () (unsigned long index)
{
    if (index < 0 || index >= arraySize_) {
	assert("FileArray<T>::operator (): index out of range!\n" && 0);
    }
    
    // calculate the index at the start of the desired block.
    unsigned long ibase = index - index % itemsPerBlock;

    CacheMap::iterator mi = cache.find(ibase);
    if (mi != cache.end()) {
	LRUList::iterator i = mi->second;
	T &tmp = i->second[index - ibase];
#if DEBUGFILEARRAY > 2
	cerr << "found cache block starting at " << i->first << endl;
#endif

	/* Move the thing to the front of the cache.
	 * The iterator in the map remains valid.
	 */
	if (i != lru.begin()) {
	    lru.splice(lru.begin(), lru, i, i);
	}

	return tmp;
    }

    /*
     * Not found in the cache: read some from the file.
     * But first, make room if necessary.
     */
    T *block = NULL;
    if (cache.size() < maxCacheSize_) {
	block = new T[itemsPerBlock];
	LRUItem ci(ibase, block);
	lru.push_front(ci);
	//cache.insert(CacheMap::value_type(ibase, lru.begin()));
	cache[ibase] = lru.begin();
    } else {
	LRUList::iterator i = --lru.end();
	/* Remove the old entry from the cache */
	cache.erase(i->first);
	/* Then, re-use the CacheItem for the new info */
	i->first = ibase;
	block = i->second;
	/* Move the thing to the front of the lru.
	 * (the check if it already is at the front is only needed
	 *  if the lru size is 1, so we omit this)
	 */
	if ( 1 || i != lru.begin()) {
	    lru.splice(lru.begin(), lru, i, i);
	}
    }

    file_->clear();
    file_->seekg(base_ + T::file_sizeof() * ibase, std::ios::beg);
    T *t = block;
    for (int j = 0; j < itemsPerBlock; j++, t++) {
	*file_ >> *t;
	if (file_->fail()) {
#if DEBUGFILEARRAY
	    if (ibase + j < arraySize_) 
		std::cerr << "file_->fail() " << j << " " << file_->tellg() << "\n";
#endif
	    break;
	}
    }

    return block[index - ibase];
}    

template <class T>
bool
FileArray<T>::get(T *object, int index)
{
    if (index >= 0 && index < arraySize_) {
	file_->seekg(base_ + T::file_sizeof() * index, std::ios::beg);
	*file >> *object;

	return true;
    }
    return false;
}

#endif /* FILEARRAY_H */

/*
 * $Id: filearray.cpp,v 1.2 1999/07/27 15:49:40 rhialto Exp $
 * $Log: filearray.cpp,v $
 * Revision 1.2  1999/07/27 15:49:40  rhialto
 * Introduce the FileArray for the full lexicon tree.
 *
 * Revision 1.1  1999/07/09 13:13:52  rhialto
 * Don't read all of the wordinfos from disk anymore; they are
 * now cached in an LRU cache.
 *
 */

#include "filearray.h"

FileArray<char> fc;

int
main(int argc, char **argv)
{
    ifstream is("a.out", ios::in);

    fc.init(&is, 0, 10000);
    
    for (int i = 0; i < 10000; i++) {
	cout << fc[i];
    }
#if 0
    for (int i = 0; i < 10000; i++) {
	cout << fc[i];
    }
#endif
    return 0;
}

begin 644 filearray.ii.gz
M'XL("..HH3<"`V9I;&5A<G)A>2YI:0#M?6MS&\>QZ&?B5XSDNLP"!&0"E"F9
M(.G*Z^2Z*L?)39BZYY;BVEH`"W(M8!=>+"0R$OW;;W?/>W9FL0`HVSE'JL3$
MSG3W]/3T=/>\OV!#]GR>+=*D+).'%]/5ZGFG\X6=>/><#3LB]<O-NOQR44R3
MQ9=9/EUL9NF7MR<G7\[759DF2P!D9^U`B2H"?[$JD]MEPK*\2LMY,DT;L;/B
M('2./-G,&_`[Z3W\S-GSWS]G'QJI+;))5FA*+N39Z_/!)G^;%^_S09Y6D_5L
M^.+LQ9DB$?\IGA;Y/+L5)-C+3J=Z6*6S=,[4/^`+_@N@\.-U7+$X3JJJS":;
M*HWC*(KC93'#7W'\?[Z-XVZW.U8T-ODZN\W3&:<!)#:[T[#YX&P,SQMI_.]&
M/@0;N]+P\7$V:J3Q]S9\[$K#Q\?YRT8:?VC#1UL:<8S:"02*/(Z9I+@H\EO^
M'R"WP!\A2%6VA;(1.'XHU%-0Z;=Q%:[#+'UG9DLV\,=\5:R;4&^S65-VEA=-
MV22BAOQ\D>5O0ZP5\[F9)5!6-D,RM2IGF0WOE@5?Z[1JAOB7Q:UDI,J6C;78
M>%EZ/[U+2D_ZVBW&)?<>_IKY2(?U,.==$B^R-62YU@QLW9>WT^D`_P8M6WH[
M70]&+[X>OC@_5V9N7<V@#,/&`>FOGYPV43:XEA#+9'J7Y>F7"8C`X(%@1Z^?
MG(V1(L^+&)X-/UU5OS[]9+1'KSX-WRCTLT_$-3'^^OP`)SP2/)Z=;O?Y``N0
M7WVU'?+,HY;KA_674^!^;>ED6'UKL%!T(\V1ZFNGKYO@5,E??=VNSD3R99M:
M=SH0;FVF8'&^_4O\PV:Y`I/#F)'V']_^^8]C(OBJ%4'TN])DO2NR&1&1GLDL
M;)F4;],2HC>K.)':BW/PC.-.C17(64-H"*0ZW+_'X+G0$HY.7[5A[W'<<2E^
MD)3FB^1V/3XZ(MIH;GL$!-'H##W+^*B>G.8S7_(D6:=.^OLR@X@AF%&GS]/K
M!4#M?60PF0.+9)`4)*^3=Z)4*WF23-]N5IX,@D<Z@6;A/];^E@$R63Y6XH3!
M25ZHS\GB+;H\_)9>'7[!7W#'8V1:.<#U75$"PG130K=?;):Y8C'>Y)MU.M/?
M!`I5?S/\'FC4&S=>+3;`K!@M^#+I"ZQ4EL=]^;O85/HC+<MXK(-^3J/S@5=#
M>''&HAXV?!=^U,32Y_T`_AH(`#FND:`F#]```[BNFBGQ(`X)K=/T;8".DGT?
MFT4@8P-%/0@@U_[B">R1$J9%\39+XZR(YYM\6D'DNG9[M@#!]N]\\"@*9E`3
M&E5Z5R43GLJ_.0VJ6*A09GZ.L?&M0:'X(-T#O8%VG"^*]U`[IUHV7`N8XIV'
ME):F"0O9MVDUM2!C:"<?X&I#@+R,:9]MQYBGQ;P5Z3GH<%&VXP(T9TKV&CJB
M%T%B*.,^1VALTZ#<-.@FWPJLF*[*A];`[^;K:9+/G2;A"L:-6]^(G+GNARBM
M2OC=FI1)P^S-),QDEM>UI-Y[#70#>PVJXZ*;_=]+0-H`(@!M"7W=(6$;@)K>
M>FC`9YV&`*KAZ[8NTU3ZF02,8[T-'S&*.V\W#X11S:,Q[7-R@GU\NDC6:Y9Q
MR+'X%+-/8\8_%1G#B&L'Q'/APQI\2@GP7(HPC%S5QCR;>[7`L#R>+RL>5]0A
MN`N+<;HLJ5+MNR`!C&>ZF*W)?#)=!8Q^JI+J@NFBIA``5-Q6"E?[/IM5=_Q;
M,R#C&TZ17"SYZ(4$%'R`4^7L.*GI_31="5NK2EJ5Z33#Z0N>QM4SIBE);I(A
M;AR];-?$9[(Y0=TNV&HS66134Q@\4"O6QZQ8I652%>55A)_=,4]G$>^D*HV3
MN+!"4D,>NF5,`*R6:A$W`PK.<3*CGF.J`N:E^6:)#HH+[T/GZ+8H9I.L8E?L
ME/4[1V"Z^=<0O^9)MN"?(_R<)`+T)6./!CTLGB93D&"62VP(5R0F%H9H^'.U
M@I^O\2?H53Y%Z'/\RHLI\$J`9R.>4*:K13+%E'/"G7#BH]?B(RD?Q+?%#QJ'
M>)9!$,\FZ2T8R4W9AYS9HRT?&Q9_P%\*^02=#VS]-EN]7X-LJ$*0ODCG%7P"
M?ZS,;N_P]TMN;*#_)PN$/!6@LW2*D/#)BBD!XL^[])Z`)!1H_'L,=PD4`3!A
M50!!PI!@FQ7HUI3#`;(&7'-$16Z:I7F5S;,I1T?`>7:?S@2>HI=G&)\*9"('
ML68AD$X)QA3I!VS]=4H:?P4U.X$JG4!=4$D615)1!K2%+O^$BL4&G_VP62L`
M%.`)B>Y$"HU*X7WRU:NV?=*R,V!FHJ[PA1]8F58;]!AH?-AC'5)]O$L678!7
MWSC(N.)H^-\KR!]+:IB'U$PSA5;*4RX9+U&P"2E^Y^G[>;=S]$%\%HO9'.0B
ML.@/?"*0*AM!QIR>MA+X7U_A9#J8%UI]`O685QZ:3R9"*9A(O'`B_"_G)C:%
M(4!E,6AHE,7U\*2ML1<!OZ"$%;'CC+:@)#07)@G]&S(B&[Z+=,:=(\WGJB8+
M&-?-M2A\8@`CM]9BZ!P).7R\8HX0$'`[_;[.6R;KMVV+@\J)7\?L)X[XD478
M0L><SE9.0#86+[N4?GS%"PT5@HU&_MS3WMS/UP#QE^ARY)J@1V'!`IK_9;:,
M9:]33CRN[LKB?8R.:5.:G=Z`F>+B8R0#!/Y?,&Q4\UA^BH"%?2,`+OC?C]S'
M@1RR.<B?YQV;44:WQH/%($A<%8V2Q-H*,J`_F'(0;4+Z%`5@BV`LX&E.(3(0
MH0D,D4(0]AA#E8L+'DR82%AL`U9$:+P)/M)O$8%8;$+^MI)%*THD(:YRQL47
M0%;.0H1Q)/1>'5I4XAOHC`C0/07E$3^CP=!B59)Z%J+BLJB;RL.E$>J::F'@
M*#(Y3EMPC=?9H/8\8R\-40ZX!X*$/UXQTB`@A&"-%[J,#R+L841!08(B)'LI
M)HUYQV:1-GP(KDM+*@C,R;(\Y%,P)]4=3:`59'B*O#LVX7B'<@"Q+[EIPZY3
M@C*>H&')`@*5R*:,I=U;&:0;QVSUOBAGR(R9;*1R<?(\'*6!+CL8-';+:@B4
MQP<IWT)<)P1K#C,8SZ`*/LIX"T#*HDJG53J[$!J[R/(4=3$RVFX]0>O9MV*H
MN"K(I(Y-O'=966W`/?V$!)PLE'8&+-B$;:*"XJ.Q)HE]647HL?PUEFMDYDA:
M3`7#"*W,WM'(T)[,![]80FPZJP^_3?LJ)GZYRM!/LJ\XU7`E$K@ZF-(U&3"5
M?#T14OC)@NCJ@2KXMRR_I681*LV&IOV8I8LJB4SL8P.;YW*1B4&Z+ET/5<T%
M!4<*62&&F7:JG+BHY13!')-'GFU.HQ['?"+5K&DOTA`],)UJ&J;7K>ZR-3MA
MLNLY:BKZF:%)-.45)VK.0!(Z9O<T]V\6*U8#K*!BD\>XU&_V5T8I,>**ZM"2
MQNVJ*J7A$SW+B;T9V-/3>QS@@8>PECJ@2:QU&\$")[PR"!LDK848"R'=EQ5L
MLPM[J<@FO(V5&L8*:]>$0>LY=B$X`_<4@B32)N4P+VJ%RN'$Z\J,I2LS]%BD
M>2,P&WB+(HVZ7VTJU+XRHAFV*2IESVKADQ.P,E.SP'LYSG.%XP&B``L@Z:\>
MQS$UD(,D/:B<+\8F;SA2L*@HI(^$%8;ED]8TME`-J0N,=&/J0<Q<#V$,NK>3
MS7+%1X-U2H8N1)8RG%SEW8O([%B88M9M9=!%BJ;$V0F,;MT@>Q()5>HK'>&5
M3*Y.N[:_6`G0E0)=&;Q;'>#**O@*!J96E[I*5RX?MY$N7IB?OICK3V]U_$2A
MG".FKG>N.T+#*FK`[#Z$L>%D;!DH2+H=6X8"@6[-[@,^3JQT6BHJ$TTES7+!
MB4>9)==J@H73_I/HRPK<I+'-)MBDTC]QH[:-E-\X&H1^MYTG+=,+FT=;<K]S
M.'+7OYT*_&YK!50K75CUL4O]SN6_@</T.P^++EELVSN.7VM=JX&>@4&*\\UB
MP6JH8O7>PA5I'C3J'C75-COF)E];9'7(A"889ZH#2OA:**&*SV`@,+V#:!?7
M2P6BB+=5^,&M()(0UL$.#=688+[8K.\P2(D\(Q&5B6$'NJ1Y6J8S52D96>M"
MG1R*5\4",#&$\^HX&F4>0+7J[*.R"66L4-HT:B7Z4@X21*\T@(,`,>>17IN$
M6+]O`N0.>0L7EQ>C]E@8FHL5Q4BMFO7U8$&X)VBZ*QI.9#F?62@V52.]E1H%
M80K\7Q,"T09(&0B;28TK5AA\L5D39[60R%@W)2O>1V)``M&=(;I1_(Z5")6*
MR*)4HA$H='U8.SB$]FH`NRWY,#,E_Z3\-!*!,,ZCX3CT]VG^K*#A/$T=&6,W
MX!$MC#T\8_BWKX=GUC`9D*!G8#^:RAC0R-KDN"G#+&*3:TO@L5<CC(:&8.ZM
MB3G;@'C-W(@'4A:J,)P*DWPVKE-0?)%UF9X%'X&-3!=@THVYXI%MGBTF&DAQ
M7NKD9+JNEFX"6F4$0L*3??QHR:DKZWLZ[AP16?%MM:)TKL0LI<L8QJ!\I5Q/
M5V)STVO6U,HPHYWD'9\GM'J3\M$#[UB0S#BXJ/=)5CD3`W;8.@B,K@QSN=T(
M:^+"8@-`WO60P@TC7&'A5Y"(W%HB+06">LDUF7C'^!`DIV<Q1S*^Q15B8WJ,
MYK#!3_/=>79?5:G.;!J6@,HJ0_[-W-S%PG(1<$-?SI9]&4)@#XXIR>G:4^$;
M':%@QK3/>/1MAA<X,IFZK4Q6H`[+C8,&C2)&%!GK#JZMN/T:7+\O#_7N^-C:
M=J;A4-LI8,`1%OV]8+W(WA32Z[)0H;ASQN06]\E.=5]U^6O@B5==L=/%M6A9
M94QPNK4U\COI2SG98ZFJ6*^GJGM;S%Q:O'0=>F:=WN%>+F&WJ5?UYLOJU-IU
MQ1)T,,6Z)Y2::0MB*(J/#'OQXH4!\VY>E,NM91D(7GB#J"?46C^LJ::FZIO9
M\)]F9#(_IH4Q\</!%6"B[_1&"5ZOO(YI"V@4R,0X6JR_T%2HG!?&'7K63*B>
M'/U0GU744]2A(%YLXQ'[;1!=S(/R<B1[\I-:9>9-E,/Y6C3RDY]6CR55E4SO
MO#1[Q$YD[@2D+<[),K7W!_*HK34JCZS$SB(*NX3]@XIC5'-^_G+7L47C"(5,
M^CHFCKR;*M*\0--A!3MSSU*@)O*-PKL0MD,ND<OZ!Q6K'O-]VF%'BU!UGQ'6
M?B,K.Q@V.HK94&@ZG!A%SNH^NY+3T_9<*VZ==Z<Q3$+?,#G!?B$FQ*U9D!ZU
MFTM!3.WHD.[I+-VNYNH`^^@U9HVF$"R=M;K&M:QYB2VN"G+)>A_$>@)2)URY
M$_#"7D(WUH:O,*0^$FNR5^L)WR8%1#AEN8<#P/@^IJO?L-\0!I\=X:MYM*..
M]X59.J5LM:'GZAPP^2Y-)CJZ7I.$VKD+D[[*B65&R!-)+A6^/"EF3RD<X"5V
M,<A+02AOOF=ZJRC?#=SN4#EN!F[<">RNHAGKG,<LZL7Q,LFS55=N'U79')Z#
M9!)&)!IPA0E7"+A"P\DMY1+L_5I1`:FM-80B1--2B@0.37Q0$#<MV@"M:T"6
M/$#SI+(+APURZ'SHF&.MN%C/[^L>6E`PUK=E2H.^S'S!6;%"^C)L?<:WQ-3'
ME"*0!"I=Z@2#:RXJT#:FEEB&XT<S"N6L`RJ&L$=<]^3RCMS[(O9E\OY!&Q"Z
M70+&?[KZ=B5E.W7'=BKX"&.I2?3;P34?J$SU-HH>1MPUFJ[U8CV_T_`B..,&
M%].=:.*HIJGL\N%>`T^?O`"^=/U4E&E*2T]HN<(SL[T^1GND*ETL5K7&Y@,`
M,Y*#A*0RA@`*]%T`UAE>E+<U+N5^ILM+>_[*!V"K@#DFCGI\B'=YR8A,=UI3
M/H/.TU"Q]+BI6E[UI<DK7[EFJV\O_I,0Y6JZ:J@37_ILT5+;`&G&I!4E"]*^
M3B)(>$<<SW443:SQ_<0XP20WM.H\FA2J=UE?88UD3$$VTYL4Q8)-#&UVN9ET
MFUI^5H#S2QOK2]ORK0DULPA.H)LWED(R544=0$A&(PS/15I=F!*$\C=3L`BX
MB)8C:S`E*AC@\;,5G07##V>BP#P.=SLM-GEE'#S"\#9^OZY'*)F,4"XD%HM.
M=;B2-8<KWFA%5A"&=7+(6)5JT&A.7$(P_9M_YK_Q(5J6;CL%PV0A-B^W2UB$
M(29%[5II%H_UBD>0B6/+RJM2CKM3+UUC\G;WZA/R02(@"KN(P:WI#E6-?J:F
MHCK]7#)1XW+P80CKB3!M6,<WUY'<"(VP3';R`!>?BJ[PT$]"D-1`&HEC,A)M
M%'TM1(SA;!`>YW5P^,,/Y*0S=6K"&@I]D&<<S-WY:GP$_(H1$ITA&W?$0(=F
M"HYAF,,)XW'#CQ_E1O+!M;%>=DEE=]UQE23TC`@@)3UV,F86]%C-M,6`:ZX9
M#"%%;(.V:GX:/65U0S7P\WT`V\/HJ5O)URY7I`WU*@68XY-2>LAKGC,!SN1:
MS#-1@:Z[QJ/&V3A5?*</!<#X5:R:C=7`F"@AD)Q1UI7G9U!,6%'.]$ZE/9K'
MTG"J3\:@VM-SEVVMU`G?[W90O2K)\JNAV@E`G<V=[L8Y5A:YW14'?K>UD:(W
MN\5(\;9&7RQ@BA'<G=(=<?P'5^/,J0*Y7<%8DM-'K.0\85<?NC.#,%4F[6V(
M&HN2VQ\.*88OK34-@A7HNP!L<!"<N0'E];6PU>%\-[3P!-$`)4U^W=H;0":A
M0^@$PK`0TSP:"Y1%@4HKE@\A`SWEN(%=.BKC'36&H-EN*/6!9A,[-$`\;B/>
M+?6RBFT%N+5H''4VY=.8L0F`C_:VM0;;#L9V']#YR,CI\'8#2V]S^8>$>DI:
MC@5Y0E]^"P"Z"<,:Y]6GHK-BM\&=X@*W(HARZ40:I$%#UW@"HZHY\.-8=U/H
M!8$VX"&(\F[-`]B:);K"FYIPQ3R>)NOJ4I9WS2+$H=:PJE@T5+$(5+%HY+EP
MJUALK6)Q2!4+?Q7EU37^9ISBG60FC$<.$&*`0YJF93G>!KDH;COU)1Z\J2BP
MR&/XY@:HPJ*T;9%'D'+!Q.&T;R7?&9U2A+AK;*S,'>.-&;3TA9L%(?![0:?7
MY4JAV)``O_CBR%UZ+U;4IT9HF]FK?<=XWT:`)MY>L1]-R`W0A)P=:#XV7Q<Y
M;[&R*&#$:8/Z_)58YEQNZ/B=VA(#UO<AGD_,XV[PR=NE/G=E%*(VIAA)]J:4
M6H8\LB+W,W@`S2A,;#X1FR?TEI,K<\,)/^9O;-U0&SH"1Y./98VM!3EW\TN;
MLANWJ>AQDX2HG2T2^SO$?(#<X8$D)*Z`DC,G-@EW(Y!V67/791D2[M==AN.V
MYLIM7=CMK=V8!!%E.X"8$@"M:4`-M8^[718>`N'6D=MJW%;J'-G$.19O3X3J
MVI=%;-&!<"D?S%+X1JEZ69:O*UJU4!%HH6)["Q7M6Z@XM(6*MBU$'NS3-Y&W
MF-W;J%TG"K71]B9JWT+;Y;N_6`]M_'VLYVZM@:[Q?/N3$?PBY=&Y\^3$:,O3
M"^LJ].Z"=>'4(DX6MP5RJQYJV(IAO<K0V>4?WHU\UI(V9_W\M#5X\SW)->(H
MU.$.S'2V79EHBW)DW6OMAR_31;%:&X*LTN5J@9O6+GE7O;F601DMIJJK5JZ$
M4MX<LWNY`19^/_`M7\)1/XON<9[I`3UH6\K7;0@_L$MVOP/1RY;L$MV=N&TM
MATLA!M&,7S]I,ZZ2K&QJQ&%?;(J[&5W+<0+B$)-R8]O-$`*\<EW%F#`V,T80
M4T'59BI'@M)OF4L!+1#EAAFSHQN<<^Z+_.AF1'/FCQ).2&MXS!(ENM$Q+MA+
M_$0C3P2F6[=_J+K]`^IF4<:?EY@/.<<X+2C)KE[07TU\]8+_H#+P:I1&`?H4
MX>K*+!3A;[!0I1-VLJT>]YP=ZBKBYS&@"IYXLA3QXQZ\71[.VJ7B[.-'%D%'
M4>D"HFNQ?*DX[K9FV62#+9.W:>PHR;VI)#:;)FX$<&97>SEZLJZ&ZA]799)5
MALF4%[="QB:E'@*<&9>1Q_-DL38S7&E@SK5!1A?"QY7Z]E)=`MVP>0?CG]EF
M"4.N9;J<I&6\W$#OG>#EV]0WZ2I[\_)3S0C\NTO60#![ER6+&/*3S0)/;^6<
MCX)?+],&=UJL'O9"Y',JRS2O8JFIX_8,MRH.!/37O_Q!F"TZM**D?WFM[R8W
M97Z)8=9UH^1WDUP0=8O@@GC;Y=;`;9O"7*EM%9FQ!/%9<CM)SEH%^BR[W;0.
M%V(^RVP_??LLO-V%!T/MSQ+;3]T^BVY7T>$2[V>1[:=MGV6WL^QH4\)GF>TD
M,[X!X[/0=K9K[+/DPI(S9AR]`KSI?9:;*;<OV&ATWG;*1LRBO_QJSSDA_;)E
MF>7FL]#R>/"1=<SK2+[S:CU.A@L[1[UENIS>X;M<]N-N]"P31Z-WDN#[B"'L
M<E6#M;\,)%W"ZH&QJ#W\LGB7[H2P3BL#WF4>1[5'/1#6-$$P^8*6N9[EP!D2
MD=#RC2F2!,(8D@A25,#%8K$=6I=/\@K"\:IQPNM5O@-A^0B;K(Q!:9&ZA&S4
M/"R\NJ80_!8!^9LH#]?=C[":E&]WD$!CVQKBV$VN\+\=H*OB;2LU!+BX#`I#
M'/)P&;^?E\LV`N0--=F]0P-.P=O(`@N#_RLM"Z-WNKHRGZ\-C>25S_)9>A]L
M)FU7F@R+WPJ4S:15AP6[VZJ'J\::;5:^_J.[0PN*?@U?IRO5H#X6N)C7[Y-)
MFT8A7_7R]4&K$?N_Q;S(EGK9PGW,^."'GA_6-?J?DG6@/7SYY-3YT]*NJ_>6
M'G@$V@>K7MNJ$QP%BL3WGWTB16JOMU,;OGIRT4C:KSZ%PFC&/Q'?]4T@+[\^
M.`"<`5_-6H'-B&%AVR?$:[#VL\,L7MT]K)-9R1\`K%A)#Q\_LIY('[L(BV22
M+N)*PK]+%F_."4-DC.M1*P[/CMXMQ0L=C2`RME40(I\L)!WZ@D)?>TD(B$WL
M0M"T]!'=VY)7PW,OLH`A9!L$3;[`/1MY<0F",#F`@E"G3@3^^4LKNWXZA5/A
M8,9;D$@6>"C3VVP-(3_F@K:]:M*,D!60:I'FLRS)+1W2SXG*JASA&<+9K#39
M41+"S!4(K38244CLKBKR!44#(D7X4(%'^3Q:$"DR7^#G57'7A(_Y=7S%(9N`
M%UT-SP%"I6D(K""'.!M)"$S3$-@.'.+\I83`-.UXA\/76^4K_-97I]N;RZ_2
M&WIY(JBS&WYG?T`OB>E0?]O$^"?PCBS`4KE'1\&2><$^`"H:2]:9S"F;BC9Q
MI7CAUX^;9`9Z=61V0LHZ$CDJ@W^SWM&/CJ(>\9#JZ&@J,BQBO$?-:EE:]6?I
MN[BJ\4=9\^Q^5070;K-9""W+"SN+6X:WZ4,(`S=7AO)R>N3&9(*+XNB(WB$V
MD51]5PYS3**4X-P"..OT=OTOO_C6[R>+MP$Y;&11MFT@WH[8`L^]\F%"GU&:
M$[//Z8%9G+@R@72^D6U'W!KN,6AICZ9XU,6Q\>QH+7V/9;Z/JFR9UF")0C:K
MI2-P:1IY9;[GLY@>9=1>B;M32,?I#GS:D4/`WW6,[S6^B:*(C;XZQQM^3^C.
MX`@Y+.:1@.RR'GN-SW5WV8`-NUWV)6L"ZC)RT[Q`LEZOSYML$G<@+\^"08IM
MM*C^[[$=3'<A:BF"A1\W!2D%CS32)?Y^9+/LG1^%&D#AT)="6@2QA$E0>.);
M8?XH,"W%Y#NC.T<LF=#;KC0*U?J63,Q1+4^JTOM,S5-%O2Y'(0`^%8TPQ3PX
MC(3,S)=)9@%S%[Y</EJ>K-.DG-ZU&NOS9X/E!TTA(K=AQ*Y1T)3N4A5:%=M#
M<)+C$3:?[*520$J:0D364)\>`%'C?&-P?)M6:?XN+)(%;P7\X*F"@07G`-/[
M3.6*:06;?X.+']>ZH0UAV4)K*RQJT#+)9S7-P42:]K'F<,VV+%/)8W#292U(
M2QJ6DM'4TJP^$V%,*''Y$>`B!*A;S[*6'8&W:8'(9T<>($9=^EI13#M/ZG.3
M5I7E[-=RLJZ*]U-L<F%6ML]4OI]6Q7)B3)@)3&/6>X)$6]*4K``72'==FXDS
MB-0FLODMQ+;J:4V?T$TRU#40FXR;V1FF>*5"LC)+]$UN$1@>IZLIWI2Z4V7-
M-=D_;%B^][8.;4,MDXJ;'8LI&P8OD-]*")\FK]?-$(."Y*L!OH+$/*U#PUO<
MIB7L+$F71>[:,]XD$!+BH1?(I."0'WXQ=0LO4"J26?+N%F'X[6MOOM=DA&4_
M?[D(S\TOSE\FII'C!F!:MYFRQ&)5278Y,7F-O&=ND;N\(Y$$F$F),?B1RN#W
MJ%;&J665EN%.<2<-_E=+*U,*+R1[Z\V$<^BH@\&ET08V@QR7\\@)WJ7)ZLGM
M-H1LM^DG\`:S[%Y0]5Y-*2>UO9FB1,O@<_/Z]'3E)'W&WZ@V_$S=Z'`51G=4
M+$V3(Z;CP96MDNHNX"K,B?!4%5:?^U;DZ]5?;4(Q`I>.+X1P#;P=C=!3ZP&:
M@I^T6I7%M,JJ17W`@??3(*@82K$?>9#"/WF."%-^Y&$*S^DS$T+@DJ/]L86#
M%@-DX9E;8,A888:B??G:;#F9E:HL>YC_YNQ[H^5_V`+%);8`=FY]4*],6HLZ
M,SQC&<K(MY3NW/79P^`E3;?SNU9TE=VE^9VO3G^AA1489,&@QIZ>4_^,H25>
M[S?+:,`OIH%?OWIR%N14].C\]2>A79L@PHJQ]_!?42TJ_:OA+]06>?K^DZQ`
M`5UCHG]5)K?+!*N>EO-DFK+GF/\)5>H+=N:<8GJJ]OR"O7Y*$;E3V8<25:\B
M-$I?0_FO[U#YU@4W.E6='%<O0#;DF:^!O+]+Z+EW\4*\.M\^P6>.%`EURMW/
MAPU<Y\6;;SS?+N8TH-[++`<W'=^!@5RD99?N&'&@-A#PK^B:70?,Q:;'O%0J
MB^KDN4%F!DR7Q7%2564V`<\?QRR*XABOZ<,C>G'<[:+1=XNG<G0RVOX:AZ(D
M$VI[470"$F<>-[=WE25`?N[]ZZ?7>T?Y&-/:P*<-O)I@7VX04C-U"TIU5^*S
M/_HVE.>*_G-^A\DC3NJ(.;:\('A<`Z1DP2(GI3/%+_/0KU`8J)YJ!WX-C)%"
MC6=^1R8X^`,>:<M]@(BJA]A4(M[P-*-[!WD59%M;.&^^;XFED,0;(VH,)H3F
M!T/R?D`OYS)$)1:4"(\;<74-6F(':K(?MJ[@=GSKM1NK#JH"XJ+=!=C>;ET=
M*=VXR\DGC%U)U>^I.#A$D)[JJ]&3'L3/*EY/XS"^Z(E9CJ\BR_RX2FZI2XK<
M8E,U9<^+\GU2SNQ\?4-=(^E)-LM*,)M@;9)%@(*7OD&#C_+B9#I-U^L`C89R
M/OBV-\LCX'_(8'293]-KYI64=46!IZ;J`]>8;HORP;JY@-7^O4L68C.Q"2B9
M,``Q5D_+%!+K%R+T:F17!04D%M1Q#:I,!<EQ)]CV5H5]>M%88^I1K:KL@VRH
MLP_<4VD?F%WK]HK@:J4E&:_*[JH,.ZC#K@K15B7V%X^_PUE":NB3NXMJ9X'M
M)[;=A'>8"/UVS1)A@^G[;RQ"B(_/6CNZLYK$OQ6YZ@B+EIN^V$(RA7]ILEYB
M75S4)-LL:P\%+>-FJ7M0'6DWR]^#+^3>W!(>/-4";=4Z)%UU1.AGUV$UQ?6K
M-`-!>8EK9?Z]I":9;B<U=3/5KE+375D$]$IS72DJ2$__[=12Q#2X1#KN^FW"
M+H4PLS7D`P2R..]%1'M5SFF37F<F+#=]^NLEN#&O,]ZGJ.OH].GJH96QU]&_
MGY1_HPC)>O-QO1:N!8<`LHB:8[=&G7$L6R:RL/@M8'V;%`-"D"8I';.\WPGT
MXOHHA`OI_5VV@*$Z7YU_=D44<3A[<L(O9((?.1_.NI7Z&YF:WY*EV;EN/F19
M16\>U314.5,`#2:0USAG)[R:;"`OA'L\I,4.:B_.DB$8@<8!\7+9F@WB5Y=U
MMW*MN*SIN@55Z["=?50PI%X[E@V-@Z_[AO62-,#2S0Y_5D9T]GS<4E.#TO$"
M-PKI<%W>IK*B<CLI[=[-OVOCMW6"3K&M/&&H8V@/V3VP]\9Q,GM7K^XQRW0_
MI7[8;#_SP:`+ZICYN/F=.:#=E2LOLLM=P"Z&1]*B<\Z!<7:-KS<1A5I=^"-3
M5M[)29<-!MGXB1R"K*8/MV4MMW6>#.U]?J":M%$2:<LE;!8PX)E?:7]?Y%4"
M!4+/E6LPT[=QEJ_3TIIHLQZ=5$BTX8G_'!L+=?]=Y^1P56@%=<PJKY@B)9=C
M=H]WJ"KA1,?WXE)6']ZE;H1C`-$/@8AU+&G<%)@9+AYS`4DOI8H<7*\VZ[N8
M7M;B$/R]`.LE&^'&MC&E6.J9BP[&,]VM"9R</`$%VO]3)T*3,6=GKPX(F8W>
M(*^';>;+S$]=!3"<Z!8RT7V[SCDO(>5S[]S:.[UR:M,]O8B?LG]2@5L[Z%:V
MMO;0]A2"770G$HU]]-573]I'MS%F`33UTFV$VG;3O3HH\RJ2HI%5_U-Z<5.W
M[6\1$@\IG:[-PR&(@'@?_X2]&VG"6-+HY+RP"#/ZS.SF$.H*P?B[_"&=_:!N
M_@0=_.7P_"DZN`R.ZX/+<%?W=O*^(L&RP,`QW.54\S39!:5BW9W'8FK-[6]J
M5>.*W1R;`P][C`#9:AY<6IPR?9>6ZS1NL=+9#'H9X!6X5/P%9\3"<V37;)TN
MYF/;#GJ+8M--":54/EOWWVJ1]F^U12R_.6QNKT@8-17Z;`'WR_Q>V4TN_$C&
M0WYP\8B0\]B8;#BR(KIVIK$2&%28GW2U7*$!E3I@6L?!`#*E>91+AY+ZX-KS
MR%IDE"V>+4,U=(T@E3(8>`LU33+BUDT@?^,8LSCO"B5$TZB%S<U@$.G)QMVX
M`=2MW/AI*F[$V8#A`99[1SL7-G'!ET-D#+VN?B$[AM[D5\"$^_:(Z)'T`(I\
M%_%1'*P(KH#9KD,RW7&BU3:&>;^53F.=J-6>A5;+9YUMMGV/U<1.*_/?AK`P
M6YUV.QX:""D7T0FX#4GL6S.:X<0<OET%T,5(IZW:VP4->A\%8)4JAMV.CZGA
MB)VW9!MMC!?B5^"%(V3\.DS16]'KQC*LQ22L00O75VYU?9^]W2_N[=SZ1;4U
M0;O)Y+(^($6",!L`D+]N)U<^>F(&2&+3^D"[^N[#W4F0NT$+[DX:N:NK^)OO
M&WA4-/@#Z)PU'G)LWZ#A?SPL;+24A_;\VX[;SK'NQO3E(3SORK)DDQX<VX%C
MY73"1=7]HE;0'6NX=ZT&N]4J7$)'=_T=:FPO"+:HM%6+,&1TKRN8B]T_K\Y>
M'Q"+U[;R^J8-Y#/PUD3!O,S2?$8J;,Z'73&\J5XTM(MX>=/WQ,A;_K4BA0_4
M6?&H@.\Q_I<>5N2A'OZDC@?LQ\ND?,O#*IIP!-"9\C<Z'X02]3BA+OL&;^#"
M=\OI:33QO/:<11J\RP0PN[[69>Y`\-$3//]*CFIX=DFVVQUI3]XZK4E/7(KG
M?8^G6=[M&\**2"YR6M;%%`G';&W26/-91VS-%N&6['F\K0Z*I;;HJ2?($ER&
MIWB;*-9"+SG%W(A4"X,\/-@C_E=?OWQ**[/%;>]M-UK:"MMYB[[*GP7EO^GM
M3;.[8I[Q_?&CYL`%)&U%"@^^C,!;N.*M];JAM8Q:43=JYKE6_HC"_XSE'U=4
M41&P`WTAENA46)`&S+XESFF`T!1[F8_2Y8W1PXV'C*W%'^D:+B]-UX`.A)/O
MFA"R14.VH9&#T+I/(U)PP6<;5M-*S^NS799RQ9T7NSW,7>M4_\'/L\G82;V0
MZZ2/U,2CN_T+F8KQ!MS()87/*[MDV*0/7I$W\HTTL`FV4R_!GQ/Z.8&?9%@?
M]^;79G-7)N4^,(T'8).^T;>CI+OEP6XJF'!OZ*7IFV-)5U:<ZHW5IEHW5%H3
M59UEF>6ZYR3&$^`3>ZL,C%P2")TFT$>3MJ23^S:D@>XET&VB+1OG]\5RE93I
M+K7H2R1(6ZZL@C$A`H"D>V#AP7IN*QR5H;%P[[;$OY!WJ8VJ[&10.GQMH_6V
M[>:A@4.[3->;A7^K=X<&*P`3L3&SMFSC'FV)*+9M\P6N'D_%;JM>95=C,\S9
M=8>IS6TP&++!.EQ@\>S@3=P!8<GR>X:,](Y1YAQ$@)1K=CIF@T'>_X4$URRH
M`\44$%+##M[.!W,SN&@K:RNX)&(?:&I[2"(D!/6*&2\R6Z_P8DKBQJF$=,]1
M]VFZG5=&77MV432&5PX-!T;$2"-LQ6'(*6I<16H0*DI1W[PX^"%+--XZXWR*
M-[DB"2`HB(NC;_#*Z,C4>\Z;I<1X([4%TNQ^]F5<O[QNV>EF38O4Y`W$(J<A
MSOP:='G30Q:N29.`%4-[-,=U7F7[U]:EG&?VKB\NMKQKQ^Q9>"4U;TVKJ%EM
M`G64$@_5M&T+_1IK?8!S?C+7[#<1/E,I6\3FVF$76L0C!])K&?7PL1KR;P[>
MK.;C2>)X#OTV&S%@$IPNWL8(");$S<@65RK-8DRE-LA5P;3@69@Q=?/S$QDS
M[P8%-4+QYNIQBC];J@%N><<QBG_+T5!4K/WN!Q;<-#1L$U>V(S6RVL)_'+`W
M&.AH:#"@@+--.+2?K&UK)X5J!P>!JAC&[_`V.%CR+>3M6A*E0GY+L4-DH>2V
M@Z=NK%4M_.!D]`4%W[EA=JUO0\YWWC#E.T]G!MBVP<@GJ&MSQ+*EF5H$*C6U
M_I5&+(9HGR!TJ=?ZWR6&.4@.G\+G?"J/\V3^IH7U"XA8*4=`;IU]"W=#L!W]
MISN%'^SMWN#U[V#O0H'L*LE*)WAT8:24<G]HB]1!)S;YKK7RSQ7L1B-T:%M.
M51%?<LJ%,RDG6_3\R]9IEQ9"DJW;T#9-4S1-321Z(S'AI^%BJ`9KFLSQMMNV
M-MEV%#LX0P1BY:'="2_3E6ZKBD7[]YW0=$KW:;J1V4;-BM+9L2\US!;91BR/
ME*,B-6\Q7;1U_<18UJ'UBGFV6+AK)))W-UD,%#W+=\%Y9',2E&=>R>6].JO^
MZ6"SD8!K1WK(/PBJEJJ%GS>S;$_?-O"KSSFVNLM#N60K=>2SS\.^"\26V9J>
MU;&52CAA\%I'1_0`*6V'M2%0\@T`(TYB5!^B#66[#7&1OB?2KJ3Q'#DWN0S'
MYM?(N=.E325%L7W)T;XBU;%/GI0/?RW3688=X]<B:0O"X9%-Z#M>E?B@27.+
M&*!13XI.MLVOMG'L'2WICYMD$9!T4+R-&FQ9'BTP97N&JE>/NFI'04]#]\P\
MW<7ECC.YZ:?T6ZR#U/-3"::_7<OVDMJS9@W\=!*\YI?L+]+[;%K<ELGJ#JJU
MB*=\R797J1TU=%4W&9&:%0U[)D>622.O%.7^,T/[+@/*QT5E0X\4]#`DZ$?'
M0Y'M#O)XH#*K-?9?M&4T4GWY_NG:BW8`;--WN]$,E%%?-=R3M9QA.3HAV7N>
M^NHII]:\I]A!$NVS$XYT?3L7-.)K(N(0$UW?#^J5#YF4B)@0'(X]4",!-9)0
M(PW%GY<5X\%ENIQ""]D^KD^[4["P/A'SK0I`*YRR;^37)7Q<</8N"<5I'-;<
M.%:;U)9DANV&1352HSJID;70%&)*GAPSFJ2[56/4/R]VVWJ$BQX=4O1A84L5
MDE1\]CYYV,VX;:W#+OZHTQPH.@:CV?5(I1@,FUR.A++C2ATOJ`@3T07VE5.^
M(/$L<FP<G^JD6^ML2,[2H^Y2T"2=QB;9R^;M;?CVMWX[F$"])++%"EJ`/[<A
MO&`19^^*E_X-&<;(L(R0-!A"VK!KK@AO[61/:"B?U%AR[FAD=Y#9/,1J'F0T
MM]A,OM?X+/S6X2);5^V>JJ&7DXQW:@3M?\<W[+;NO18UM<4BP<#+I&5E/>!H
MO3<OK]<DL-K[G<;[K<9KI/S:B:]W8>OU:3MHA/UZ!]CAZ>NVP/;%"F@$,JB7
M/.T1Q_R%=HX1*T`\])&]@U\7'7X_N'SSJ5@*#/EZU[@.(%Y4=]]3Y_[,A(YZ
M+@.(;CY-)H^16&4P_K1WE0H>6,[-B#A`IY<B!*=Y5_O;4[2;<AI8`1K5RNTC
M2'J3A,G"+%4LB.>N9"T9D[S@D]'1JNNBXL)G&%G]PD?7UO^RZZ7YE1(&3`'8
MIH8AK,:J0AOABW"BE43;1")K#HW4A?^;;`)"L9AU\2AR0^ORDL/YN.)A<A<A
M3>3-/HFM]3F@4!+TDJ`N+AKUC5^N':2^E7BM=SB:">PM'QQ1=N69-U-W>0H-
MJ\=C&=3AOQIZ"R%;BE$OGWU@T[0L\:C/\V)3L6*.D4I1/CS'I!2`Q@P<<Q5!
M:,J/X0BOU@O71:^SUGNA9$>K*+6OL5>&.??I[],,M@W2/>QS@]C68]=&$=LT
M0BUP>LW,#-V9W(,CO\5LZ876&0"EXD%-\QU5Y2YN6,]C]-U`2QW](LGF(C+&
M(U%4W,6%HI&#%O&-3)`OS\UZ2Z,GL,,E>:F'*;O>X\;1S7HY7%%@")"K<@Q\
M;,+&JO@*]!7C)>V0?1S[[VFRVG*63C:WNBEE%)'FFR7[`#%8B6>R7A.I'9T[
M#\64%LN'Z^M->\*H'*&V/4FHUU6XN<?Q2;0=?+W#&G6L>&7PMH(QH2!*/32R
MN>'0P`[#`T]<U5!E96`:M8GQ^FSTU7F?/?=3?MX%(T&%UUN8@Z$&:8GM$*R`
M1X88(A"Q'"@13OM`L9R?A<3"R6O9*&X=W?(,[808R[H8!<]"EC+&:J.-!+A%
M)67GJ__3W9'F0:L[/$F_IE&,$^N#Y4Z`;$.PWQ&71&!GC>/?_OG;/WTGNJN9
M_I^__:_X=__OYH]_A[SAR,W][C_^]L<__OG;O]_\G7RA`OY2$!1O&9.6"6'\
M[2__^.X/\3_^*H4S>:C2M>EFI;6-(I%UP@2U`7C!8_93)+D=\&D/NL""UXJA
M)]GD^#)S,?G!(*K3>A2MQSC0AO_D;[53)$68+C+<:3A+JN3-\/LQ?X]9R<RP
MMIP6T]3>F.+XWJBXK+G,C+_][@]__*_]ZO^E67=>]8[M`,!JTN839;?&'0.$
M*_OT#L;JL16]KFD[".K1<0Y56R.:@P4?915C?<=N%MX\X&0(NG=ILHKQ-[]C
MN_585E^_"$EO#?&8$8/\AR!TCMP*DO#?3_4LH<+B0AE=AAZ!NA)EWGB$LR35
M@*)+I0MC*\^,*\5#(_I%;*/7U+4@,B,LT_%U5:`F(E-5-(ZFU.\35^FX.G2L
M&+%7YUS'AVA"3TW&A))1;$F*ICJT8LHT;B:;/8=/N8O\VMLE93\P=]:/W;9I
M]MA6(_V(QIY^=5?CK6W7MIWL!G+"M9H\#F@T1/FQ+BM_^[F2_I$(/-84>V>7
M#^X)_*@>&OC=S*6XE:3/8)`@1P?;<`B%,-99?@MC!&&*!7Y+]X<SKIU@&08&
M#1^;#.$QXX;0C7)T7Q8855%!5$#&&D2-B0!'N!88`<2+=(X-(@TFV'';K'+-
M,V"OK\P";!,A.K!+07@ID8:WYAD47)5T!GY\P:C.`U;"+)SJAU<N**@ON967
M`-ND\HEKH#FUQ%\5\6V*)8Z`&Y/%$QV8*)>%]VF]E'W/US2V90R;%'857#AH
MZ/:Z),..\$B:FS$MH6Y;PR#_N0:B1E&#/_I:1,?-8LK'%&_7,_=A\FJ+C#KO
MN(44^V">E/=2\L-YFDQHV)AE[-(*1,?\S2L1-;E%[V:&,Z<9*!II%K,6`8SJ
M5[[B?8VQ"KE$]Y^W059^6&5QKJR>Y8K>Z5JN@>P+HRBB2ON?'7H]=HZ<<D_'
M1YVM[`<B'D>_C-)UJ;KCGEQ9_5U7,20%/_1V(<C)LE;."5ULC[5V3FX@+QP1
MTI/6=W1J#6J)4;R[UV`XE]R.6\:KIH?C*>+ZU1B^^FC$8:"*O\<=I_NBIM-B
M-2_0$I\H?H^@QW`3PDH10=E*;N>1W&EPSH"Z>M:R&L,QC`LR?,E/=TVCN@8]
MK16>$J3RJJR3VG0K;S(8MJ&`,M<4F&7Z3/FIW4LGH"F&3:CYO#8DZQ63/>FQ
MXW.NCVTUO+.#AM?"S[W.K-@AZR$D&M;BK&".#I+(B1QL7C$CY!\PX/8A,474
M>N177\&SAGQ8IHI8>.%T(;`>C0DD26^E5@!%9]*#27.!4%1,354!PYSZ-W+2
MZ\*:Q,*=+JL'=3'`JB\I"'KVB$@P.@XHV!?L_*NSMC,$[08#K-=:&RUW9"T.
M/E$!EBML05[H6FOZVO^U+*`U93)S;<'9Q86>%!-KORW+,:?0.M]#-3Z<PHAP
ME__IN=,OV-GP"?;9T-X0/"!M[+79<EG=+`6,X@$/A8N[)F7_%I^#ZY]N_'=%
MWZB-DS?.U7N*C^AFV./]C$Y?C:SC5]`U&71UH*.>[]MZ=LTJAQJ9V(^3S?UN
M1]CJ1_+M`VR7OO-K4EC'O?"%($T,LT:&^_6#>O8E";N<[/.6NIN(Y)V-.YZ!
MI[*@[?'H>RUIS)]--X1@'=^L(T3=W:6\1VW5@^X"U>+*N`'2.&7I*Y&F=/IR
M+]T'/Y"\M::O[J_A+V5P.S!Z`CNPR;,\JT"08%]GUKZ[5F=B0\)UTJ'[607Q
M$ZO8IH??EN2VT=9SY+7K1-3=C8$CPJU/"->D\>L6@VO67!(0:JOI;+I6N'R0
M4\_-1WC[_$40N?BH;?QQ#Y+E$1=[[Q9DR&WA4SIA^>+%"UK@D'U!QF)(&$H&
M'UN\'S.<M]VO=>H6L$UK'=A2@5;:Q8!FZ_BO?_D#?R&!_QZ;9\$#"N:_29#0
MH^X!&AX0'2U-_ARB<T[">TKUUMRPT^8]`-9M:!Y:;>Y&VSI.^SGO3@O68?^;
MU'YU]ZIMO:RAIK2^:QIJ0-ZNM/\=*#O:Y]#%)GO8:'4'"O-?@K*KI6XC/747
M!=!^.K/>]@:5D)5JN&FD;?/O?*/*05KP*:Y;629OTQ@EP6]38>U,9O>)NE[#
M12DUV"?L?WLZC]"E*ELM8^.E*YW]!F<UE:3;3'8=SG:V''>ZH3><S1B9WVN-
M<_:67MSO<8',SUL%([[MA&VGNNS)9SH!P@ANFRSE_18[9QC$;68N)$/U8^@.
MVNM"?2*!^@1[,VP9K`Z#T6I0#6P-LR+4SKYS&I]8.%HT<F;`4Z!;+_\\06O#
MX-QRU'+\PF\_:NINX@JD3DM-"(VDQ35+@FB^HZUP*O<+U*K=P+C)<-CW1&VW
M&^V'P8?;$4N^'IOBUM8O\`.$_>GM2\"E&ZIBZ.:>5J95'V2?6G2N]6FLN5WK
MD`TZZ*J7@R8$Z[,$^]^4L-/%,&S':36_65B"L[D*QM/#OF#:O%39,!VBY4+H
MH[Y@%HMI.:9"2-=(='8.-RR1[>9LB/W0G)='?$TM89B(MLT>GF/B#>AQU(;H
MI&UNWT;2P3]U"^TWG>D-N*F?44T]DAKZ1#7<I7M(5?5%4J-VK1OL6Z-6G4O=
M0&<UG*>ED:+J4ZVB=][W1IX&H^68LR=8CD'(YA59=:TU;7K)BUEJ^4J^&0O_
M&QL/`IK?M$.FEK@JTW?\>5<\(S(V[Y)V#S[^+9W+GW^M2I<CZWE;O3O:RL.G
M)&^.Z>)M[ZAYW(PJ=47?R7W-?\4M"5`-D'=SITRZF)MH$_,>YYU>C/6_\`C%
M^9YH!%;L)QD=MK&!+V^N>PRW-]6(&IN[:WGZBA?/0Y**&L,"^)#,$E.D(>[Q
M!4<$B^[%XX\N;"!9W"`C/H]-0B_PCT#SOU[*GU&_KST72QI_=<4X"7[ZQ:+P
MK!6%9S:%5@_;1CWB^@7UD(/>MW5>L-?/V/+:,2W];B1+Q6[;;?F(O7I)LB-5
MN_Y:[<F)]72M_5QM[1G[01L6T8BT91$H;F5Q,&A@D2XS&0[/6]G3AM=TZ3BD
MW#@F3QK2KDOGW=AF$^OOMTQ]V-U6GQ:_5!!]<0Q9X\1BDQD:M/ISM"%+HU-[
MX5>E32!N.WWOQRJ@8[^1<FD="UI>8%6MIS5F=<'\DMZF]NR\#7JM!&2#-9+0
MR'4T2T.US;Y-N:C-9V@]:F7L1!>6B6;,<.F)L#5!W.7OIV!NA11$--JT3"&#
M$W-#/!,..[[FF7=X(WRSYDU6@VNTP'KJA&\=M0,W5865$ZZ9"UG2,)E[;GP5
MMW=TB?)%X49!\LRNT2)$&2Q/]1#K`-0UI6[%\??@&NT][E<5MD,FHXTUDA7[
M--XRRE#=*'2E.?/PY1%\EM.!]4EZF^51E^8.Y!:\D.RGBS0I4:&4;+BW=]H!
M41M'.M>R;F62WZ8FHSN-\O:LJ#&B>XJZ?L%&IVU]5:!3\S;7]@X1J(-[ZL?O
M5Y3"$)4R0IE@@,$'09;14NAN/-1,1*&G^<PL6T==3C$<SA.MR1C--GZLK%7+
M!8F(I%6I,!51L#4;ZT615-5EO"Y%I\(U?%'B%KXL<;3@2E$5?/&KPE$U_%*5
M)N;*D+&V&FMNJ,SB=:;:;2\.<,BG677O(>:MJ:[:+5W,*7&9W,=VJ1)#P42#
M8=<-V.=ED5?6<^N""5NZ+KA3A(VDP?%I((MX-!CXE,J!=ZD[6/KQ;^S#&&7P
MT(_[1L8N+BB31X5BL.1T*F&NU/>J6&<X6.VS)C_+0VS3*TLG"CG*YTA:+[3S
MH6SA>ZQLGBKN0E$%11Z8;E<5(()XYB-E9M>')5OK;[25`-&2N5$-T,[OA&7<
MU@&-&TCUF=]'WV_!HI-ROF;6]>TS[?^[N3F]%2:[*/+;`^FN-NN[F'<PBTK-
MM][;T29@4;_Q(@E+<E_S*F6R3KWM[^@\G0@3H59008W1M1'[@3INQ30&O0I>
M1V^R;!'"R4_=ER3*V`PR141I%F3;4&7T%<5NK8<X`A)*FOGU$XRR$S7B:2B^
MQ.51S"`X[WZ4J2G<V(9/QDQ*`8I5K*TX9]MVD0I,FN...8`35HT415SD0S0&
M`\A0<J%HJ3DJK@71.MC5)-SNMQ-RK9.UQ4[O5Q#U956M&@'<'4P=4=PQHJY%
MY&ZTK&K,:^IS<WY"]R^TE7AA!UH_R8!77*.CM(@YT;?)@%FJFF0,<C7V#-\J
MX'$-_MWG!YI[EW&7ND313]O*<4?4,]QFU,/,%\9T6I?'U'ZO7,,F-OSHBG``
MU;8V+K8F+-'=H&(;+5VL)Q<G%-VJ:P0G@X#=FFIH-\<,*![Y$%T-H7@@AETK
M]34O*HCI"/%=&]!*'E/++1U*/S1>@Q*W*='0HZQF[/"`=B:G<'\8US4,#V*S
MCQ^9F?!#U[JJQ\-RU@>@/9G<IOSVH\YAL?F,B'`WM)_<L9K*@6SR[,=-:GB4
M95K>II%L/<-KT9#)`%P7$&'PQ4+'3.JGETP6XFP>J1POGOMPD\6AD^DE\/>J
MS*;5_TV3MW\I9VF9Y;?7M4KU/5"[$:.*!XB(.\2<=1EV>:VN&1>2E7Z,?SYT
MQ]ZG>)T+4\T73VJK/L(B*X-LEF"D/P0V"%E@%Q?:1%D3SCHYQ3<2[I59,S)P
ML?G!DT&O*A@3'T""!WL.V,@%&VDPM4F,7N)(Z1F.G)[@@&+-&Q%JA>6BL'Z]
M@%P4H%_@0F"<J*2K5T=BTK+YW2W^*(/B"']['W]JTZ:7(2?KM"ES&G7+NS-U
MT]J'AE)I#\K<MN:Z83#>#S%Y_X(0'MJ4LRT"H_+M<BXN@D//3NMW8;9%<6V>
MX:P-H8WCS%^PEZ=?/<GJVZXR"`Z<`V]U!NIRWTI+')NBG9S#;9OA5NW11AT.
M<G1*/#DQ3T)1J[3@TRO"=L,ZVAVO0PZ\_TS,AED3=(LTEU-^4L8962V:J`23
M@0"7J@A4I0RWOT(R;X&Q>/.'"%WI,:,Q9LO$U"$5C=>_F$TGNKO$8P,LL6T[
M>N4C!A$D`&/5BO;W6M95#>K'N@7%Z0"QE<$_T[815T7624**INB,_,UQJW<U
MR+,6U%J3E2USA;%]>$2UQ!;$97FL^_%]+3Z5#S:9.L3L?C"T1^O.,H!\$4I'
MT5XP_F+1E?0"'&:'=Z[$:U4G)^K%[]')R=B.68UWJ83=-;JIW',FYQRDLBIU
MM7:D]=5[.=83?F*#P][=VQ<7,ZL[RX>)#5EFSE$Q)4"_:7(:V!P1RG&(UF/]
M)!C*3C!D2$U(2W(E$1_W%8&,_?>OM!ZA7,D:Z[%2L-9"5+SJ-5E90NCIN$PJ
MD#'=:.B-*Q16*W5O,>G!@Z]'-_7=<,_=TF.;>FK[?MKTSIQ:NO4UTFCL#C3=
M=\MXV^G;TV0MM/@?W18R7TPVK(2V*JJP0.??NZ.+D:NRP/45/!SSZTD88UK;
M!O-JMZ>_B*KZS`+WT*Y=*!8SURP8'THP*E0'^+YQN'UOU>9C^*<5C%T&FR8E
MW^7IIN.IT+1\<_Z2;D;'J6&<BY51DI#;,SEA)&<ND=H+,;W"/Y10R!_TF;F6
M*RXCU*NM1#;*H"=08=!IGDE&LN]?.(4Q9N1Q*T!%*K47W.!P1D&>G'SO['FH
MPWQOO-B4H0R1F2XU^F(AO1R_D5"P/Z2+3`F.8L.NAS69,!AR^E:9B,DS=A]T
M&4]I-[A2:WZ'Z2>P?TEO:KR@W7TB5[IUUJK1UVY],/S7Y(;KSY#WA4/^V3QR
MFUFYG;RV;_K/>,SZW\*=!QZ]_F_IT_=7@,`TK=G8GUU>6Y?7YV+[U3L^@\^@
M^Q-GCEZV.'-$D*-7[#G@IU"?Y(&>]_0=+A(GRP#NMPC7L5\R4^ETX&/LI*VK
MV<5%-E]799HL64_N*"GF\W5:B5TKT*F7ZV[G"#=W9!6+`$CFBSSYG,E/1F'&
M8W:(UJHD*@0K'..=V&,V`1N//SG0F)$<\,!M3(]IX>:SWR?3NU0FG4E&;M2$
M-GOS/8O4"\Q8I.#LAATK&!"-%X;S+%E&QB)B49^83V-9I-S/F[HUG5NUFNM:
MS0?75;I8W$9*?B@$LTY6:59EK5(M%*)!>*YTEF8Q2I16&5K`5@$:6%.WVL(B
MC?6SJ%*%+8($HFE)B1`9ZX$C6IRX32M\0(Z4I%M[`<D6-C4)G]5#]>)%B].$
M1@.;-;5SW3:(K?=C]?O:I/E_3<O?\?=ZR+_),Q'($UV68Y79QP?^KMF?__:/
M;P'7@T)&6V03W)_5=>@6W#)9N90%L)[IOF94@_],Q!JZ`&"+<L,39#982_CA
M7P0$VZ+JJ[HVO\_.K#T:R]/12_8EN[FXH!80EX9UO31M2J;-`--E3@@^`V9-
M-W%4JR49:H12(<_1+%VD4-R;[[/!]3H%_F>02(3X5+7WJ4_%VXW#7=B,@%!F
MZ;VZ"!_="B:`QSA%/\X_KJ\,1:,JB"YQ$RD^K#V3X%0'UX9=XD3]X0IPRXY#
M_-9,VI[\1A%['BSB0J")YT)I6]"S?^;/T=6?!E_1,SU:GPV'7_79\W_N6L@_
M\W_R8O1K>H_B(0:GVF@"</<%$1F(O__+UW]EES#T:XD*1CWDQ1PP(Z)FA!)+
M6DOA`&J"):"G2U,CH>GX8H-*?*,XQ#(@3COJ'/%HY9FEXU0"&3A($\&9D=W'
M=-H9@JI^]*A4SMA.(QQ@;R)Z;QSG&PC0=+5XA<2^[DO;'E+Y$A/O>+YY8\D2
M.1=&C$TS+C$(%#&K*[JBN>64N.P<48EO>-7=/FT]*Q`0[F!`?9R/;20]V><'
MUW+HC3(57RA[+&ZL:V,V$!<^&U+G.+`)=&A*UG%P;6V#$VGK-'U[&W%7>%*S
MI*S'A"2YQRO6%Q=0G`IF>C1BU[JL0MD?*!Z'/Y>.RK,?3D[ZK.+O31QQSXFO
M#/7`Y1SQ(17Q-4^RA5%E4DGJ4R=$U+`7G:,C8DX](VQ18/2.\`^4P7^+;!$$
M4088CS$O1SPK84E/QA/(?ZV[>"TDQ@^.B1311#'Y(9U6\@9ZKVD$:WB*-D8:
M2L<TMFXW1*^W&Q<Y29SS,M9=M=RDXWJ]Q<8/7,0?GIDC@^EJA6,#74^\K/.:
MS:?C#E2OLTQ`*WG0=SOMBP=:>O#Q3M=9!%#9.GJ>O`!3"Y:9>,WDVR'SZ0N*
MXX]QV'<*=OL4_LEW4:R!TRD?.!&`>M#D:(KV&QM]"N,G3^5.L6+_'V:R,B6B
#C@$`
`
end

-Olaf.
--
___ Olaf 'Rhialto' Seibert - rhialto@polder.ubc. ---- Unauthorized duplication,
\X/ .kun.nl ---- while sometimes necessary, is never as good as the real thing. 
>From gatgul@voicenet.com Fri Jul 30 07:26:00 1999
From: Uncle George <gatgul@voicenet.com>
To: gcc-bugs@gcc.gnu.org
Subject: [Fwd: egcs 112 & alpha & bad -O1 optimization]
Date: Fri, 30 Jul 1999 07:26:00 -0000
Message-id: <37A1B3C8.AD368BDA@voicenet.com>
X-SW-Source: 1999-07/msg00923.html
Content-length: 768

Followup:
This is the simplist reduction of the code that causes the Optimization
error,

    if u remove the  "l = (((struct varlena *)( v ))->vl_len) "
statement then the compiled ( with cc -S -O1 )  appears to be more
correct.
    If u leave it in, then the *v++ gets screwed up.

gat


typedef signed int int32;
struct varlena { int32  vl_len; char    vl_dat[1]; };
typedef union nameData
{ char  data[32 ]; int  alignmentDummy;
} NameData;
typedef NameData *Name;
static long comphash(long l, char *v);

static long
comphash(long l, char *v)
{
        long            i;
        NameData        n;

         if (l < 0)
                l = (((struct varlena *)( v ))->vl_len) ;

        i = 0;
        while (l--)
                i += *v++;
        return i;
}
~


^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: Internal compiler error 980711.
  1999-07-23  7:44 Internal " Anders S. Johansen
@ 1999-07-25  1:21 ` Martin v. Loewis
  0 siblings, 0 replies; 33+ messages in thread
From: Martin v. Loewis @ 1999-07-25  1:21 UTC (permalink / raw)
  To: dduck; +Cc: gcc-bugs

FCC: /home/martin/Mail/sent
--text follows this line--
> Compiling the included source by doing a "make sense" produces the
> error. It's all caused by a typo on my part in directory.h, but I
> thought you might want to see it. I'm running egcs on an unmodified Red
> Hat 6.0. Output of c++ --version is:

Thanks for your bug report. gcc-2.95 19990717 says

directory.h:134: `queue<Tsense_updqunit,deque<Tsense_updqunit,allocator<Tsense_updqunit>,0> >' specified as declarator-id

and does not crash, so it appears that the bug has been fixed.

Regards,
Martin

P.S. In case you wonder what the error message means: The semicolon
after class Tsense_fastupdq is missing.
>From martin@mira.isdn.cs.tu-berlin.de Sun Jul 25 01:26:00 1999
From: "Martin v. Loewis" <martin@mira.isdn.cs.tu-berlin.de>
To: kk425@acf5.nyu.edu
Cc: gcc-bugs@gcc.gnu.org, kk425@acf5.nyu.edu, kavitha@hotmail.com
Subject: Re: Internal compiler error.
Date: Sun, 25 Jul 1999 01:26:00 -0000
Message-id: <199907250822.KAA00922@mira.isdn.cs.tu-berlin.de>
References: <Pine.OSF.3.95.990723144112.7108A-100000@acf5.nyu.edu>
X-SW-Source: 1999-07/msg00786.html
Content-length: 323

> I am encountering an internal compiler error in my main.C
> Attached please find the program files:
> main.C, wabbit.h, wabbit.C, immobile.h, inert.h, grandchild.h
> 
> gcc version egcs-2.90.97 

Thanks for your bug report. I could not reproduce it with egcs 1.1, so
I suggest you update your compiler.

Regards,
Martin


^ permalink raw reply	[flat|nested] 33+ messages in thread

* Internal compiler error 980711.
@ 1999-07-23  7:44 Anders S. Johansen
  1999-07-25  1:21 ` Martin v. Loewis
  0 siblings, 1 reply; 33+ messages in thread
From: Anders S. Johansen @ 1999-07-23  7:44 UTC (permalink / raw)
  To: gcc-bugs

Compiling the included source by doing a "make sense" produces the
error. It's all caused by a typo on my part in directory.h, but I
thought you might want to see it. I'm running egcs on an unmodified Red
Hat 6.0. Output of c++ --version is:

[dduck@rattatosk src]$ c++ --version
egcs-2.91.66


Full error message on make is:
[dduck@rattatosk src]$ !make
make sense
c++ -O3 -funroll-loops -mcpu=pentiumpro -c directory.cpp
In file included from directory.cpp:2:
directory.h:134: warning: all member functions in class
`Tsense_fastupdq' are private
directory.h:134: Internal compiler error 980711.
directory.h:134: Please submit a full bug report to
`egcs-bugs@egcs.cygnus.com'.directory.h:134: See
<URL: http://egcs.cygnus.com/faq.html#bugreport > for details.
make: *** [directory.o] Error 1


I include all of the source and the makefile in a .zip file.

Regards
	Anders
-- 
Anders S. Johansen, Jagtvej 109, 3.tv, 2200 Kbh. N +045 35836565
Wisdom = TANJ + TANSTAAFL
sense4.zip


^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: Internal compiler error 980711
  1999-07-31 23:33   ` Mumit Khan
@ 1999-07-05 11:08     ` Thomas Maeder
  0 siblings, 0 replies; 33+ messages in thread
From: Thomas Maeder @ 1999-07-05 11:08 UTC (permalink / raw)
  To: Mumit Khan; +Cc: Martin v. Loewis, egcs-bugs

Mumit Khan schrieb:
> 
> "Martin v. Loewis" <martin@mira.isdn.cs.tu-berlin.de> writes:

Thanks for your quick help!


> Have to wait for gcc-2.95, the next release, sorry. Or, you can apply
> the *untested and unsupported* patch to memory in the include/g++ dir.

Ok, I tried the patch. Seems to work; if not, I'll let you know as soon
as I know.

Thomas



^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: Internal compiler error 980711
       [not found] <377F4A8E.11B48DE4@glue.ch>
@ 1999-07-04 13:54 ` Martin v. Loewis
  1999-07-31 23:33   ` Mumit Khan
  0 siblings, 1 reply; 33+ messages in thread
From: Martin v. Loewis @ 1999-07-04 13:54 UTC (permalink / raw)
  To: maeder; +Cc: egcs-bugs

> I'm using egcs 1.1.2 (egcs-2.91.66) on 32bit Windows (NT Service Pack 4,
> Intel). The attached compilation unit produces the following internal
> error:

Thanks for your bug report. gcc-2.95 19990701 says

//h/Probase/Source/Pieces/Piece.h: At top level:
//h/Probase/Source/Pieces/Piece.h:112: syntax error before `;'
//h/Probase/Source/Pieces/Piece.h:114: syntax error before `;'

The reason is that std::auto_ptr is not available, which in turn seems
to come from a missing #include <memory>.

Regards,
Martin
>From frohlich@na.uni-tuebingen.de Sun Jul 04 14:04:00 1999
From: Mathias Froehlich <frohlich@na.uni-tuebingen.de>
To: egcs-bugs@egcs.cygnus.com
Subject: Bugreport on g77-2.95 19990629 (prerelease)
Date: Sun, 04 Jul 1999 14:04:00 -0000
Message-id: <14207.52319.216353.567348@na12>
X-SW-Source: 1999-07/msg00147.html
Content-length: 1330

Hi egcs Team!

I have probably found a bug in g77-2.95 19990629 (prerelease)
(i686-pc-linux-gnu). I use a RedHat-6.0 system.

The file sgeqpf.f from LAPACK (you can find it in the SRC
subdirectory of the LAPACK source tree) seem to be misscompiled using
this and many previous versions of egcs.

I can observe an infinite loop while executing 

xeigtsts < gsv.in > sgsv.out

in the TESTING directory of the LAPACK source tree. The libraries I
used to bild xeigtsts are all perfectly tested (no failed tests in
LAPACK/TESTING!) only sgeqpf.o is replaced with a new object file.

If I compile sgeqpf.f with the command line

g77 -O2 -march=pentiumpro -c sgeqpf.f -o sgeqpf.o

I see that infinite loop.
If I compile using one of the following two combinations

g77 -O2 -mcpu=pentiumpro -c sgeqpf.f -o sgeqpf.o
g77 -O1 -march=pentiumpro -c sgeqpf.f -o sgeqpf.o

everything works perfect.

The infinite loop happens in slapmt. This function interpretes the
permutation which is generated by sgeqpf (the argument called JPVT).

Ok. This is what I know so far.
If you have further questions feel free to contact me.
   (frohlich@na.uni-tuebingen.de)

     Regards,

            Mathias Froehlich

-- 
Mathias Fr"ohlich              e-mail: frohlich@na.uni-tuebingen.de
Institut f"ur Mathematik, Universit"at T"ubingen, D-72076 T"ubingen
>From zack@rabi.columbia.edu Sun Jul 04 14:41:00 1999
From: Zack Weinberg <zack@rabi.columbia.edu>
To: Manfred Hollstein <mhollstein@cygnus.com>, egcs-bugs@egcs.cygnus.com
Subject: Re: Another incompatibility of a CPPLIB based cpp?
Date: Sun, 04 Jul 1999 14:41:00 -0000
Message-id: <199907042141.RAA03096@blastula.phys.columbia.edu>
X-SW-Source: 1999-07/msg00148.html
Content-length: 2181

I'm not sure you should be counting on this behavior; 210x70-108-0 is
not a legal C token.  However, please try this patch.

zw

 p.s. I haven't received your mail for some reason (I'm not on the list right
now).

1999-07-04 Zack Weinberg <zack@rabi.columbia.edu>

	* cpphash.c (unsafe_chars): Correct rule about extending a
	pp-number with + or -.
	(macroexpand): If raw_before, trim leading space and markers
	from argument.

Index: cpphash.c
===================================================================
RCS file: /cvs/egcs/egcs/gcc/cpphash.c,v
retrieving revision 1.22
diff -u -r1.22 cpphash.c
--- cpphash.c	1999/06/07 10:35:24	1.22
+++ cpphash.c	1999/07/04 21:36:47
@@ -1337,10 +1337,17 @@
 	      U_CHAR *l1 = p1 + arg->raw_length;
 	      if (ap->raw_before)
 		{
-		  while (p1 != l1 && is_space[*p1])
-		    p1++;
-		  while (p1 != l1 && is_idchar[*p1])
-		    xbuf[totlen++] = *p1++;
+		  /* Arg is concatenated before: delete leading whitespace,
+		     whitespace markers, and no-reexpansion markers.  */
+		  while (p1 != l1)
+		    {
+		      if (is_space[p1[0]])
+			p1++;
+		      else if (p1[0] == '\r')
+			p1 += 2;
+		      else
+			break;
+		    }
 		}
 	      if (ap->raw_after)
 		{
@@ -1460,15 +1467,12 @@
 {
   switch (c1)
     {
-    case '+':
-    case '-':
+    case '+':  case '-':
       if (c2 == c1 || c2 == '=')
 	return 1;
       goto letter;
 
-    case '.':    case '0':    case '1':    case '2':    case '3':
-    case '4':    case '5':    case '6':    case '7':    case '8':
-    case '9':    case 'e':    case 'E':    case 'p':    case 'P':
+    case 'e':  case 'E':  case 'p':  case 'P':
       if (c2 == '-' || c2 == '+')
 	return 1;		/* could extend a pre-processing number */
       goto letter;
@@ -1478,6 +1482,8 @@
 	return 1;		/* Could turn into L"xxx" or L'xxx'.  */
       goto letter;
 
+    case '.':  case '0':  case '1':  case '2':  case '3':
+    case '4':  case '5':  case '6':  case '7':  case '8':  case '9':
     case '_':  case 'a':  case 'b':  case 'c':  case 'd':  case 'f':
     case 'g':  case 'h':  case 'i':  case 'j':  case 'k':  case 'l':
     case 'm':  case 'n':  case 'o':  case 'q':  case 'r':  case 's':
>From khan@xraylith.wisc.EDU Sun Jul 04 16:04:00 1999
From: Mumit Khan <khan@xraylith.wisc.EDU>
To: "Martin v. Loewis" <martin@mira.isdn.cs.tu-berlin.de>
Cc: maeder@glue.ch, egcs-bugs@egcs.cygnus.com
Subject: Re: Internal compiler error 980711 
Date: Sun, 04 Jul 1999 16:04:00 -0000
Message-id: <199907042303.SAA11056@mercury.xraylith.wisc.edu>
References: <199907042052.WAA00451@mira.isdn.cs.tu-berlin.de>
X-SW-Source: 1999-07/msg00149.html
Content-length: 1744

"Martin v. Loewis" <martin@mira.isdn.cs.tu-berlin.de> writes:
> > I'm using egcs 1.1.2 (egcs-2.91.66) on 32bit Windows (NT Service Pack 4,
> > Intel). The attached compilation unit produces the following internal
> > error:
> 
> Thanks for your bug report. gcc-2.95 19990701 says
> 
> //h/Probase/Source/Pieces/Piece.h: At top level:
> //h/Probase/Source/Pieces/Piece.h:112: syntax error before `;'
> //h/Probase/Source/Pieces/Piece.h:114: syntax error before `;'
> 
> The reason is that std::auto_ptr is not available, which in turn seems
> to come from a missing #include <memory>.
> 

Including <memory> won't help much either since egcs-1.1.2 STL had
auto_ptr disabled.

Have to wait for gcc-2.95, the next release, sorry. Or, you can apply
the *untested and unsupported* patch to memory in the include/g++ dir.

Thu Mar 15 22:01:16 1999  Mumit Khan  <khan@xraylith.wisc.edu>

	* stl/memory (auto_ptr): Enable for egcs-1.1.2.

--- memory	Mon Mar 15 12:12:08 1999
+++ memory	Mon Apr 15 21:46:55 1999
@@ -26,8 +26,8 @@
 //  of the interface are still being discussed by the C++ standardization
 //  committee.  It will be included once the iterface is finalized.
 
-#if 0
-#if defined(_MUTABLE_IS_KEYWORD) && defined(_EXPLICIT_IS_KEYWORD) && \
+#if 1
+#if 1 || defined(_MUTABLE_IS_KEYWORD) && defined(_EXPLICIT_IS_KEYWORD) && \
     defined(__STL_MEMBER_TEMPLATES)
 
 __STL_BEGIN_NAMESPACE
@@ -73,7 +73,7 @@ public:
   X& operator*() const __STL_NOTHROW { return *ptr; }
   X* operator->() const __STL_NOTHROW { return ptr; }
   X* get() const __STL_NOTHROW { return ptr; }
-  X* release const __STL_NOTHROW { owns = false; return ptr }
+  X* release () __STL_NOTHROW { owns = false; return ptr; }
 };
 
 __STL_END_NAMESPACE

Regards,
Mumit


^ permalink raw reply	[flat|nested] 33+ messages in thread

* Internal compiler error 980711
@ 1999-06-25  1:46 Francesco Giacomini
  0 siblings, 0 replies; 33+ messages in thread
From: Francesco Giacomini @ 1999-06-25  1:46 UTC (permalink / raw)
  To: egcs-bugs

% c++ -v
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.66/specs
gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)
% uname -a
Linux pcatd37.cern.ch 2.2.9 #1-2.2.9.bphys-SMP Sat Jun 5 16:29:31 MEST 1999 i686
unknown
% c++ -I/data/giaco/pilot/t2ref/include  -I/data/giaco/sisci_api/include  -c
SCIException.cxx -o /data/giaco/pilot/t2ref/i686-Linux/obj/SCIException.o
In file included from SCIException.cxx:5:
/data/giaco/pilot/t2ref/include/msg/sci/SCIException.h:52: Internal compiler
error 980711.
/data/giaco/pilot/t2ref/include/msg/sci/SCIException.h:52: Please submit a full
bug report to `egcs-bugs@egcs.cygnus.com'.
/data/giaco/pilot/t2ref/include/msg/sci/SCIException.h:52: See
<URL: http://egcs.cygnus.com/faq.html#bugreport > for details.

A few remarks:
- the Linux kernel is patched with bigphysarea.
- the source code contains some errors, in particualar I use vector and string
without including the corresponding include files and I don't initialize a
vector in the correct way. If I only include <string> and <vector> the internal
compiler error disappears.

Regards, Francesco.
-- 
Francesco.Giacomini@cern.ch                        CERN EP-ATD
http://wwwinfo.cern.ch/~giacomin          Tel. +41 22 76 75022
SCIException.ii.gz


^ permalink raw reply	[flat|nested] 33+ messages in thread

* internal compiler error 980711
@ 1999-05-31 21:06 Dominic Williams
  1999-05-08  5:57 ` Martin v. Loewis
  0 siblings, 1 reply; 33+ messages in thread
From: Dominic Williams @ 1999-05-31 21:06 UTC (permalink / raw)
  To: egcs-bugs

EGCS VERSION
------------

g++ -v output:

Reading specs from
/usr/local/lib/gcc-lib/alpha-dec-osf3.2/egcs-2.91.66/specs
gcc version egcs-2.91.66 19990314 (egcs-1.1.2 release)

INPUT FILE
----------

// bug.cc

namespace NameA {
    class A {
    };
}

namespace NameB {
    class B;
}

typedef NameA::A NameB::B;

int main() {
    NameB::B b;
    return 0;
}

COMMAND ARGUMENTS
-----------------

g++ bug.cc

MACHINE
-------

ALPHAstation 255 300MHz
OSF 3.2g

CONFIGURE OPERANDS
------------------

--languages=c++

(libstdc++ compiled with -fsquangle).

MODIFICATIONS TO COMPILER SOURCE
-------------------------------

None

DESCRIPTION OF BUG
------------------

g++ bug.cc
bug.cc:10: Internal compiler error 980711.
bug.cc:10: Please submit a full bug report to
`egcs-bugs@egcs.cygnus.com'.
bug.cc:10: See <URL: http://egcs.cygnus.com/faq.html#bugreport > for
details.


^ permalink raw reply	[flat|nested] 33+ messages in thread

* Internal compiler error 980711
@ 1999-05-31 21:06 Helmut Swaczinna
  1999-05-31 21:06 ` Martin v. Loewis
  0 siblings, 1 reply; 33+ messages in thread
From: Helmut Swaczinna @ 1999-05-31 21:06 UTC (permalink / raw)
  To: egcs-bugs

[-- Attachment #1: Type: text/plain, Size: 312 bytes --]

g++ -v: gcc version egcs-2.91.60 19981201 (egcs-1.1.1 release)

uname -a: Linux dpases 2.0.36 #8 Tue Dec 8 15:34:59 MET 1998 i686 unknown

g++ -I. -I../../include -Wall -g -Wno-unused -D__x86__ -D__linux__
-D__OSVERSION__=2 -D_REENTRANT -c logmgr.cpp
logmgr.cpp:57: Internal compiler error 980711.
logmgr.ii.gz


[-- Attachment #2: logmgr.ii.gz --]
[-- Type: application/x-gzip, Size: 70511 bytes --]

^ permalink raw reply	[flat|nested] 33+ messages in thread

* Internal compiler error 980711
@ 1999-05-31 21:06 Cathy James
  1999-05-31 21:06 ` Martin v. Loewis
  0 siblings, 1 reply; 33+ messages in thread
From: Cathy James @ 1999-05-31 21:06 UTC (permalink / raw)
  To: egcs-bugs

[-- Attachment #1: Type: text/plain, Size: 75 bytes --]

egcs 1.1.2
Solaris 7 (UltraSparc)

g++ -c -g -DENABLE_CORBA

 
bug.tar.gz


[-- Attachment #2: bug.tar.gz --]
[-- Type: application/x-gzip, Size: 19927 bytes --]

^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: Internal compiler error 980711
  1999-05-31 21:06 Cathy James
@ 1999-05-31 21:06 ` Martin v. Loewis
  0 siblings, 0 replies; 33+ messages in thread
From: Martin v. Loewis @ 1999-05-31 21:06 UTC (permalink / raw)
  To: cjames; +Cc: egcs-bugs

Thanks for your bug report. egcs-2.93.21 reports

In file included from bug.cpp:3:
OSStdIncludes.h: At top level:
OSStdIncludes.h:7: syntax error before `;'
OSStdIncludes.h:8: syntax error before `::'

which is caused by a missing include of <list>. Anyway, the bug seems
to be fixed.

Hope this helps,
Martin


^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: Internal compiler error 980711
  1999-05-31 21:06 Helmut Swaczinna
@ 1999-05-31 21:06 ` Martin v. Loewis
  0 siblings, 0 replies; 33+ messages in thread
From: Martin v. Loewis @ 1999-05-31 21:06 UTC (permalink / raw)
  To: Helmut.Swaczinna; +Cc: egcs-bugs

Thanks for your bug report. egcs-2.93.21 reports a number of errors;
among them

logmgr.cpp: At top level:
logmgr.cpp:57: syntax error before `;'

where the problem apparently is that CORBA::sequence is not a template
type.

Anyway, the bug appears to be fixed.

Hope this helps,
Martin


^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: internal compiler error 980711
  1999-05-31 21:06 internal " Dominic Williams
@ 1999-05-08  5:57 ` Martin v. Loewis
  0 siblings, 0 replies; 33+ messages in thread
From: Martin v. Loewis @ 1999-05-08  5:57 UTC (permalink / raw)
  To: d.williams; +Cc: egcs-bugs

> g++ bug.cc
> bug.cc:10: Internal compiler error 980711.
> bug.cc:10: Please submit a full bug report to
> `egcs-bugs@egcs.cygnus.com'.
> bug.cc:10: See <URL: http://egcs.cygnus.com/faq.html#bugreport > for
> details.

Thanks for your bug report. egcs-2.93.21 reports

bug.cc:10: `B' specified as declarator-id
bug.cc:10: multiple declarations `int' and `NameA::A'
bug.cc: In function `int main()':
bug.cc:13: aggregate `class NameB::B b' has incomplete type and cannot be initialized

so the bug will be fixed in the next egcs release.

Regards,
Martin
>From dpw@doc.ic.ac.uk Sat May 08 06:16:00 1999
From: David Wragg <dpw@doc.ic.ac.uk>
To: egcs-bugs@egcs.cygnus.com
Subject: Does egcs-1.1.2 have known bugs with -O6 -march=pentiumpro ?
Date: Sat, 08 May 1999 06:16:00 -0000
Message-id: <y7rn1zfitwn.fsf@sytry.doc.ic.ac.uk>
X-SW-Source: 1999-05/msg00165.html
Content-length: 436

Hi,

I'm having problems with code generated by 1.1.2 with -O6
-march=pentiumpro that go away with -O6 -mpentiumpro. I know that
1.1.1 had problems with -O6 -march=pentiumpro relating to cmov, but
the 1.1.2 release announcement indicates that these were fixed. Could
someone tell me if there are known problems in this area; if not I'll
try and isolate the problem code.

Thanks,
Dave Wragg
(Not subcribed to the list, so please Cc me)
>From craig@jcb-sc.com Sat May 08 07:21:00 1999
From: craig@jcb-sc.com
To: alleon@club-internet.fr
Cc: craig@jcb-sc.com
Subject: Re: Pb mixing C & Fortran IO
Date: Sat, 08 May 1999 07:21:00 -0000
Message-id: <19990508141746.18225.qmail@deer>
References: <926144451.1249.ezmlm@sourceware.cygnus.com> <3733FF86.D01958ED@club-internet.fr> <373402A1.7CDBB1DA@club-internet.fr> <373402A1.7CDBB1DA@club-internet.fr>
X-SW-Source: 1999-05/msg00166.html
Content-length: 1047

> I encounter a problem when mixing C and Fortran IO in my code. Here are samples that
> reproduce the problem :

Don't do that.  Any file or unit opened in one module cannot be safely
accessed in another module (via the usual language facilities, anyway,
which includes g77's libU77 routines, such as FGETC) *unless* that module
is uses the same level of language facilities (where Fortran's WRITE and
g77's FPUTC are on *two* different levels) *and* is compiled by the same
compiler.

And, yes, we need to document this.  We explain it this way in the docs
on each of the pertinent libU77 intrinsics:

  Stream I/O should not be mixed with normal record-oriented (formatted or
  unformatted) I/O on the same unit; the results are unpredictable.

However, we should explain it also in writeups on inter-language and
inter-compiler mixing.  I'll work on this later.

One approach I think some people use to avoid this whole problem is to
code all I/O in C, and all number-crunching in Fortran, when they have
to use both.

        tq vm, (burley)
>From N8TM@aol.com Sat May 08 08:13:00 1999
From: N8TM@aol.com
To: egcs-bugs@egcs.cygnus.com
Subject: egcs-19990502/g77 ICE in expand_expr for do while()
Date: Sat, 08 May 1999 08:13:00 -0000
Message-id: <9d60d393.2465ae49@aol.com>
X-SW-Source: 1999-05/msg00167.html
Content-length: 366

These ICEs which I saw yesterday may be boiled down to the following out of 
context fragment which continues to fail on i[56]86.  Unlike the complete 
version, I can assign this to FSF:

      subroutine dobug(xdata ,xin,ndata,nxy)
      real xdata (ndata ),xin(nxy)
	   i= 1
		  j= 2
		  dowhile(xin(i) > xdata (j))
		    j= j+1
		    enddo
      return
      end
>From matti.aarnio@sonera.fi Sat May 08 11:34:00 1999
From: Matti Aarnio <matti.aarnio@sonera.fi>
To: egcs-bugs@egcs.cygnus.com
Subject: Alpha optimizer problem ?
Date: Sat, 08 May 1999 11:34:00 -0000
Message-id: <19990508183354Z92377-409+2@mea.tmt.tele.fi>
X-SW-Source: 1999-05/msg00168.html
Content-length: 1856

Sorry, no easy to try small source packages for this..

I have been trying to compile  OpenSSL (current rsynced cvs repository
version) at my Linux/Alpha system using current CVS snapshot of the egcs.
( About OpenSSL: www.openssl.org )

When the "./config" produces the default Makefiles, the package is compiled
with "-O3", and "make test" fails at IDEA algorithm tests, as well as at RC5,
"TEST BN" and RSA tests.

When I edit "Configure" file for optimizer setup:

  # Dec Alpha, OSF/1 - the alpha164-cc is the flags for a 21164A with
  # the new compiler
  # For gcc, the following gave a %50 speedup on a 164 over the 'DES_INT' version
  "alpha-gcc","gcc:-O3:(unknown)::SIXTY_FOUR_BIT_LONG DES_UNROLL DES_RISC1:::",
  "alpha-cc", "cc:-std1 -tune host -O4 -readonly_strings:(unknown)::SIXTY_FOUR_BIT_LONG:::",
  "alpha164-cc", "cc:-std1 -tune host -fast -readonly_strings:(unknown)::SIXTY_FOUR_BIT_LONG:::",

Changeing above "-O3" to "-O1" produces working package (per "make test"),
and using there "-O2" fails alike "-O3".

For some reason those above mentioned crypto parts fail when optimized
with -O2 or above.  If I compile the system with -O3, and then remove
all .o and 'lib' files at crypto/idea/, crypto/rc5/, crypto/bn/ and
crypto/rsa/ subdirs, change "CFLAGS=" at the top-level Makefile to "-O1",
and then again do 'make test', the resulting new tests are all ok.
(Which I take to mean that the -O1 of those crypto codes is ok.)

Because IDEA algorithm is very small loop, and in fact the en-, and de-
code are the same algorithm, just with different keys, it should be fairly
trivial to do more fine grained testing of various submodules of the key
scheduling in addition to the encrypted, and then decrypted datablocks,
as the current ideatest.c does.. (but I don't now have a change to try that.)

/Matti Aarnio <matti.aarnio@sonera.fi>
>From nillius@nada.kth.se Sat May 08 12:55:00 1999
From: Peter Nillius <nillius@nada.kth.se>
To: egcs-bugs@egcs.cygnus.com
Subject: bug egcs 1.1.2
Date: Sat, 08 May 1999 12:55:00 -0000
Message-id: <Pine.GSO.3.95.990508214732.3597A-101000@cvap13.nada.kth.se>
X-SW-Source: 1999-05/msg00169.html
Content-length: 2496

Hello there!

The bug I am sendning doesn't produce a compiler error. However I am
pretty sure it is a bug. See the included t2.C for
(minimalistic) comments.

Yours sincerely,
Peter Nillius
email: nillius@nada.kth.se


Output from command: g++ -v --save-temps -o t2 t2.C

Reading specs from
/opt/egcs/egcs-1.1.2/lib/gcc-lib/powerpc-unknown-linux-gnulibc1/egcs-2.91.66/specs
gcc version egcs-2.91.66 19990314 (egcs-1.1.2 release)

/opt/egcs/egcs-1.1.2/lib/gcc-lib/powerpc-unknown-linux-gnulibc1/egcs-2.91.66/cpp
-lang-c++ -v -undef -D__GNUC__=2 -D__GNUG__=2 -D__cplusplus
-D__GNUC_MINOR__=91 -DPPC -D__ELF__ -Dunix -Dlinux -Dpowerpc
-D__PPC__ -D__ELF__ -D__unix__ -D__linux__ -D__powerpc__ -D__PPC
-D__unix -D__linux -D__powerpc -Asystem(unix) -Asystem(linux)
-Acpu(powerpc) -Amachine(powerpc) -D__EXCEPTIONS -D__CHAR_UNSIGNED__
-D_CALL_SYSV -D_BIG_ENDIAN -D__BIG_ENDIAN__ -Amachine(bigendian)
-D_ARCH_PPC -D__unix__ -D__linux__ -Dunix -Dlinux -Asystem(unix)
-Asystem(linux) t2.C t2.ii
GNU CPP version egcs-2.91.66 19990314 (egcs-1.1.2 release) (PowerPC
GNU/Linux)
#include "..." search starts here:
#include <...> search starts here:
 /opt/egcs/egcs-1.1.2/include/g++
 /usr/local/include
 /opt/egcs/egcs-1.1.2/powerpc-unknown-linux-gnulibc1/include

/opt/egcs/egcs-1.1.2/lib/gcc-lib/powerpc-unknown-linux-gnulibc1/egcs-2.91.66/include
 /usr/include
End of search list.

/opt/egcs/egcs-1.1.2/lib/gcc-lib/powerpc-unknown-linux-gnulibc1/egcs-2.91.66/cc1plus
t2.ii -quiet -dumpbase t2.cc -version -o t2.s
GNU C++ version egcs-2.91.66 19990314 (egcs-1.1.2 release)
(powerpc-unknown-linux-gnulibc1) compiled by GNU C version
egcs-2.91.66 19990314 (egcs-1.1.2 release).
 as -mppc -V -Qy -o t2.o t2.s
GNU assembler version 2.9.1 (powerpc-unknown-linux-gnulibc1), using
BFD version 2.9.1

/opt/egcs/egcs-1.1.2/lib/gcc-lib/powerpc-unknown-linux-gnulibc1/egcs-2.91.66/collect2
-m elf32ppc -dynamic-linker /lib/ld.so.1 -o t2 /usr/lib/crt1.o
/usr/lib/crti.o
/opt/egcs/egcs-1.1.2/lib/gcc-lib/powerpc-unknown-linux-gnulibc1/egcs-2.91.66/crtbegin.o
-L/opt/egcs/egcs-1.1.2/lib/gcc-lib/powerpc-unknown-linux-gnulibc1/egcs-2.91.66
-L/opt/egcs/egcs-1.1.2/powerpc-unknown-linux-gnulibc1/lib
-L/opt/egcs/egcs-1.1.2/lib t2.o -lstdc++ -lm
/opt/egcs/egcs-1.1.2/lib/gcc-lib/powerpc-unknown-linux-gnulibc1/egcs-2.91.66/libgcc.a
-lc
/opt/egcs/egcs-1.1.2/lib/gcc-lib/powerpc-unknown-linux-gnulibc1/egcs-2.91.66/libgcc.a
/opt/egcs/egcs-1.1.2/lib/gcc-lib/powerpc-unknown-linux-gnulibc1/egcs-2.91.66/crtend.o
/usr/lib/crtn.o



^ permalink raw reply	[flat|nested] 33+ messages in thread

* Internal compiler error 980711.
@ 1999-04-30 23:15 Daniel Engovatov
  0 siblings, 0 replies; 33+ messages in thread
From: Daniel Engovatov @ 1999-04-30 23:15 UTC (permalink / raw)
  To: egcs-bugs

Hi,
	Sorry, no time to write a full bug report.
But I guess you already know this bug - when I 
made a typo

std::degue<int>& getSegment(double _startingTime, double _span);

instead of deque..

egcs 1.1.2 (for linux) died with an internal compiler error -
instead of blaming me for forgetfullness...

Regards,
Daniel.

g++ -O6 -Wall -funroll-all-loops -c TimingData.cpp In file included from
TimingData.cpp:7: TimingData.h:68: Internal compiler error 980711.
TimingData.h:68: Please submit a full bug report to
`egcs-bugs@egcs.cygnus.com'. TimingData.h:68: See
<URL: http://egcs.cygnus.com/faq.html#bugreport > for details. make: ***
[TimingData.o] Error 1




^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: Internal compiler error 980711
  1999-03-29  8:18 KELEMEN Peter
@ 1999-04-28 10:53 ` Nathan Sidwell
  0 siblings, 0 replies; 33+ messages in thread
From: Nathan Sidwell @ 1999-04-28 10:53 UTC (permalink / raw)
  To: fuji; +Cc: egcs-bugs

KELEMEN Peter wrote:

> std::map<int, int> x;
Thanks for the report, the current snapshot reports
kelemen.C:4: syntax error before `;'

which is what you expected. The fix should end up in the 1.2 release.

nathan

-- 
Dr Nathan Sidwell :: Computer Science Department :: Bristol University
      You can up the bandwidth, but you can't up the speed of light      
nathan@acm.org  http://www.cs.bris.ac.uk/~nathan/  nathan@cs.bris.ac.uk
>From korbb@egcs.cygnus.com Wed Apr 28 11:21:00 1999
From: korbb@egcs.cygnus.com
To: egcs-bugs@egcs.cygnus.com, egcs@egcs.cygnus.com
Cc: ddsinc09@ix.netcom.com
Subject: Re: EGCS Optimization bug on HPUX
Date: Wed, 28 Apr 1999 11:21:00 -0000
Message-id: <19990428182114.5767.qmail@egcs.cygnus.com>
X-SW-Source: 1999-04/msg00800.html
Content-length: 1592

Reply-To: ddsinc09@ix.netcom.com


Has this issue ever been addressed or looked at?
I haven't seen followup since
John David Anglin <dave@hiauly1.hia.nrc.ca>
a week ago.  Thanks.


> The following code fragment appears in AutoGen's evalExpr_SHSTR
> routine in src/agExpr.c:
> 
>      *(pz++) = '"';
>      for (;;) {
>          switch (*(pz++) = *(pzDta++)) {
>          case NUL:
>              goto loopDone2;
> 
>          case '"':
>          case '\\':
>              pz[-1]  = '\\';
>              *(pz++) = pzDta[-1];
>          }
>      } loopDone2:;
>      pz[-1] = '"';
>      *pz    = NUL;
> 
> AutoGen is available from:
> 
>    ftp://sourceware.cygnus.com/pub/egcs/infrastructure/autogen.tar.gz
> 
> Under optimization levels 2 and above, the value for "pzDta" is
> apparently stored in both a register and in memory _AND_ they are
> not kept in sync.  Here is an example from autogen/tests/evalstr.test:

I believe the above observation is essentially correct.  However, it
is the synchronization between two registers rather than register and
memory.  At -O2 and above, additional registers are used to hold pz-1
and pzDta-1.  These registers are not properly kept in sync with the
registers used for pz and pzDta.

I created this test program:

#define NUL 0
void loop (char * pz, char * pzDta)
{
    for (;;) {
        switch (*(pz++) = *(pzDta++)) {
        case NUL:
            goto loopDone2;

        case '"':
        case '\\':
            pz[-1]  = '\\';
            *(pz++) = pzDta[-1];
        }
    } loopDone2:;
}

Here is the assembler code at -O1:

[[omitted]]
>From Franz.Sirl-kernel@lauterbach.com Wed Apr 28 11:21:00 1999
From: Franz Sirl <Franz.Sirl-kernel@lauterbach.com>
To: egcs-bugs@egcs.cygnus.com
Cc: Michael Meissner <meissner@cygnus.com>, David Edelsohn <dje@watson.ibm.com>
Subject: Possible minor bugs in PPC/SYSV stacklayout
Date: Wed, 28 Apr 1999 11:21:00 -0000
Message-id: <4.2.0.32.19990428200626.03b83b80@mail.lauterbach.com>
X-SW-Source: 1999-04/msg00801.html
Content-length: 1845

Hi,

in rs6000.h exists this fragment:

/* Size of V.4 varargs area in bytes */
#define RS6000_VARARGS_SIZE \
  ((GP_ARG_NUM_REG * (TARGET_32BIT ? 4 : 8)) + (FP_ARG_NUM_REG * 8) + 8)


and the following code in rs6000.c:setup_incoming_varargs():

  /* Save FP registers if needed.  */
  if ((DEFAULT_ABI == ABI_V4 || DEFAULT_ABI == ABI_SOLARIS) && 
TARGET_HARD_FLOAT && !no_rtl)
    {
      int fregno     = cum->fregno;
      int num_fp_reg = FP_ARG_V4_MAX_REG + 1 - fregno;

      if (num_fp_reg >= 0)
        {
          rtx cr1 = gen_rtx_REG (CCmode, 69);
          rtx lab = gen_label_rtx ();
          int off = (GP_ARG_NUM_REG * reg_size) + ((fregno - 
FP_ARG_MIN_REG) * 8);

          emit_jump_insn (gen_rtx_SET (VOIDmode,
                                   pc_rtx,
                                   gen_rtx_IF_THEN_ELSE (VOIDmode,
                                            gen_rtx_NE (VOIDmode, cr1, 
const0_rtx),
                                            gen_rtx_LABEL_REF (VOIDmode, lab),
                                            pc_rtx)));

          while ( num_fp_reg-- >= 0)
            {
              emit_move_insn (gen_rtx_MEM (DFmode, plus_constant 
(save_area, off)),
                              gen_rtx_REG (DFmode, fregno++));
              off += 8;
            }

          emit_label (lab);
        }
    }

Shouldn't both (num_fp_reg-- >= 0) comparisons be (num_fp_reg-- > 0)? The 
ABI requires f1-f8 to be saved, but currently f1-f9 are saved. And isn't 
the last addition of 8 in RS6000_VARARGS_SIZE superfluous then? A quick 
browse of the ABI spec didn't reveal that this is required.

The other thing is that the current mainline allocates a stackframe that is 
roughly twice as large as the stackframe allocated by egcs-1.1.2. David, 
could this be caused by the 64-bit stuff you checked in?

Franz.


^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: Internal compiler error 980711
  1999-03-31 23:54 Anders Joelsson
@ 1999-03-31 23:54 ` Martin v. Loewis
  0 siblings, 0 replies; 33+ messages in thread
From: Martin v. Loewis @ 1999-03-31 23:54 UTC (permalink / raw)
  To: andersj; +Cc: egcs-bugs

> The following example gives an internal compiler error
> (  forgot to include <map):

Thanks for your report. This is a known bug, which is fixed in the
development snapshots. It is still present in 1.1.2.

Regards,
Martin


^ permalink raw reply	[flat|nested] 33+ messages in thread

* Internal compiler error 980711
@ 1999-03-31 23:54 Braden N. McDaniel
  0 siblings, 0 replies; 33+ messages in thread
From: Braden N. McDaniel @ 1999-03-31 23:54 UTC (permalink / raw)
  To: egcs-bugs

[-- Attachment #1: Type: text/plain, Size: 130 bytes --]

egcs version 1.1.2
Red Hat Linux 5.2, kernel 2.0.36
only option passed was -c


Braden McDaniel
ExternInterfaceDeclaration.ii.gz


[-- Attachment #2: ExternInterfaceDeclaration.ii.gz --]
[-- Type: application/x-gzip, Size: 31044 bytes --]

^ permalink raw reply	[flat|nested] 33+ messages in thread

* Internal compiler error 980711
@ 1999-03-31 23:54 Anders Joelsson
  1999-03-31 23:54 ` Martin v. Loewis
  0 siblings, 1 reply; 33+ messages in thread
From: Anders Joelsson @ 1999-03-31 23:54 UTC (permalink / raw)
  To: 'egcs-bugs@cygnus.com'

Version: egcs-1.1b
OS: Solaris 2.5.1


The following example gives an internal compiler error
(  forgot to include <map):

class C
{
public:

   std::map<int, int> m;

}


gonzo:/proj/fc/work/andersj/src/tst/c/egcsbug> g++ egcsbug.cpp
egcsbug.cpp:5: Internal compiler error 980711.
egcsbug.cpp:5: Please submit a full bug report to `egcs-bugs@cygnus.com'.
gonzo:/proj/fc/work/andersj/src/tst/c/egcsbug> 




Best Regards

Anders Joelson


^ permalink raw reply	[flat|nested] 33+ messages in thread

* Internal compiler error 980711
@ 1999-03-29  8:18 KELEMEN Peter
  1999-04-28 10:53 ` Nathan Sidwell
  0 siblings, 1 reply; 33+ messages in thread
From: KELEMEN Peter @ 1999-03-29  8:18 UTC (permalink / raw)
  To: egcs-bugs

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 8454 bytes --]

Hello.

One day playing around with egcs C++ compiler I came accross this
problem.

Test cases are separated by "##########".
Source code lines follow until the "--" separator.
'g++ -E' output follows until the next "--" separator.
My comments follow until the next "##########" separator.

				* * *

##########
std::map<int, int> x;
--
# 1 "x.cc"
std::map<int, int> x;
--
x.cc:1: Internal compiler error 980711.
x.cc:1: Please submit a full bug report to `egcs-bugs@egcs.cygnus.com'.
x.cc:1: See <URL: http://egcs.cygnus.com/faq.html#bugreport > for details.
--
This is the simplest source file that I can reproduce the bug with.  It
turned out that way, I wanted to use "map" from STL, but I forgot to
include <map>.  If I #include <map>, everything goes well and g++ fails
at linking.  It seems that it it's irrelevant if I use map or any other
string starting with a letter.  Also it seems that it's irrelevant if I
have something else than "std" before the double colon.  If I leave out
"std::", the compiler complains about parse error before ';' which is
right IMHO.
##########

				* * *

Filename containing the source:
x.cc

Command used to compile source:
g++ x.cc

Machine type and operating system:
Sun UltraSPARC I (167Mhz), Solaris 2.6
SunOS valerie 5.6 Generic sun4u sparc SUNW,Ultra-1

Complete command used to configure egcs:
CC=/usr/local/langs/gcc-2.7.2.3/bin/gcc ../egcs-1.1.2/configure \
	--prefix=/usr/local/langs/egcs-1.1.2 \
	--with-local-prefix=/usr/local/langs/egcs-1.1.2 \
	--with-gxx-include-dir=/usr/local/langs/egcs-1.1.2/include/g++ \
	--enable-shared \
	--enable-haifa \
	--enable-threads \
	--enable-version-specific-runtime-libs \
	--enable-languages="c,c++,objc"

Modifications to the compiler code:
NONE

Command used to compile egcs (with gcc-2.7.2.3):
nice -19 safemake CFLAGS='-O' LIBCFLAGS='-g -O2' LIBCXXFLAGS='-g -O2 -fno-implicit-templates' bootstrap
NOTE: safemake is a shell script that passes all parameters to make and
redirects the output to a log file.  Compilation log is not attached due
to size (391k) and is available upon request.

Failure syndrome:
I get "Internal compiler error 980711." message.

Compiler version (g++ -v):
Reading specs from /usr/local/langs/egcs-1.1.2/lib/gcc-lib/sparc-sun-solaris2.6/egcs-2.91.66/specs
gcc version egcs-2.91.66 19990314 (egcs-1.1.2 release)

				* * *

-- 
KELEMEN Péter				fuji@cs.tut.fi
Research Assistant			http://www.cs.tut.fi/~fuji
Room HB230, +358 3 3653704		Dept. of Information Technology
Tampere University of Technology	Software Systems Laboratory
>From law@upchuck.cygnus.com Mon Mar 29 08:19:00 1999
From: Jeffrey A Law <law@upchuck.cygnus.com>
To: ak@muc.de
Cc: egcs-bugs@egcs.cygnus.com
Subject: Re: Strange regression in egcs-current/x86 
Date: Mon, 29 Mar 1999 08:19:00 -0000
Message-id: <965.922706270@upchuck>
References: <19980704150630.38682@kali.lrz-muenchen.de>
X-SW-Source: 1999-03/msg00948.html
Content-length: 1194

  In message <19980704150630.38682@kali.lrz-muenchen.de>you write:
  > Hello,
  > 
  > There is something strange in the x86 code generated by egcs-current. 
I don't think so.

  > f(int i)
  > {
  > 	float b[i + 1];
  > 
  > 	for (int c = 0; c <= i; c++) { 
  > 		b[c] = sin(c - 1); /* nonsense */ 
  > 	} 
  > }


  >         movl 8(%ebp),%ecx
  >         leal 1(%ecx),%eax        <-------
  >         sall $5,%eax             <------- shift to the left
  > 	    shrl $3,%eax             <------- shift back
  >         subl %eax,%esp
  > [...]
  > 
  > g++ 2.7.2 did it with:
  > 
  > [..]
  >         movl %esp,-8(%ebp)
  >         leal 4(,%esi,4),%eax
  >         subl %eax,%esp
  > 
  > I know that often more primitive operations are faster on later x86 CPUs,
  > but I doubt that first shifting to the left, and the backshifting to the 
  > right is the fastest way to do it. It seems some patterns got lost or the
  > combiner has some problems. 
Combining shifts like that is not safe.

Consider the value 0x20000000

If you shift it left 5 times, then shift it right 3 times you get the value
zero.

If you combine the shifts and just shift it left 2 times you get 0x80000000.

jeff
>From norbert@dune.gia.rwth-aachen.de Mon Mar 29 08:43:00 1999
From: Norbert Berzen <norbert@dune.gia.rwth-aachen.de>
To: law@cygnus.com
Cc: egcs-bugs@egcs.cygnus.com
Subject: Re: Bad line number debug info on alpha-dec-osf
Date: Mon, 29 Mar 1999 08:43:00 -0000
Message-id: <9903291108.AA07176@dune.gia.rwth-aachen.de>
References: <2327.922596281@upchuck> <2327.922596281@upchuck>
X-SW-Source: 1999-03/msg00949.html
Content-length: 1558

Compiler:            egcs-2.91.66
--------

Machine/OS:          alpha-dec-osf3.2
----------

Compilation command: gcc -g -S -o myfile myfile.c
-------------------

Input file:          "myfile.c"
----------

      int a;

      void f (void)
      {
        a = 7;
      }

      int main ()
      {
        f ();
	return 0;
      }

Output file:        "myfile.s"
-----------

        ... some stuff deleted here

	.align 5
	.globl f
	.ent f
f:
	.frame $15,16,$26,0
	.mask 0x4008000,-16
	ldgp $29,0($27)
$f..ng:
$LM1:
	 #.stabn 68,0,6,$LM1
	subq $30,16,$30

        ... some stuff deleted here


The Bug:  The label `$LM1:' (and the `#.stabn 68,0,6,$LM1')
-------   should appear _before_ the `ldgp $29,0($27)'.

Comment:
-------

The effect of this bug is that the function prologue checking
mechanism of stock gdb-4.17 (and gdb-4.17.X) gets totally
confused. So the `next' and `nexti' commands of gdb do not
work as expected. They step _into_ `f()' instead of stepping
over it. IMHO the bug should be fixed but it is not so easy to
do it the clean way since not only alpha specific source must
be modified but also machine independent source is affected.

The two offending functions are:

alpha_start_function() (called by `assemble_start_function()'):
   Here, the `ldgp $29,0($27)' gets patched into the compiler output.

final_start_function():
   Here the `#.stabn ...' gets generated.

Perhaps another way of fixing the problem would be making the
`#.stabn ...' directly refer to the function's label `f' instead
of `$LM1'.


Greetings
-- 
Norbert
>From arvinds@mit.edu Mon Mar 29 09:24:00 1999
From: Arvind Sankar <arvinds@mit.edu>
To: Jeffrey A Law <law@upchuck.cygnus.com>, ak@muc.de
Cc: egcs-bugs@egcs.cygnus.com
Subject: Re: Strange regression in egcs-current/x86
Date: Mon, 29 Mar 1999 09:24:00 -0000
Message-id: <19990329122359.A7311@anjala.mit.edu>
References: <19980704150630.38682@kali.lrz-muenchen.de> <965.922706270@upchuck> <965.922706270@upchuck>
X-SW-Source: 1999-03/msg00950.html
Content-length: 1085

On Mon, Mar 29, 1999 at 04:17:50AM -0700, Jeffrey A Law wrote:
>   In message <19980704150630.38682@kali.lrz-muenchen.de>you write:
>   > Hello,
>   > 
>   > There is something strange in the x86 code generated by egcs-current. 
> I don't think so.
> 
>   > f(int i)
>   > {
>   > 	float b[i + 1];
>   > 
>   > 	for (int c = 0; c <= i; c++) { 
>   > 		b[c] = sin(c - 1); /* nonsense */ 
>   > 	} 
>   > }
> 
> 
>   > I know that often more primitive operations are faster on later x86 CPUs,
>   > but I doubt that first shifting to the left, and the backshifting to the 
>   > right is the fastest way to do it. It seems some patterns got lost or the
>   > combiner has some problems. 
> Combining shifts like that is not safe.
> 
> Consider the value 0x20000000
> 
> If you shift it left 5 times, then shift it right 3 times you get the value
> zero.
> 
> If you combine the shifts and just shift it left 2 times you get 0x80000000.
> 
> jeff

But isn't the code asking for an array of size 0x80000000? Is this done because
we can't have negative array sizes on the stack?

-- arvind
>From earnie_boyd@yahoo.com Mon Mar 29 10:32:00 1999
From: Earnie Boyd <earnie_boyd@yahoo.com>
To: egcs-bugs@egcs.cygnus.com
Subject: c++ -E -dM testit.h
Date: Mon, 29 Mar 1999 10:32:00 -0000
Message-id: <19990329183413.5585.rocketmail@web121.yahoomail.com>
X-SW-Source: 1999-03/msg00951.html
Content-length: 455

I have found that the subjected command doesn't set the __cplusplus macro
properly.  Is this a bug or a feature?


===
-                        \\||//
-------------------o0O0--Earnie--0O0o-------------------
--                earnie_boyd@yahoo.com               --
----------------------ooo0O--O0ooo----------------------

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: Internal compiler error 980711
  1998-11-04 12:11 B. K. Oxley (binkley)@Home
@ 1998-11-26 20:58 ` Alexandre Oliva
  0 siblings, 0 replies; 33+ messages in thread
From: Alexandre Oliva @ 1998-11-26 20:58 UTC (permalink / raw)
  To: B. K. Oxley (binkley)@Home; +Cc: egcs-bugs

On Nov  4, 1998, "B. K. Oxley (binkley) at Home" <binkley@bigfoot.com> wrote:

> XFile.h:81: Internal compiler error 980711.
> XFile.h:81: Please submit a full bug report to `egcs-bugs@cygnus.com'.

> template<class P,
>   class V = typename P::value_type,
>   class S = typename P::size_type>
> class index_proxy
> {
> public:
>   typedef P parent_type;

> private:
>   friend parent_type;

Thanks for your report.  The problem is that you cannot declare a
template argument as a friend.  I installed the simplified testcase
above in the testsuite.

-- 
Alexandre Oliva  http://www.dcc.unicamp.br/~oliva  aoliva@{acm.org}
oliva@{dcc.unicamp.br,gnu.org,egcs.cygnus.com,samba.org}
Universidade Estadual de Campinas, SP, Brasil



^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: Internal compiler error 980711
  1998-11-17  8:15 Jan Braun
@ 1998-11-26 20:58 ` Alexandre Oliva
  0 siblings, 0 replies; 33+ messages in thread
From: Alexandre Oliva @ 1998-11-26 20:58 UTC (permalink / raw)
  To: Jan Braun; +Cc: egcs-bugs

> my egcs-1.1b asked me to send you this bug-report, but I'm quiet
> shure, you allready know this.

I don't think so.  A complete bug report would be welcome.  See
http://egcs.cygnus.com/faq.html#bugreport for instructions.

-- 
Alexandre Oliva  http://www.dcc.unicamp.br/~oliva  aoliva@{acm.org}
oliva@{dcc.unicamp.br,gnu.org,egcs.cygnus.com,samba.org}
Universidade Estadual de Campinas, SP, Brasil



^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: Internal compiler error 980711
  1998-10-24 22:55 Amaury Cedrick Darsch
@ 1998-11-26 20:58 ` Alexandre Oliva
  0 siblings, 0 replies; 33+ messages in thread
From: Alexandre Oliva @ 1998-11-26 20:58 UTC (permalink / raw)
  To: Amaury Cedrick Darsch; +Cc: egcs-bugs, amaury

On Oct 25, 1998, Amaury Cedrick Darsch <amaury@sj-coop.net> wrote:

> ecgs-version: 1.1 (egcs-2.91.57 debian distribution i586-linux kernel 2.0.35)

> namespace A {
>   struct foo {
>     A::foo (void) {

I couldn't reproduce the ICE you report with egcs 1.1, nor with its
latest snapshot, on a x86 platform running RedHat Linux 5.1.  I always 
get the following error message:

t.cc:12: using-declaration for non-member at class scope
t.cc:12: parse error before `('

-- 
Alexandre Oliva  http://www.dcc.unicamp.br/~oliva  aoliva@{acm.org}
oliva@{dcc.unicamp.br,gnu.org,egcs.cygnus.com,samba.org}
Universidade Estadual de Campinas, SP, Brasil



^ permalink raw reply	[flat|nested] 33+ messages in thread

* Re: Internal compiler error 980711
  1998-10-15  6:56 bjornw
@ 1998-11-26 20:41 ` Alexandre Oliva
  0 siblings, 0 replies; 33+ messages in thread
From: Alexandre Oliva @ 1998-11-26 20:41 UTC (permalink / raw)
  To: bjornw; +Cc: egcs-bugs

On Oct 15, 1998, bjornw@fairplay.no wrote:

> namespace hei { class CSomeClass {}; extern CSomeClass SomeClass; };
> hei::CSomeClass hei::CSomeClass;

Thanks, I installed your testcase in the testsuite

-- 
Alexandre Oliva  http://www.dcc.unicamp.br/~oliva  aoliva@{acm.org}
oliva@{dcc.unicamp.br,gnu.org,egcs.cygnus.com,samba.org}
Universidade Estadual de Campinas, SP, Brasil



^ permalink raw reply	[flat|nested] 33+ messages in thread

* Internal compiler error 980711
@ 1998-11-17  8:15 Jan Braun
  1998-11-26 20:58 ` Alexandre Oliva
  0 siblings, 1 reply; 33+ messages in thread
From: Jan Braun @ 1998-11-17  8:15 UTC (permalink / raw)
  To: egcs-bugs

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1062 bytes --]

Hi,

my egcs-1.1b asked me to send you this bug-report, but I'm quiet
shure, you allready know this.

I wanted to compile this function head.  I used JBM as namespace and
matrix<T> is a typo of Matrix<T> which is actually the name of the
class I write.  

template <class T>
bool
JBM::matrix<T>::push_back(const t_vec& _new_column)

I defined 

  typedef vector<T> t_vec;

in the header file.  If I replace `t_vec' with `vector<T>', I still get:
`Internal compiler error 980711.' 

But if I correct the typo, the source is compiled without errors.

If you need more information, don't hesitate to mail me.  Thanks for
your great work.

Have a nice time


     Jan

-- 
   Jan Braun                                  <Jan.Braun@tu-clausthal.de>
   Institut für Technische Mechanik           http://www.itm.tu-clausthal.de/
   TU Clausthal                               Tel.: 0 53 23 / 72-37 27 
   Graupenstraße 3			      Fax.: 0 53 23 / 72-37 27 
   38678 Clausthal-Zellerfeld
===== ypchsh /usr/local/bin/emacs :-)  (-: ``Go FORTH now and create ...''====


^ permalink raw reply	[flat|nested] 33+ messages in thread

* Internal compiler error 980711
@ 1998-11-04 12:11 B. K. Oxley (binkley)@Home
  1998-11-26 20:58 ` Alexandre Oliva
  0 siblings, 1 reply; 33+ messages in thread
From: B. K. Oxley (binkley)@Home @ 1998-11-04 12:11 UTC (permalink / raw)
  To: egcs-bugs

While compiling with g++ I got an internal compiler error 980711:

cd h:/src/STLX/
make -k main
g++     main.cc   -o main
In file included from main.cc:1:
XFile.h:81: Internal compiler error 980711.
XFile.h:81: Please submit a full bug report to `egcs-bugs@cygnus.com'.
make: *** [main] Error 1

Compilation exited abnormally with code 2 at Wed Nov 04 15:08:01

My compiler information:

h:\src\STLX>g++ -v
g++ -v
Reading specs from C:\mingw32\lib\gcc-lib\i386-mingw32\egcs-2.91.57\specs
gcc version egcs-2.91.57 19980901 (egcs-1.1 release)

Verbose compiling says:

h:\src\STLX>g++ -v main.cc -o main
g++ -v main.cc -o main
Reading specs from C:\mingw32\lib\gcc-lib\i386-mingw32\egcs-2.91.57\specs
gcc version egcs-2.91.57 19980901 (egcs-1.1 release)

C:\mingw32\lib\gcc-lib\i386-mingw32\egcs-2.91.57\cpp.exe -lang-c++ -v -ipref
ix
C:\mingw32\lib\gcc-lib\i386-mingw32\egcs-2.91.57\ -undef -D__GNUC__=2 -D__GN
UG__=2 -D__cplusplus -D__GNUC_MINOR__=91 -Di386 -D_WIN32 -DWIN32 -D__WIN32__
 -D__MINGW32__ -DWINNT -D_X86_=1 -D__STDC__=1 -D__stdcall=__attribute__((__s
tdcall__)) -D__cdecl=__attribute__((__cdecl__)) -D__declspec(x)=__attribute_
_((x)) -D__i386__ -D_WIN32 -D__WIN32__ -D__WIN32__ -D__MINGW32__ -D__WINNT__
 -D_X86_=1 -D__STDC__=1 -D__stdcall=__attribute__((__stdcall__)) -D__cdecl=_
_attribute__((__cdecl__)) -D__declspec(x)=__attribute__((x)) -D__i386 -D__WI
N32 -D__WINNT -Asystem(winnt) -Acpu(i386) -Amachine(i386) -D__EXCEPTIONS -re
map -Asystem(unix) -Acpu(i386) -Amachine(i386) -Di386 -D__i386 -D__i386__
main.cc C:\TEMP\ccRgaaaa.ii
GNU CPP version egcs-2.91.57 19980901 (egcs-1.1 release) (80386, BSD syntax)
#include "..." search starts here:
#include <...> search starts here:
 C:\mingw32\lib\gcc-lib\i386-mingw32\egcs-2.91.57\..\..\..\..\include\g++
 C:\mingw32\lib\gcc-lib\i386-mingw32\egcs-2.91.57\..\..\..\..\include

C:\mingw32\lib\gcc-lib\i386-mingw32\egcs-2.91.57\..\..\..\..\i386-mingw32\in
clude
 C:\mingw32\lib\gcc-lib\i386-mingw32\egcs-2.91.57\include
 C:\mingw32\include\g++
 C:\mingw32\include
End of search list.
 C:\mingw32\lib\gcc-lib\i386-mingw32\egcs-2.91.57\cc1plus.exe
C:\TEMP\ccRgaaaa.ii -quiet -dumpbase main.cc -version -o C:\TEMP\ccynaaaa.s
GNU C++ version egcs-2.91.57 19980901 (egcs-1.1 release) (i386-mingw32)
compiled by GNU C version egcs-2.91.57 19980901 (egcs-1.1 release).
In file included from main.cc:1:
XFile.h:81: Internal compiler error 980711.
XFile.h:81: Please submit a full bug report to `egcs-bugs@cygnus.com'.

The text of the main file:

#include "XFile.h"

#include <iostream>

int
main ( )
{
  XFileStream xfs;
}

The text of the header file ("XFile.h") is:

// Emacs, this is -*- C++ -*-

#ifndef XFILE_H
#define XFILE_H

// $Id$

#include <string>
#include <vector>

template<class P,
  class V = typename P::value_type,
  class S = typename P::size_type>
class index_proxy
{
public:
  typedef P parent_type;
  typedef V value_type;
  typedef S size_type;

  // Need to lookup reference-to-member-function syntax and
  // parameterize these calls to be template parameters with default
  // values. --bko FIXME

  index_proxy& operator= (const value_type& v)
    { parent.write_value (index, v); return *this; }

  operator value_type ( ) const
    { return parent.read_value (index); }

private:
  friend parent_type;

  mutable const parent_type& parent;
  size_type index;

  index_proxy (const parent_type& p, size_type i)
    : parent (p), index (i)
    { }
};

class XFileStream
{
public:
  typedef unsigned char value_type;
  typedef unsigned long size_type;
  typedef index_proxy<XFileStream> index_type;

  index_type operator[] (size_type i)
    { return index_type (*this, i); }

  const index_type operator[] (size_type i) const
    { return (*this)[i]; }

  value_type read_value (size_type i) const
    { return data[i]; }

  void write_value (size_type i, const value_type& v)
    { data[i] = v; }

private:
  std::string name;
  std::vector<value_type> data;
};

class XFile
{
public:
  typedef typename XFileStream::value_type value_type;
  typedef typename XFileStream::size_type size_type;
  typedef index_proxy<XFileStream> index_type;

  index_type operator[] (size_type i)
    { return streams[""][i]; }

  const index_type operator[] (size_type i) const
    { return (*this)[i]; }

private:
  std::string name;
  std::map<std::string, XFileStream> streams;
};

#endif

Is there anything else I can do?

Cheers,
--binkley



^ permalink raw reply	[flat|nested] 33+ messages in thread

* Internal compiler error 980711
@ 1998-10-24 22:55 Amaury Cedrick Darsch
  1998-11-26 20:58 ` Alexandre Oliva
  0 siblings, 1 reply; 33+ messages in thread
From: Amaury Cedrick Darsch @ 1998-10-24 22:55 UTC (permalink / raw)
  To: egcs-bugs; +Cc: amaury

Dear egcs team,

Please find below a simple example, which causes an internal compiler error 
when using
namespace within a struct (more precisely with the constructor).

ecgs-version: 1.1 (egcs-2.91.57 debian distribution i586-linux kernel 2.0.35)

to reproduce: g++ -c foo.cpp

example:

namespace A {

  struct foo {
    int x;
    
    // this constructor causes an internal compiler error
    // removing A:: is ok ...
    // using a forward declaration for the struct (inside a class) and later 
using
    // the same code produces the same internal error

    A::foo (void) {
      x= 0;
    }
  };
}


best regards - amaury




^ permalink raw reply	[flat|nested] 33+ messages in thread

* Internal compiler error 980711
@ 1998-10-15  6:56 bjornw
  1998-11-26 20:41 ` Alexandre Oliva
  0 siblings, 1 reply; 33+ messages in thread
From: bjornw @ 1998-10-15  6:56 UTC (permalink / raw)
  To: egcs-bugs

Hi there!

Linux, RedHat-5.1 with 2.0.34 kernel
gcc version egcs-2.92.13 19981005 (gcc2 ss-980609 experimental)

The following buggy code gives an internal compiler error:
(I tried some older versions of egcs, and they gave the same error)

namespace hei {
  class CSomeClass {};
  extern CSomeClass SomeClass;
};

hei::CSomeClass hei::CSomeClass;
//           Notice--^
// Should have been:
// hei::CSomeClass hei::SomeClass;




^ permalink raw reply	[flat|nested] 33+ messages in thread

end of thread, other threads:[~2000-07-27  7:37 UTC | newest]

Thread overview: 33+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-07-27  7:37 Internal compiler error 980711 Andy Henson
  -- strict thread matches above, loose matches on Subject: below --
2000-05-19 14:49 Randolph Bentson
1999-12-31 20:54 Martin Trautmann
1999-12-31 20:54 ` Martin v. Loewis
1999-10-31 23:03 Diego Dainese
1999-10-31 23:03 ` Martin v. Loewis
1999-07-30  6:40 internal " Olaf Seibert
1999-07-23  7:44 Internal " Anders S. Johansen
1999-07-25  1:21 ` Martin v. Loewis
     [not found] <377F4A8E.11B48DE4@glue.ch>
1999-07-04 13:54 ` Martin v. Loewis
1999-07-31 23:33   ` Mumit Khan
1999-07-05 11:08     ` Thomas Maeder
1999-06-25  1:46 Francesco Giacomini
1999-05-31 21:06 Cathy James
1999-05-31 21:06 ` Martin v. Loewis
1999-05-31 21:06 Helmut Swaczinna
1999-05-31 21:06 ` Martin v. Loewis
1999-05-31 21:06 internal " Dominic Williams
1999-05-08  5:57 ` Martin v. Loewis
1999-04-30 23:15 Internal " Daniel Engovatov
1999-03-31 23:54 Braden N. McDaniel
1999-03-31 23:54 Anders Joelsson
1999-03-31 23:54 ` Martin v. Loewis
1999-03-29  8:18 KELEMEN Peter
1999-04-28 10:53 ` Nathan Sidwell
1998-11-17  8:15 Jan Braun
1998-11-26 20:58 ` Alexandre Oliva
1998-11-04 12:11 B. K. Oxley (binkley)@Home
1998-11-26 20:58 ` Alexandre Oliva
1998-10-24 22:55 Amaury Cedrick Darsch
1998-11-26 20:58 ` Alexandre Oliva
1998-10-15  6:56 bjornw
1998-11-26 20:41 ` Alexandre Oliva

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