No Subject

No Subject

[Alexander Favorov]

Hi!
I found a very special effect in EGCS 1.0.2. for CYGWIN b19 on NT4.0.

Such a code:
/*************************************/
#include <stdio.h>
#include <stdlib.h>
main()
{
	char buf;
    buf='\13';
    printf ("Char value is %3i",(int)buf);	
    return 0;
}
/*************************************/

gives :
Char value is  11

All conversions with '\nnn' works in such a strange way.
Another unconvinient thing is that gets() leaves \13 before
end zero. Of course, we can treat only \10 as end-of-line,
but it makes some problems when reading Win/Dos texts...

                With best regards, 
                                Alexander.

Re:

[Dave Brolley]

Alexander Favorov wrote:

> Hi!
> I found a very special effect in EGCS 1.0.2. for CYGWIN b19 on NT4.0.
>
> Such a code:
> /*************************************/
> #include <stdio.h>
> #include <stdlib.h>
> main()
> {
>         char buf;
>     buf='\13';
>     printf ("Char value is %3i",(int)buf);
>     return 0;
> }
> /*************************************/
>
> gives :
> Char value is  11

This is correct. \13 is octal.

Dave

Re:

[ИнфоПространство]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; format=flowed; charset="windows-1251"; reply-type=original, Size: 2488 bytes --]

  =- ÊÎÐÏÎÐÀÒÈÂÍÛÅ ÌÅÐÎÏÐÈßÒÈß -=
  =- ÍÀ ÎÑÒÎÆÅÍÊÅ ÍÀ 2000 êâ.ì -=

 • êîíôåðåíöèè, ñåìèíàðû, ñîáðàíèÿ
 • âûñòàâêè, ïðåçåíòàöèè, ïðàçäíèêè
 • áàíêåòû, ôóðøåòû

 1. Ôóíêöèîíàëüíàÿ ïðèíàäëåæíîñòü: Öåíòð ïðåäíàçíà÷åí äëÿ ïðîâåäåíèÿ âûñòàâîê, êîíôåðåíöèé, ñåìèíàðîâ, ïðåçåíòàöèé, ïîêàçîâ è ïðàçäíè÷íûõ ìåðîïðèÿòèé.

 2. Ìåñòîíàõîæäåíèå: Èñòîðè÷åñêèé öåíòð, 300 ìåòðîâ îò Õðàìà Õðèñòà Ñïàñèòåëÿ, ì.Êðîïîòêèíñêàÿ, ìèêð-í Îñòîæåíêà, 50 ìåòðîâ îò Ïðå÷èñòåíñêîé íàá.

 3. Òåõíè÷åñêèå õàðàêòåðèñòèêè: Îáùàÿ ïëîùàäü öåíòðà 2000 êâ.ì, óíèâåðñàëüíûé çàë-òðàíñôîðìåð ñ äèàïàçîíîì ïëîùàäåé îò 20 äî 1500 êâ.ì, 2 VIP-çàëà, Êàôå-ïèööåðèÿ-êîíäèòåðñêàÿ.

 4. Îñîáåííîñòè:
 - Ñïåöèàëüíûå âûñòàâî÷íûå ñòåíäû äî ïîòîëêà ñ ðàçëè÷íîé öâåòîâîé è ôóíêöèîíàëüíîé ãàììîé.
 - Âîçìîæíîñòü ýêñïîíèðîâàíèÿ àâòîìîáèëåé.
 - Âñòðîåííîå â ïîòîëîê âûñòàâî÷íîå îñâåùåíèå.
 - Øèðîêèé âûáîð ìåáåëè.
 - 2 ñöåíû
 - 2 âõîäà: öåíòðàëüíûé è òåõíè÷åñêèé.
 - Âûñîêîêà÷åñòâåííîå êîâðîâîå ïîêðûòèå
 - Ïðîôåññèîíàëüíîå çâóêîóñèëèòåëüíîå îáîðóäîâàíèå.

 Êîíôåðåíö-ïàêåò îò 36 ó.å. Âíóòð. êóðñ êîìïàíèè: 1 ó.å.=30 ðóá.

 Äèðåêòîð ïî ðàçâèòèþ áèçíåñà è îðãàíèçàöèè êîðïîðàòèâíûõ ìåðîïðèÿòèé:
 Ñàâðàñîâà Íàòàëüÿ  òåë.: 290~0621, 290-7-241, 290~00~66; ô.: 290~0~649
-------------------------------------------
                 Ìåæäóíàðîäíûé 
                 èíôîðìàöèîííî-
                 âûñòàâî÷íûé öåíòð 

                 =- ÈíôîÏðîñòðàíñòâî -=

                 1-é Çà÷àòüåâñêèé ïåð.,4
                 òåë. (095) 290~7241
                 ôàêñ (095) 202~9~245
\0

Re:

[Инна Давидовна]

Âíèìaíèe àêöèÿ!
3akaæèòe äo 2O äåêàáðÿ Å-ìàil paccûëêy è noëy÷è áîíóñ(paccûëêó ïî àñå)....
 
appeasable@3432.cjb.net 





\0

Re:

[Белла Геннадиевна]

Âíèìàíèå!
Òîëüêî äî 1 äåêàáðÿ 2OO4 ãîäà âû ñìîæåòå çàêàçàòü Å-Mail paccûëêó(ïëàòíî) è ïîëó÷èòü paccûëêó ïî icq(áåñïëàòíî)....
 
alveolar@e881.cjb.net 





\0

Re:

[Mark Mitchell]

> My question is: should *your* computer's absolute pathname
> be in the generated parse.c file that is in the tarball?

That's funny; I never noticed that before.  It's harmless that's it's
there; some path has got to be there, and it might as well be mine... :-)

> Kelley Cook
>
> BTW, as an outsider, let me say that you are doing a
> wonderful job as a release manager.

Thanks for your support!

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

RE:

[Meenan Vishnu]

Hi Loren,

Sorry about the wrong address.  I found the address at gnu site.  Anyway, I
first tried without the
-D_GLIBCPP_USE_LONG_LONG option and it spits out tons of error messages.
Basically, the library does not like long long
variables.  (Even though I have no right), I tried defining the
_GLIBCPP_USE_LONG_LONG macro and it
compiles but the printed result is wrong. (0 instead of 5).

If this is not a bug, what should I do to enable me to use long long
variables in g++.  The earlier version of
g++ let me use long long without a problem.  It is only the version 3.0 and
3.01 (on Solaries) that is preventing me.
BTW, I installed gcc 3.0 and 3.01 on the Linux machines and it works.  Do I
have to do something different on the Solaris machines?

Thank You,
Meenan

-----Original Message-----
From: Loren James Rittle [ mailto:rittle@latour.rsch.comm.mot.com ]
Sent: Tuesday, October 23, 2001 7:14 PM
To: gcc-bugs@gcc.gnu.org
Cc: meenan.vishnu@calix.com
Subject: 


In article <8119A4CE9D90D311912A00508B552B2A084DCFC3@cnexch>:

> I installed gcc 3.01 on Solaries 2.7 but it does not compiler the
following
> simple program [which does not conform to any standard -ljr]:  [...]

> I tried compiling as

> g++ -c -D_GLIBCPP_USE_LONG_LONG -static junk.cc
[...]

Your bug report was filed to the wrong place.

Why do you think you have the right to define a macro in implementor
space on the command line?

Not a bug...

Regards,
Loren

No Subject

[Paul Janssen]

Hi,
	just build a new compiler this was one of the two problems I found.
 It dissapears when compiling with the -O option.
However, if I do so other problems occur in other source files.
The whole project compiled fine under : gcc version egcs-2.91.10 980221 
(gcc-2.8.0 release) without -O option.

I extracted the piece of problem code from my soource file ( see below).

/***********************************************************************  
*******/
/*
FILE: test.c

COMPILING FROM:
Windows NT - Cygwin32 B20.1

COMPILING WITH:
Binutils-2.9.1 with patch binutils-2.9.1-coldfire-990206.diff, 
target=m68k-coff
EGCS-1.1.2, target=m68k-coff
newlib-1.8.0

COMMAND-LINE:
bash-2.02$ gcc68 -v -c -ansi -Wall -m5200 -mnobitfield test.c -o test.o
Reading specs from 
\\e\ProgramFiles\cygnus\cygwin-b20\gcc-m68k\lib\gcc-lib\m68k-coff\egcs-2  
.91.66\specs
gcc version egcs-2.91.66 19990314 (egcs-1.1.2 release)
 
\\e\ProgramFiles\cygnus\cygwin-b20\gcc-m68k\lib\gcc-lib\m68k-coff\egcs-2  
.91.66\cpp.exe -lang-c89 -v -undef -D__GNUC__=2 -D__GNUC_MINOR__=91 
-trigraphs -D__STRICT_ANSI__ -D__mc68000__ -D__embedded__ -D__mc68000 
-Asystem(embedded) -Amachine(mc68000) -Wall -D__mcf5200__ -D__mcf5200 
test.c D:\TEMP\ccDf9IOi.i
GNU CPP version egcs-2.91.66 19990314 (egcs-1.1.2 release) (68k, Motorola 
syntax)
#include "..." search starts here:
#include <...> search starts here:
 
\\e\ProgramFiles\cygnus\cygwin-b20\gcc-m68k\lib\gcc-lib\m68k-coff\egcs-2  
.91.66\include
 \\e\ProgramFiles\cygnus\cygwin-b20\gcc-m68k\m68k-coff\include
End of search list.
 
\\e\ProgramFiles\cygnus\cygwin-b20\gcc-m68k\lib\gcc-lib\m68k-coff\egcs-2  
.91.66\cc1.exe D:\TEMP\ccDf9IOi.i -quiet -dumpbase test.c -m5200 
-mnobitfield -ansi -Wall -ansi -version -o D:\TEMP\ccsuLKvQ.s
GNU C version egcs-2.91.66 19990314 (egcs-1.1.2 release) (m68k-coff) 
compiled by
 GNU C version egcs-2.91.57 19980901 (egcs-1.1 release).
expr.c:2568: Internal compiler error in function emit_move_insn_1
bash-2.02$

*/

typedef struct {
  int	cs [8];
} CS5206;

void
Init_CPU (void)
{
  register int	i;

#if 1
  /* this goes wrong :
	expr.c:2568: Internal compiler error in function emit_move_insn_1
  */
  for (i = 3; i < 8; i++) {
    ((CS5206 *) (0x04000064) ) ->cs [i] = 0 ;
  }
#else
  /* this compiles fine */
    ((CS5206 *) (0x04000000 +0x064) ) ->cs [3] = 0 ;
    ((CS5206 *) (0x04000000 +0x064) ) ->cs [4] = 0 ;
    ((CS5206 *) (0x04000000 +0x064) ) ->cs [5] = 0 ;
    ((CS5206 *) (0x04000000 +0x064) ) ->cs [6] = 0 ;
    ((CS5206 *) (0x04000000 +0x064) ) ->cs [7] = 0 ;
#endif
}
/***********************************************************************  
******/

============================================
Paul Janssen
Software Engineer

SPaSE bv.			http://www.spase.com
Kerkenbos 1021		tel.: +31 24 378 2882
6546 BB Nijmegen		fax.: +31 24 378 8388
The Netherlands		mailto:paulja@spase.nl
============================================

Re:

[Jeffrey A Law]

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

  In message < 01BE7C56.B69F56C0.paulja@spase.nl >you write:
  > Hi,
  > 	just build a new compiler this was one of the two problems I found.
  >  It dissapears when compiling with the -O option.
  > However, if I do so other problems occur in other source files.
  > The whole project compiled fine under : gcc version egcs-2.91.10 980221 
  > (gcc-2.8.0 release) without -O option.
  > 
  > I extracted the piece of problem code from my soource file ( see below).
[ ... ]
Thanks.  This bug has been fixed in the development sources.

jeff
>From law@upchuck.cygnus.com Fri Apr 09 01:21:00 1999
From: Jeffrey A Law <law@upchuck.cygnus.com>
To: Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at>
Cc: egcs-bugs@egcs.cygnus.com
Subject: Re: Bootstrap failure on sparc-sun-solaris2.6 
Date: Fri, 09 Apr 1999 01:21:00 -0000
Message-id: <19987.923645397@upchuck>
References: <Pine.GSO.4.10.9904071240230.20108-100000@markab.dbai.tuwien.ac.at>
X-SW-Source: 1999-04/msg00224.html
Content-length: 1275

  In message < Pine.GSO.4.10.9904071240230.20108-100000@markab.dbai.tuwien.ac.at
>you write:
  > With current CVS (see the Date: Header) I get this for a vanilla (srctree
  > != buildtree) build on sparc-sun-solaris2.6.
  > 
  > stage1/xgcc -Bstage1/ -B/sw/test/egcs/SunOS/sparc-sun-solaris2.6/bin/  -DIN
  > _GCC -DHAIFA  -DSVR4  -W -Wall -O2 -O  -DHAVE_CONFIG_H    -I. -I/sw/test/eg
  > cs/egcs/gcc -I/sw/test/egcs/egcs/gcc/config -I/sw/test/egcs/egcs/gcc/../inc
  > lude -c insn-recog.c
  > /sw/test/egcs/egcs/gcc/jump.c:3632: Internal compiler error in function mar
  > k_jump_label
  > Please submit a full bug report to `egcs-bugs@egcs.cygnus.com'.
  > See <URL: http://egcs.cygnus.com/faq.html#bugreport > for details.
  > gmake[2]: *** [insn-recog.o] Error 1
  > gmake[2]: Leaving directory `/files/pfeifer/OBJ-0704-12:02/gcc'
  > gmake[1]: *** [bootstrap] Error 2
  > gmake[1]: Leaving directory `/files/pfeifer/OBJ-0704-12:02/gcc'
  > gmake: *** [bootstrap] Error 2
  > 
  > (After my first abort I did another egcs_update and another bootstrap, so
  > this is not a temporary problem. 19 hours ago I successfully bootstrapped
  > with exactly the same configuration.)
It's a bug in the block merging code.  I'll be installing a fix in a few
minutes.

Thanks,
jeff
>From law@upchuck.cygnus.com Fri Apr 09 01:34:00 1999
From: Jeffrey A Law <law@upchuck.cygnus.com>
To: Paul Lai <plai@Lynx.COM>
Cc: egcs-bugs@egcs.cygnus.com
Subject: Re: internal compiler error (egcs-1.1.1 & egcs-1.1.2), cc1 
Date: Fri, 09 Apr 1999 01:34:00 -0000
Message-id: <20063.923646167@upchuck>
References: <37012884.44F7C9A1@lynx.com>
X-SW-Source: 1999-04/msg00225.html
Content-length: 895

  In message <37012884.44F7C9A1@lynx.com>you write:
  > This is a multi-part message in MIME format.
  > --------------F2A0B864A02D11D7BF9978F9
  > Content-Type: text/plain; charset=us-ascii
  > Content-Transfer-Encoding: 7bit
  > 
  > The attached simple testcase causes an internal compiler error.
  > egcs-1.1.1 & egcs-1.1.2 are both being tested under i386-pc-linux
  > (redhat 5.1).
  > FSF 2.8.1 does not emit an error with this testcase.
  > 
  > The problem appears to be in
  >     egcs-1.1.2/gcc/expr.c:expand_expr()     lines       6189 -- 6216
  >     These lines do not appear in FSF 281 and when removed, seem to make
  > the compiler happier.
  >     But, what is lost if these lines are removed (besides the compiler
  > internal error)?
Thanks, this bug has been fixed in the mainline sources.

You merely lose optimziations by removing those lines in your local sources.

jeff
>From valette@crf.canon.fr Fri Apr 09 01:34:00 1999
From: "VALETTE Eric" <valette@crf.canon.fr>
To: martin@mira.isdn.cs.tu-berlin.de
Cc: egcs-bugs@egcs.cygnus.com
Subject: Re: egcc 1.1.2 outputs global object constructors as local (C static) symbols
Date: Fri, 09 Apr 1999 01:34:00 -0000
Message-id: <m10VWnH-0000WqC@tri-yann.crf.canon.fr>
References: <m10VFvj-0000WqC@tri-yann.crf.canon.fr> <199904082102.XAA01764@mira.isdn.cs.tu-berlin.de> <m10VVcy-0000WqC@tri-yann.crf.canon.fr> <199904090750.JAA00605@mira.isdn.cs.tu-berlin.de> <199904090750.JAA00605@mira.isdn.cs.tu-berlin.de>
X-SW-Source: 1999-04/msg00226.html
Content-length: 2543

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

>> I want to understand. I can fix it myself anyway but would like to
>> understand what the problem was ...

Martin> After 1.1.1, we also got reports about duplicate symbols in case a),
Martin> and that was more severe. That was supposed to be fail-safe, because
Martin> of the one-definition-rule. It turns out that people often break this
Martin> rule with dynamically-loaded shared libraries. They have the same
Martin> global symbol in different shared libraries. As long as they don't
Martin> reference that symbol, everything is OK.

For me this is a bug in the dynamic library design (name space polution that
should be solved using namespace...) and I do not see why it should propagate 
to gcc generation code. 

Anyway, they then have duplicate symbols that are hardly usable when both 
symbols are referenced (I may miss something because I know very little 
about dynamic linker technic). 


>> Side remarks : when you are building embbedded system written in C++,
>> trust me, that you do not want to let the linker make things behing 
>> your back and that the "system" crt0 has nothing to do with application
>> crt0...
>> 
>> So, I hope you realize that you may not have the FULL picture of C++
>> use in mind despite the tone of your mail

Martin> I was expecting something like that (embedded systems). I think I
Martin> would have been more verbose initially when you had indicated why you
Martin> were following that approach, and not only what the approach was.

Martin> I still think it is the wrong approach. i586-pc-linux-gnu (or whatever
Martin> Linux target you appear to use) is what C++ calls a 'hosted'
Martin> environment, whereas you seem to be targetting a 'freestanding'
Martin> environment. gcc is well-suited for freestanding environments, you
Martin> just have to define what its properties are. 

However, we would like to use the *same* compiler for compiling the
system and applications. Think about having a compiler for linux kernel 
and another for applications... Is there a way to gracefully control 
"global initializer" instanciation?

Martin> gcc is also very good at cross-compilation. However, creating objects
Martin> for one target and then using it on another is not guaranteed to work.

Thanks for this concrete/informative answer. Side question more related to
binutils. Is there a way to parse a fully resolved binary (not located) 
and change the symbol type from local to global?

Have a nice day,

-- eric
>From law@upchuck.cygnus.com Fri Apr 09 01:36:00 1999
From: Jeffrey A Law <law@upchuck.cygnus.com>
To: "Aki Niimura" <akineko@worldnet.att.net>
Cc: egcs-bugs@egcs.cygnus.com
Subject: Re: egcs 1.1.2 (egcs-2.91.66) Assembler error(?) 
Date: Fri, 09 Apr 1999 01:36:00 -0000
Message-id: <20080.923646310@upchuck>
References: <01be81f1$d8f52b00$c0a80101@Evelyn>
X-SW-Source: 1999-04/msg00227.html
Content-length: 946

  In message < 01be81f1$d8f52b00$c0a80101@Evelyn >you write:
  > g++ bug report:
  > 
  > Reporter : Aki Niimura  neko@my-dejanews.com
  > Date : 04/08/99
  > 
  > g++ version : egcs 1.1.2 (egcs-2.91.66)
  > Environment :
  > %uname -a
  > SunOS Evelyn 5.7 Generic sun4m sparc SUNW,SPARCstation-4  (Solaris Sparc)
  > 
  > %uname -a
  > SunOS kifer 5.7 Generic i86pc i386 i86pc  (Solaris x86)
  > 
  > Bug(?) description :
  > I'm getting assembler syntax errors when I complied under Solaris x86 the
  > program which is complied w/o errors under Solaris Sparc.
  > I know '$' character is causing this. However, I'm wondering why it
  > works with Sparc but doesn't work with Solaris x86.
  > Because gcc uses an unified assembler.
  > Is there any workaround to make this work?
  > Any suggestions, comments are highly appreciated. (Yes! I need a
  > workaround.)
  > 
Best workaround I can suggest would be to use the gnu assembler.

jeff
>From martin@mira.isdn.cs.tu-berlin.de Fri Apr 09 01:43:00 1999
From: "Martin v. Loewis" <martin@mira.isdn.cs.tu-berlin.de>
To: rittle@rsch.comm.mot.com
Cc: egcs-bugs@egcs.cygnus.com
Subject: Re: Nested object construction parse errors
Date: Fri, 09 Apr 1999 01:43:00 -0000
Message-id: <199904090830.KAA00689@mira.isdn.cs.tu-berlin.de>
References: <199904090213.VAA01915@supra.rsch.comm.mot.com> <199904090213.VAA01915@supra.rsch.comm.mot.com>
X-SW-Source: 1999-04/msg00228.html
Content-length: 449

>   outer a (inner (g (1), 2), 3); // line 22

Thanks for your report. I believe this is a known problem; at least
variants of it are: g++ thinks that 

    outer a (inner (g

is the beginning of a declaration of a function a, returning an outer,
and expecting an inner (named g). Then the numbers don't fit into the
picture - parse error. One work-around is to write this as

   outer a ((inner (g (1), 2)), 3); // line 22

Hope this helps,
Martin
>From valette@crf.canon.fr Fri Apr 09 01:52:00 1999
From: "VALETTE Eric" <valette@crf.canon.fr>
To: martin@mira.isdn.cs.tu-berlin.de
Cc: egcs-bugs@egcs.cygnus.com
Subject: Re: egcc 1.1.2 outputs global object constructors as local (C static) symbols
Date: Fri, 09 Apr 1999 01:52:00 -0000
Message-id: <m10VX4b-0000WqC@tri-yann.crf.canon.fr>
References: <m10VFvj-0000WqC@tri-yann.crf.canon.fr> <199904082102.XAA01764@mira.isdn.cs.tu-berlin.de> <m10VVcy-0000WqC@tri-yann.crf.canon.fr> <199904090750.JAA00605@mira.isdn.cs.tu-berlin.de> <199904090750.JAA00605@mira.isdn.cs.tu-berlin.de>
X-SW-Source: 1999-04/msg00229.html
Content-length: 1315

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


Martin> I still think it is the wrong approach. i586-pc-linux-gnu (or whatever
Martin> Linux target you appear to use) is what C++ calls a 'hosted'
Martin> environment, whereas you seem to be targetting a 'freestanding'
Martin> environment. gcc is well-suited for freestanding environments, you
Martin> just have to define what its properties are. 

eric>However, we would like to use the *same* compiler for compiling the
eric>system and applications. Think about having a compiler for linux kernel 
eric>and another for applications... Is there a way to gracefully control 
eric>"global initializer" instanciation?

Thinking a little bit more about the problem I have nothing against
GNU ld doing the work provided I have access to the ctors/dtors table
and the name of the global objects in addition to their address.

This would really solves the problem without requiring gcc modification

exported_symbol_ctor_table ctor_table {
   {function_pointer, original_symbol_name},
   ...
   {0, 0}
};

NB : the original_symbol_name may be REQUIRED to use proprietary
     constructor ordering technic based on symbol name and would
     remove the need of some GNU C++ extension like pragma for
     ordering constructors...
	


-- eric
>From law@upchuck.cygnus.com Fri Apr 09 02:01:00 1999
From: Jeffrey A Law <law@upchuck.cygnus.com>
To: Arvind Sankar <arvinds@mit.edu>
Cc: egcs-bugs@egcs.cygnus.com
Subject: Re: ICE with -O2 -march=pentiumpro 
Date: Fri, 09 Apr 1999 02:01:00 -0000
Message-id: <20218.923647817@upchuck>
References: <19990331125717.A24428@anjala.mit.edu>
X-SW-Source: 1999-04/msg00230.html
Content-length: 1720

  In message <19990331125717.A24428@anjala.mit.edu>you write:
  > 
  > --LQksG6bCIzRHxTLp
  > Content-Type: text/plain; charset=us-ascii
  > 
  > The attached source (culled from a gimp plugin) produces an ICE with
  > -O2 -march=pentiumpro
  > -On for n <= 1 is ok, as is -march=pentium.
  > 
  > btw, if I specify -march=<bad> where bad is not a valid arch, the ICE still
  > happens after cc1 tells me that bad is not a valid value, while not specify
  > ing
  > any arch (the default is pentium) works. Seems to be a bug somewhere in opt
  > ion
  > processing as well...
  > 
  > System is egcs-19990328, i686-pc-linux-gnu, glibc 2.1
  > Compiler output:
  > 1.i: In function `p_frames_to_multilayer':
  > 1.i:36: Could not split insn
  > (insn 104 19 32 (set (reg/v:SI 1 %edx)
  >         (if_then_else:SI (ge:SI (reg/v:SI 0 %eax)
  >                 (mem/s:SI (plus:SI (reg:SI 2 %ecx)
  >                         (const_int 4)) 2))
  >             (reg/v:SI 1 %edx)
  >             (mem/s:SI (plus:SI (mem/f:SI (plus:SI (reg:SI 6 %ebp)
  >                             (const_int 8)) 0)
  >                     (const_int 4)) 2))) 367 {movsicc+2} (insn_list 124 (nil
  > ))
  >     (expr_list:REG_DEAD (reg/v:SI 0 %eax)
  >         (expr_list:REG_DEAD (reg:SI 2 %ecx)
  >             (nil))))
  > ../../gcc/toplev.c:1453: Internal compiler error in function fatal_insn
  > Please submit a full bug report to `egcs-bugs@egcs.cygnus.com'.
  > See <URL: http://egcs.cygnus.com/faq.html#bugreport > for details.
This is majorly weird.  (mem (plus (mem (plus (const_int))))) is not a valid
operand.  It shouldn't have survived long enough to cause a "Could not split
insn" error.  Smells like a reload problem.  

jeff
>From law@upchuck.cygnus.com Fri Apr 09 02:05:00 1999
From: Jeffrey A Law <law@upchuck.cygnus.com>
To: Brad Lucier <lucier@math.purdue.edu>
Cc: egcs-bugs@egcs.cygnus.com
Subject: Re: 19990328 snapshot has problem loading FP constant on sparc 
Date: Fri, 09 Apr 1999 02:05:00 -0000
Message-id: <20246.923648040@upchuck>
References: <199903301819.NAA25681@polya.math.purdue.edu>
X-SW-Source: 1999-04/msg00231.html
Content-length: 380

  In message <199903301819.NAA25681@polya.math.purdue.edu>you write:
  > I read "How to submit a bug report" in the FAQ, and will try to include
  > the information requested there.
[ ... ]
Is this derived from gtk?  I've got a similar looking bug report for gtk
that is quite a bit larger.  Obviously I'd prefer to debug the smaller
testcase and ignore the big one :-) :-)

jeff
>From fjh@cs.mu.OZ.AU Fri Apr 09 02:16:00 1999
From: Fergus Henderson <fjh@cs.mu.OZ.AU>
To: egcs-bugs@egcs.cygnus.com, egcs-patches@egcs.cygnus.com
Cc: Hans-Peter Nilsson <hp@bitrange.com>, Richard Henderson <rth@cygnus.com>
Subject: Re: egcs-1.1b alpha-dec-osf3.2 internal error in change_address()
Date: Fri, 09 Apr 1999 02:16:00 -0000
Message-id: <19990409191625.A11390@murlibobo.cs.mu.OZ.AU>
References: <Pine.BSF.4.02A.9904082110430.19565-100000@dair.pair.com> <19990408184845.C3289@cygnus.com> <19990408184845.C3289@cygnus.com>
X-SW-Source: 1999-04/msg00232.html
Content-length: 5796

On 08-Apr-1999, Richard Henderson <rth@cygnus.com> wrote:
> In general, yes.  However, I would consider it a serious regression
> if for Alpha any function that didn't use alloca ever did not have
> its frame pointer eliminated.  Even at -O0.
...
> So your whole debugging session starts way too late.  You
> would have needed to find out why fp_is_frame_pointer is
> true at all.

At the end of this email is a description of what happens for
egcs-1.1.2, running on the test case `void foo() {}', with no options.
In short, it seems that the frame pointer is not eliminated if
-fomit-frame-pointer is not specified.  The gcc documentation says that
-fomit-frame-pointer is only set at -O, and it seems to me that it
would be surprising if the frame pointer were omitted even if
-fomit-frame-pointer was not enabled, so the observed behaviour seems
to me to be consistent with the documentation.  (Is there any reason
why the frame pointer should be omitted even if -fomit-frame-pointer is
not specified?  If so, I don't see it.)

So, I agree that you should be allowed to use $15 as a global register
variable; but I think that in order to make that work, you should compile
with `-fomit-frame-pointer' (or equivalently with `-O' or `-O2' or higher).

The test case in my original bug report was broken code,
because it used $15 but did not specify `-fomit-frame-pointer'.
The gcc bug is just that gcc should not abort with an internal
compiler error; ideally it should instead report a better error
message.  (In fact even generating incorrect code would in some
respects be better than reporting a spurious ICE; it may take
some time for the user to find the problem, but at least when
they find it they will know that it is their fault and not gcc's.)

In addition, there is also a problem with fix_register()
in regclass.c being overly conservative; it should not disallow
the use of the frame pointer if -fomit-frame-pointer is enabled.

Does everyone agree with this diagnosis?

I have included a completely untested (I haven't even compiled it)
patch to regclass.c to address the second problem.

Index: regclass.c
===================================================================
RCS file: /cvs/egcs/egcs/gcc/regclass.c,v
retrieving revision 1.54
diff -u -r1.54 regclass.c
--- regclass.c	1999/02/25 23:45:28	1.54
+++ regclass.c	1999/04/09 09:11:08
@@ -579,9 +579,9 @@
     {
       if ((i == STACK_POINTER_REGNUM
 #ifdef HARD_FRAME_POINTER_REGNUM
-	   || i == HARD_FRAME_POINTER_REGNUM
+	   || (i == HARD_FRAME_POINTER_REGNUM && !flag_omit_frame_pointer)
 #else
-	   || i == FRAME_POINTER_REGNUM
+	   || (i == FRAME_POINTER_REGNUM && !flag_omit_frame_pointer)
 #endif
 	   )
 	  && (fixed == 0 || call_used == 0))
@@ -590,8 +590,10 @@
 	    { "call-saved", "call-used" },
 	    { "no-such-option", "fixed" }};
 	  
-	  error ("can't use '%s' as a %s register", name, 
-		 what_option[fixed][call_used]);
+	  error ("can't use '%s' as a %s register%s", name, 
+		 what_option[fixed][call_used],
+		 (i == STACK_POINTER_REGNUM ? ""
+		  : " without '-fomit-frame-pointer'"));
 	}
       else
 	{

----------
Below is a description of what happens for egcs-1.1.2, running on the
test case `void foo() {}', with no options.

frame_pointer_needed is set to 1 at reload1.c:715 in reload():

 |   /* Does this function require a frame pointer?  */
 | 
 |   frame_pointer_needed = (! flag_omit_frame_pointer
 | #ifdef EXIT_IGNORE_STACK
 |                           /* ?? If EXIT_IGNORE_STACK is set, we will not save
 |                              and restore sp for alloca.  So we can't eliminate
 |                              the frame pointer in that case.  At some point,
 |                              we should improve this by emitting the
 |                              sp-adjusting insns for this case.  */
 |                           || (current_function_calls_alloca
 |                               && EXIT_IGNORE_STACK)
 | #endif
 |                           || FRAME_POINTER_REQUIRED);

Here `flag_omit_frame_pointer' is 0, so the remaining tests are irrelevant.

Then, just below, at reload1.c:734, the `can_eliminate' flag
for the elimination from the frame pointer to the stack pointer
is set to 0, because frame_pointer_needed is 1.

 |       ep->can_eliminate = ep->can_eliminate_previous
 |         = (CAN_ELIMINATE (ep->from, ep->to)
 |            && ! (ep->to == STACK_POINTER_REGNUM && frame_pointer_needed));

It stays 0.

Then, at reload1.c:1626, still in reload(), the code recomputes
frame_pointer_needed based on the can_eliminate flags.

 |       /* See if any registers that we thought we could eliminate the previous
 |          time are no longer eliminable.  If so, something has changed and we
 |          must spill the register.  Also, recompute the number of eliminable
 |          registers and see if the frame pointer is needed; it is if there is
 |          no elimination of the frame pointer that we can perform.  */
 | 
 |       frame_pointer_needed = 1;
 |       for (ep = reg_eliminate; ep < &reg_eliminate[NUM_ELIMINABLE_REGS]; ep++)
 |         {
 |           if (ep->can_eliminate && ep->from == FRAME_POINTER_REGNUM
 |               && ep->to != HARD_FRAME_POINTER_REGNUM)
 |             frame_pointer_needed = 0;

But the can_eliminate flags that we need were set to 0 as explained above.
So frame_pointer_needed gets set to 1 again and stays that way.
Indeed it stays that way for the duration, so when we get to
alpha_expand_epilogue() it is 1, and so we generate an epilogue
that uses the frame pointer.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: < http://www.cs.mu.oz.au/~fjh >  |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3        |     -- the last words of T. S. Garp.
>From dardaill@ilog.fr Fri Apr 09 02:39:00 1999
From: Pascale Dardailler <dardaill@ilog.fr>
To: egcs-bugs@egcs.cygnus.com, dardaill@ilog.fr
Subject: problem with setlocale.
Date: Fri, 09 Apr 1999 02:39:00 -0000
Message-id: <370DCA5C.1E30EF75@ilog.fr>
X-SW-Source: 1999-04/msg00233.html
Content-length: 937

I have a pretty stupid question, but I cannot find any answer on the
web, so perhaps you could enlight me.
I've been trying to understand why the setlocale does not work as
expected:


#include <locale.h>
#include <stdio.h>
#include <langinfo.h>
#include <stdlib.h>

int main()
{
        setlocale(LC_ALL, "");

        printf("locale %s\n", setlocale(LC_ALL, NULL));

        printf("encoding %s\n", nl_langinfo(_NL_CTYPE_CODESET_NAME));

        printf("mb cur max size %d\n",
nl_langinfo(_NL_CTYPE_MB_CUR_MAX));

        printf("max char size %d\n", MB_CUR_MAX);

        return 0;
}


Then setting LC_ALL or LANG to fr_FR, I get:

locale fr_FR
encoding ISO-8859-1
mb cur max size 2
max char size 2

Why is this 2 instead of 1?



Here are the details related to my installation:

The egcs version : egcs-2.91.60
The system type : DELL Precision 410 / Windows NT 4.0 SP4 / Pentium II
400
MHz bi-processor / 256MB RAM


    Pascale.

RE:

[Gregory, Allan]

Ok, I have found the problem!!
	I am doing the make as a 'normal' user. The user has '.' in the
path.
	I think that it was using the cccp in objdir/gcc when compiling
files.

	I have removed '.' from my path, things now get a lot further.

	Thanks for the help :)

> -----Original Message-----
> From:	Zack Weinberg [SMTP:zack@rabi.columbia.edu]
> Sent:	Monday, January 25, 1999 19:16
> To:	Gregory, Allan
> Cc:	egcs-bugs@cygnus.com
> Subject:	Re: 
> 
> On Mon, 25 Jan 1999 17:24:01 -0000, "Gregory, Allan" wrote:
> >Ok, got GNU make 3.77, doing make -v gives its version as 3.77
> >
> >	doing make bootstrap still fails the compile gencodes.c with
> >__builtin_va_alist as undefined.
> >
> >Again I have removed cccp.o objdir/gcc, when I do a make bootstarp now,
> it
> >fails to compile cccp.c with the same error (about __builtin_va_list).
> >
> >What puzzles me about this, is that it compiles cccp.c the first time
> that I
> >ran make bootstrap, but it can not compile it after the first time!
> 
> Ok.  __builtin_va_list is defined in gcc/ginclude/stdarg.h, and that
> directory should be put in the include search path automatically.
> What is the command printed by Make that fails?  (either one)
> 
> zw
> 
> p.s. please keep <egcs-bugs@cygnus.com> in the cc: list.

Re:

[Zack Weinberg]

On Mon, 25 Jan 1999 17:24:01 -0000, "Gregory, Allan" wrote:
>Ok, got GNU make 3.77, doing make -v gives its version as 3.77
>
>	doing make bootstrap still fails the compile gencodes.c with
>__builtin_va_alist as undefined.
>
>Again I have removed cccp.o objdir/gcc, when I do a make bootstarp now, it
>fails to compile cccp.c with the same error (about __builtin_va_list).
>
>What puzzles me about this, is that it compiles cccp.c the first time that I
>ran make bootstrap, but it can not compile it after the first time!

Ok.  __builtin_va_list is defined in gcc/ginclude/stdarg.h, and that
directory should be put in the include search path automatically.
What is the command printed by Make that fails?  (either one)

zw

p.s. please keep <egcs-bugs@cygnus.com> in the cc: list.

Re:

[Ross Smith]

From: Patrick Barron <barron@adulis.fr>
>
>in file f.h :
>template <class T>
>T& foo( T* )
>{
>static T my_data;
>return my_data;
>};
>
>in file file1-a.cpp :
>#include "f.h"
>int& i1 = foo( (int*) 0);
>
>in file file2-a.cpp :
>#include "f.h"
>int& i1 = foo( (int*) 0);
>
>int the file main
>#include "f.h"
>int main()
>{
>return 1;
>}
>
>So, when the compiler try to link then I have this error :
>file2-a.o(.bss+0x4): multiple definition of `i1'
>
>I read that the problem comes frome the static variable. But in the
>programm where I try to insert the STL is very big and need some static
>varible. So, how can I resolve this problem ?

There is a problem with your code; it's not an EGCS bug, and has
nothing to do with the STL.

You've broken the "one definition rule" by defining i1 twice. If you
intended each of the two modules to have its own separate version of
i1, you should either declare them "static" or put them in an
anonymous namespace. If you intended them both to share a single
global i1, you should declare it "extern" in a header file and define
it in only one of the source modules.

--
Ross Smith ................................... mailto:ross.s@ihug.co.nz
.............. The Internet Group, Auckland, New Zealand ..............
                               * * * * *
       "We're bored. We're armed. And we're off the medication."

No Subject

[Professor W P Jones]

I have tried to compile DDD 3.0 on my system running Redhat 5.1 with Motif
2.1 installed.   However when I run ./configure (which is part of DDD) I get
the following config.log output:

This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.

configure:613: checking host system type
configure:634: checking target system type
configure:652: checking build system type
configure:685: checking for a BSD compatible install
configure:738: checking whether build environment is sane
configure:795: checking whether make sets ${MAKE}
configure:834: checking for working aclocal
configure:847: checking for working autoconf
configure:860: checking for working automake
configure:873: checking for working autoheader
configure:886: checking for working makeinfo
configure:900: checking whether make sets ${MAKE}
configure:2250: checking for c++
configure:2281: checking whether the C++ compiler (c++  ) works
configure:2295: c++ -o conftest    conftest.C  1>&5
/usr/bin/ld: cannot open -lstdc++: No such file or directory
collect2: ld returned 1 exit status
configure: failed program was:
#line 2291 "configure"
#include "confdefs.h"
main(){return(0);}

This presumably is a problem with egcs?  I have egcs-1.1b-2 including
egcs-libstdc++-1.1b-1 installed on my system.  It seems however that c++
cannot 'find' libstdc++.  Any suggestions?

Many thanks
Bill Jones

Professor W P Jones
Combustion Research Programme Coordinator
Department of Chemical Engineering
Imperial College
London SW7 2BY
Tel:	+44 (0) 171 594 5574/5603
Fax:	+44 (0) 171 594 5637/5619
E-mail:	w.jones@ic.ac.uk

Re:

[Ruslan Shevchenko]

Professor W P Jones wrote:
>
> configure:2250: checking for c++
> configure:2281: checking whether the C++ compiler (c++  ) works
> configure:2295: c++ -o conftest    conftest.C  1>&5
> /usr/bin/ld: cannot open -lstdc++: No such file or directory
> collect2: ld returned 1 exit status
> configure: failed program was:
> #line 2291 "configure"
> #include "confdefs.h"
> main(){return(0);}
> 
> This presumably is a problem with egcs?  I have egcs-1.1b-2 including
> egcs-libstdc++-1.1b-1 installed on my system.  It seems however that c++
> cannot 'find' libstdc++.  Any suggestions?

looks, like you install rpm package with egcs, but not install
lates g++lib-devel package (I can't remember package name extastly,
look at something simular in RedHat rpm listing)

-- 
    @=                                   
     //RSSH                             
mailto:Ruslan@Shevchenko.Kiev.UA

CORBA in Ukraine & ex-USSR: http://www.corbadev.kiev.ua

Re:

[N8TM]

In a message dated 7/31/98 10:29:16 PM Pacific Daylight Time,
law@hurl.cygnus.com writes:

> If binutils/gas was configured and installed with the same prefix
>  that you use for egcs, then egcs should *always* find gas before
>  the system assembler.  It it doesn't, then that is a very serious
>  bug.
 As you can see just from today's postings, I'm not the only one seeing these
problems.  Something is going wrong with search paths and linker specification
in the stage bootstraps, and it's not limited to just one environment, and not
fully cured with recent snapshots.  It's not a big issue on Irix6, as long as
you know about it, because there it's logical to specify the local environment
default options for as, and it's not normal to try --with-gnu-as.  And it's
not a big issue on NT/cygwin32 because the only bad thing that happens is that
the comparisons of objc and g77 between builds are bogus, as there wasn't
actually a rebuild.

Re:

[N8TM]

In a message dated 7/31/98 10:29:16 PM Pacific Daylight Time,
law@hurl.cygnus.com writes:

> Of particular interest is what prefix values were used to configure
>  egcs-1.0.3a & binutils (whatever version you're using).
>  

I built both egcs-1.0.3a and egcs-19980727 using the same options;
binutils-2.9.1 pre-installed, and configured --with-gnu-as.  For egcs-19980727
I specified no prefix, as I wanted it to install in the default /usr/local
which is where binutils-2.9.1 is installed.  for egcs-1.0.3a I specified a
subdirectory under /usr/local as I was attempting to set up for parallel
testsuite runs.  I ended up giving up on --with-gnu-as, hoping that won't
affect the regression testing.

Re:

[Jeffrey A Law]

  In message < 699c9331.35c32b8c@aol.com >you write:
  > I built both egcs-1.0.3a and egcs-19980727 using the same options;
  > binutils-2.9.1 pre-installed, and configured --with-gnu-as.  For egcs-19980  > 727
  > I specified no prefix, as I wanted it to install in the default /usr/local
  > which is where binutils-2.9.1 is installed.  for egcs-1.0.3a I specified a
  > subdirectory under /usr/local as I was attempting to set up for parallel
  > testsuite runs.
Ah.

So for the snapshot, things should have worked and for egcs-1.0.3a
things should not have worked.

Is that consistent with what actually happened to you?

Note that a well placed symlink in the <prefix>/<configuration>/bin/as
to your gas binary can eliminate this problem.  I usually don't recommend
this though (since making the prefixes match is the better solution).

But for your case the symlink is probably the best thing to do for the
egcs-1.0.3a directory.

  > I ended up giving up on --with-gnu-as, hoping that won't
  > affect the regression testing.
Consistend use --with-gnu-as is important to regression testing on
the PA and some other platforms.
jeff

Re:

[N8TM]

Yes, egcs-1.0.3a has a habit of shifting to the HPUX /bin/as while building
objc on HPUX10.20, in spite of everything apparently being set up correctly.
If you insist on using 1.0.3a, and aren't using objc, you could just eliminate
that from the build, or prevail upon your sysadmin to replace /bin/as
temporarily with gnu as, or give up and build without --with-gnu-as.  There
must be something wrong with Makefile, at least as it gets configured.
However, egcs-1.0.3a is too buggy on HP to be worth a great deal of effort.  I
have been revisiting this problem just this week, as I volunteered to do
regression tests between egcs-1.0.3a, gcc-2.8.1/g77-0.5.23, and pre-release
snapshots of egcs-1.1.  I can say already that the current pre-release
snapshot egcs-19980727 is head and shoulders above earlier gnu compilers for
HPUX10.20. It does have one quirk on HPUX10: you must first install gnu m4 and
autoconf and always set the environment variable DEFAULT_M4 to your installed
gnu m4 before running configure.  But I'm no compiler expert, just an engineer
maintaining Fortran applications part time.

Re:

[Jeffrey A Law]

  In message <d6e1dac6.35c11ac6@aol.com>you write:
  > Yes, egcs-1.0.3a has a habit of shifting to the HPUX /bin/as while building
  > objc on HPUX10.20, in spite of everything apparently being set up correctly  > .
Can you give more information on this.

Of particular interest is what prefix values were used to configure
egcs-1.0.3a & binutils (whatever version you're using).

If binutils/gas was configured and installed with the same prefix
that you use for egcs, then egcs should *always* find gas before
the system assembler.  It it doesn't, then that is a very serious
bug.

Jeff

No Subject

[Johannes Leebmann]

Hallo EGCS-team!

We tried several times to install egcs-1.0.2 on a sun solaris2.4
host. 

The compilation ends with:

Links are now set up to build a native compiler for 
sparc-sun-solaris2.4

While building egcs-1.0.2 with the command *make*
the error...

gcc  -o makeinfo makeinfo.o multi.o -L../libtxi -ltxi 
ld: elf error: file ../libtxi/libtxi.a: unable to locate archive symbol table: Request error: offset out of range 
ld: fatal: File processing errors.  No output written to makeinfo
collect2: ld returned 1 exit status
make[2]: *** [makeinfo] Error 1


...was reported.


We cant find any way to gon on. Please try to help us to
take the next steps. 

With our sincere thanks Johannes Leebmann.

Re:

[Jeffrey A Law]

  In message < 9804211215.AA19969@sun7.photo.verm.tu-muenchen.de >you write:
  > Hallo EGCS-team!
  > 
  > We tried several times to install egcs-1.0.2 on a sun solaris2.4
  > host. 
  > 
  > The compilation ends with:
  > 
  > Links are now set up to build a native compiler for 
  > sparc-sun-solaris2.4
  > 
  > While building egcs-1.0.2 with the command *make*
  > the error...
  > 
  > gcc  -o makeinfo makeinfo.o multi.o -L../libtxi -ltxi 
  > ld: elf error: file ../libtxi/libtxi.a: unable to locate archive symbol tab
  > le: Request error: offset out of range 
  > ld: fatal: File processing errors.  No output written to makeinfo
This would probably indicate an error with ld, ar or ranlib, not
egcs itself.

It could also be a problem with your assembler, but that is less likely.

jeff

No Subject

[harry eaton]

Sorry I can't seem to prodcue a smaller example, but I get the message:

dialog.c: In function `AddButtons':
dialog.c:170: internal error--insn does not satisfy its constraints:
(insn 310 110 311 (set (reg:SI 0 r0)
        (high:SI (symbol_ref:SI ("*.LC3")))) 380 {elf_high} (nil)
    (nil))
gcc: Internal compiler error: program cc1 got fatal signal 11
make: *** [dialog.o] Error 1

When I compile ( ftp://ftp.linuxppc.org/users/harry/PCB/pcb-1.6.2.B.tgz )
under linux-ppc.  The gziped distribution is about 1/2 Meg.
Simply untar, cd into the pcb-1.6.2.BETA directory, type "xmkmf -a",
then cd into src then make.

It only occurs with -O2 (and higher).  I compiled egcs-1.0.2 with
--enable-haifa, but it might do the same without this since I haven't
tried it.  I haven't tried other architectures either - perhaps they are
better (or not, who knows).

harry

Re:

[Franz Sirl]

Hi,

this looks like the bug I reported in
< http://www.cygnus.com/ml/egcs-bugs/1998-Apr/0172.html >, I got the same
constraint message til I stripped down the source... This is still true
with an egcs-cvs snapshot from yesterday.

Did someone already look at this? I would at least like to know if this is
a bug in the source, a general egcs bug or a bug in the PPC backend, to
decide if I should submit a testcase.

Thanks,
Franz


At 8:54 Uhr -0000 16.04.1998, harry eaton wrote:
>Sorry I can't seem to prodcue a smaller example, but I get the message:
>
>dialog.c: In function `AddButtons':
>dialog.c:170: internal error--insn does not satisfy its constraints:
>(insn 310 110 311 (set (reg:SI 0 r0)
>        (high:SI (symbol_ref:SI ("*.LC3")))) 380 {elf_high} (nil)
>    (nil))
>gcc: Internal compiler error: program cc1 got fatal signal 11
>make: *** [dialog.o] Error 1
>
>When I compile ( ftp://ftp.linuxppc.org/users/harry/PCB/pcb-1.6.2.B.tgz )
>under linux-ppc.  The gziped distribution is about 1/2 Meg.
>Simply untar, cd into the pcb-1.6.2.BETA directory, type "xmkmf -a",
>then cd into src then make.
>
>It only occurs with -O2 (and higher).  I compiled egcs-1.0.2 with
>--enable-haifa, but it might do the same without this since I haven't
>tried it.  I haven't tried other architectures either - perhaps they are
>better (or not, who knows).
>
>harry



Ciao,
Franz.

--
--------------------------------------------------------------------------
URLs	< mailto:Franz.Sirl@munich.netsurf.de >
	< http://homepages.munich.netsurf.de/Franz.Sirl >
--------------------------------------------------------------------------