public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* Re: Bugreport
1999-07-31 23:33 Bugreport Max Weninger
@ 1999-07-16 3:13 ` Nathan Sidwell
0 siblings, 0 replies; 23+ messages in thread
From: Nathan Sidwell @ 1999-07-16 3:13 UTC (permalink / raw)
To: Max Weninger; +Cc: egcs-bugs
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
^ permalink raw reply [flat|nested] 23+ messages in thread
* Bugreport
@ 1999-07-31 23:33 Max Weninger
1999-07-16 3:13 ` Bugreport Nathan Sidwell
0 siblings, 1 reply; 23+ messages in thread
From: Max Weninger @ 1999-07-31 23:33 UTC (permalink / raw)
To: egcs-bugs
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
.-|
_________._|____________________________________________________
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: bugreport
2003-10-31 15:14 bugreport Jean-Pierre.Flament
@ 2003-10-31 22:06 ` Toon Moene
0 siblings, 0 replies; 23+ messages in thread
From: Toon Moene @ 2003-10-31 22:06 UTC (permalink / raw)
To: Jean-Pierre.Flament; +Cc: gcc-bugs
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)
^ permalink raw reply [flat|nested] 23+ messages in thread
* bugreport
@ 2003-10-31 15:14 Jean-Pierre.Flament
2003-10-31 22:06 ` bugreport Toon Moene
0 siblings, 1 reply; 23+ messages in thread
From: Jean-Pierre.Flament @ 2003-10-31 15:14 UTC (permalink / raw)
To: gcc-bugs
[-- 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
^ permalink raw reply [flat|nested] 23+ messages in thread
* bugreport
@ 2000-04-01 12:43 ggg
0 siblings, 0 replies; 23+ messages in thread
From: ggg @ 2000-04-01 12:43 UTC (permalink / raw)
To: egcs-bugs
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)
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: bugreport
1999-09-30 19:57 bugreport Dietmar Schaefer
@ 1999-11-04 13:16 ` Alexandre Oliva
0 siblings, 0 replies; 23+ messages in thread
From: Alexandre Oliva @ 1999-11-04 13:16 UTC (permalink / raw)
To: Dietmar Schaefer; +Cc: bug-gcc
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
^ permalink raw reply [flat|nested] 23+ messages in thread
* bugreport
@ 1999-09-30 19:57 Dietmar Schaefer
1999-11-04 13:16 ` bugreport Alexandre Oliva
0 siblings, 1 reply; 23+ messages in thread
From: Dietmar Schaefer @ 1999-09-30 19:57 UTC (permalink / raw)
To: bug-gcc
[-- 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 --]
^ permalink raw reply [flat|nested] 23+ messages in thread
* Bugreport
@ 1999-09-01 6:22 Christian Wichert
0 siblings, 0 replies; 23+ messages in thread
From: Christian Wichert @ 1999-09-01 6:22 UTC (permalink / raw)
To: gcc-bugs
[-- 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.
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: bugreport
1999-06-06 3:55 ` bugreport Berthold Höllmann
@ 1999-06-30 23:07 ` Martin v. Loewis
0 siblings, 0 replies; 23+ messages in thread
From: Martin v. Loewis @ 1999-06-30 23:07 UTC (permalink / raw)
To: bhoel; +Cc: egcs-bugs
> 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
^ permalink raw reply [flat|nested] 23+ messages in thread
* Bugreport
@ 1999-06-30 23:07 Simon Thum
1999-06-22 22:54 ` Bugreport Alexandre Oliva
0 siblings, 1 reply; 23+ messages in thread
From: Simon Thum @ 1999-06-30 23:07 UTC (permalink / raw)
To: egcs-bugs
[-- 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.
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: bugreport
1999-06-05 15:08 ` bugreport Martin v. Loewis
1999-06-06 3:55 ` bugreport Berthold Höllmann
@ 1999-06-30 23:07 ` Berthold Höllmann
1 sibling, 0 replies; 23+ messages in thread
From: Berthold Höllmann @ 1999-06-30 23:07 UTC (permalink / raw)
To: Martin v. Loewis; +Cc: egcs-bugs
"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.
^ permalink raw reply [flat|nested] 23+ messages in thread
* bugreport
@ 1999-06-30 23:07 Berthold Höllmann
1999-06-05 15:08 ` bugreport Martin v. Loewis
0 siblings, 1 reply; 23+ messages in thread
From: Berthold Höllmann @ 1999-06-30 23:07 UTC (permalink / raw)
To: egcs-bugs
[-- 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 --]
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Bugreport
1999-06-30 23:07 Bugreport Simon Thum
@ 1999-06-22 22:54 ` Alexandre Oliva
0 siblings, 0 replies; 23+ messages in thread
From: Alexandre Oliva @ 1999-06-22 22:54 UTC (permalink / raw)
To: Simon Thum; +Cc: egcs-bugs
[-- 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
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: bugreport
1999-06-05 15:08 ` bugreport Martin v. Loewis
@ 1999-06-06 3:55 ` Berthold Höllmann
1999-06-30 23:07 ` bugreport Martin v. Loewis
1999-06-30 23:07 ` bugreport Berthold Höllmann
1 sibling, 1 reply; 23+ messages in thread
From: Berthold Höllmann @ 1999-06-06 3:55 UTC (permalink / raw)
To: Martin v. Loewis; +Cc: egcs-bugs
[-- 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
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: bugreport
1999-06-30 23:07 bugreport Berthold Höllmann
@ 1999-06-05 15:08 ` Martin v. Loewis
1999-06-06 3:55 ` bugreport Berthold Höllmann
1999-06-30 23:07 ` bugreport Berthold Höllmann
0 siblings, 2 replies; 23+ messages in thread
From: Martin v. Loewis @ 1999-06-05 15:08 UTC (permalink / raw)
To: bhoel; +Cc: egcs-bugs
> 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
^ permalink raw reply [flat|nested] 23+ messages in thread
* bugreport
@ 1999-05-31 21:06 Max Gilead
1999-05-31 18:45 ` bugreport Alexandre Oliva
0 siblings, 1 reply; 23+ messages in thread
From: Max Gilead @ 1999-05-31 21:06 UTC (permalink / raw)
To: egcs-bugs
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
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: bugreport
1999-05-31 21:06 bugreport Max Gilead
@ 1999-05-31 18:45 ` Alexandre Oliva
0 siblings, 0 replies; 23+ messages in thread
From: Alexandre Oliva @ 1999-05-31 18:45 UTC (permalink / raw)
To: gilead; +Cc: egcs-bugs
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
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Bugreport
1999-02-08 12:11 Bugreport Oliver Kohlbacher
@ 1999-02-08 12:42 ` Alexandre Oliva
0 siblings, 0 replies; 23+ messages in thread
From: Alexandre Oliva @ 1999-02-08 12:42 UTC (permalink / raw)
To: Oliver Kohlbacher; +Cc: egcs-bugs
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
^ permalink raw reply [flat|nested] 23+ messages in thread
* Bugreport
@ 1999-02-08 12:11 Oliver Kohlbacher
1999-02-08 12:42 ` Bugreport Alexandre Oliva
0 siblings, 1 reply; 23+ messages in thread
From: Oliver Kohlbacher @ 1999-02-08 12:11 UTC (permalink / raw)
To: egcs-bugs
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;
}
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Bugreport
1999-01-31 11:40 Bugreport Benno Tietz
@ 1999-01-31 20:04 ` Jeffrey A Law
0 siblings, 0 replies; 23+ messages in thread
From: Jeffrey A Law @ 1999-01-31 20:04 UTC (permalink / raw)
To: Benno Tietz; +Cc: egcs-bugs
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
^ permalink raw reply [flat|nested] 23+ messages in thread
* Bugreport
@ 1999-01-31 11:40 Benno Tietz
1999-01-31 20:04 ` Bugreport Jeffrey A Law
0 siblings, 1 reply; 23+ messages in thread
From: Benno Tietz @ 1999-01-31 11:40 UTC (permalink / raw)
To: egcs-bugs
[-- 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
Â
Â
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: bugreport
1998-09-07 22:57 bugreport Magnus Drougge
@ 1998-09-08 1:05 ` Gerald Pfeifer
0 siblings, 0 replies; 23+ messages in thread
From: Gerald Pfeifer @ 1998-09-08 1:05 UTC (permalink / raw)
To: Magnus Drougge; +Cc: egcs-bugs
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/
^ permalink raw reply [flat|nested] 23+ messages in thread
* bugreport
@ 1998-09-07 22:57 Magnus Drougge
1998-09-08 1:05 ` bugreport Gerald Pfeifer
0 siblings, 1 reply; 23+ messages in thread
From: Magnus Drougge @ 1998-09-07 22:57 UTC (permalink / raw)
To: egcs-bugs
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
^ permalink raw reply [flat|nested] 23+ messages in thread
end of thread, other threads:[~2003-10-31 22:05 UTC | newest]
Thread overview: 23+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1999-07-31 23:33 Bugreport Max Weninger
1999-07-16 3:13 ` Bugreport Nathan Sidwell
-- strict thread matches above, loose matches on Subject: below --
2003-10-31 15:14 bugreport Jean-Pierre.Flament
2003-10-31 22:06 ` bugreport Toon Moene
2000-04-01 12:43 bugreport ggg
1999-09-30 19:57 bugreport Dietmar Schaefer
1999-11-04 13:16 ` bugreport Alexandre Oliva
1999-09-01 6:22 Bugreport Christian Wichert
1999-06-30 23:07 Bugreport Simon Thum
1999-06-22 22:54 ` Bugreport Alexandre Oliva
1999-06-30 23:07 bugreport Berthold Höllmann
1999-06-05 15:08 ` bugreport Martin v. Loewis
1999-06-06 3:55 ` bugreport Berthold Höllmann
1999-06-30 23:07 ` bugreport Martin v. Loewis
1999-06-30 23:07 ` bugreport Berthold Höllmann
1999-05-31 21:06 bugreport Max Gilead
1999-05-31 18:45 ` bugreport Alexandre Oliva
1999-02-08 12:11 Bugreport Oliver Kohlbacher
1999-02-08 12:42 ` Bugreport Alexandre Oliva
1999-01-31 11:40 Bugreport Benno Tietz
1999-01-31 20:04 ` Bugreport Jeffrey A Law
1998-09-07 22:57 bugreport Magnus Drougge
1998-09-08 1:05 ` bugreport Gerald Pfeifer
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).