bugreport

bugreport

[Jean-Pierre.Flament]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=X-roman8, Size: 6658 bytes --]

       Dear gentelmen,
      
      I have got a problem with a program reading mixed NAMELIST
      and "GROUP DATA" data.
      The namelist are the standard fortran namelist, and the
      "group data" is indeed a group of free format data
      enclosed within a couple of $NAME/$END banners
      The input is in a disk file which is rewound before 
      each read. The program either locates the $NAME
      when reading a "group data"² or issues a read(ir,NAME)
      when reading a namelist.
      it happens that, executing this program on a PC pentium,
      compiled with g77, that the data of a namelist are not read
      correctly. Fortunately the little program below reproduces
      the result of the actual run. The data file is after the 
      fortran code.
   *  the compilation command is
 
      g77 -g -C -o pgmtest pgmtest.f

      or 
 
      g77 -O2 -o pgmtest pgmtest.f

   *  and then pgmtest <datafile

   *  and here is the result of g77 -v

Lecture des spe©cification à partir de /usr/lib/gcc-lib/i386-redhat-linux/3.2/specs
Configure© avec: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info
 --enable-shared --enable-threads=posix --disable-checking --host=i386-redhat-linux
 --with-system-zlib --enable-__cxa_atexit
Mode¨le de thread: posix
version gcc 3.2 20020903 (Red Hat Linux 8.0 3.2-7)

   *  Here is what happens

      1/ the data consist of a "group data" named $FILE specifying
         free format data , followed by the namelist CNTRL
         setting the variable ISPHER to 1, while the initialization
         in the program sets it to 0.
      2/  When there is at least one SLASH in the strings of $FILE
          we get ISPHER=0 instead of 1. When there is no SLASH,
          ISPHER is correct, =1
      3/ when $CNTRL is put before $FILE the result is correct, even
         when there is SLASH in $FILE
      4/ when a line (even empty) is inserted between the $END of 
         $FILE and $CNTRL, the result is correct: this the workarround
         that I found.

         I guessed that the SLASH(es) in $FILE was the source of
         error because a / may end a namelist

         This problem never occured with other compilers (on 
         IBM -AIX or FORTRAN VS-,HP ,DEC or SGI)
     
    SAMPLE FORTRAN CODE pgmtest.f
--------------------------------------------------------
      program bug
c
      implicit real*8 (a-h,o-z)
      parameter (MXIODA=255,MXATOM=128,MXSYM=48,IBMMX=255)
      parameter (ZERO=0.0D+00)
      character*80 texte
      character*8 errmsg,BLANK
      integer direct
      integer thime
      integer semisp
      integer dirstp
      integer runflg
      integer fldint
c
c     ----- variables in common -----
c
c
      data BLANK   /'        '/
      data time   /9999999.0D+00/
      data igraf  /0/
      data direct /0/
      data iprint /0/
      data irest  /0/
      data runflg /0/
      data noprop /0/
      data nosym  /0/
      data qmttol /1.0d-04/
      data ispher /0/
      data list   /0/
      data ifield /0/
      data intfld /0/
      data moddia /1/
      data lenmem /200000/
      data lenxio /     1/
      data lenvec /200000/
c
 9997 format(' ----- namelist $CNTRL -----',                  /,
     #       ' runflg = ',i2 ,  ' noprop = ',i2 ,  ' nosym  = ',i2 ,
     #       ' ispher = ',i2 ,  ' direct = ',i2 ,                   /,
     #       ' irest  = ',i2 ,                                      /,
     #       ' igraf  = ',i2 ,  ' iprint = ',i2 ,  ' list   = ',i2 ,/,
     #       ' moddia = ',i2 ,                                      /,
     #       ' maxlcm = ',i10,/,' maxvec = ',i10,/,' maxxio = ',i10,/,
     #       ' qmttol = ',e10.3,                                    /,
     #       ' time   = ',f10.1,' (sec)')
c
      namelist /cntrl/ time,iprint,irest,runflg,noprop,nosym,qmttol,
     #                 list,moddia,maxxio,maxvec,maxlcm,
     #                 direct,igraf,ispher
c
      maxxio = lenxio
      maxvec = lenvec
      maxlcm = lcmmax
c
      ier = 0
      do while(ier.eq.0)
         read(5,'(a80)',iostat=ier) texte
         write(4,'(a80)') texte
      enddo
      ir = 4
      iw = 6
      rewind ir
      read(ir,cntrl,end=10,err=10)
   10 continue
c
c
      write(iw,9997) runflg,noprop,nosym,ispher,direct,
     #               irest,
     #               igraf,iprint,list,
     #               moddia,
     #               maxlcm,maxvec,maxxio,
     #               qmttol,time
c
      end


THE DATA after the ---------------------
---------------------------------
 $file
 oms omsmc.i2
 pseu pseudo/PSN
 $end
 $CNTRL ispher=1,NOSYM=0,RUNFLG=0,noprop=0, $END
 $GUESS NGUESS=9,norb=44,gssfil='gss.i2',  $END
 $BASIS
   ***   Iode      ********
    0    0   15     0    ...  ECP 
C1      2
I         53.0  LC  1.3335 0.0 0.0 - O K I
      1   S   3   give  1.0
      1   2.188316    0.799111
      1   1.749319   -1.200211
      1    .321036    0.610723
      1   S   1   give  1.0
      1    .160762     .180945
      1   S   1   give  1.0
      1    .078052     .105244
      1   P   3   give  1.0
      1   2.159164    0.320438
      1   1.855827   -0.467669
      1    .383991    0.427095
      1   P   1   give  1.0
      1    .163129    1.0
      1   P   1   give  1.0
      1    .065984    1.0
      1   D   1   give  1.0
      1    .730000    1.0
      1   D   1   give  1.0
      1    .270000    1.0

I         53.0  LC  1.3335   0.0 0.0 + O K I
      1   S   3   give  1.0
      1   2.188316    0.799111
      1   1.749319   -1.200211
      1    .321036    0.610723
      1   S   1   give  1.0
      1    .160762     .180945
      1   S   1   give  1.0
      1    .078052     .105244
      1   P   3   give  1.0
      1   2.159164    0.320438
      1   1.855827   -0.467669
      1    .383991    0.427095
      1   P   1   give  1.0
      1    .163129    1.0
      1   P   1   give  1.0
      1    .065984    1.0
      1   D   1   give  1.0
      1    .730000    1.0
      1   D   1   give  1.0
      1    .270000    1.0

 $END
 $ECP
 I-ECP    46    3
    1
  0.0         0 1.0
    1
 50.44054     2 2.648255
    1
 42.905904    2 2.226666
    1
 5.445394     2 0.644831
 I-ECP    46    3
 $END
 $WFN WFNFLG=1, $END
 $SCF NCO=7, $end
 $MC  MAXIT=30,nocas=1,nocan=0, $END
 $TRF  $END
 $DRT
    ***     CALCUL MCSCF DE I2 1S+ + 1Pi      ***
    0   10    1    3    0  0 0         0         0         0    0    0
7*DOC 8*VAL
 $END
 $GUGSRT $END
 $GUGEM $END
 $GUGDIA NSTATE=8,maxit=160,  $END
 $GUGDM  $END
 $GUGDM2 nstate=8,istate=1,2,3,4,5,6,7,8,wstate=8*1.0, $END
 $CASMP2   $END
 $NEWTON $END
 $PUN nopltx=1,noplto=1,gamess=1,biosym=1,hyperc=1, $END

Re: bugreport

[Toon Moene]

Jean-Pierre.Flament@univ-lille1.fr wrote:

[ ... ]

Please submit this bug report to our Bug Database:

http://gcc.gnu.org/bugzilla/

Component: fortran.

Otherwise, we'll lose track of your problem.

Merci,

-- 
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
GNU Fortran 95: http://gcc.gnu.org/fortran/ (under construction)

bugreport

[ggg]

The version of mu gcc:
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)

Re: bugreport

[Alexandre Oliva]

On Sep 28, 1999, Dietmar Schaefer <dietmar@ast.dfs.de> wrote:

> Building ddd-3.1.6-alpha-dec-osf4.0d...
> c++  -DHAVE_CONFIG_H -DNDEBUG -O2 -g -W -Wall  -felide-constructors
> -fconserve-space -trigraphs -c -I. -I. -I./.. -I/usr/include/X11  -o
> HelpCB.o HelpCB.C
> HelpCB.C: In function `void PopupTip(void *, XtIntervalId *)':
> HelpCB.C:2148: Internal compiler error in `scan_region', at
> except.c:2566
> Please submit a full bug report.

Thanks for your bug report.  The latest development snapshot of gcc
compiles it successfully, but it is unlikely that the bug will be
fixed in the 2.95.* series.  You'll have to compile this particular
file without -DNDEBUG on alpha, before gcc 2.96 is released.

-- 
Alexandre Oliva http://www.ic.unicamp.br/~oliva IC-Unicamp, Bra[sz]il
oliva@{lsd.ic.unicamp.br,guarana.{org,com}} aoliva@{acm,computer}.org
oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org}
** I may forward mail about projects to mailing lists; please use them

bugreport

[Dietmar Schaefer]

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

 Making all in ./ddd...
Building ddd-3.1.6-alpha-dec-osf4.0d...
c++  -DHAVE_CONFIG_H -DNDEBUG -O2 -g -W -Wall  -felide-constructors
-fconserve-space -trigraphs -c -I. -I. -I./.. -I/usr/include/X11  -o
HelpCB.o HelpCB.C
HelpCB.C: In function `void PopupTip(void *, XtIntervalId *)':
HelpCB.C:2148: Internal compiler error in `scan_region', at
except.c:2566
Please submit a full bug report.


--



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

Bugreport

[Christian Wichert]

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

----------------- main.cc

template<class T> class V
{
  static  V<T> c( 0, 1 );
};

------------------

This code causes an
main.cc:4: Internal compiler error.
main.cc:4: Please submit a full bug report.      

instead an "in-class initialization of static data member of
non-integral type V" error.


>gcc -V
Reading specs from /usr/local/lib/gcc-lib/i586-pc-linux-gnu/2.95.1/specs
gcc version 2.95.1 19990809 (prerelease)     


Christian

-- 
In a world without walls and fences - who needs windows and gates?
>From akarpov@my-deja.com Wed Sep 01 07:26:00 1999
From: akarpov@my-deja.com
To: gnu-gcc-bug@moderators.isc.org
Subject: GNU compiler bug?
Date: Wed, 01 Sep 1999 07:26:00 -0000
Message-id: <7qjd02$jtq$1@nnrp1.deja.com>
X-SW-Source: 1999-09/msg00006.html
Content-length: 1215

Hello VxWorkers!

IÂ’m  extremely puzzled by a bug I've discovered in the GNU compiler. It
can be reproduced by this simple example of code:

/** begin of the example (gnu_bug.c) **/
#include <stdlib.h>
#include <string.h>
void myfunc(char*s, int *x)
{  char *loc;

   loc=malloc(246);
   strcpy(loc,"11111");
   free(s);		/*    pushl %ebx           */
			/*    call 0x11bf70 <free> */
    s= loc;		/**** NO CODE GENERATED ! ***/
   *x= 246;		/*    movl $0xf6, (%esi)   */

}
void main(void)
{
char *str; int y;
str=malloc(246);
strcpy(str,"sdfsd");
myfunc(str,&y);
}
/** end of the example  (gnu_bug.c) **/

The problem is that no code is generated for the source line “s=loc;”
in the myfunc() !
This is also what I saw in the disassembled code.
Here I brought the compilation options on my x86 BSP:

cc386 -O -fvolatile -nostdlib -fno-builtin -fno-defer-pop -m486 -Wall -
I/h   -I. -IC:\Tornado\target\config\all -IC:\Tornado\target/h -
IC:\Tornado\target/src/config -IC:\Tornado\target/src/drv -ansi -
nostdinc -DCPU=I80486   -Wp,-lang-c++ -o gnu_bug.o -g -Winline -c gnu_
bug.c

Any thoughts guys?

Thanks,
Alex

- VxWorks -


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
>From mark@codesourcery.com Wed Sep 01 07:26:00 1999
From: Mark Mitchell <mark@codesourcery.com>
To: nathan@cs.bris.ac.uk, nathan@acm.org
Cc: egcs-bugs@egcs.cygnus.com
Subject: Re: C++ BUG: Missed ambiguity
Date: Wed, 01 Sep 1999 07:26:00 -0000
Message-id: <19990901073221Y.mitchell@codesourcery.com>
References: <37CCEE2D.8DFD7C04@acm.org>
X-SW-Source: 1999-09/msg00007.html
Content-length: 229

>>>>> "Nathan" == Nathan Sidwell <nathan@acm.org> writes:

    Nathan> shall I install the test case?

Please.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com
>From rearnsha@arm.com Wed Sep 01 07:30:00 1999
From: Richard Earnshaw <rearnsha@arm.com>
To: gcc-bugs@gcc.gnu.org
Cc: richard.earnshaw@arm.com
Subject: Bug with haifa scheduler
Date: Wed, 01 Sep 1999 07:30:00 -0000
Message-id: <199909011430.PAA00518@sun52.NIS.cambridge>
X-SW-Source: 1999-09/msg00008.html
Content-length: 987

Since we switched to the Haifa scheduler by default I've been unable to 
bootstrap the compiler on the ARM.  I've finally managed to track down 
what appears to be the cause of this.

Before the first scheduling pass is done all the insns are split and then 
the notes on the insns are updated; the problem seems to be introduced by 
the process of updating the notes.

The notes are updated by calling update_life_info(), which in turn calls 
new_insn_dead_notes().  However, this code then uses mark_set_resources() 
and TEST_HARD_REG_BIT() -- the problem is here: since this is before 
register allocation the split insns still contain pseudos so this 
technique of noting register usage is just bogus.

Before I start hacking this to pieces, can someone just confirm that I'm 
not going barking and this code really is not appropriate if called before 
reload has completed?

If so, can I fix this by rewriting it in terms of a full reg-set? or is 
there a simpler way?

Richard.

Bugreport

[Max Weninger]

Hi,

I discovered a (in my opinion) bug in the latest gcc-2.95 prerelease.

-------------------------------------------------------------------------------------
Compiler Info:

Reading specs from /opt/gcc-dev/lib/gcc-lib/alphaev56-unknown-linux-gnu/2.95/specs
gcc version 2.95 19990712 (prerelease)

--------------------------------------------------------------------------------------

Source Code:

#include <iostream>
        enum EFlags {
                eFirst =0x00001000,
                eLast =0x80000000
        };
        enum EFlags1 {
                eFlags1       = eFirst << 11
        };
        enum EFlags2 {
                eFlags2    = eFlags1 << 1
        };
        enum EFlags3 {
                eFlags3       = eFlags2<< 7
        };
        enum EFlags4 {
                eFlags4        = eFirst << 19
        };
int main( int, char **)
{
        cerr << eFlags3<< endl;
        cerr << eFlags4<< endl;
}

----------------------------------------------------------------------------------------
Compile options:

g++ shift.C 

----------------------------------------------------------------------------------------

Description:

extreme /tmp/test> ./a.out
-2147483648
2147483648

Why is eFlags3 negative ?

If you remove the eLast Flags from the EFlags enum 

        enum EFlags {
                eFirst =0x00001000
        };

the result is

extreme /tmp/test> ./a.out
-2147483648
-2147483648

No both results are negative

---------------------------------------------------------------------

System Information:

Linux extreme 2.2.5 #4 Thu Jun 17 18:18:13 CEST 1999 alpha unknown
RedHat 5.2 on a 21164a 600MHz Alpha

----------------------------------------------------------------------

Regards

Max

-- 
_______________________________________________________________
     \                  
    o/\_          DI Max Weninger
   <\__,\         Email (max@takefive.co.at)          
    ">.  |         
     ` .-|        TakeFive Software - Jakob-Haringer-Str. 8
        . \       A-5020 Salzburg - AUSTRIA
         . \      Tel: +43 662 4579150 - Fax: +43 662 4579156
         .-|      
_________._|____________________________________________________

Re: Bugreport

[Nathan Sidwell]

Max Weninger wrote:
>         enum EFlags {
>                 eFirst =0x00001000,
>                 eLast =0x80000000
>         };
>         enum EFlags1 {
>                 eFlags1       = eFirst << 11
>         };
>         enum EFlags2 {
>                 eFlags2    = eFlags1 << 1
>         };
>         enum EFlags3 {
>                 eFlags3       = eFlags2<< 7
>         };
>         enum EFlags4 {
>                 eFlags4        = eFirst << 19
>         };
Not a bug. it's implementation defined.

the underlying type of an enum is one the integral types. Which type is chosen
depends on the values within the enumeration. [7.2/5].
during the enum definition each enumvalue has the type of its initializing
expression, at the close '}', the enumvalue types are reassigned [7.2/4] based
on their *representable* values.

On your system int and unsigned int are 32 bits, 0x1000 has the type int,
0x80000000 has the type unsigned int (and is not representable as an int). The
underlying type of EFirst is unsigned int.
During definition of Eflags1, the expression `eFirst << 11' has type `unsigned
int' (but is representable as `int'). At the close }, the underlying type `int'
(appears) to be chosen (implementation defined).
Similar logic holds for eflags2.
Now eflags3 is built from eflags2 which has an int underlying type. Therefore
the
type of `eflags2 << 7' is `int' and it overflows and is truncated to the
representable value `-1 << 31'. So at the close }, eFlags3 is seen to have the
value -1 << 31, and the type int is still chosen for the underlying type.
Eflags4 is taken directly from eFirst, so `efirst << 19' has the type `unsigned
int' and value `(unsigned)1 << 31'. Therefore at the close }, the underlying
type `unsigned int' is chosen.

> extreme /tmp/test> ./a.out
> -2147483648
> 2147483648
i.e. (int)1 << 31 and (unsigned)1 << 31

> If you remove the eLast Flags from the EFlags enum
Now Efirst has the underlying type `int', so eflags4 behaves the same as
eflags3.

> extreme /tmp/test> ./a.out
> -2147483648
> -2147483648

If you want to avoid this behaviour you must insert explicit (unsigned long)
casts into the definitions of your enums. (Should the results be representable
as int, that may% be chosen as the underlying type still. If unsigned int will
do, then that may also be chosen, even though you gave the initializers type
'unsigned long').

You're being confused by `value', `type', `representable value' and the
reassignment of type which occurs during enum definition which is based on the
representable values of the enum constants.

% remember it's implementation defined whether int or unsigned int is preferred
for values which are representable in both.

nathan

-- 
Dr Nathan Sidwell :: Computer Science Department :: Bristol University
        I have seen the death of PhotoShop -- it is called GIMP
nathan@acm.org  http://www.cs.bris.ac.uk/~nathan/  nathan@cs.bris.ac.uk
>From gandalf@winds.org Fri Jul 16 04:03:00 1999
From: Byron Stanoszek <gandalf@winds.org>
To: egcs-bugs@egcs.cygnus.com
Subject: GCC 2.95 Prerelease, ASM Problem?
Date: Fri, 16 Jul 1999 04:03:00 -0000
Message-id: <Pine.LNX.4.10.9907160655400.5224-100000@winds.org>
X-SW-Source: 1999-07/msg00610.html
Content-length: 883

Compiling svgalib-1.4.0.tar.gz normally with gcc 2.95 (vs. gcc-2.91.66) fails
due to some __asm__ statements saying a forbidden variable %ax/%dx/etc is
modified and its contents is spilled.

I assume this is part of changes made to gcc that allow for better
optimization, but breaks traditional assembly.

My wish is that there is some backward compatibility here, because many people
are probably going to complain about programs that once compiled
(svgalib-1.4.0) under the old gcc no longer work under the new.

This problem is reproducible, just download the tar and try yourself. I saw no
problems resolved using -march=486 or -march=pentium.

---
      .               .      |   - Gandalf, the Administrator of WindsMARE -
 -~~--__- WindsMARE -__--~~- |       Byron Stanoszek - gandalf@winds.org
   `                     '   |  telnet://winds.org:7348 , http://www.winds.org

Re: bugreport

[Martin v. Loewis]

> This is not true for me on 

You may want to contact Henk Jansen, or look at his message in

http://egcs.cygnus.com/ml/egcs-bugs/1999-06/msg00077.html

I don't know whether he had to modify CXX - this is entirely possible,
as the standard library of g++ is not compliant, yet.

Regards,
Martin

Bugreport

[Simon Thum]

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

Hi there!

I´m runnig Intel-Linux and egcs 2.91.66, and had this nasty error.
Members with default args from the class seem to be treated static for
some reason, and I found no explanation in my C++ book.
I have constructed a minimal-case ´Program´ to reproduce the bug. I
simply invoked:

g++ egcs-err.cpp

and it stated a static member couldn´t access in-class data.
I ommitted the preprocessing since it should have no meaning.

BTW, on our SUN´s the problem also occurs, with the same egcs.

Good luck 
>From bhoel@server.python.net Wed Jun 30 23:07:00 1999
From: Berthold Höllmann <bhoel@server.python.net>
To: "Martin v. Loewis" <martin@mira.isdn.cs.tu-berlin.de>
Cc: egcs-bugs@egcs.cygnus.com
Subject: Re: bugreport
Date: Wed, 30 Jun 1999 23:07:00 -0000
Message-id: <375A4F33.737C9036@starship.python.net>
References: <37595E0A.F1529DA2@starship.python.net> <199906052205.AAA01288@mira.isdn.cs.tu-berlin.de>
X-SW-Source: 1999-06n/msg00153.html
Content-length: 3881

"Martin v. Loewis" wrote:
> 
> > asked me to send a bugreport
> 
> Thanks for your bug report. gcc-2.95 19990529 compiles it just fine,
> so it seems that the bug has been fixed. In fact, the most recent
> report on CXX did not complain about not compiling, anymore - it
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> complained about compiling too slowly.

This is not true for me on 

>uname -a
Linux pchoel 2.2.5 #4 Sam Mai 22 17:56:56 MEST 1999 i686 unknown

using the 19990602 snapshot version:

g++ -fpic  -I./Include -I./Demo -g -O2 -I/usr/local/include/python1.5
-I/usr/local/include/python1.5 -DHAVE_CONFIG_H -c ./Demo/example.cxx
/usr/local/lib/gcc-lib/i686-pc-linux-gnu/gcc-2.95/../../../../include/g++-2/stl_iterator.h:
In instantiation of
`iterator_traits<Py::SeqBase<Py::Object>::iterator>':
/usr/local/lib/gcc-lib/i686-pc-linux-gnu/gcc-2.95/../../../../include/g++-2/stl_iterator.h:154:  
instantiated from
`sort<Py::SeqBase<Py::Object>::iterator>(Py::SeqBase<Py::Object>::iterator,
Py::SeqBase<Py::Object>::iterator)'
./Demo/example.cxx:205:   instantiated from here
/usr/local/lib/gcc-lib/i686-pc-linux-gnu/gcc-2.95/../../../../include/g++-2/stl_iterator.h:104:
no type named `iterator_category' in `class
Py::SeqBase<Py::Object>::iterator'
/usr/local/lib/gcc-lib/i686-pc-linux-gnu/gcc-2.95/../../../../include/g++-2/stl_iterator.h:105:
no type named `value_type' in `class Py::SeqBase<Py::Object>::iterator'
/usr/local/lib/gcc-lib/i686-pc-linux-gnu/gcc-2.95/../../../../include/g++-2/stl_iterator.h:106:
no type named `difference_type' in `class
Py::SeqBase<Py::Object>::iterator'
/usr/local/lib/gcc-lib/i686-pc-linux-gnu/gcc-2.95/../../../../include/g++-2/stl_iterator.h:107:
no type named `pointer' in `class Py::SeqBase<Py::Object>::iterator'
/usr/local/lib/gcc-lib/i686-pc-linux-gnu/gcc-2.95/../../../../include/g++-2/stl_iterator.h:108:
no type named `reference' in `class Py::SeqBase<Py::Object>::iterator'
/usr/local/lib/gcc-lib/i686-pc-linux-gnu/gcc-2.95/../../../../include/g++-2/stl_iterator.h:
In function `void
sort<Py::SeqBase<Py::Object>::iterator>(Py::SeqBase<Py::Object>::iterator,
Py::SeqBase<Py::Object>::iterator)':
./Demo/example.cxx:205:   instantiated from here
/usr/local/lib/gcc-lib/i686-pc-linux-gnu/gcc-2.95/../../../../include/g++-2/stl_iterator.h:154:
no type named `value_type' in `struct
iterator_traits<Py::SeqBase<Py::Object>::iterator>'
/usr/local/lib/gcc-lib/i686-pc-linux-gnu/gcc-2.95/../../../../include/g++-2/stl_algo.h:1320:
warning: cannot pass objects of type `Py::SeqBase<Py::Object>::iterator'
through `...'
/usr/local/lib/gcc-lib/i686-pc-linux-gnu/gcc-2.95/../../../../include/g++-2/stl_iterator.h:
At top level:
/usr/local/lib/gcc-lib/i686-pc-linux-gnu/gcc-2.95/../../../../include/g++-2/stl_iterator.h:
In instantiation of
`__value_type<Py::SeqBase<Py::Object>::iterator>(...)':
/usr/local/lib/gcc-lib/i686-pc-linux-gnu/gcc-2.95/../../../../include/g++-2/stl_algo.h:1320:  
instantiated from
`sort<Py::SeqBase<Py::Object>::iterator>(Py::SeqBase<Py::Object>::iterator,
Py::SeqBase<Py::Object>::iterator)'
./Demo/example.cxx:205:   instantiated from here
/usr/local/lib/gcc-lib/i686-pc-linux-gnu/gcc-2.95/../../../../include/g++-2/stl_iterator.h:154:
no type named `value_type' in `struct
iterator_traits<Py::SeqBase<Py::Object>::iterator>'
/usr/local/lib/gcc-lib/i686-pc-linux-gnu/gcc-2.95/../../../../include/g++-2/stl_iterator.h:
In function `{error}
__value_type<Py::SeqBase<Py::Object>::iterator>(...)':
/usr/local/lib/gcc-lib/i686-pc-linux-gnu/gcc-2.95/../../../../include/g++-2/stl_iterator.h:154:
confused by earlier errors, bailing out
make: *** [example.o] Error 1

Regards

Berthold
-- 
bhoel@starship.python.net
        It is unlawful to use this email address for unsolicited ads
        (USC Title 47 Sec.227). I will assess a US$500 charge for
        reviewing and deleting each unsolicited ad.

Re: bugreport

[Berthold Höllmann]

"Martin v. Loewis" wrote:
> 
> > asked me to send a bugreport
> 
> Thanks for your bug report. gcc-2.95 19990529 compiles it just fine,
> so it seems that the bug has been fixed. In fact, the most recent
> report on CXX did not complain about not compiling, anymore - it
> complained about compiling too slowly.
> 
> Regards,
> Martin
It seems, that the problem of compiling egcs was, that I installed pgcs
1.1.3 which produces wrong code. I still had problems compiling the
19990602 snapshot using pgcs, but was successfull using an older
snapshot version.

Cheers

Berthold
-- 
bhoel@starship.python.net
        It is unlawful to use this email address for unsolicited ads
        (USC Title 47 Sec.227). I will assess a US$500 charge for
        reviewing and deleting each unsolicited ad.

bugreport

[Berthold Höllmann]

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

Hello,

gcc on 

>uname -a
Linux pchoel 2.2.5 #4 Sam Mai 22 17:56:56 MEST 1999 i686 unknown

asked me to send a bugreport

>g++ -v --save-temps -fpic  -D__STL_USE_NAMESPACES -I./Include -I./Demo -g -O2 -I/usr/local/include/python1.5 -I/usr/local/include/python1.5 -DHAVE_CONFIG_H -c ./Demo/r.cxx
Reading specs from /opt/lib/gcc-lib/i686-pc-linux-gnu/pgcc-2.91.66/specs
gcc version pgcc-2.91.66 19990314 (egcs-1.1.2 release)
 /opt/lib/gcc-lib/i686-pc-linux-gnu/pgcc-2.91.66/cpp -lang-c++ -v
-I./Include -I./Demo -I/usr/local/include/python1.5
-I/usr/local/include/python1.5 -undef -D__GNUC__=2 -D__GNUG__=2
-D__cplusplus -D__GNUC_MINOR__=91 -D__ELF__ -Dunix -Di386 -D__i386__
-Dlinux -D__ELF__ -D__unix__ -D__i386__ -D__i386__ -D__linux__ -D__unix
-D__i386 -D__linux -Asystem(posix) -D__EXCEPTIONS -D__OPTIMIZE__ -g
-Asystem(unix) -Acpu(i386) -Amachine(i386) -Di386 -D__i386 -D__i386__
-Di686 -Dpentiumpro -D__i686 -D__i686__ -D__pentiumpro -D__pentiumpro__
-D__PIC__ -D__pic__ -D__STL_USE_NAMESPACES -DHAVE_CONFIG_H ./Demo/r.cxx
r.ii
GNU CPP version pgcc-2.91.66 19990314 (egcs-1.1.2 release) (i386
Linux/ELF)
#include "..." search starts here:
#include <...> search starts here:
 Include
 Demo
 /usr/local/include/python1.5
 /usr/local/v/include
 /usr/local/qt/include
 /opt/include/g++
 /usr/local/include
 /opt/i686-pc-linux-gnu/include
 /opt/lib/gcc-lib/i686-pc-linux-gnu/pgcc-2.91.66/include
 /usr/include
End of search list.
 /opt/lib/gcc-lib/i686-pc-linux-gnu/pgcc-2.91.66/cc1plus r.ii -quiet
-dumpbase r.cc -g -O2 -version -fpic -o r.s
GNU C++ version pgcc-2.91.66 19990314 (egcs-1.1.2 release)
(i686-pc-linux-gnu) compiled by GNU C version egcs-2.91.66 19990314
(egcs-1.1.2 release).
Include/CXX_Objects.h: In method `int ::Py::String::capacity() const':
In file included from Include/CXX_Extensions.h:8,
                 from Demo/r.h:3,
                 from ./Demo/r.cxx:1:
Include/CXX_Objects.h:1229: Internal compiler error.
Include/CXX_Objects.h:1229: Please submit a full bug report to
`egcs-bugs@egcs.cygnus.com'.
Include/CXX_Objects.h:1229: See
<URL: http://egcs.cygnus.com/faq.html#bugreport > for details.

Cheers

Berthold
-- 
bhoel@starship.python.net
        It is unlawful to use this email address for unsolicited ads
        (USC Title 47 Sec.227). I will assess a US$500 charge for
        reviewing and deleting each unsolicited ad.
r.ii.bz2
r.s.bz2


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

[-- Attachment #3: r.s.bz2 --]
[-- Type: application/x-bzip2, Size: 13532 bytes --]

Re: Bugreport

[Alexandre Oliva]

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

On Jun 22, 1999, Simon Thum <Simon.Thum@mni.fh-giessen.de> wrote:

> and it stated a static member couldn´t access in-class data.

> class X{ private: int i; public: int f(int a=i){return i=a;} };

Thanks for your bug report.  This will probably be fixed in gcc-2.95.
The latest snapshot says:

t.cc:5: invalid use of member `X::i'

In fact, you can't use non-static data member in default argument
expressions.

-- 
Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il
{oliva,Alexandre.Oliva}@dcc.unicamp.br  aoliva@{acm.org,computer.org}
oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org}
*** E-mail about software projects will be forwarded to mailing lists

Re: bugreport

[Berthold Höllmann]

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

"Martin v. Loewis" wrote:
> 
> > asked me to send a bugreport
> 
> Thanks for your bug report. gcc-2.95 19990529 compiles it just fine,
> so it seems that the bug has been fixed. In fact, the most recent
> report on CXX did not complain about not compiling, anymore - it
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> complained about compiling too slowly.

This is not true for me on 

>uname -a
Linux pchoel 2.2.5 #4 Sam Mai 22 17:56:56 MEST 1999 i686 unknown

using the 19990602 snapshot version:

g++ -fpic  -I./Include -I./Demo -g -O2 -I/usr/local/include/python1.5
-I/usr/local/include/python1.5 -DHAVE_CONFIG_H -c ./Demo/example.cxx
/usr/local/lib/gcc-lib/i686-pc-linux-gnu/gcc-2.95/../../../../include/g++-2/stl_iterator.h:
In instantiation of
`iterator_traits<Py::SeqBase<Py::Object>::iterator>':
/usr/local/lib/gcc-lib/i686-pc-linux-gnu/gcc-2.95/../../../../include/g++-2/stl_iterator.h:154:  
instantiated from
`sort<Py::SeqBase<Py::Object>::iterator>(Py::SeqBase<Py::Object>::iterator,
Py::SeqBase<Py::Object>::iterator)'
./Demo/example.cxx:205:   instantiated from here
/usr/local/lib/gcc-lib/i686-pc-linux-gnu/gcc-2.95/../../../../include/g++-2/stl_iterator.h:104:
no type named `iterator_category' in `class
Py::SeqBase<Py::Object>::iterator'
/usr/local/lib/gcc-lib/i686-pc-linux-gnu/gcc-2.95/../../../../include/g++-2/stl_iterator.h:105:
no type named `value_type' in `class Py::SeqBase<Py::Object>::iterator'
/usr/local/lib/gcc-lib/i686-pc-linux-gnu/gcc-2.95/../../../../include/g++-2/stl_iterator.h:106:
no type named `difference_type' in `class
Py::SeqBase<Py::Object>::iterator'
/usr/local/lib/gcc-lib/i686-pc-linux-gnu/gcc-2.95/../../../../include/g++-2/stl_iterator.h:107:
no type named `pointer' in `class Py::SeqBase<Py::Object>::iterator'
/usr/local/lib/gcc-lib/i686-pc-linux-gnu/gcc-2.95/../../../../include/g++-2/stl_iterator.h:108:
no type named `reference' in `class Py::SeqBase<Py::Object>::iterator'
/usr/local/lib/gcc-lib/i686-pc-linux-gnu/gcc-2.95/../../../../include/g++-2/stl_iterator.h:
In function `void
sort<Py::SeqBase<Py::Object>::iterator>(Py::SeqBase<Py::Object>::iterator,
Py::SeqBase<Py::Object>::iterator)':
./Demo/example.cxx:205:   instantiated from here
/usr/local/lib/gcc-lib/i686-pc-linux-gnu/gcc-2.95/../../../../include/g++-2/stl_iterator.h:154:
no type named `value_type' in `struct
iterator_traits<Py::SeqBase<Py::Object>::iterator>'
/usr/local/lib/gcc-lib/i686-pc-linux-gnu/gcc-2.95/../../../../include/g++-2/stl_algo.h:1320:
warning: cannot pass objects of type `Py::SeqBase<Py::Object>::iterator'
through `...'
/usr/local/lib/gcc-lib/i686-pc-linux-gnu/gcc-2.95/../../../../include/g++-2/stl_iterator.h:
At top level:
/usr/local/lib/gcc-lib/i686-pc-linux-gnu/gcc-2.95/../../../../include/g++-2/stl_iterator.h:
In instantiation of
`__value_type<Py::SeqBase<Py::Object>::iterator>(...)':
/usr/local/lib/gcc-lib/i686-pc-linux-gnu/gcc-2.95/../../../../include/g++-2/stl_algo.h:1320:  
instantiated from
`sort<Py::SeqBase<Py::Object>::iterator>(Py::SeqBase<Py::Object>::iterator,
Py::SeqBase<Py::Object>::iterator)'
./Demo/example.cxx:205:   instantiated from here
/usr/local/lib/gcc-lib/i686-pc-linux-gnu/gcc-2.95/../../../../include/g++-2/stl_iterator.h:154:
no type named `value_type' in `struct
iterator_traits<Py::SeqBase<Py::Object>::iterator>'
/usr/local/lib/gcc-lib/i686-pc-linux-gnu/gcc-2.95/../../../../include/g++-2/stl_iterator.h:
In function `{error}
__value_type<Py::SeqBase<Py::Object>::iterator>(...)':
/usr/local/lib/gcc-lib/i686-pc-linux-gnu/gcc-2.95/../../../../include/g++-2/stl_iterator.h:154:
confused by earlier errors, bailing out
make: *** [example.o] Error 1

Regards

Berthold
-- 
bhoel@starship.python.net
        It is unlawful to use this email address for unsolicited ads
        (USC Title 47 Sec.227). I will assess a US$500 charge for
        reviewing and deleting each unsolicited ad.
>From bhoel@server.python.net Sun Jun 06 03:55:00 1999
From: Berthold Höllmann <bhoel@server.python.net>
To: "Martin v. Loewis" <martin@mira.isdn.cs.tu-berlin.de>
Cc: egcs-bugs@egcs.cygnus.com
Subject: Re: bugreport
Date: Sun, 06 Jun 1999 03:55:00 -0000
Message-id: <375A4D4E.805C8C98@starship.python.net>
References: <37595E0A.F1529DA2@starship.python.net> <199906052205.AAA01288@mira.isdn.cs.tu-berlin.de>
X-SW-Source: 1999-06/msg00152.html
Content-length: 793

"Martin v. Loewis" wrote:
> 
> > asked me to send a bugreport
> 
> Thanks for your bug report. gcc-2.95 19990529 compiles it just fine,
> so it seems that the bug has been fixed. In fact, the most recent
> report on CXX did not complain about not compiling, anymore - it
> complained about compiling too slowly.
> 
> Regards,
> Martin
It seems, that the problem of compiling egcs was, that I installed pgcs
1.1.3 which produces wrong code. I still had problems compiling the
19990602 snapshot using pgcs, but was successfull using an older
snapshot version.

Cheers

Berthold
-- 
bhoel@starship.python.net
        It is unlawful to use this email address for unsolicited ads
        (USC Title 47 Sec.227). I will assess a US$500 charge for
        reviewing and deleting each unsolicited ad.
>From martin@mira.isdn.cs.tu-berlin.de Sun Jun 06 10:59:00 1999
From: "Martin v. Loewis" <martin@mira.isdn.cs.tu-berlin.de>
To: bhoel@server.python.net
Cc: egcs-bugs@egcs.cygnus.com
Subject: Re: bugreport
Date: Sun, 06 Jun 1999 10:59:00 -0000
Message-id: <199906061757.TAA00480@mira.isdn.cs.tu-berlin.de>
References: <37595E0A.F1529DA2@starship.python.net> <199906052205.AAA01288@mira.isdn.cs.tu-berlin.de> <375A4F33.737C9036@starship.python.net> <375A4F33.737C9036@starship.python.net>
X-SW-Source: 1999-06/msg00154.html
Content-length: 296

> This is not true for me on 

You may want to contact Henk Jansen, or look at his message in

http://egcs.cygnus.com/ml/egcs-bugs/1999-06/msg00077.html

I don't know whether he had to modify CXX - this is entirely possible,
as the standard library of g++ is not compliant, yet.

Regards,
Martin
>From mark@codesourcery.com Sun Jun 06 11:09:00 1999
From: mark@codesourcery.com
To: martin@mira.isdn.cs.tu-berlin.de
Cc: Franz.Sirl@munich.netsurf.de, egcs-bugs@egcs.cygnus.com
Subject: Re: Incompatibility with 1.1. (Was: Do you need the vtablebug fixed?)
Date: Sun, 06 Jun 1999 11:09:00 -0000
Message-id: <19990606111206P.mitchell@codesourcery.com>
References: <56082721395400.00455@ns1102.munich.netsurf.de> <199906061020.MAA00969@mira.isdn.cs.tu-berlin.de> <199906061020.MAA00969@mira.isdn.cs.tu-berlin.de>
X-SW-Source: 1999-06/msg00155.html
Content-length: 1861

Martin --

  Thanks for tracking down the mangling change.  Here's the fix,
applied on the mainline and branch.  (Well, the test-suite change is
not on the branch.)

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

1999-06-06  Mark Mitchell  <mark@codesourcery.com>

	* method.c (is_back_referenceable_type): Back-reference bools when
	not squangling.

Index: testsuite/g++.old-deja/g++.other/mangle1.C
===================================================================
RCS file: /egcs/carton/cvsfiles/egcs/gcc/testsuite/g++.old-deja/g++.other/mangle1.C,v
retrieving revision 1.1
diff -u -p -r1.1 mangle1.C
--- mangle1.C	1999/03/24 02:36:09	1.1
+++ mangle1.C	1999/06/06 18:04:51
@@ -40,3 +40,6 @@ int f__FRC1AiT0N20RiN25 = 0; // ERROR - 
 void f(const A2&, int, const A2&, const A2&, const A2&, int, int,
        int) { } // ERROR - name clash<
 int f__FRC1AiT0N20iii = 0; // ERROR - name clash
+
+void f(bool, bool) {} // ERROR - name clash
+int f__FbT0 = 0; // ERROR - name clash
Index: cp/method.c
===================================================================
RCS file: /egcs/carton/cvsfiles/egcs/gcc/cp/method.c,v
retrieving revision 1.101
diff -u -p -r1.101 method.c
--- method.c	1999/05/25 15:31:34	1.101
+++ method.c	1999/06/06 18:04:53
@@ -372,10 +372,16 @@ is_back_referenceable_type (type)
 
   switch (TREE_CODE (type)) 
     {
+    case BOOLEAN_TYPE:
+      if (!flag_do_squangling)
+	/* Even though the mangling of this is just `b', we did
+	   historically generate back-references for it.  */
+	return 1;
+      /* Fall through.  */
+      
     case INTEGER_TYPE:
     case REAL_TYPE:
     case VOID_TYPE:
-    case BOOLEAN_TYPE:
       /* These types have single-character manglings, so there's no
 	 point in generating back-references.  */
       return 0;         
>From martin@mira.isdn.cs.tu-berlin.de Sun Jun 06 13:59:00 1999
From: "Martin v. Loewis" <martin@mira.isdn.cs.tu-berlin.de>
To: mark@codesourcery.com
Cc: Franz.Sirl@munich.netsurf.de, egcs-bugs@egcs.cygnus.com
Subject: Re: Incompatibility with 1.1. (Was: Do you need the vtablebug fixed?)
Date: Sun, 06 Jun 1999 13:59:00 -0000
Message-id: <199906062057.WAA07866@mira.isdn.cs.tu-berlin.de>
References: <56082721395400.00455@ns1102.munich.netsurf.de> <199906061020.MAA00969@mira.isdn.cs.tu-berlin.de> <19990606111206P.mitchell@codesourcery.com> <19990606111206P.mitchell@codesourcery.com>
X-SW-Source: 1999-06/msg00156.html
Content-length: 457

>   Thanks for tracking down the mangling change.  Here's the fix,
> applied on the mainline and branch.  (Well, the test-suite change is
> not on the branch.)

Excellent! It seems to work for the http.ii fragment Franz sent
me. Franz, could you check the status of mixing 1.1.x-compiled Qt with
2.95-compiled KDE applications?

If you are using snapshots instead of CVS, you can just apply Mark's
patch to gcc/cp/method.c of your snapshot.

Thanks,
Martin
>From shysavanna@webtv.net Sun Jun 06 14:31:00 1999
From: <shysavanna@webtv.net>
To: egcs@cygnus.com
Subject: Sparetime income from home, Start your own business using your computer
Date: Sun, 06 Jun 1999 14:31:00 -0000
Message-id: <14835.928704691.0@NO-ID-FOUND.mhonarc.com>
X-SW-Source: 1999-06/msg00157.html
Content-length: 1561

  Make $1,250-$2,000 A Week, Start your own profitable internet 
business.

   Tired of the dead-end nine to five world in which you're 
working? There is a way out: A home-based business. If you're 
looking for the home business opportunity that's just right for 
you, you'll want the valuable information we have to offer
   
  Whether you are looking for an opportunity to earn a little 
extra spending money or you are looking for a way out of the 
nine-to-five rat race, you'll find this information to be exactly 
what you need to help you get started.

  You'll learn how to start your own business on the internet.

  Have you ever dreamed of waking up in the morning, getting your 
cup of coffee, reading the morning paper and then walking over to 
your computer to see how much money you made last night while you 
were asleep?

  We'll show you how to start your business from start to finish 
on the internet.

  FOR FREE DETAILS: Send name and address to: ONTIMEPUBL@AOL.COM

  
  
Please give name and address. Your request will be processed 
within 24 hours of receiving.          


Cordially,

Ted Rankin
Advertising Account Executive



-----------------------------------------------------------------
This message is sent in compliance of the new email bill section 
301. Per section 301 paragraph (a)(2)(c) of S.1618, Further 
transmissions to you by the sender of this email may be stopped 
at no cost to you by clicking reply and type remove in the 
subject line. Your request will be processed within 24 hours.
 
 
 
 
 
 
 
 
 
 
 
 
 
>From peeter@aia.tartu.ee Sun Jun 06 16:08:00 1999
From: Peeter Russak <peeter@aia.tartu.ee>
To: egcs-bugs@egcs.cygnus.com
Subject: maybe another one....
Date: Sun, 06 Jun 1999 16:08:00 -0000
Message-id: <199906062307.CAA29104@server.aia.tartu.ee>
X-SW-Source: 1999-06/msg00158.html
Content-length: 979

That's what he said when compiling qt-2.00beta1-snapshot-19990605.tar.gz:

g++ -c -I/home/marie/pezz/koffice/qt-public-cvs/include -I/usr/X11R6/include
-pipe -DNO_DEBUG -O2 -fPIC -I3rdparty/zlib -I3rdparty/libpng  -o
widgets/qlistview.o widgets/qlistview.cpp
widgets/qlistview.cpp: In method `Void QListView::keyPressEvent(class
QKeyEvent *)':
widgets/qlistview.cpp:2921: Internal compiler error.
widgets/qlistview.cpp:2921: Please submit a full bug report to
`egcs-bugs@egcs.cygnus.com'.
widgets/qlistview.cpp:2921: See
<URL: http://egcs.cygnus.com/faq.html#bugreport > for details.
cpp: output pipe has been closed
make[1]: *** [widgets/qlistview.o] Error 1
make[1]: Leaving directory /home/marie/pezz/koffice/qt-public-cvs/src'
make: *** [src] Error 2

Machine is amd133 with RedHat6.0
[marie@marie qt-public-cvs]$ rpm -q egcs
egcs-1.1.2-12
[marie@marie qt-public-cvs]$ uname -a
Linux marie 2.3.4 #1 Tue Jun 1 11:42:12 EEST 1999 i486 unknown


-- 
Peeter(peeter@aia.tartu.ee)
>From oliva@dcc.unicamp.br Sun Jun 06 16:51:00 1999
From: Alexandre Oliva <oliva@dcc.unicamp.br>
To: craig@jcb-sc.com
Cc: egcs-testresults@egcs.cygnus.com, egcs-bugs@egcs.cygnus.com
Subject: Re: Results for gcc-2.95 19990602 (prerelease) testsuite on sparc-sun-sunos4.1.3
Date: Sun, 06 Jun 1999 16:51:00 -0000
Message-id: <oremjoopri.fsf@tigre.dcc.unicamp.br>
References: <199906051030.HAA28328@araguaia.dcc.unicamp.br> <19990605161649.1016.qmail@deer>
X-SW-Source: 1999-06/msg00159.html
Content-length: 816

On Jun  5, 1999, craig@jcb-sc.com wrote:

>> FAIL: g77.f-torture/execute/u77-test.f compilation,  -O2 -fomit-frame-pointer -finline-functions -funroll-loops 

> This looks like a new failure to me.  It might be spurious, or it
> could indicate a (very recent?) bug in the gcc back end.  Possibly
> even something weird in the g77 front end, of course.  Could someone
> investigate?

My log says the compiler timed out :-(

In fact, `time' says f771 took 1'12'' to compile this testcase with
these flags on this poor SPARCstation2 :-(

-- 
Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il
{oliva,Alexandre.Oliva}@dcc.unicamp.br  aoliva@{acm.org,computer.org}
oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org}
*** E-mail about software projects will be forwarded to mailing lists

Re: bugreport

[Martin v. Loewis]

> asked me to send a bugreport

Thanks for your bug report. gcc-2.95 19990529 compiles it just fine,
so it seems that the bug has been fixed. In fact, the most recent
report on CXX did not complain about not compiling, anymore - it
complained about compiling too slowly.

Regards,
Martin
>From jimr@nsasearch.com Sat Jun 05 15:12:00 1999
From: "Jim Ristuccia"<jimr@nsasearch.com>
To: "listarch-egcs-bugs@egcs.cygnus.com "<listarch-egcs-bugs@egcs.cygnus.com>
Subject: Can you help me?
Date: Sat, 05 Jun 1999 15:12:00 -0000
Message-id: <199906052214.PAA14659@mail.ixpres.com>
X-SW-Source: 1999-06/msg00148.html
Content-length: 1947

I am working on some projects in wireless broadband access.  As a recruiter with an executive search firm, I am writing to ask for your help in a set of recruitment searches currently in progress.   I came upon your name in the course of some of my research and was hoping that you might have a perspective on my assignment.

Unlike an unannounced telephone call, e-mail seems to allow the kind of passive contact that can be invaluable in business; it allows a response when it is convenient?. However, I am sensitive to work priorities and if you would prefer that I not contact you in the future, or that I use a different address, please let me know.

My office is working with a variety of companies across the Telecom industry, but I am primarily writing about several software and hardware engineering positions that I am working on. 

I have several venture capital backed start-ups in both California and Northern Virginia that are growing fast and looking for talented engineering talent.   

The Hardware positions require experience developing FPGA/CPLD and board designs, knowledge of Motorola and Intel processors and WAN interfaces. High-speed digital board design for Telecom applications (T1, DS-3, OC-3, xDSL, etc?) desired. 

The Software positions require expertise with control and management software design. Requires skills in embedded software development, with expertise in C/C++ with database knowledge and an understanding of SNMP, VxWorks and MIBs. Understanding of routing, switching and bridging a plus.

Any help you can give me, in either locating qualified individuals for these roles or potential places to look, would be most appreciated. Additional, I would welcome an opportunity to speak with you directly if you have time in your schedule 

Thank you very much and best regards,

Jim Ristuccia
Director
National Search Associates
(760) 431-1750 x104
(760) 431-7078 fax
jimr@nsasearch.com
www.nsasearch.com

bugreport

[Max Gilead]

Hi.

While compiling Crystal Space a bug was found

Can't provide the compiler output but it was in line 43 of the attached
file (internal compiler error 191).

I am using newly-installed RH Linux  6.0
Max

Re: bugreport

[Alexandre Oliva]

On May 31, 1999, Max Gilead <gilead@linart.krakow.pl> wrote:

> Can't provide the compiler output

Why not?

> but it was in line 43 of the attached file (internal compiler error
> 191).

This is not enough for us to reproduce the bug, since this file
includes a dozen of other files, all of which may affect the outcome.
Please read http://egcs.cygnus.com/faq.html#bugreport

-- 
Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il
{oliva,Alexandre.Oliva}@dcc.unicamp.br  aoliva@{acm.org,computer.org}
oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org}
*** E-mail about software projects will be forwarded to mailing lists

Re: Bugreport

[Alexandre Oliva]

On Feb  8, 1999, Oliver Kohlbacher <oliver@mpi-sb.mpg.de> wrote:

> 		void foo(A<T1, T2>::EnumType = A<T1, T2>::VALUE) {};
                        ^^ `typename' is missing here

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

Bugreport

[Oliver Kohlbacher]

Hi,

I have to report another bug in egcs 1.1.1, but I suppose a rather rare one.
I tried to compile the following code (attachment) using egcs 1.1.1 under 
Solaris 2.6/SPARC. It doesn't compile because egcs complains about a parse
error. If the two test classes A and B are template classes that only take
one parameter, everything works fine. Just template classes using two or more 
(I tested 2, 3, 4) parameters won't compile.

Regards,
 Oliver Kohlbacher
------
Compiler/System data:
gcc version egcs-2.91.60 19981201 (egcs-1.1.1 release)
running under Solaris 2.6 on a SUN Ultra1/SPARC
------
template <class T1, class T2>
class A {
	public:
		enum EnumType {
			VALUE = 1
		};
};

template <class T1, class T2>
class B {
	public:
		void foo(A<T1, T2>::EnumType = A<T1, T2>::VALUE) {};
};

int main() {
	return 0;
}

Re: Bugreport

[Jeffrey A Law]

  In message < 000701be4d51$13bd10c0$0858fd91@default >you write:
  > This is a multi-part message in MIME format.
  > 
  > ------=_NextPart_000_0004_01BE4D59.236E1E80
  > Content-Type: text/plain;
  > 	charset="iso-8859-1"
  > Content-Transfer-Encoding: quoted-printable
  > 
  > Hi,
  > here is my bugreport. gcc-2.7.2.1 compiles the files without any =
  > problems.
Please read the FAQ.
jeff

Bugreport

[Benno Tietz]

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

Hi,
here is my bugreport. gcc-2.7.2.1 
compiles the files without any problems.
Benno Tietz
 
BYW: Thnx for producing such a good 
compiler.
 
 
Compiler version:
 
batty:/home/benno/hyatt/16.3 # gcc 
-v Reading specs from 
/usr/local/lib/gcc-lib/i586-pc-linux-gnulibc1/egcs-2.93.04/specs
 
gcc version egcs-2.93.04 19990131 
(gcc2 ss-980929 experimental) 
 
File producing 
trouble:
 
========= ut.i 
============= typedef struct {  unsigned long fds_bits [(1024 / (8 * 
sizeof(unsigned long)) ) ]; } __kernel_fd_set;
 
int CheckInput(void) {   
__kernel_fd_set readfds;
 
  __asm__ __volatile__("cld 
; rep ; stosl" :"=m" (*(__kernel_fd_set *) (  
&readfds  )) :"a" (0), "c" ((1024 / (8 * 
sizeof(unsigned long)) ) ), "D" ((__kernel_fd_set *) (  
&readfds  )) :"cx","di")  
; } ============================
 
Command-line option:
 
batty:/home/benno/hyatt/16.3 # 
gcc  -O2 -c ut.i ut.i: In function `CheckInput': ut.i:8: Invalid 
`asm' statement: ut.i:8: fixed or forbidden register 2 (cx) was spilled for 
class CREG.
 
Machine-type:
 
AMD K6-2 running Linux 
2.0.35
 
Compiler building:
 
./configure 
--enable-haifa
 
 

Re: bugreport

[Gerald Pfeifer]

On Tue, 8 Sep 1998, Magnus Drougge wrote:
> Can you point me to a bug-report specification?

Please try

  info -f /sw/swtest/egcs/info/gcc.info Bug Reporting

(where you replace that /sw/swtest/... part by your actual path).

Gerald
-- 
Gerald Pfeifer (Jerry)      Vienna University of Technology
pfeifer@dbai.tuwien.ac.at   http://www.dbai.tuwien.ac.at/~pfeifer/

bugreport

[Magnus Drougge]

Well, I got the following message.
Can you point me to a bug-report specification?
Obviously, this is not enough...

kapp.cpp: In method `void KApplication::parseCommandLine(int &, char **)':
kapp.cpp:752: Internal compiler error.
kapp.cpp:752: Please submit a full bug report to `egcs-bugs@cygnus.com'.

/Drougge