From mboxrd@z Thu Jan 1 00:00:00 1970 From: Manfred Maennle To: egcs-bugs@egcs.cygnus.com Subject: bug report Date: Tue, 06 Jul 1999 07:53:00 -0000 Message-id: X-SW-Source: 1999-07/msg00203.html List-Id: Hi, I want to submit you the following bug report of an internal compiler error in the function fata_insn that I did not find in the list of known bugs. Here's the command line: i81s1:/home/i8fs1/maennle/fzymodel/fzymodel-1.1/src>g++ -v --save-temps -DFLOAT -Wall -pedantic -O -DTNT_NO_BOUNDS_CHECK -DNDEBUG -I/home/i8fs1/maennle/local/include -I/home/i8fs1/wilhelmi/local/include fmodel.cc Reading specs from /home/i8fs1/wilhelmi/local/lib/gcc-lib/sparc-sun-solaris2.5/egcs-2.91.66/specs gcc version egcs-2.91.66 19990314 (egcs-1.1.2 release) /home/i8fs1/wilhelmi/local/lib/gcc-lib/sparc-sun-solaris2.5/egcs-2.91.66/cpp -lang-c++ -v -I/home/i8fs1/maennle/local/include -I/home/i8fs1/wilhelmi/local/include -undef -D__GNUC__=2 -D__GNUG__=2 -D__cplusplus -D__GNUC_MINOR__=91 -Dsparc -Dsun -Dunix -D_ _svr4__ -D__SVR4 -D__sparc__ -D__sun__ -D__unix__ -D__svr4__ -D__SVR4 -D__sparc -D__sun -D__unix -Asystem(unix) -Asystem(svr4) -D__EXCEPTIONS -D__OPTIMIZE__ -Wall -pedantic -D__GCC_NEW_VARARGS__ -Acpu(sparc) -Amachine(sparc) -DFLOAT -DTNT_NO_BOUNDS_CHECK -DNDEBUG fmodel.cc fmodel.ii GNU CPP version egcs-2.91.66 19990314 (egcs-1.1.2 release) (sparc) #include "..." search starts here: #include <...> search starts here: /home/i8fs1/maennle/local/include /home/i8fs1/wilhelmi/local/include /home/i8fs1/wilhelmi/local/include/g++ /home/i8fs1/wilhelmi/local/sparc-sun-solaris2.5/include /home/i8fs1/wilhelmi/local/lib/gcc-lib/sparc-sun-solaris2.5/egcs-2.91.66/include /usr/include End of search list. /home/i8fs1/wilhelmi/local/lib/gcc-lib/sparc-sun-solaris2.5/egcs-2.91.66/cc1plus fmodel.ii -quiet -dumpbase fmodel.cc -O -Wall -pedantic -version -o fmodel.s GNU C++ version egcs-2.91.66 19990314 (egcs-1.1.2 release) (sparc-sun-solaris2.5) compiled by GNU C version egcs-2.91.66 19990314 (egcs-1.1.2 release). fmodel.cc: In method `Real FModel::optimize_RPROP(const class Data &, const class Data &)': fmodel.cc:608: internal error--unrecognizable insn: (insn 1618 2535 1620 (set (mem:SI (reg:SI 650)) (plus:SI (mem:SI (reg:SI 648)) (const_int -1))) -1 (insn_list 2532 (insn_list 2535 (nil))) (expr_list:REG_DEAD (reg:SI 648) (expr_list:REG_DEAD (reg:SI 650) (nil)))) /home/i8fs1/wilhelmi/egcs-1.1.2/gcc/toplev.c:1367: Internal compiler error in function fatal_insn Here's my system (Solaris 2.5): i81s1:/home/i8fs1/maennle/fzymodel/fzymodel-1.1/src>uname -a SunOS i81s1 5.5 Generic sun4u sparc SUNW,Ultra-1 Find the files fmodel.cc and fmodel.ii gzipped and attached to this mail. Surprisingly, the error does NOT occur when 1) omitting the -O option, or 2) commenting out line 602 ("--iteration") in fmodel.cc (which then also works with -O, -O2, or -O3) Thanks for improving the compiler, bye, Manfred -- Manfred Maennle, University of Karlsruhe, Germany phone: +49 721 608-6323, fax: +49 721 608-3962 homepage: http://goethe.ira.uka.de/people/maennle email: maennle@computer.org --pgp key available-- >>From craig@jcb-sc.com Tue Jul 06 07:58:00 1999 From: craig@jcb-sc.com To: bug-gdb@gnu.org Cc: craig@jcb-sc.com Subject: Re: g77/gdb and complex numbers. Date: Tue, 06 Jul 1999 07:58:00 -0000 Message-id: <19990706145754.5656.qmail@deer> References: <19990706133229.A389@shef.ac.uk> X-SW-Source: 1999-07/msg00204.html Content-length: 4599 [bug-gdb: In case this hasn't already been reported, gdb 4.18 doesn't print Fortran complex numbers correctly, as shown below. Another rare case of a g77/gdb problem that seems to be a gdb problem (most of them are g77 problems, or at least mostly so).] > Yesterday, I posted to comp.lang.fortran a query about how the >g77/gdb duo treat complex numbers. Basically, I cannot inspect complex >number arrays (or single complex variables). Also, in this sort of test >programs, I cannot redirect my output to the console. print* -statements >print fine on gdb, but when executed from the pront, I just get a clean >prompt again. This is the test program: >(gdb) p carr >$1 = (Invalid F77 type code 3 in symbol table. >(gdb) p carr(1) >$2 = Invalid F77 type code 3 in symbol table. I believe those diagnostics are due to the g77 option `-femulate-complex' being the default in EGCS versions 1.0 and 1.1. In the soon-to-be-released EGCS 1.2, which has been renamed GCC 2.95, `-fno-emulate-complex' is now the default, as we believe the remaining back-end bugs affecting "native" complex types have been fixed. The good news is, this should cause gdb to recognize COMPLEX numbers. The bad news is, it seems gdb doesn't print them correctly -- it prints the real value twice, instead of the real value then the imaginary value. Enclosed below is a gdb session that shows this. > Also, why with this short program, and running it in the console, I >get no output whatsoever? I don't know what "running it in the console" means in this context -- it works fine for me, running it from my shell (bash), on my Redhat Linux 5.2 system. tq vm, (burley) Current directory is ~/gnu/play/ GNU gdb 4.18 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-linux-gnu"... (gdb) break 18 Breakpoint 1 at 0x804c074: file ../../../../egcs-19990629/libf2c/libF77/main.c, line 18. (gdb) delete 1 (gdb) break complex.f:18 Breakpoint 2 at 0x8048d50: file complex.f, line 18. (gdb) r Starting program: /home3/craig/gnu/play/a.out Breakpoint 2, MAIN__ () at complex.f:28 Current language: auto; currently fortran (gdb) c Continuing. Press a key Program received signal SIGINT, Interrupt. 0x400926f4 in read () from /lib/libc.so.6 (gdb) b complex.f:39 Breakpoint 3 at 0x8048eff: file complex.f, line 39. (gdb) c Continuing. k Values of carr Complex Value Real Part Imaginary Part 0.0000 9.0000 .0000E+00 0.9000E+01 1.0000 8.0000 .1000E+01 0.8000E+01 2.0000 7.0000 .2000E+01 0.7000E+01 3.0000 6.0000 .3000E+01 0.6000E+01 4.0000 5.0000 .4000E+01 0.5000E+01 5.0000 4.0000 .5000E+01 0.4000E+01 6.0000 3.0000 .6000E+01 0.3000E+01 7.0000 2.0000 .7000E+01 0.2000E+01 8.0000 1.0000 .8000E+01 0.1000E+01 9.0000 0.0000 .9000E+01 0.0000E+00 Breakpoint 3, MAIN__ () at complex.f:39 (gdb) p carr $1 = ((0,0), (1,1), (2,2), (3,3), (4,4), (5,5), (6,6), (7,7), (8,8), (9,9)) (gdb) p drpart $2 = (0, 1, 2, 3, 4, 5, 6, 7, 8, 9) (gdb) p dimag $3 = (9, 8, 7, 6, 5, 4, 3, 2, 1, 0) (gdb) set lang c Warning: the current language does not match this frame. (gdb) p carr $4 = {Invalid C/C++ type code 20 in symbol table. (gdb) set lang default Unknown language `default'. (gdb) set lang The currently understood settings are: local or auto Automatic setting based on source file c Use the C language c++ Use the C++ language asm Use the Asm language chill Use the Chill language fortran Use the Fortran language java Use the Java language modula-2 Use the Modula-2 language scheme Use the Scheme language (gdb) set lang auto (gdb) p carr $5 = ((0,0), (1,1), (2,2), (3,3), (4,4), (5,5), (6,6), (7,7), (8,8), (9,9)) (gdb) p carr(1) $6 = (0,0) (gdb) p imag(carr(1)) No symbol "imag" in current context. (gdb) p aimag(carr(1)) No symbol "aimag" in current context. (gdb) set lang c (gdb) p &carr[0] $7 = (complex *) 0xbffffc58 (gdb) p *$ $8 = Invalid C/C++ type code 20 in symbol table. (gdb) p (float *) $7 $9 = (float *) 0xbffffc58 (gdb) p $9[0] $10 = 0 (gdb) p $9[1] $11 = 9 (gdb) p $9[2] $12 = 1 (gdb) p $9[3] $13 = 8 (gdb) p $9[4] $14 = 2 (gdb) p $9[5] $15 = 7 (gdb) quit The program is running. Exit anyway? (y or n) y Debugger finished >>From donn@interix.com Tue Jul 06 08:51:00 1999 From: Donn Terry To: harald.harders@dlr.de Cc: egcs-bugs@egcs.cygnus.com Subject: Re: Suggestion: empty lines between errors and warnings Date: Tue, 06 Jul 1999 08:51:00 -0000 Message-id: <3782247A.72C7BCE3@interix.com> References: X-SW-Source: 1999-07/msg00205.html Content-length: 2590 I have mixed feelings about this, and wanted to make an alternate suggestion. First, I agree that reading multiline error messages can be difficult because of the visual clutter, and that something like line separators would help. On the other hand, getting more on a single screenful is also helpful, and separators work against that (particularly in the case of single-line messages). So, how about two "goal" rules for new or revised messages? 1) Allowing for the interpolation of a reasonably long identifier (say, 15 characters), no single line of an error message should exceed 80 characters in width. 2) All lines but the first of an error message should be indented a few (2?) characters. In the example below, I've also included a | in the first column, which might make it much more effective in the face of varying width of the filename/line prefix. Thus errors would look like: :: blather fjkdlsa fj b more blather identifier. :: | extended blather on a related topic :: | and to really emphasize your coding error. :: grumpiness on some new topic. The goal is to provide a visual clue as to where a given message starts and ends, without taking up much more space. (I can live with it the way it is, but I wanted to suggest this as an alternative to blank lines.) Donn Harald Harders wrote: > > Dear egcs developer. > > This is not really an error report but rather a suggestion. > > In C++ with egcs (egcs-2.91.66 19990314 (egcs-1.1.2 release)) error > messages and warnings are sometimes very long over a couple of lines. So > reading them is confusing. > It would make it easier to understand an seperate them by an empty line > between different messages. > > Is it possible to add this feature for C++. In C and Fortran this is not > necessary since there the messages are shorter. > > Yours > Harald > > -- > __/|__ Harald Harders Mail: harald.harders@dlr.de > /_/_/_/ DLR Tel.: (05 31) 2 95 - 26 78 > |/ Institut fuer Flugmechanik Fax.: (05 31) 2 95 - 26 47 > DLR Lilienthalplatz 7 http://www.fm.bs.dlr.de/flugmechanik/ > D-38108 Braunschweig http://mbpc06.mb.ing.tu-bs.de/~harders/ -- =================================================== Donn Terry mailto:donn@interix.com Softway Systems, Inc. http://www.interix.com 2850 McClelland Dr, Ste. 1800 Ft.Collins CO 80525 Tel: +1-970-204-9900 Fax: +1-970-204-9951 =================================================== >>From mrs@wrs.com Tue Jul 06 09:20:00 1999 From: mrs@wrs.com (Mike Stump) To: hpreg@vmware.com Cc: egcs-bugs@egcs.cygnus.com, mts@vmware.com Subject: Re: egcs-2.91.66 bug (Debian potato) Date: Tue, 06 Jul 1999 09:20:00 -0000 Message-id: <199907061620.JAA11162@kankakee.wrs.com> X-SW-Source: 1999-07/msg00206.html Content-length: 472 > From: Regis Duchesne > Date: 02 Jul 1999 18:06:13 -0700 > mrs@wrs.com (Mike Stump) writes: > > Try -fno-strict-aliasing. If that cures the `problem', > It unfortunately does not cure the problem > > then I think the problem is a lack of understanding C. > Isn't the role of _a C compiler_ to understand C ? :) :-) Yes, this is a dwim feature. I think long term the compiler should be more dwimesque, but for now, you have to play by the rules. >>From pal@cs.brown.edu Tue Jul 06 09:38:00 1999 From: Phil Levis To: egcs-bugs@egcs.cygnus.com Subject: egcs internal compiler error Date: Tue, 06 Jul 1999 09:38:00 -0000 Message-id: X-SW-Source: 1999-07/msg00207.html Content-length: 237 I obtained an internal compiler error after a small modification was made to a file (a loop was split to two different loops). It compiles without all of the optimization flags I'm using. Enclosed is the compilation log/.ii file. Phil >>From rth@cygnus.com Tue Jul 06 10:24:00 1999 From: Richard Henderson To: Alexandre Oliva Cc: egcs-bugs@egcs.cygnus.com Subject: Re: shared libstdc++ is broken on alphaev56-dec-osf4.0d Date: Tue, 06 Jul 1999 10:24:00 -0000 Message-id: <19990706102351.A2416@cygnus.com> References: X-SW-Source: 1999-07/msg00208.html Content-length: 772 On Mon, Jul 05, 1999 at 10:52:02AM -0300, Alexandre Oliva wrote: > Richard, it seems that the following patch broke shared library > construction on alpha-dec-osf4.0: > > Mon Jun 21 20:10:42 1999 Richard Henderson > > * collect2.c (main): Log frame table count. > (GCC_OK_SYMBOL) [ECOFF]: Accept stGlobal. > (scan_prog_file) [COFF]: Handle frame tables. Without this patch, absolutely no EH works, staticly linked or otherwise. > FAIL: g++.brendan/nest21.C (test for excess errors) > /usr/bin/ld: > /usr/local/tmp/egcs/gcc/libgcc.a(_eh.o): \ > _GLOBAL_$F$__default_terminate: multiply defined So we need to somehow prevent libgcc symbols from being exported from the shared library. I don't know DU well enough to know if that's possible. r~ >>From fischegm@wooster.edu Tue Jul 06 11:08:00 1999 From: Greyson Fischer To: egcs-bugs@egcs.cygnus.com Subject: Error report Date: Tue, 06 Jul 1999 11:08:00 -0000 Message-id: <99070614090800.00373@greyson> X-SW-Source: 1999-07/msg00209.html Content-length: 716 While compiling some source files that I cannot display or send due to NDAs, I found the following error. Although there is nothing serious about it, if a struct is declared without a closing brace and a semi-colon, an internal error is reported with the instructions to write here... I thought that since it is just a simple typematic error that the compiler should give an error like (parse error before ';' ) instead of: FPObj.h:274: Internal compiler error. FPObj.h:274: Please submit a full bug report to `egcs-bugs@egcs.cygnus.com'. FPObj.h:274: See for details. I'm using egcs-2.91.66 that came with a SuSE 6.1 distribution installed on a Pentium ][. >>From mrs@wrs.com Tue Jul 06 11:13:00 1999 From: mrs@wrs.com (Mike Stump) To: egcs-bugs@egcs.cygnus.com, ronis@onsager.chem.mcgill.ca Subject: Re: Build Failure for gcc-2.96 19990705 (experimental) Date: Tue, 06 Jul 1999 11:13:00 -0000 Message-id: <199907061813.LAA16995@kankakee.wrs.com> X-SW-Source: 1999-07/msg00210.html Content-length: 56 Your build wasn't clean enough. Just try make again... >>From mitr@email.cz Tue Jul 06 11:38:00 1999 From: mitr@email.cz To: egcs-bugs@egcs.cygnus.com Subject: Too optimized and not so much optimized code Date: Tue, 06 Jul 1999 11:38:00 -0000 Message-id: <990706203539RP.08049@tajfun.atc.cz> X-SW-Source: 1999-07/msg00211.html Content-length: 1590 I came across a bit strange egcs-1.1.2 behaviour ----------------------------- $ cat > tst.c ----------------------------- unsigned expand (char s) { unsigned x; x = 0; *(char *)&x = s; return x; } unsigned mult_256 (char s) { unsigned x; x = 0; ((char *)&x)[1] = s; return x; } ----------------------------- $ egcs -O2 -fomit-frame-pointer -S tst.c $ cat tst.s ----------------------------- .file "tst.c" .version "01.01" gcc2_compiled.: .text .align 4 .globl expand .type expand,@function expand: movl 4(%esp),%eax ret .Lfe1: .size expand,.Lfe1-expand .align 4 .globl mult_256 .type mult_256,@function mult_256: subl $4,%esp movl 8(%esp),%eax movl $0,(%esp) movb %al,1(%esp) movl (%esp),%eax popl %ecx ret .Lfe2: .size mult_256,.Lfe2-mult_256 .ident "GCC: (GNU) egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)" ------------------------------ (Yes, I know that it is not portable) 1) don't you think that expand () is overoptimized ? IMHO it should look like this: expand: movzbl 4(%esp),%eax ret 2) the mult_256 () is here for two reasons: a) it is compiled reasonably, so one would conclude that expand () should too b) instead of the last three insns the following should be generated popl %eax ret Thanks for the time you spend while developing egcs. Mirek --- CREATED BY ATC O..R..G..A..N..I..Z..E..R --- http://email.cz <--- Get Your Free Email