[Bug libfortran/31099] [4.3/4.2 regression] Runtime error on legal code using RECL
--- Comment #5 from Thomas dot Koenig at online dot de 2007-03-09 20:13
---
Subject: Re: [4.3/4.2 regression] Runtime error on legal code using RECL
I believe I have a fix. I am testing now. We were not initializing a few
things when we have a record length given.
Index: io/open.c
===
--- io/open.c (revision 122529)
+++ io/open.c (working copy)
@@ -437,6 +437,8 @@ new_unit (st_parameter_open *opp, gfc_un
{
u-flags.has_recl = 1;
u-recl = opp-recl_in;
+ u-recl_subrecord = u-recl;
+ u-bytes_left = u-recl;
}
else
{
This looks good.
Thanks, Jerry, for picking up on this so fast.
I had been sort of wondering wether I had introduced any regressions
with my subrecord patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31099
[Bug fortran/30981] a ** exp fails for integer exponents if exp is -huge()-1 (endless loop)
--- Comment #11 from Thomas dot Koenig at online dot de 2007-02-28 23:13 --- Subject: Re: a ** exp fails for integer exponents if exp is -huge()-1 (endless loop) --- Comment #10 from pinskia at gcc dot gnu dot org 2007-02-28 22:39 --- Yes declare this as undefined code and close the bug :). Alternatively, attach this patch :-) Thomas --- Comment #12 from Thomas dot Koenig at online dot de 2007-02-28 23:13 --- Created an attachment (id=13127) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13127action=view) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30981
[Bug fortran/30452] Strange syntax error with high-value character
--- Comment #3 from Thomas dot Koenig at online dot de 2007-01-13 08:42 --- Subject: Re: Strange syntax error with high-value character jvdelisle at gcc dot gnu dot org wrote: Turns out that the character 254 which is Hex FE is also the 2's complement representation of -2 which is what is used to signal an error if there is a missing delimiter. It should not be converting this to an int -2 Same thing happens for character 255, BTW. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30452
[Bug fortran/30452] Strange syntax error with high-value character
--- Comment #4 from Thomas dot Koenig at online dot de 2007-01-13 11:51 --- Subject: Re: Strange syntax error with high-value character jvdelisle at gcc dot gnu dot org wrote: Turns out that the character 254 which is Hex FE is also the 2's complement representation of -2 which is what is used to signal an error if there is a missing delimiter. It should not be converting this to an int -2 Here's a patch which fixes the testcase. Currently regtesting. --- Comment #5 from Thomas dot Koenig at online dot de 2007-01-13 11:51 --- Created an attachment (id=12895) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12895action=view) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30452
[Bug fortran/19292] [meta-bug] g77 features lacking in gfortran
--- Comment #21 from Thomas dot Koenig at online dot de 2006-05-27 20:24 --- Subject: Re: [meta-bug] g77 features lacking in gfortran sgk at troutmask dot apl dot washington dot edu wrote: 27757 does not belong in this meta-bug. It is actually a regression with respect to a version of gfortran. Do you know which version? We should mark 27757 as a regression, then. Thomas -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19292
[Bug fortran/13082] Function entries and entries with alternate returns not implemented
--- Additional Comments From Thomas dot Koenig at online dot de 2005-04-08 07:36 --- Subject: Re: Function entries and entries with alternate returns not implemented You wrote (in bugzilla): - We tried out the designed successor and found it very immature. In fact it is not even a proper FORTRAN compiler because it does not implement the standard. Then we started the usual interaction with the developers. And here things started to degrade. On one side we ignored how thin is this group of developers. So we were a bit demanding in our approach. On the other side the developers gave us the impression to not understand how serious the situation is for us. We expect that g77 will be provided by distributors for some time to come. - The moral of the story is that the developers need some help, which I cannot provide, because I am not a compiler expert (!). Neither am I. I am a chemical engineer with a working knowledge of C, Unix and Fortran. Still, I have some patches in the tree, but only in the libgfortran library (which is simple enough so I can understand most of it :), not in the compiler proper. Of course this requires some good will from the developers to check and introduce these patches. I have just recently (yesterday :-) become an official gcc developer, and I have found the people who were here before me quite helpful. For people who want to contribute, the door is open. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13082
[Bug bootstrap/20783] New: [4.1 Regression] Bootstrapping 4.1 takes 50% longer than 4.0
I just ran two parallel bootstraps of mainline and 4.0, on a single-processor Athlon XP 2600+. Configuration was with --prefix=$HOME --enable-languages=c,f95 in both cases. The 4.0 build, which finished earlier, used real58m0.437s user25m1.021s sys 1m36.735s The 4.1 build used real67m24.663s user38m19.830s sys 1m41.125s The compiler used for boostrapping was $ gcc -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc-4.1/configure --prefix=/home/ig25 --enable-languages=c,f95 Thread model: posix gcc version 4.1.0 20050402 (experimental) $ cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 6 model : 8 model name : AMD Athlon(TM) XP 2600+ stepping: 1 cpu MHz : 2083.203 cache size : 256 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmovpat pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow bogomips: 4128.76 -- Summary: [4.1 Regression] Bootstrapping 4.1 takes 50% longer than 4.0 Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: Thomas dot Koenig at online dot de CC: gcc-bugs at gcc dot gnu dot org GCC host triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20783
[Bug bootstrap/20783] [4.1 Regression] Bootstrapping 4.1 takes 50% longer than 4.0
--- Additional Comments From Thomas dot Koenig at online dot de 2005-04-06 14:21 --- This goes away when --disable-checking is specified for 4.0 and 4.1. Closing as invalid. -- What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20783
[Bug libfortran/20744] size= isn't implemented correctly
--- Additional Comments From Thomas dot Koenig at online dot de 2005-04-05 07:17 --- This is fixed with http://gcc.gnu.org/bugzilla/attachment.cgi?id=8525action=view (an attachment to PR 20661). Thomas -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20744
[Bug libfortran/20744] New: size= isn't implemented correctly
$ cat size_1.f90
! { dg-do run }
! size= isn't implemented correctly at the moment.
program main
open(77,pad='yes')
write(77,'(A)') '123'
rewind(77)
read(77,'(I2)',advance='no',size=i) j
print *,i
if (i /= 2) call abort
end program main
$ gfortran size_1.f90
$ ./a.out
0
Aborted
$ gfortran -v
Using built-in specs.
Target: ia64-unknown-linux-gnu
Configured with: ../gcc-4.1-20050403/configure --prefix=/home/zfkts
--enable-languages=c,f95
Thread model: posix
gcc version 4.1.0 20050403 (experimental)
--
Summary: size= isn't implemented correctly
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: libfortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Thomas dot Koenig at online dot de
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20744
[Bug libfortran/20744] size= isn't implemented correctly
-- What|Removed |Added Keywords||wrong-code Known to fail||4.0.0 4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20744
[Bug fortran/18481] [g77 regression] ICE with assigned integer variable format
--- Additional Comments From Thomas dot Koenig at online dot de 2005-04-01 11:45 --- No write or print statement is necessary: $ cat assign.f90 program main assign 1000 to i 1000 format (A) end $ gfortran assign.f90 $ gfortran -fdump-parse-tree assign.f90 In file assign.f90:2 assign 1000 to i 1 Warning: Obsolete: ASSIGN statement at (1) Namespace: A-H: (REAL 4) I-N: (INTEGER 4) O-Z: (REAL 4) symtree: i Ambig 0 symbol i (INTEGER 4)(VARIABLE UNKNOWN-INTENT UNKNOWN-ACCESS UNKNOWN-PROC IMPLICIT-TYPE) symtree: main Ambig 0 symbol main (UNKNOWN 0)(PROGRAM UNKNOWN-INTENT UNKNOWN-ACCESS UNKNOWN-PROC) LABEL ASSIGN i 1000 assign.f90: In function 'MAIN__': assign.f90:2: internal compiler error: in gfc_add_modify_expr, at fortran/trans.c:152 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. $ $ gfortran -v Using built-in specs. Target: ia64-unknown-linux-gnu Configured with: ../gcc-4.1-20050327/configure --prefix=/home/zfkts --enable-languages=c,f95 Thread model: posix gcc version 4.1.0 20050327 (experimental) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18481
[Bug libfortran/20661] End of record not detected
--- Additional Comments From Thomas dot Koenig at online dot de 2005-04-01
13:34 ---
This patch fixes the test case. It also includes my
EOR patch for advancing I/O.
This is regression-tested on mainline. I'll submit a proper
patch when I have finished regression-testing it on 4.0.
--- transfer.c.orig 2005-03-25 14:35:29.0 +0100
+++ transfer.c 2005-04-01 15:34:19.0 +0200
@@ -150,7 +150,12 @@ read_sf (int *length)
else
p = base = data;
- memset(base,'\0',*length);
+ memset(base,' ',*length);
+
+ /* If we have seen an eor previously, return blanks. */
+
+ if (sf_seen_eor)
+return base;
current_unit-bytes_left = options.default_recl;
readlen = 1;
@@ -179,12 +184,6 @@ read_sf (int *length)
if (readlen 1 || *q == '\n' || *q == '\r')
{
- /* ??? What is this for? */
- if (current_unit-unit_number == options.stdin_unit)
-{
- if (n = 0)
-continue;
-}
/* Unexpected end of line. */
if (current_unit-flags.pad == PAD_NO)
{
@@ -193,8 +192,13 @@ read_sf (int *length)
}
current_unit-bytes_left = 0;
- *length = n;
sf_seen_eor = 1;
+
+ if (advance_status == ADVANCE_NO)
+ ioparm.library_return = LIBRARY_EOR;
+ else
+ *length = n;
+
break;
}
@@ -748,6 +752,9 @@ formatted_transfer (bt type, void *p, in
internal_error (Bad format node);
}
+ if (ioparm.library_return == LIBRARY_EOR)
+ generate_error (ERROR_EOR, NULL);
+
/* Free a buffer that we had to allocate during a sequential
formatted read of a block that was larger than the static
buffer. */
@@ -1223,7 +1230,10 @@ next_record_r (int done)
length = 1;
/* sf_read has already terminated input because of an '\n' */
if (sf_seen_eor)
- break;
+ {
+ sf_seen_eor=0;
+ break;
+ }
do
{
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20661
[Bug libfortran/20661] End of record not detected
--- Additional Comments From Thomas dot Koenig at online dot de 2005-03-29 15:11 --- I'll try and have a look. Hopefully, my copyright papers that I sent off on 2005-03-19 will come through sometime soon, because the end-of-record patch at http://gcc.gnu.org/ml/gcc-patches/2005-03/msg00729.html (or something that does the same job) needs to be applied before going into this one. Thomas -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20661
[Bug fortran/20618] New: Variable format expressions not supported
This occurs in a legacy package that I inherited. A testcase looks like this: $ cat v-fmt.f program main implicit none integer i,n real a(10) a(1) = 1. a(2) = -1. n = 2 print 9000,(a(i),i=1,n) 9000 format (nF12.5, and that's all.) end $ ifort v-fmt.f $ ./a.out 1.0-1.0 and that's all. $ gfortran v-fmt.f In file v-fmt.f:9 9000 format (nF12.5, and that's all.) 1 Error: Unexpected element in format string at (1) In file v-fmt.f:8 print 9000,(a(i),i=1,n) 1 Error: FORMAT label 9000 at (1) not defined $ gfortran -v Using built-in specs. Target: ia64-unknown-linux-gnu Configured with: ../gcc-4.1-20050320/configure --prefix=/home/zfkts --enable-languages=c,f95 Thread model: posix gcc version 4.1.0 20050320 (experimental) There, the repeat count n is substituded by the value of the expression n. This also works with expressions like n-1, and for other parts of a format expression. For new code, this can be done with an internal write to the format. For legacy code, this can be a bit of a headache to convert. g77 also doesn't support this extension, so this is not a regression wrt g77. -- Summary: Variable format expressions not supported Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: Thomas dot Koenig at online dot de CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20618
[Bug fortran/20618] Variable format expressions not supported
--- Additional Comments From Thomas dot Koenig at online dot de 2005-03-24 14:29 --- Actually, implementing this would be a bit harder than I thought. It seems that the variable expression is evaluated at runtime, so you can do things like $ cat v-fmt2.f program main character*1 c 10 continue read(fmt=9000,unit=*,end=20) j,c print *,c goto 10 20 continue 9000 format(i1,tj,a1) end $ ifort -traceback v-fmt2.f $ ./a.out 1abcd 1 2abcd a 3abcd b Still doable with non-advancing I/O and internal writes, but tricky. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20618
[Bug fortran/20592] New: -fno-automatic (g77 option) is missing from gfortran.
Currently, we don't support the -fno-automatic option that g77 supports. This option turns on the save attribute for all local variables, and is needed for a lot of legacy code. Thomas -- Summary: -fno-automatic (g77 option) is missing from gfortran. Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: Thomas dot Koenig at online dot de CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20592
[Bug fortran/20592] -fno-automatic (g77 option) is missing from gfortran.
-- What|Removed |Added OtherBugsDependingO||19292 nThis|| Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20592
[Bug fortran/20538] compiling -finline-functions -O2 and we crash at runtime
--- Additional Comments From Thomas dot Koenig at online dot de 2005-03-19 13:20 --- (In reply to comment #8) Due to general gfortran lameness only contained functions are ever inlined. Top-level functions are never inlined. Why? I've worked with a Fortrtran 77 compiler (vor the Fujitsu VP series of vector computers) that did inline subroutines if they apppeared previously in the source code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20538
[Bug middle-end/20545] New: unnecessary operations in tailcall
$ cat output-block.c
int flush_output(void)
{
return add_block();
}
$ gcc -O3 -S output-block.c
$ cat output-block.s
.file output-block.c
.text
.p2align 4,,15
.globl flush_output
.type flush_output, @function
flush_output:
pushl %ebp
movl%esp, %ebp
popl%ebp
jmp add_block
.size flush_output, .-flush_output
.ident GCC: (GNU) 4.1.0 20050315 (experimental)
.section.note.GNU-stack,,@progbits
The operations on ebp aren't necessary.
--
Summary: unnecessary operations in tailcall
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Thomas dot Koenig at online dot de
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20545
[Bug middle-end/20517] New: bit shift/mask optimization potential
$ cat shift.c
#include stdio.h
#define OFFSET 4
#define MASK 0xf0
int main()
{
unsigned int f,g;
scanf(%u,f);
if ((f MASK) OFFSET == 1) {
printf(success\n);
}
return 0;
}
$ gcc -S -O2 -fdump-tree-optimized shift.c
$ tail -20 shift.c.t66.optimized
unsigned int g;
unsigned int f;
int D.1807;
unsigned int D.1806;
unsigned int D.1805;
unsigned int f.10;
bb 0:
scanf (%u[0], f);
if ((f 240) 4 == 1) goto L0; else goto L1;
L0:;
printf (success\n[0]);
L1:;
return 0;
}
$ gcc -v
Using built-in specs.
Target: ia64-unknown-linux-gnu
Configured with: ../gcc-4.1-20050306/configure --prefix=/home/zfkts
--enable-languages=c,f95 --disable-optimization
Thread model: posix
gcc version 4.1.0 20050306 (experimental)
The expression (f 0xf0) 4 == 1 could be optimized
to f 0xf == 1 4.
Code like that occurs in the libgfortan library.
--
Summary: bit shift/mask optimization potential
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Thomas dot Koenig at online dot de
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20517
[Bug middle-end/20517] bit shift/mask optimization potential
-- What|Removed |Added Keywords||missed-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20517
[Bug middle-end/20432] complex reciprocal has too many operations
--- Additional Comments From Thomas dot Koenig at online dot de 2005-03-17 13:41 --- (In reply to comment #3) I cannot remember the rules but -0.0 * 0.0 could be -0.0 (and not 0.0), someone needs to help me here. I'm trying to see what input could apply to, but I can't think of one. What were you referring to? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20432
[Bug libfortran/20471] Segmentation fault on read after backspace and rewind
--- Additional Comments From Thomas dot Koenig at online dot de 2005-03-17 14:40 --- (In reply to comment #2) The patches suggested in comment #2 under bug 20156 fixes bugs 20156, 20125 and 20471 on the macintosh and does not seem to cause any new problems. Can you submit this as a regular patch? The how-to is documented under http://gcc.gnu.org/contribute.html. Specifically, send the patch with appropriate ChangeLog entries and test cases both to [EMAIL PROTECTED] and [EMAIL PROTECTED] so it can be reviewed. Probably, for this size of patch, a short copyright disclaimer would be OK. Thomas -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20471
[Bug libfortran/19014] print *,maxloc(array) segfaults
-- What|Removed |Added BugsThisDependsOn||19106 AssignedTo|unassigned at gcc dot gnu |Thomas dot Koenig at online |dot org |dot de Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19014
[Bug libfortran/20092] console input doesn't deal correctly with CR
--- Additional Comments From Thomas dot Koenig at online dot de 2005-03-13 21:10 --- I believe this is also fixed with http://gcc.gnu.org/ml/gcc-patches/2005-03/msg00729.html Copyright papers, where are you? :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20092
[Bug libfortran/19106] segfault in executable for print *,sum(a,dim=2,mask=a0)
--- Additional Comments From Thomas dot Koenig at online dot de 2005-03-13 22:11 --- Patch here: http://gcc.gnu.org/ml/fortran/2005-03/msg00232.html -- What|Removed |Added Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19106
[Bug bootstrap/20437] New: bootstrap --enable-maintainer-mode broken
$ ../gcc-4.1/configure --prefix=$HOME --enable-languages=c,f95 --enable-maintainer-mode creating cache ./config.cache checking host system type... i686-pc-linux-gnu checking target system type... i686-pc-linux-gnu checking build system type... i686-pc-linux-gnu checking for a BSD compatible install... /usr/bin/install -c checking whether ln works... yes checking whether ln -s works... yes checking for gcc... gcc checking whether the C compiler (gcc ) works... yes checking whether the C compiler (gcc ) is a cross-compiler... no checking whether we are using GNU C... yes checking whether gcc accepts -g... yes checking for gnatbind... no checking whether compiler driver understands Ada... no checking how to compare bootstrapped objects... cmp --ignore-initial=16 $$f1 $$f2 checking for correct version of gmp.h... yes checking for MPFR... yes *** This configuration is not supported in the following subdirectories: target-libada gnattools target-libstdc++-v3 target-libffi target-boehm-gc target-zlib target-libjava zlib fastjar target-libobjc (Any other directories should still work fine.) checking for bison... bison checking for bison... bison -y checking for gm4... no checking for gnum4... no checking for m4... m4 checking for flex... flex checking for flex... flex checking for makeinfo... makeinfo checking for i686-pc-linux-gnu-ar... no checking for ar... ar checking for i686-pc-linux-gnu-as... no checking for as... as checking for i686-pc-linux-gnu-dlltool... no checking for dlltool... dlltool checking for i686-pc-linux-gnu-ld... no checking for ld... ld checking for i686-pc-linux-gnu-nm... no checking for nm... nm checking for i686-pc-linux-gnu-ranlib... no checking for ranlib... ranlib checking for i686-pc-linux-gnu-windres... no checking for windres... windres checking for i686-pc-linux-gnu-objcopy... no checking for objcopy... objcopy checking for i686-pc-linux-gnu-objdump... no checking for objdump... objdump checking for i686-pc-linux-gnu-ar... no checking for ar... ar checking for i686-pc-linux-gnu-as... no checking for as... as checking for i686-pc-linux-gnu-dlltool... no checking for dlltool... dlltool checking for i686-pc-linux-gnu-ld... no checking for ld... ld checking for i686-pc-linux-gnu-nm... no checking for nm... nm checking for i686-pc-linux-gnu-ranlib... no checking for ranlib... ranlib checking for i686-pc-linux-gnu-windres... no checking for windres... windres checking whether to enable maintainer-specific portions of Makefiles... yes checking if symbolic links between directories work... yes updating cache ./config.cache creating ./config.status creating Makefile $ make bootstrap cd ../gcc-4.1 autogen Makefile.def cd ../gcc-4.1 autoconf configure.in:2207: error: possibly undefined macro: AS_FOR_TARGET If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. make: *** [../gcc-4.1/configure] Error 1 $ grep version_string ../gcc-4.1/gcc/version.c const char version_string[] = 4.1.0 20050312 (experimental); $ autogen -v autogen - The Automated Program Generator - Ver. 5.6.6 $ autoconf -V autoconf (GNU Autoconf) 2.59 Written by David J. MacKenzie and Akim Demaille. Copyright (C) 2003 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. -- Summary: bootstrap --enable-maintainer-mode broken Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: Thomas dot Koenig at online dot de CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20437
[Bug libfortran/20438] New: conflicting types for int8_t with --enable-maintainer-mode
/home/ig25/i686-pc-linux-gnu/lib/ -isystem /home/ig25/i686-pc-linux-gnu/include -isystem /home/ig25/i686-pc-linux-gnu/sys-include -g -O2 -Wall -fno-repack-arrays -fno-underscoring' selected_real_kind.inc cd ../../../gcc-4.0/libgfortran /bin/sh /home/ig25/gcc-4.0/missing --run autoheader rm -f stamp-h1 touch ../../../gcc-4.0/libgfortran/config.h.in cd . /bin/sh ./config.status config.h config.status: creating config.h config.status: config.h is unchanged make all-am make[3]: Entering directory `/home/ig25/gcc-4.0-bin/i686-pc-linux-gnu/libgfortran' /bin/sh ./libtool --mode=compile /home/ig25/gcc-4.0-bin/gcc/xgcc -B/home/ig25/gcc-4.0-bin/gcc/ -B/home/ig25/i686-pc-linux-gnu/bin/ -B/home/ig25/i686-pc-linux-gnu/lib/ -isystem /home/ig25/i686-pc-linux-gnu/include -isystem /home/ig25/i686-pc-linux-gnu/sys-include -DHAVE_CONFIG_H -I. -I../../../gcc-4.0/libgfortran -I. -iquote../../../gcc-4.0/libgfortran/io -std=gnu99 -O2 -g -O2 -c -o environ.lo `test -f 'runtime/environ.c' || echo '../../../gcc-4.0/libgfortran/'`runtime/environ.c mkdir .libs /home/ig25/gcc-4.0-bin/gcc/xgcc -B/home/ig25/gcc-4.0-bin/gcc/ -B/home/ig25/i686-pc-linux-gnu/bin/ -B/home/ig25/i686-pc-linux-gnu/lib/ -isystem /home/ig25/i686-pc-linux-gnu/include -isystem /home/ig25/i686-pc-linux-gnu/sys-include -DHAVE_CONFIG_H -I. -I../../../gcc-4.0/libgfortran -I. -iquote../../../gcc-4.0/libgfortran/io -std=gnu99 -O2 -g -O2 -c ../../../gcc-4.0/libgfortran/runtime/environ.c -fPIC -DPIC -o .libs/environ.o In file included from ../../../gcc-4.0/libgfortran/runtime/environ.c:35: ../../../gcc-4.0/libgfortran/libgfortran.h:63: error: conflicting types for 'int8_t' /usr/include/sys/types.h:191: error: previous declaration of 'int8_t' was here make[3]: *** [environ.lo] Error 1 make[3]: Leaving directory `/home/ig25/gcc-4.0-bin/i686-pc-linux-gnu/libgfortran' make[2]: *** [all] Error 2 make[2]: Leaving directory `/home/ig25/gcc-4.0-bin/i686-pc-linux-gnu/libgfortran' make[1]: *** [all-target-libgfortran] Error 2 make[1]: Leaving directory `/home/ig25/gcc-4.0-bin' make: *** [bootstrap] Error 2 This is on a Debian experimental system. I'll try installing automake and rerunning next, then disabling multilib. -- Summary: conflicting types for int8_t with --enable-maintainer- mode Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: Thomas dot Koenig at online dot de CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20438
[Bug middle-end/20434] pessimization of complex expression
--- Additional Comments From Thomas dot Koenig at online dot de 2005-03-12 09:45 --- (In reply to comment #4) (In reply to comment #3) - Why the casts to double? Because that is required by the C standard. Isn't that covered by the as-if rule? I'm fairly sure the cast to double won't change the result of the operator :-) No but the addition is done in double. Again, the as-if rule: If a and b are floats, the expression a+b 0 should be the same for any a and b regardless wether they are done in float or double. The same is true, for float a,b and c, of c = a+b; It is _not_ true for exmperssions like c = a+b-a, of course. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20434
[Bug libfortran/19106] segfault in executable for print *,sum(a,dim=2,mask=a0)
--- Additional Comments From Thomas dot Koenig at online dot de 2005-03-12 22:52 --- The 0 as data pointer is a signal to the library that it needs to fill out the properties of the array, because the front end can't determine it. See http://gcc.gnu.org/ml/fortran/2005-03/msg00199.html http://gcc.gnu.org/ml/fortran/2004-08/msg00050.html http://gcc.gnu.org/ml/fortran/2004-08/msg00017.html http://gcc.gnu.org/ml/fortran/2004-08/msg00019.html -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |Thomas dot Koenig at online |dot org |dot de Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19106
[Bug middle-end/20434] pessimization of complex expression
--- Additional Comments From Thomas dot Koenig at online dot de 2005-03-12 23:13 --- (In reply to comment #6) Well the real reason is creal/cimag returns double and not float. Use crealf/cimagf instead. You're right, of course. Doing that gets me bb 0: foo (cr, ci); return cr + 0.0 + ci + 0.0 0.0; OK, the direct cast has gone away. I wonder if this still converts to double, though... Well yes this is a missed optimization, which should be filed separately. I think using crealf/cimagf pretty much solves this. If you lie to the compiler... :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20434
[Bug middle-end/20432] New: complex reciprocal has too many operations
#include math.h
#include complex.h
int main()
{
float complex c,d;
foo(c);
d=1.0/c;
return creal(d)+cimag(d)0;
}
$ gcc -S -O -fdump-tree-optimized recip.c
$ tail -25 recip.c.t66.optimized
bb 0:
foo (c);
SR.24 = (double) REALPART_EXPR c;
SR.23 = (double) IMAGPART_EXPR c;
if (ABS_EXPR SR.24 ABS_EXPR SR.23) goto L1; else goto L2;
L1:;
D.2387 = SR.24 / SR.23;
D.2389 = SR.23 + SR.24 * D.2387;
SR.25 = (D.2387 + 0.0) / D.2389;
SR.26 = (D.2387 * 0.0 - 1.0e+0) / D.2389;
goto bb 3;
L2:;
D.2395 = SR.23 / SR.24;
D.2397 = SR.24 + SR.23 * D.2395;
SR.25 = (D.2395 * 0.0 + 1.0e+0) / D.2397;
SR.26 = (0.0 - D.2395) / D.2397;
bb 3:
return (double) (float) SR.25 + (double) (float) SR.26 0.0;
}
$ gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.1/configure --prefix=/home/ig25
--enable-languages=c,f95
Thread model: posix
gcc version 4.1.0 20050311 (experimental)
I can't see a reason why the +0 and *0 operations should
be necessary.
Thomas
--
Summary: complex reciprocal has too many operations
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Thomas dot Koenig at online dot de
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20432
[Bug libfortran/19155] blanks not treated as zeros in 'E' format read (NIST FM110.FOR)
--- Additional Comments From Thomas dot Koenig at online dot de 2005-03-11 21:21 --- My vote would go for fixing this, because of the NIST testsuite failure. Thomas -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19155
[Bug middle-end/20432] complex reciprocal has too many operations
--- Additional Comments From Thomas dot Koenig at online dot de 2005-03-11 21:36 --- (In reply to comment #1) D.2395 * 0.0 Can trap if D.2395 is a non quiet NAN. D.2395 gets its value from D.2395 = SR.23 / SR.24; two lines earlier. Is there anything that would generate a signaling NaN for this case and not trap immediately? Likewise for D.2387 + 0.0 Same argument. Though in this case it does not matter because we are going to trap later on. .. which is true, and which is why I think this is missed-optimization. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20432
[Bug middle-end/20434] pessimization of complex expression
--- Additional Comments From Thomas dot Koenig at online dot de 2005-03-11 21:59 --- There are two strange things here: - Why the + 0. ? - Why the casts to double? -- What|Removed |Added Keywords||missed-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20434
[Bug middle-end/20434] New: pessimization of complex expression
$ cat complex-parts.c
#include math.h
#include complex.h
int main()
{
float cr,ci;
float complex c;
foo(cr,ci);
c = cr+I*ci;
return creal(c)+cimag(c)0;
}
$ gcc -S -O2 -fdump-tree-optimized complex-parts.c
$ tail -10 complex-parts.c.t66.optimized
float D.2359;
float cr.18;
bb 0:
foo (cr, ci);
return (double) (cr + 0.0) + (double) (ci + 0.0) 0.0;
}
$ gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.1/configure --prefix=/home/ig25
--enable-languages=c,f95
Thread model: posix
gcc version 4.1.0 20050311 (experimental)
--
Summary: pessimization of complex expression
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Thomas dot Koenig at online dot de
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20434
[Bug middle-end/20434] pessimization of complex expression
--- Additional Comments From Thomas dot Koenig at online dot de 2005-03-11 22:49 --- - Why the casts to double? Because that is required by the C standard. Isn't that covered by the as-if rule? I'm fairly sure the cast to double won't change the result of the operator :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20434
[Bug libfortran/18958] eoshift segfaults when shifting off the end of an array
--- Additional Comments From Thomas dot Koenig at online dot de 2005-03-09
15:13 ---
$ cat eoshift.f90
print *,eoshift((/1, 3/), 3)
end
$ gfortran eoshift.f90
$ ./a.out
Segmentation fault
This fails because the loop
for (n = 0; n len; n++)
{
memcpy (dest, src, size);
dest += roffset;
src += soffset;
}
at line 146 ff. in eoshift0.c runs over its bounds
with the test case, because both n and len are of type index_type,
index_type is size_t, which is unsigned, and len is supposed to be -1
(so it's either 0x or 0x, depending on
wether size_t is 32-bit or 64-bit).
This has an easy, one-letter fix: typedef index_type as ssize_t
instad of size_t in libgfortran.h.
This fixes the bug and causes no testsuite regressions. It also
has the potential to fix other, latent bugs like this one. This is
also a design decision which I feel should be discussed on
the fortran mailing list.
It would require some configuration work for libgfortran (not
all systems have ssize_t), which I don't feel I can handle
competently at the moment, so I won't submit a patch (at least
not now).
Thomas
--
What|Removed |Added
Keywords||wrong-code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18958
[Bug fortran/20323] optional arguments incorrectly accepted in specification expressions
--- Additional Comments From Thomas dot Koenig at online dot de 2005-03-09 16:01 --- The complaint is a segfault at runtime when you actually want to do anything with the string whose length depends on a missing optional argument. This isn't too bad (the same thing happens if you access a missing optional argument). Thomas -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20323
[Bug libfortran/18495] Intrinisc function SPREAD is broken
--- Additional Comments From Thomas dot Koenig at online dot de 2005-03-09
23:33 ---
This looks very much like a front end bug. The
along parameter gets the wrong value.
Look at this:
$ cat test_spread.f90
program test_spread
implicit none
integer, parameter :: N = 1000
integer:: I
integer, dimension(N) :: source
integer, dimension(N,N) :: sink
do i = 1 , N
source(i) = N
end do
print *,'product'
sink = spread( source , 1 , N ) * spread( source , N , N )
print *, sink
stop
end program test_spread
$ gfortran -fdump-tree-original test_spread.f90
From the *.t02.original file:
L.2:;
_gfortran_filename = test_spread.f90;
_gfortran_line = 10;
_gfortran_ioparm.unit = 6;
_gfortran_ioparm.list_format = 1;
_gfortran_st_write ();
_gfortran_transfer_character (product, 7);
_gfortran_st_write_done ();
{
int4 C.512 = 1000;
int4 C.511 = 1000;
struct array1_int4 parm.3;
struct array2_int4 atmp.2;
int4 C.492 = 1000;
int4 C.491 = 1;
struct array1_int4 parm.1;
struct array2_int4 atmp.0;
... and further down:
parm.1.dtype = 265;
parm.1.dim[0].lbound = 1;
parm.1.dim[0].ubound = 1000;
parm.1.dim[0].stride = 1;
parm.1.data = (int4[0:] *) (int4[0:] *) source[0];
parm.1.offset = 0;
_gfortran_spread (atmp.0, parm.1, C.491, C.492);
^^
This is =1000, which is bogus
The last parameter of spread is along, which is supposed
to give the dimension. 1000 is a bit too high :-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18495
[Bug libfortran/20131] gfortan - incorrectly reads beyond the end of line.
--- Additional Comments From Thomas dot Koenig at online dot de 2005-03-08 08:20 --- Updated patch: http://gcc.gnu.org/ml/gcc-patches/2005-03/msg00729.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20131
[Bug libfortran/19568] incorrect formatted read
--- Additional Comments From Thomas dot Koenig at online dot de 2005-03-08 08:21 --- Updated patch: http://gcc.gnu.org/ml/gcc-patches/2005-03/msg00729.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19568
[Bug fortran/15080] Forall bounds not calculated correctly (forall_3.f90)
--- Additional Comments From Thomas dot Koenig at online dot de 2005-03-08 15:35 --- Here's a somewhat reduced testcase that fails for me on ia64-unknown-linux-gnu: $ cat forall_5.f90 program evil_forall implicit none type t logical valid integer :: s integer, dimension(:), pointer :: p end type type (t), dimension (2) :: v integer i allocate (v(1)%p(2)) allocate (v(2)%p(2)) v(:)%valid = (/.true., .true./) v(:)%s = (/1, 2/) v(1)%p(:) = (/9, 10/) v(2)%p(:) = (/11, 12/) forall (i=1:2,v(i)%valid) v(i)%p(1:v(i)%s) = v(3-i)%p(1:v(i)%s) end forall if (any(v(1)%p(:) .ne. (/11, 10/))) call abort end program Still gives me 335 lines of *.t02.original - not easy to debug... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15080
[Bug fortran/20387] New: ICE in gfc_conv_array_initializer
, 11351,11353,11369,11383,11393,11399,11411,11423,11437,11443, 11447,11467,11471,11483,11489,11491,11497,11503,11519,11527, 11549,11551,11579,11587,11593,11597,11617,11621,11633,11657, 11677,11681,11689,11699,11701,11717,11719,11731,11743,11777, 11779,11783,11789,11801,11807,11813,11821,11827,11831,11833, 11839,11863,11867,11887,11897,11903,11909,11923,11927,11933, 11939,11941,11953,11959,11969,11971,11981,11987,12007,12011, 12037,12041,12043,12049,12071,12073,12097,12101,12107,12109, 12113,12119,12143,12149,12157,12161,12163,12197,12203,12211, 12227,12239,12241,12251,12253,12263,12269,12277,12281,12289, 12301,12323,12329,12343,12347,12373,12377,12379,12391,12401, 12409,12413,12421,12433,12437,12451,12457,12473,12479,12487, 12491,12497,12503,12511,12517,12527,12539,12541,12547,12553 /) integer, dimension(1500), parameter, public :: allprimes=(/ primes_1_to_300, primes_301_to_600, primes_601_to_900, primes_901_to_1200, primes_1201_to_1500 /) contains end module bug04 -- Summary: ICE in gfc_conv_array_initializer Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: Thomas dot Koenig at online dot de CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20387
[Bug fortran/15080] Forall bounds not calculated correctly (forall_3.f90)
--- Additional Comments From Thomas dot Koenig at online dot de 2005-03-08 20:30 --- On i686-pc-linux-gnu, forall_5.f90 does the following: $ gfortran forall_5.f90 $ ./a.out Fortran runtime error: Attempt to allocate a negative amount of memory. $ gfortran -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc-4.0/configure --prefix=/home/ig25 --enable-languages=c,f95 Thread model: posix gcc version 4.0.0 20050306 (prerelease) Did I mention I don't like memory corruption? Thomas -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15080
[Bug libfortran/19568] incorrect formatted read
--- Additional Comments From Thomas dot Koenig at online dot de 2005-03-06 23:34 --- Updated patch: http://gcc.gnu.org/ml/gcc-patches/2005-03/msg00566.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19568
[Bug libfortran/20131] gfortan - incorrectly reads beyond the end of line.
--- Additional Comments From Thomas dot Koenig at online dot de 2005-03-06 23:34 --- Patch: http://gcc.gnu.org/ml/gcc-patches/2005-03/msg00566.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20131
[Bug libfortran/16339] Unformatted i/o on large arrays inefficient
--- Additional Comments From Thomas dot Koenig at online dot de 2005-03-04 10:47 --- This is really _very_ inefficient, by a factor of 20. Some test numbers: $ g77 write-record.f $ time ./a.out real0m1.819s user0m1.774s sys 0m0.044s $ gfortran write-record.f $ time ./a.out real0m43.723s user0m9.003s sys 0m34.571s $ cat write-record.f program main integer n parameter (n=1000) real a(n) write (10) (a(i),i=1,n) end $ gfortran -v Using built-in specs. Target: ia64-unknown-linux-gnu Configured with: ../gcc-4.1-20050227/configure --prefix=/home/zfkts --enable-languages=c,f95 Thread model: posix gcc version 4.1.0 20050227 (experimental) By comparison: $ ifort write-record.f $ time ./a.out real0m0.117s user0m0.001s sys 0m0.116s -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16339
[Bug libfortran/20278] Performance regression in formatted output vs. g77
--- Additional Comments From Thomas dot Koenig at online dot de 2005-03-03 20:27 --- Same thing on i686: $ gfortran write-many.f $ time ./a.out real0m5.576s user0m5.508s sys 0m0.038s $ g77 write-many.f $ time ./a.out real0m3.252s user0m3.185s sys 0m0.041s -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20278
[Bug libfortran/20278] New: Performance regression in formatted output vs. g77
$ cat write-many.f program main open(10,status='SCRATCH') a = 0.3858204 do i=1,100 a = a + 0.4761748164 write(10, '(G12.5)'),a end do end $ gfortran write-many.f $ time ./a.out real0m8.165s user0m8.092s sys 0m0.059s $ g77 write-many.f $ time ./a.out real0m5.760s user0m5.719s sys 0m0.032s $ gfortran -v Using built-in specs. Target: ia64-unknown-linux-gnu Configured with: ../gcc-4.1-20050227/configure --prefix=/home/zfkts --enable-languages=c,f95 Thread model: posix gcc version 4.1.0 20050227 (experimental) -- Summary: Performance regression in formatted output vs. g77 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P2 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: Thomas dot Koenig at online dot de CC: gcc-bugs at gcc dot gnu dot org GCC target triplet: ia64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20278
[Bug middle-end/19953] Special-case real + complex arithmetic operation (-ffast-math)
--- Additional Comments From Thomas dot Koenig at online dot de 2005-03-01
15:43 ---
(In reply to comment #14)
(In reply to comment #13)
(In reply to comment #11)
I get the same as I got above with the following version on x86:
GNU C version 4.0.0 20050225 (experimental) (i686-pc-linux-gnu)
compiled by GNU C version 4.0.0 20050225 (experimental).
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
And no local patches which could cause this.
I can only assume that this has regressed, that this is a
little-endian problem (why it should be so is beyond me, though),
that your specific vibes make this go away or that mine make it
appear :-)
I have just done the following:
- Downloaded the 4.1 20050227 snapshot onto a ia-64 Linux box
- untarred it
$ mkdir gcc-bin
$ cd gcc-bin/
$ ../gcc-4.1-20050227/configure --prefix=$HOME --enable-languages=c,f95
$ make -j2 bootstrap
$ make install
Then, I get:
$ gcc -v
Using built-in specs.
Target: ia64-unknown-linux-gnu
Configured with: ../gcc-4.1-20050227/configure --prefix=/home/zfkts
--enable-languages=c,f95
Thread model: posix
gcc version 4.1.0 20050227 (experimental)
$ cat c-div.c
#include math.h
#include complex.h
int main()
{
float a;
complex float b,c;
foo(a,b);
c = b/a;
return creal(c) + cimag(c) 0;
}
$ gcc -O3 -fdump-tree-optimized -S c-div.c
$ cat c-div.c.t65.optimized
;; Function main (main)
Analyzing Edge Insertions.
main ()
{
float SR.12;
float SR.11;
float SR.10;
float SR.9;
float c$imag;
float c$real;
float SR.6;
float SR.5;
float SR.4;
float SR.3;
float D.2255;
float D.2254;
float D.2253;
float D.2252;
float D.2251;
float D.2250;
float D.2249;
float D.2248;
float D.2247;
float D.2246;
float D.2245;
float D.2244;
float D.2243;
float D.2242;
float D.2241;
float D.2240;
float D.2239;
float D.2238;
float D.2237;
float D.2236;
float D.2233;
float D.2232;
float D.2231;
float D.2230;
float D.2229;
float D.2228;
complex float c;
complex float b;
float a;
double D.2225;
double D.2224;
float D.2223;
double D.;
float D.2221;
complex float c.2;
complex float c.1;
int D.2218;
complex float D.2217;
complex float D.2216;
float a.0;
bb 0:
foo (a, b);
SR.4 = a;
D.2228 = REALPART_EXPR b;
D.2229 = IMAGPART_EXPR b;
if (ABS_EXPR SR.4 0.0) goto L1; else goto L2;
L1:;
D.2238 = SR.4 / 0.0;
D.2240 = SR.4 * D.2238 + 0.0;
c$real = (D.2229 + D.2228 * D.2238) / D.2240;
c$imag = (D.2229 * D.2238 - D.2228) / D.2240;
goto bb 3;
L2:;
D.2247 = 0.0 / SR.4;
D.2249 = SR.4 + D.2247 * 0.0;
c$real = (D.2228 + D.2229 * D.2247) / D.2249;
c$imag = (D.2229 - D.2228 * D.2247) / D.2249;
bb 3:
return (double) c$real + (double) c$imag 0.0;
}
Anything more I can do to test this?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19953
[Bug middle-end/19953] Special-case real + complex arithmetic operation (-ffast-math)
--- Additional Comments From Thomas dot Koenig at online dot de 2005-03-01 21:07 --- Andrew, I'm sorry if I'm not making myself clear here. The problem that I see is that, on ia64-unknown-linux-gnu and on i386-pc-linux-gnu, with clean trees, I see code like L2:; D.2390 = 0.0 / SR.22; D.2392 = SR.22 + D.2390 * 0.0; c$real = (D.2371 + D.2372 * D.2390) / D.2392; c$imag = (D.2372 - D.2371 * D.2390) / D.2392; in *.t65.optimized for the simple test case with -O1 and -O3. As you have stated, this is independent of PR 20139. I just rechecked this with the 4.0.0 20050226 (prerelease) snapshot. You have posted different results, which I cannot reproduce. Something has to be the cause of this difference, but I have no real idea what it could be. Is the *.t65.optimized that I am looking at the correct file? Is there any patch in your tree that may be the cause of these of these different results after all? What version are you using, exactly? How can I download the exact version from cvs? Can this be caused by header files? I think that this is highly unlikely, this is why I didn't include the preprocessed source, but I can do so, of course. Is there anything else that I can do to clear this up? Thomas -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19953
[Bug middle-end/19953] Special-case real + complex arithmetic operation (-ffast-math)
--- Additional Comments From Thomas dot Koenig at online dot de 2005-03-01 21:26 --- (In reply to comment #18) L2:; D.2390 = 0.0 / SR.22; D.2392 = SR.22 + D.2390 * 0.0; c$real = (D.2371 + D.2372 * D.2390) / D.2392; c$imag = (D.2372 - D.2371 * D.2390) / D.2392; in *.t65.optimized for the simple test case with -O1 and -O3. As you have stated, this is independent of PR 20139. Yes that code is correct. as 0.0/SR.22 is not 0.0 if SR.22 is NAN. and 0.0 * D.2390 is not 0.0 if D.2390 is NAN. Ok, then I have misunderstood you - you were referring to the results with -ffast-math. However, there still is a missed optimization here. If SR.22 is NaN, then the proposed simplification c$real = D.2371 / SR.22; c$imag = D.2372 / SR.22 would still yield NaN for c$real and c$imag, which is correct. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19953
[Bug middle-end/19953] Special-case real + complex arithmetic operation (-ffast-math)
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-28 20:55 --- Comment #7 shows that there is still something to be done for (br+I*bi)/a (with real br, bi, a). This could be simplified to br/a + I*bi/a, which isn't happening. Thomas -- What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19953
[Bug middle-end/18902] Naive (default) complex division algorithm
-- Bug 18902 depends on bug 19953, which changed state. Bug 19953 Summary: Special-case real + complex arithmetic operation (-ffast-math) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19953 What|Old Value |New Value Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18902
[Bug middle-end/19953] Special-case real + complex arithmetic operation (-ffast-math)
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-28 20:55 --- What I meant was comment#8 *sigh* -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19953
[Bug middle-end/19953] Special-case real + complex arithmetic operation (-ffast-math)
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-27
12:52 ---
Is this really fixed?
Look at this:
$ cat c-div.c
#include math.h
#include complex.h
int main()
{
float a;
complex float b,c;
foo(a,b);
c = b/a;
return creal(c) + cimag(c) 0;
}
$ gcc -ffast-math -O3 -fdump-tree-optimized -fno-cx-limited-range -S c-div.c
$ tail -20 c-div.c.t65.optimized
if (ABS_EXPR SR.26 0.0) goto L1; else goto L2;
L1:;
D.3021 = SR.26 * Inf;
D.3022 = SR.26 * D.3021;
c$real = (D.3012 + D.3011 * D.3021) / D.3022;
c$imag = (D.3012 * D.3021 - D.3011) / D.3022;
goto bb 3;
L2:;
D.3030 = 0.0 / SR.26;
c$real = (D.3011 + D.3012 * D.3030) / SR.26;
c$imag = (D.3012 - D.3011 * D.3030) / SR.26;
bb 3:
return (double) c$real + (double) c$imag 0.0;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19953
[Bug libfortran/20163] gfortran - error opening direct access file
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-26 20:46 --- Patch for the first bug here: http://gcc.gnu.org/ml/gcc-patches/2005-02/msg01694.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20163
[Bug libfortran/20163] gfortran - error opening direct access file
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-26 20:49 --- Here is a reduced test case for the second error: $ cat open-after-error.f open(10,status=foo,err=100) call abort 100 continue open(10,status=scratch) end $ cat open-after-error.f open(10,status=foo,err=100) call abort 100 continue open(10,status=scratch) end $ gfortran open-after-error.f $ ./a.out At line 4 of file open-after-error.f Internal Error: Recursive library calls not allowed -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20163
[Bug libfortran/20131] gfortan - incorrectly reads beyond the end of line.
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-23 12:28 --- I'll check later wether this is fixed with the proposed fix for PR 19568 to be found at http://gcc.gnu.org/ml/gcc-patches/2005-01/msg02295.html Thomas -- What|Removed |Added CC||Thomas dot Koenig at online ||dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20131
[Bug libfortran/20131] gfortan - incorrectly reads beyond the end of line.
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-23 21:27 --- No, this isn't fixed with the patch I referred to earlier. Thomas -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20131
[Bug libfortran/20179] cannot mix C and Fortran I/O
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-23 22:54 --- Add fflush(stdout); at the end of cio.c, and things work as expected. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20179
[Bug libfortran/20163] gfortran - error opening direct access file
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-23 23:09 --- This is two bugs. The first bug can be reduced to $ cat open-opt.f open(unit=10,status=scratch ) end $ gfortran open-opt.f $ ./a.out At line 1 of file open-opt.f Fortran runtime error: Bad STATUS parameter in OPEN statement -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20163
[Bug libfortran/20163] gfortran - error opening direct access file
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-23
23:29 ---
This has a pretty good chance of fixing it.
Proper testing, Changelog entry, ... tomorrow.
Index: string.c
===
RCS file: /cvsroot/gcc/gcc/libgfortran/runtime/string.c,v
retrieving revision 1.4
diff -c -r1.4 string.c
*** string.c12 Jan 2005 21:27:31 - 1.4
--- string.c23 Feb 2005 23:28:02 -
***
*** 41,57
compare0 (const char *s1, int s1_len, const char *s2)
{
int i;
! if (strncasecmp (s1, s2, s1_len) != 0)
! return 0;
!
! /* The rest of s1 needs to be blanks for equality. */
!
! for (i = strlen (s2); i s1_len; i++)
! if (s1[i] != ' ')
! return 0;
!
! return 1;
}
--- 41,51
compare0 (const char *s1, int s1_len, const char *s2)
{
int i;
+ int len;
! /* Strip traling blanks from the Fortran string. */
! len = fstrlen(s1, s1_len);
! return strncasecmp(s1,s2,len) == 0;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20163
[Bug libfortran/20092] gfortran not correctly padding keyboard or text file input
-- What|Removed |Added CC||Thomas dot Koenig at online ||dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20092
[Bug libfortran/20074] New: reshape of pointer array segfaults at runtime
From a posting to comp.lang.fortran. $ cat tryresh.f90 ! From: Alfredo Buttari [EMAIL PROTECTED] ! Newsgroups: comp.lang.fortran ! Subject: reshape problem ! Date: 18 Feb 2005 09:54:35 -0800 program tryreshape integer,allocatable :: vect1(:),resh1(:,:) integer,pointer :: vect(:),resh(:,:) integer :: vect2(2*4), resh2(2,4) integer :: r, s(2) r=2; nb=4 s(:)=(/r,nb/) allocate(vect(nb*r),vect1(nb*r)) allocate(resh(r,nb),resh1(r,nb)) vect =1 vect1=1 vect2=1 write(*,'(Reshaping to ,1(i1.1,x),i2.2)')s ! THIS WORKS resh2 = reshape(vect2,s) write(*,'(resh2: ,1(i3,2x))')resh2(1,1) ! THIS WORKS resh1 = reshape(vect1,s) write(*,'(resh1: ,1(i3,2x))')resh1(1,1) ! THIS DOESN'T resh = reshape(vect,s) write(*,'(resh : ,1(i3,2x))')resh(1,1) end program tryreshape $ gfortran -g tryresh.f90 $ ./a.out Reshaping to 2x04 resh2: 1 resh1: 1 Segmentation fault $ gdb ./a.out GNU gdb 6.3-debian Copyright 2004 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 i386-linux...Using host libthread_db library /lib/tls/libthread_db.so.1. (gdb) r Starting program: /home/ig25/Krempel/a.out Reshaping to 2x04 resh2: 1 resh1: 1 Program received signal SIGSEGV, Segmentation fault. 0x40127cef in memcpy () from /lib/tls/libc.so.6 (gdb) bt #0 0x40127cef in memcpy () from /lib/tls/libc.so.6 #1 0x40056f08 in *_gfortrani_reshape_packed (ret=0x0, rsize=32, source=0x20 Address 0x20 out of bounds, ssize=32, pad=0x0, psize=4) at ../../../gcc/libgfortran/intrinsics/reshape_packed.c:45 #2 0x40044b8b in *_gfortran_reshape_4 (ret=0xb4c4, source=Variable source is not available. ) at ../../../gcc/libgfortran/generated/reshape_i4.c:160 #3 0x08048d6f in MAIN__ () at tryresh.f90:35 #4 0x08048f43 in main (argc=32, argv=0x20) at ../../../gcc/libgfortran/fmain.c:18 (gdb) q The program is running. Exit anyway? (y or n) y $ gfortran -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc/configure --prefix=/home/ig25 --enable-languages=c,f95 Thread model: posix gcc version 4.0.0 20050219 (experimental) -- Summary: reshape of pointer array segfaults at runtime Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: Thomas dot Koenig at online dot de CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20074
[Bug libfortran/20037] libfortran: format termination bug in formatted write
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-18 10:42 --- I think this is identical to PR 15332. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20037
[Bug target/19974] incorrect complex division on ia-64 with flag_complex_method = 2
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-17 09:42 --- (In reply to comment #7) Using Mathematica I get for (10^20 + 10^12 I)/(1 - 10^-8) = 10^20 + 2 * 10^12 I so really neither of them are mathematically correct. The test case was (10^20-10^12*I)/(1-10^(-8)*I), which is 10^20, obviously. For what it is worth, ifort also gets 18059 as the result. I'll do some checking to see what this should really be. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19974
[Bug target/19974] incorrect complex division on ia-64 with flag_complex_method = 2
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-17 13:52 --- Another datapoint - the fact that slarrb has problems has been confirmed by a Lapack developer. A new version is slated to appear as a patch soon. Hopefully, this will reduce the potential hang in the test program to a mere failure. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19974
[Bug middle-end/19974] incorrect complex division on ia-64 with flag_complex_method = 2
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-16
12:41 ---
I think I have identified the problem.
The hang itself is probably caused by a Lapack bug, because slarrb is
only fed 0. and NaN as arguments.
The reason why this is so is probably due to a problem in complex
division with flag_complex_method = 2. Here's a test case:
$ cat c-tst.c
#include stdio.h
#include math.h
#include complex.h
int main()
{
float complex a,b,c;
a = 1.e20-I*1.e12;
b = 1. - I*1.e-8;
c = a/b;
printf(%.5g %.5g\n,creal(c),cimag(c));
return 0;
}
This has flag_complex_medhod = 2:
$ gcc -B ~/gcc-C2/gcc c-tst.c
$ ./a.out
1e+20 18059
^^
wrong
This has flag_complex_method = 1:
$ gcc -B ~/gcc-C1/gcc c-tst.c
$ ./a.out
1e+20 0
^^
correct
Probably a wrong sign when recovering from overflow in the
new complex division routines.
Adding rth to the cc list.
--
What|Removed |Added
CC||rth at gcc dot gnu dot org
OtherBugsDependingO||18902
nThis||
Summary|Lapack hang in xeigtstc on |incorrect complex division
|ia-64 |on ia-64 with
||flag_complex_method = 2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19974
[Bug middle-end/19974] incorrect complex division on ia-64 with flag_complex_method = 2
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-16 20:51 --- Checking this on i686-unknown-linux-gnu, I find the same result with flag_complex_method=2 as on ia-64. I am also seeing the same result with logarithmic scaling (using frexp and ldexp). Maybe I'm being bitten by the decimal fractions not being exactly representable in binary, and the Lapack failure has some other reason. I'll keep looking. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19974
[Bug middle-end/19953] Special-case real + complex arithmetic operation (-ffast-math)
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-15 10:29 --- And in fact this only can happen with -funsafe-math-optimizations (or maybe with -fno-trapping- math because a+0.0 can trap. Hmm... if b is complex and has the value (0., signalling NaN) and a is real with the value 1.0, should a+b trap? I don't think so, but I'm open to discussion on that point. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19953
[Bug middle-end/19974] New: Lapack hang in xeigtstc on ia-64
35 is 69.27 Matrix order= 20, type= 9, seed=1052,3651,3662,3633, result 36 is 2182.68 CST:2 out of 4662 tests failed to pass the threshold CST -- Complex Hermitian eigenvalue problem Matrix types (see xDRVST for details): Special Matrices: 1=Zero matrix. 5=Diagonal: clustered entries. 2=Identity matrix. 6=Diagonal: large, evenly spaced. 3=Diagonal: evenly spaced entries. 7=Diagonal: small, evenly spaced. 4=Diagonal: geometr. spaced entries. Dense Hermitian Matrices: 8=Evenly spaced eigenvals. 12=Small, evenly spaced eigenvals. 9=Geometrically spaced eigenvals. 13=Matrix with random O(1) entries. 10=Clustered eigenvalues. 14=Matrix with large random entries. 11=Large, evenly spaced eigenvals. 15=Matrix with small random entries. Tests performed: See cdrvst.f Matrix order= 20, type= 9, seed=1494,3156,1807,2209, result 101 is 353.18 (wait for a long time...) Program received signal SIGINT, Interrupt. slarrb_ ([EMAIL PROTECTED], d=0x4, l=0x4, ld=0x4, lld=0x4, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], reltol=Cannot access memory at address 0x1 ) at slarrb.f:191 191 TMP = D( N ) + S Current language: auto; currently fortran (gdb) c Continuing. Program received signal SIGINT, Interrupt. slarrb_ ([EMAIL PROTECTED], d=0x7fc07f80, l=0x7fc07f80, ld=0x7fc07f80, lld=0x7fc07f80, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], reltol=Cannot access memory at address 0x0 ) at slarrb.f:195 195DELTA = TWO*DELTA (gdb) c Continuing. Program received signal SIGINT, Interrupt. slarrb_ (n=Cannot access memory at address 0x1 ) at slarrb.f:185 185 DO 70 J = 1, N - 1 (gdb) c Continuing. Program received signal SIGINT, Interrupt. slarrb_ ([EMAIL PROTECTED], d=0x47fc0, l=0x47fc0, ld=0x47fc0, lld=0x47fc0, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], reltol=Cannot access memory at address 0x0 ) at slarrb.f:183 183 S = -RIGHT (gdb) c Continuing. Program received signal SIGINT, Interrupt. 0x4047fd71 in slarrb_ ([EMAIL PROTECTED], d=0x47fc0, l=0x47fc0, ld=0x47fc0, lld=0x47fc0, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], reltol=Cannot access memory at address 0x0 ) at slarrb.f:183 183 S = -RIGHT (gdb) c Continuing. Program received signal SIGINT, Interrupt. 0x4047fe91 in slarrb_ (n=Cannot access memory at address 0x3 ) at slarrb.f:187 187S = S*( LD( J ) / TMP )*L( J ) - RIGHT (gdb) c Continuing. Program received signal SIGINT, Interrupt. 0x40480111 in slarrb_ ([EMAIL PROTECTED], d=0x7fc07fc0, l=0x7fc07fc0, ld=0x7fc07fc0, lld=0x7fc07fc0, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], reltol=Cannot access memory at address 0x3 ) at slarrb.f:191 191 TMP = D( N ) + S (gdb) c Continuing. Program received signal SIGINT, Interrupt. 0x4047fe70 in slarrb_ ([EMAIL PROTECTED], d=0x7fc07fc0, l=0x7fc07fc0, ld=0x7fc07fc0, lld=0x7fc07fc0, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], reltol=Cannot access memory at address 0x1 ) at slarrb.f:186 186TMP = D( J ) + S (gdb) c Continuing. Program received signal SIGINT, Interrupt. slarrb_ ([EMAIL PROTECTED], d=0x600d5cf8, l=0x600d5cf8, ld=0x600d5cf8, lld=0x600d5cf8, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], reltol=Cannot access memory at address 0x1 ) at slarrb.f:187 187S = S*( LD( J ) / TMP )*L( J ) - RIGHT -- Summary: Lapack hang in xeigtstc on ia-64 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P2 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: Thomas dot Koenig at online dot de CC: gcc-bugs at gcc dot gnu dot org GCC target triplet: ia64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19974
[Bug middle-end/19974] Lapack hang in xeigtstc on ia-64
-- What|Removed |Added OtherBugsDependingO||5900 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19974
[Bug middle-end/19974] Lapack hang in xeigtstc on ia-64
-- What|Removed |Added Keywords||wrong-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19974
[Bug middle-end/19974] Lapack hang in xeigtstc on ia-64
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-15 20:14 --- This does not happen on an Athlon-xp with -march=athlon-xp -mfmath=sse. Might be target or 64-bit specific. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19974
[Bug target/18977] [4.0 regression] LAPACK test xeigtsts segfaults with optimization
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-14 12:25 --- I can confirm that this is fixed in the 20050213 snapshot. Both the reduced C test case and the original Fortran routine don't segfault any more. Thanks to whoever fixed this :-) I would suggest adding sl4-error.c to the testsuite, to make sure that this does not regress. Thomas -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18977
[Bug middle-end/19953] New: Special-case real*complex multiplication for flag_complex_method=2
Looking at the following piece of code:
#include math.h
#include complex.h
int main()
{
float a;
complex float b,c;
foo(a, b);
c = a*b;
return creal(c)+cimag(c)0;
}
and compiling this with flag_complex_method=2 and -O3, I find
that the statement is translated to (in t65.optimized) to
# BLOCK 0
# PRED: ENTRY [100.0%] (fallthru,exec)
# aD.2211_25 = V_MAY_DEF aD.2211_1;
# bD.2212_26 = V_MAY_DEF bD.2212_7;
foo (aD.2211, bD.2212);
# D.2217_11 = V_MUST_DEF D.2217_10;
D.2217 = __mulsc3 (aD.2211, 0.0, REALPART_EXPR bD.2212, IMAGPART_EXPR
bD.2212);
return (doubleD.24) REALPART_EXPR D.2217 + (doubleD.24) IMAGPART_EXPR
D.2217 0.0;
# SUCC: EXIT [100.0%]
This costs quite a lot of performance. Multiplying a real number
by a complex number doesn't require any special cases, so the whole
__mulsc3 machinery is not needed here.
$ gcc -v
Using built-in specs.
Target: ia64-unknown-linux-gnu
Configured with: ../gcc-4.0-20050213/configure --prefix=/home/zfkts
--enable-languages=c,f95
Thread model: posix
gcc version 4.0.0 20050213 (experimental)
--
Summary: Special-case real*complex multiplication for
flag_complex_method=2
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Thomas dot Koenig at online dot de
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19953
[Bug middle-end/19953] Special-case real*complex multiplication for flag_complex_method=2
-- What|Removed |Added OtherBugsDependingO||18902 nThis|| Keywords||missed-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19953
[Bug middle-end/19953] Special-case real + complex arithmetic operation
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-14
20:06 ---
Same thing for complex division, where the performance
penalty is probably also pretty severe:
$ cat c-div.c
#include math.h
#include complex.h
int main()
{
float a;
complex float b,c;
foo(a,b);
c = b/a;
return creal(c) + cimag(c) 0;
}
$ gcc -fdump-tree-all-all -O3 -S c-div.c
$ tail -20 c-div.c.t65.optimized
complex floatD.25 c.20D.2363;
complex floatD.25 c.19D.2362;
intD.0 D.2361;
complex floatD.25 D.2360;
complex floatD.25 D.2359;
floatD.21 a.18D.2358;
# BLOCK 0
# PRED: ENTRY [100.0%] (fallthru,exec)
# aD.2354_25 = V_MAY_DEF aD.2354_1;
# bD.2355_26 = V_MAY_DEF bD.2355_5;
foo (aD.2354, bD.2355);
# D.2360_11 = V_MUST_DEF D.2360_10;
D.2360 = __divsc3 (REALPART_EXPR bD.2355, IMAGPART_EXPR bD.2355,
aD.2354,0.0);
return (doubleD.22) REALPART_EXPR D.2360 + (doubleD.22) IMAGPART_EXPR
D.2360 0.0;
# SUCC: EXIT [100.0%]
}
Addition has the same problem. Here, a floating point register is
carefully zeroed in order to add something to it:
$ cat c-add.c
#include math.h
#include complex.h
int main()
{
float a;
complex float b,c;
foo(a,b);
c = b+a;
return creal(c) + cimag(c) 0;
}
$ gcc -fdump-tree-all-all -O3 -S c-add.c
$ tail -20 c-add.c.t65.optimized
doubleD.22 D.2365;
floatD.21 D.2364;
complex floatD.25 c.20D.2363;
complex floatD.25 c.19D.2362;
intD.0 D.2361;
complex floatD.25 D.2360;
complex floatD.25 D.2359;
floatD.21 a.18D.2358;
# BLOCK 0
# PRED: ENTRY [100.0%] (fallthru,exec)
# aD.2354_27 = V_MAY_DEF aD.2354_1;
# bD.2355_28 = V_MAY_DEF bD.2355_7;
foo (aD.2354, bD.2355);
return (doubleD.22) (aD.2354 + REALPART_EXPR bD.2355) + (doubleD.22)
(IMAGPART_EXPR bD.2355 + 0.0) 0.0;
# SUCC: EXIT [100.0%]
}
$ tail -20 c-add.s
leal-4(%ebp), %eax
movl%eax, (%esp)
callfoo
flds-12(%ebp)
fldz
fadds -8(%ebp)
fxch%st(1)
fadds -4(%ebp)
leave
faddp %st, %st(1)
fldz
fucompp
fnstsw %ax
testb $69, %ah
sete%al
movzbl %al, %eax
ret
.size main, .-main
.ident GCC: (GNU) 4.0.0 20050212 (experimental)
.section.note.GNU-stack,,@progbits
If somebody tackles this, it would also be nice if purely
imaginary numbers were also special-cased.
--
What|Removed |Added
Summary|Special-case real*complex |Special-case real + complex
|multiplication for |arithmetic operation
|flag_complex_method=2 |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19953
[Bug middle-end/19953] [4.0 regression] Special-case real + complex arithmetic operation
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-14
22:38 ---
For addition, this is a regression against 3.3.5:
$ cat c-add.c
#include math.h
#include complex.h
int main()
{
float a;
complex float b,c;
foo(a,b);
c = b+a;
return creal(c) + cimag(c) 0;
}
$ /usr/bin/gcc -S -O3 c-add.c
$ tail -20 c-add.s
callfoo
flds-4(%ebp)
flds-8(%ebp)
fxch%st(1)
fadds .LC0
fxch%st(1)
fadds -12(%ebp)
faddp %st, %st(1)
fldz
fucompp
fnstsw %ax
testb $69, %ah
sete%dl
movl%ebp, %esp
popl%ebp
movzbl %dl, %eax
ret
.size main, .-main
.section.note.GNU-stack,,@progbits
.ident GCC: (GNU) 3.3.5 (Debian 1:3.3.5-8)
Note there's only one fldz there, for comparison (which is OK).
--
What|Removed |Added
Summary|Special-case real + complex |[4.0 regression] Special-
|arithmetic operation|case real + complex
||arithmetic operation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19953
[Bug fortran/19936] New: confused error message about implied do loop
$ cat implied_parameter.f90 program main integer, parameter :: i=4 print *,(/(i,i=1,4)/) end program main $ gfortran implied_parameter.f90 In file implied_parameter.f90:3 print *,(/(i,i=1,4)/) 1 Error: Syntax error in COMPLEX constant at (1) $ gfortran -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc/configure --prefix=/home/ig25 --enable-languages=c,f95 Thread model: posix gcc version 4.0.0 20050212 (experimental) -- Summary: confused error message about implied do loop Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: Thomas dot Koenig at online dot de CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19936
[Bug fortran/19928] Reference of constant derived type component causes failure
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-13 17:50 --- Looking at PR 17123 a bit more closely, I think that this is a duplicate. Thomas -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19928
[Bug driver/19848] options passed from -verbose-asm do not adequately reflect optimization
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-10 08:52 --- (In reply to comment #2) There are a gazillion places where we just check if (optimize) without any specific flag. It would be quite a lot of work to introduce flags for all of them, and I'm not sure it's worth it... $ find . -name '*.c' | xargs grep '( *optimize[) =!|]' | wc -l 151 Hmm... It would still be better if this could be at least lumped into an option (maybe -foptimize-misc or whatever) which would still be visible in -fverbose-asm. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19848
[Bug fortran/5900] [g77 gfortran] Lapack regressions since g77 2.95.2
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-10
10:17 ---
It appears the problem is caused by one of the
optimization options that cannot be controlled with
flags.
One suspect is this code snippet from gcc/config/ia64.c :
static bool
ia64_rtx_costs (rtx x, int code, int outer_code, int *total)
{
switch (code)
...
case DIV:
case UDIV:
case MOD:
case UMOD:
/* We make divide expensive, so that divide-by-constant will be
optimized to a multiply. */
*total = COSTS_N_INSNS (60);
return true;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5900
[Bug driver/19825] -fno-loop-optimize2 does not work
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-10 20:31 --- *** This bug has been marked as a duplicate of 19848 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19825
[Bug driver/19848] options passed from -verbose-asm do not adequately reflect optimization
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-10 20:31 --- *** Bug 19825 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19848
[Bug fortran/5900] [g77 gfortran] Lapack regressions since g77 2.95.2
-- Bug 5900 depends on bug 19825, which changed state. Bug 19825 Summary: -fno-loop-optimize2 does not work http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19825 What|Old Value |New Value Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5900
[Bug driver/19848] options passed from -verbose-asm do not adequately reflect optimization
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-10 20:35 --- (In reply to comment #4) $ find . -name '*.c' | xargs grep '[(|!] *optimize[) =!|]' | wc -l 204 Any idea how I should go about further debugging PR 5900? There is a wrong-code for ia-64 there, which apparently depends on one of these 204 places. Thomas -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19848
[Bug fortran/5900] [g77 gfortran] Lapack regressions since g77 2.95.2
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-09 08:12 --- gfortran -c -O1 -fno-tree-ccp -fno-tree-ch -fno-tree-copyrename -fno-tree-dce -fno-tree-dominator-opts -fverbose-asm -fno-unswitch-loops -fno-peel-loops -fno-unroll-loops -fno-tree-dse -fno-tree-fre -fno-tree-loop-im -fno-tree-loop-ivcanon -fno-tree-loop-optimize -fno-tree-lrs -fno-tree-sra -fno-tree-ter -fno-loop-optimize -fverbose-asm ../*.f yields the following options: // options passed: -ffixed-form -auxbase -O1 -fno-tree-ccp -fno-tree-ch // -fno-tree-copyrename -fno-tree-dce -fno-tree-dominator-opts // -fverbose-asm -fno-unswitch-loops -fno-peel-loops -fno-unroll-loops // -fno-tree-dse -fno-tree-fre -fno-tree-loop-im -fno-tree-loop-ivcanon // -fno-tree-loop-optimize -fno-tree-lrs -fno-tree-sra -fno-tree-ter // -fno-loop-optimize // options enabled: -falign-loops -fargument-noalias-global // -fbranch-count-reg -fcommon -fcprop-registers -fdefer-pop // -feliminate-unused-debug-types -ffunction-cse -fgcse-lm // -fguess-branch-probability -fident -fif-conversion -fif-conversion2 // -fivopts -fkeep-static-consts -fleading-underscore -floop-optimize2 // -fmath-errno -fmerge-constants -fomit-frame-pointer -fpeephole // -freg-struct-return -fsched-interblock -fsched-spec // -fsched-stalled-insns-dep -fsplit-ivs-in-unroller -ftrapping-math // -funwind-tables -fverbose-asm -fzero-initialized-in-bss -mgnu-as // -mgnu-ld -minline-float-divide-max-throughput -mdwarf2-asm // -mtune=itanium2 and no change in the failures. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5900
[Bug driver/19848] New: options passed from -verbose-asm do not adequately reflect optimization
This caused me a lot of pain in trying to disable specific optimizations with -O1. $ gfortran -O1 -o dasum-1.s -S -fverbose-asm -fno-loop-optimize -fno-tree-sra -fno-tree-ter -fno-omit-frame-pointer -fno-tree-dse -fno-tree-dominator-opts -fno-tree-ch -fno-tree-fre -fno-merge-constants -fno-cprop-registers -fno-if-conversion2 -fno-defer-pop -fno-tree-lrs -fno-guess-branch-probability -fno-tree-ccp -fno-tree-copyrename -fno-tree-dce -fno-if-conversion ../dasum.f $ gfortran -O0 -o dasum-0.s -S -fverbose-asm ../dasum.f $ diff -u dasum-0.s dasum-1.s | head -30 --- dasum-0.s 2005-02-09 13:38:52.0 +0100 +++ dasum-1.s 2005-02-09 13:38:46.0 +0100 @@ -3,7 +3,12 @@ // GNU F95 version 4.0.0 20050130 (experimental) (ia64-unknown-linux-gnu) // compiled by GNU C version 4.0.0 20050130 (experimental). // GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 -// options passed: -ffixed-form -auxbase-strip -O0 -fverbose-asm +// options passed: -ffixed-form -auxbase-strip -O1 -fverbose-asm +// -fno-loop-optimize -fno-tree-sra -fno-tree-ter -fno-omit-frame-pointer +// -fno-tree-dse -fno-tree-dominator-opts -fno-tree-ch -fno-tree-fre +// -fno-merge-constants -fno-cprop-registers -fno-if-conversion2 +// -fno-defer-pop -fno-tree-lrs -fno-guess-branch-probability -fno-tree-ccp +// -fno-tree-copyrename -fno-tree-dce -fno-if-conversion // options enabled: -falign-loops -fargument-noalias-global // -fbranch-count-reg -fcommon -feliminate-unused-debug-types // -ffunction-cse -fgcse-lm -fident -fivopts -fkeep-static-consts @@ -23,531 +28,280 @@ .prologue 14, 35 .save ar.pfs, r36 alloc r36 = ar.pfs, 3, 4, 2, 0 // + adds r16 = -8, r12 //,, .vframe r37 mov r37 = r12 //, - adds r12 = -80, r12 //,, + adds r12 = -32, r12 //,, + mov r17 = ar.lc //, + ;; + .savepsp ar.lc, 8 + st8 [r16] = r17, 8 //, mov r38 = r1//, As you can see from the fact that there is no differences in the options enabled: list in the assembly output, the assembly should be identical. However, the compilation results are very different, so -O1 seems to do other, undocumented things. $ cat ../dasum.f double precision function dasum(n,dx,incx) c c takes the sum of the absolute values. c jack dongarra, linpack, 3/11/78. c modified 3/93 to return if incx .le. 0. c modified 12/3/93, array(1) declarations changed to array(*) c double precision dx(*),dtemp integer i,incx,m,mp1,n,nincx c dasum = 0.0d0 dtemp = 0.0d0 if( n.le.0 .or. incx.le.0 )return if(incx.eq.1)go to 20 c ccode for increment not equal to 1 c nincx = n*incx do 10 i = 1,nincx,incx dtemp = dtemp + dabs(dx(i)) 10 continue dasum = dtemp return c ccode for increment equal to 1 c c cclean-up loop c 20 m = mod(n,6) if( m .eq. 0 ) go to 40 do 30 i = 1,m dtemp = dtemp + dabs(dx(i)) 30 continue if( n .lt. 6 ) go to 60 40 mp1 = m + 1 do 50 i = mp1,n,6 dtemp = dtemp + dabs(dx(i)) + dabs(dx(i + 1)) + dabs(dx(i + 2)) * + dabs(dx(i + 3)) + dabs(dx(i + 4)) + dabs(dx(i + 5)) 50 continue 60 dasum = dtemp return end -- Summary: options passed from -verbose-asm do not adequately reflect optimization Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P2 Component: driver AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: Thomas dot Koenig at online dot de CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19848
[Bug driver/19848] options passed from -verbose-asm do not adequately reflect optimization
-- What|Removed |Added OtherBugsDependingO||5900 nThis|| Version|unknown |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19848
[Bug fortran/5900] [g77 gfortran] Lapack regressions since g77 2.95.2
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-09 12:43 --- See PR 19848. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5900
[Bug driver/19848] options passed from -verbose-asm do not adequately reflect optimization
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-09
21:19 ---
Same thing on i686-pc-linux-gnu with the gcc driver:
$ cat main.c
int main()
{
return 0;
}
$ gcc -S -fverbose-asm -o main-o0.s main.c
$ gcc -S -fno-cprop-registers -fno-defer-pop -fno-guess-branch-probability
-fno-if-conversion -fno-if-conversion2 -fno-loop-optimize -fno-merge-constants
-fno-tree-ccp -fno-tree-ch -fno-tree-copyrename -fno-tree-dce
-fno-tree-dominator-opts -fno-tree-dse -fno-tree-fre -fno-tree-lrs -fno-tree-sra
-fno-tree-ter -fverbose-asm -O1 -o main-o1.s main.c
$ diff -u main-o0.s main-o1.s
--- main-o0.s 2005-02-09 22:17:54.0 +0100
+++ main-o1.s 2005-02-09 22:18:14.0 +0100
@@ -2,7 +2,12 @@
# GNU C version 4.0.0 20050208 (experimental) (i686-pc-linux-gnu)
# compiled by GNU C version 4.0.0 20050203 (experimental).
# GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
-# options passed: -mtune=pentiumpro -auxbase-strip -fverbose-asm
+# options passed: -mtune=pentiumpro -auxbase-strip -O1
+# -fno-cprop-registers -fno-defer-pop -fno-guess-branch-probability
+# -fno-if-conversion -fno-if-conversion2 -fno-loop-optimize
+# -fno-merge-constants -fno-tree-ccp -fno-tree-ch -fno-tree-copyrename
+# -fno-tree-dce -fno-tree-dominator-opts -fno-tree-dse -fno-tree-fre
+# -fno-tree-lrs -fno-tree-sra -fno-tree-ter -fverbose-asm
# options enabled: -falign-loops -fargument-alias -fbranch-count-reg
# -fcommon -feliminate-unused-debug-types -ffunction-cse -fgcse-lm -fident
# -fivopts -fkeep-static-consts -fleading-underscore -floop-optimize2
@@ -21,13 +26,8 @@
movl%esp, %ebp #,
subl$8, %esp#,
andl$-16, %esp #,
- movl$0, %eax#, tmp60
- addl$15, %eax #, tmp61
- addl$15, %eax #, tmp62
- shrl$4, %eax#, tmp63
- sall$4, %eax#, tmp64
- subl%eax, %esp # tmp64,
- movl$0, %eax#, D.1118
+ subl$16, %esp #,
+ movl$0, %eax#, result
leave
ret
.size main, .-main
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19848
[Bug fortran/5900] [g77 gfortran] Lapack regressions since g77 2.95.2
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-08 09:24 --- On ia64-unknown-linux-gnu, -O1 produces the same result that -O3 does. Here's a shell script that I currently use for shotgun testing of single optimization options: for a in \ branch-count-reg cprop-registers \ function-cse gcse-lm \ guess-branch-probability if-conversion if-conversion2 \ ivopts keep-static-consts loop-optimize \ loop-optimize2 math-errno \ peephole sched-interblock sched-spec \ sched-stalled-insns-dep split-ivs-in-unroller \ tree-ccp tree-ch tree-copyrename tree-dce tree-dominator-opts \ tree-dse tree-fre tree-loop-im tree-loop-ivcanon \ tree-loop-optimize tree-lrs tree-sra tree-ter do echo $a rm *.o gfortran -c -f$a ../*.f \ gfortran -g *.o -o xeigtstd \ xeigtstd ded.in $a.out done The directory above contains all the Fortran routines necessary for xeigtstd, namely alahdg.f derrgg.f dget51.f dlaev2.f dlarrb.f dlatms.f dsbev.f dsyevr.f alareq.f derrhs.f dget52.f dlaexc.f dlarre.f dlatrd.f dsbevx.f dsyevx.f alasum.f derrst.f dget53.f dlafts.f dlarrf.f dlatrs.f dsbgst.f dsygs2.f alasvm.f dgbbrd.f dget54.f dlag2.f dlarrv.f dlctes.f dsbgvd.f dsygst.f chkxer.f dgbmv.f dgetc2.f dlagge.f dlartg.f dlctsx.f dsbgv.f dsygvd.f dasum.f dgebak.f dggbak.f dlags2.f dlartv.f dlsets.f dsbgvx.f dsygv.f daxpy.f dgebal.f dggbal.f dlagsy.f dlaruv.f dnrm2.f dsbmv.f dsygvx.f dbdsdc.f dgebd2.f dgges.f dlagtf.f dlas2.f dopbl3.f dsbt21.f dsymm.f dbdsqr.f dgebrd.f dggesx.f dlagts.f dlascl.f dopgtr.f dsbtrd.f dsymv.f dbdt01.f dgecon.f dggev.f dlagv2.f dlasd0.f dopla2.f dscal.f dsyr2.f dbdt02.f dgees.f dggevx.f dlahd2.f dlasd1.f dopla.f dsecnd.f dsyr2k.f dbdt03.f dgeesx.f dggglm.f dlahqr.f dlasd2.f dopmtr.f dsgt01.f dsyr.f dchkbb.f dgeev.f dgghrd.f dlahrd.f dlasd3.f dorg2l.f dslect.f dsyrk.f dchkbd.f dgeevx.f dgglse.f dlakf2.f dlasd4.f dorg2r.f dspevd.f dsyt21.f dchkbk.f dgegs.f dggqrf.f dlaln2.f dlasd5.f dorgbr.f dspev.f dsyt22.f dchkbl.f dgegv.f dggrqf.f dlamch.f dlasd6.f dorghr.f dspevx.f dsytd2.f dchkec.f dgehd2.f dggsvd.f dlamrg.f dlasd7.f dorgl2.f dspgst.f dsytrd.f dchkee.f dgehrd.f dggsvp.f dlangb.f dlasd8.f dorglq.f dspgvd.f dtbmv.f dchkgg.f dgelq2.f dglmts.f dlange.f dlasda.f dorgql.f dspgv.f dtgevc.f dchkgk.f dgelqf.f dgqrts.f dlanhs.f dlasdq.f dorgqr.f dspgvx.f dtgex2.f dchkgl.f dgemm.f dgrqts.f dlansb.f dlasdt.f dorgr2.f dspmv.f dtgexc.f dchkhs.f dgemv.f dgsvts.f dlansp.f dlaset.f dorgrq.f dspr2.f dtgsen.f dchksb.f dgeqpf.f dhgeqz.f dlanst.f dlasq1.f dorgtr.f dspr.fdtgsja.f dchkst.f dgeqr2.f dhsein.f dlansy.f dlasq2.f dorm2l.f dspt21.f dtgsna.f dckglm.f dgeqrf.f dhseqr.f dlanv2.f dlasq3.f dorm2r.f dsptrd.f dtgsy2.f dckgqr.f dger.fdhst01.f dlapll.f dlasq4.f dormbr.f dstebz.f dtgsyl.f dckgsv.f dgerq2.f dlabad.f dlapmt.f dlasq5.f dormhr.f dstech.f dtpmv.f dcklse.f dgerqf.f dlabrd.f dlapy2.f dlasq6.f dorml2.f dstect.f dtpsv.f dcopy.f dgesc2.f dlacon.f dlapy3.f dlasr.f dormlq.f dstedc.f dtrevc.f ddot.fdgesdd.f dlacpy.f dlaqtr.f dlasrt.f dormql.f dstegr.f dtrexc.f ddrges.f dgesvd.f dladiv.f dlar1v.f dlassq.f dormqr.f dstein.f dtrmm.f ddrgev.f dget02.f dlae2.f dlar2v.f dlasum.f dormr2.f dsteqr.f dtrmv.f ddrgsx.f dget10.f dlaebz.f dlaran.f dlasv2.f dormrq.f dsterf.f dtrsen.f ddrgvx.f dget22.f dlaed0.f dlarfb.f dlaswp.f dormtr.f dstevd.f dtrsm.f ddrvbd.f dget23.f dlaed1.f dlarf.f dlasy2.f dort01.f dstev.f dtrsna.f ddrves.f dget24.f dlaed2.f dlarfg.f dlatb9.f dort03.f dstevr.f dtrsv.f ddrvev.f dget31.f dlaed3.f dlarft.f dlatdf.f dpbstf.f dstevx.f dtrsyl.f ddrvgg.f dget32.f dlaed4.f dlarfx.f dlatm1.f dpotf2.f dstt21.f idamax.f ddrvsg.f dget33.f dlaed5.f dlarfy.f dlatm2.f dpotrf.f dstt22.f ieeeck.f ddrvst.f dget34.f dlaed6.f dlarge.f dlatm3.f dpptrf.f dsvdch.f ilaenv.f ddrvsx.f dget35.f dlaed7.f dlargv.f dlatm4.f dpteqr.f dsvdct.f lsame.f ddrvvx.f dget36.f dlaed8.f dlarhs.f dlatm5.f dpttrf.f dswap.f lsamen.f derrbd.f dget37.f dlaed9.f dlarnd.f dlatm6.f drot.fdsxt1.f xerbla.f derrec.f dget38.f dlaeda.f dlarnv.f dlatme.f drscl.f dsyevd.f xlaenv.f derred.f dget39.f dlaein.f dlarot.f dlatmr.f dsbevd.f dsyev.f There is no single optimization option that will cause any failures for xeigtstd for ded.in *sigh*. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5900
[Bug fortran/5900] [g77 gfortran] Lapack regressions since g77 2.95.2
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-08 15:36 --- (In reply to comment #34) Please, try the opposite: disable optimizations through -O1 -fno-[optnam] and see if you find out something. Still the same four failures with #! /bin/sh for a in \ verbose-asm \ cprop-registers defer-pop \ guess-branch-probability if-conversion if-conversion2 \ loop-optimize \ loop-optimize2 merge-constants omit-frame-pointer \ split-ivs-in-unroller trapping-math \ tree-ccp tree-ch tree-copyrename tree-dce tree-dominator-opts \ tree-dse tree-fre tree-loop-im tree-loop-ivcanon \ tree-loop-optimize tree-lrs tree-sra tree-ter do echo $a rm *.o gfortran -c -g -O1 -fno-$a ../*.f \ gfortran -c -g -O0 ../dlasy2.f \ gfortran -g *.o -o xeigtstd \ xeigtstd ded.in $a.out done The separate compilation of dlasy2.f is to get around the segfault in PR 18977. Any important optimization options that I've missed? Thomas -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5900
[Bug driver/19825] New: -fno-loop-optimize2 does not work
Apparently, the compiler likes -floop-optimize2 very much and does not want it to be switched off: $ gcc -O1 -fno-loop-optimize -fno-loop-optimize2 -S -fverbose-asm example.c $ cat example.s .file example.c .pred.safe_across_calls p1-p5,p16-p63 // GNU C version 4.0.0 20050130 (experimental) (ia64-unknown-linux-gnu) // compiled by GNU C version 4.0.0 20050130 (experimental). // GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 // options passed: -auxbase -O1 -fno-loop-optimize -fno-loop-optimize2 // -fverbose-asm // options enabled: -falign-loops -fargument-alias -fbranch-count-reg // -fcommon -fcprop-registers -fdefer-pop -feliminate-unused-debug-types // -ffunction-cse -fgcse-lm -fguess-branch-probability -fident // -fif-conversion -fif-conversion2 -fivopts -fkeep-static-consts // -fleading-underscore -floop-optimize2 -fmath-errno -fmerge-constants // -fomit-frame-pointer -fpeephole -freg-struct-return -fsched-interblock // -fsched-spec -fsched-stalled-insns-dep -fsplit-ivs-in-unroller // -ftrapping-math -ftree-ccp -ftree-ch -ftree-copyrename -ftree-dce // -ftree-dominator-opts -ftree-dse -ftree-fre -ftree-loop-im // -ftree-loop-ivcanon -ftree-loop-optimize -ftree-lrs -ftree-sra // -ftree-ter -funwind-tables -fverbose-asm -fzero-initialized-in-bss // -mgnu-as -mgnu-ld -minline-float-divide-max-throughput -mdwarf2-asm // -mtune=itanium2 .text .align 16 .global main# .proc main# main: .prologue .body mov r8 = r0 // result, br.ret.sptk.many b0 // ;; .endp main# .ident GCC: (GNU) 4.0.0 20050130 (experimental) $ gcc -dumpmachine ia64-unknown-linux-gnu -- Summary: -fno-loop-optimize2 does not work Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: driver AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: Thomas dot Koenig at online dot de CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19825
[Bug driver/19825] -fno-loop-optimize2 does not work
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-08 16:36 --- This blocks testing of compiler options in PR 5900. -- What|Removed |Added OtherBugsDependingO||5900 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19825
[Bug fortran/5900] [g77 gfortran] Lapack regressions since g77 2.95.2
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-08 16:36 --- I am not sure which of my tests of compiler options were actually testing anything. There appears to be a bug in passing at least one -fno - switch (see PR 19825). Thomas -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5900
