[Bug fortran/31608] wrong types in array transfer
--- Comment #2 from pault at gcc dot gnu dot org 2007-04-18 09:36 --- (In reply to comment #1) > Adding pault, as he's the likely culprit :) > Richard and Tobi, I am a bit trapped right now, as chairman of a review meeting; I'll try to look at it this evening. On the face of it, character*(20) .ne. array of character*(1) should not be allowed! Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31608
[Bug libfortran/31286] cshift uses uninitialized variables
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-04-18 09:47 --- Subject: Bug 31286 Author: fxcoudert Date: Wed Apr 18 09:47:28 2007 New Revision: 123944 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123944 Log: PR libfortran/31286 PR libfortran/31296 * intrinsics/cshift0.c (cshift0): Initialize sstride[0] and rstride[0]. * intrinsics/unpack_generic.c (unpack0, unpack0_char): Zero the array structures we pass to unpack_internal. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/ChangeLog-2004 trunk/libgfortran/ChangeLog-2005 trunk/libgfortran/ChangeLog-2006 trunk/libgfortran/intrinsics/cshift0.c trunk/libgfortran/intrinsics/unpack_generic.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31286
[Bug libfortran/31296] Uninitialized variable in _gfortran_unpack0_char
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-04-18 09:47 --- Subject: Bug 31296 Author: fxcoudert Date: Wed Apr 18 09:47:28 2007 New Revision: 123944 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123944 Log: PR libfortran/31286 PR libfortran/31296 * intrinsics/cshift0.c (cshift0): Initialize sstride[0] and rstride[0]. * intrinsics/unpack_generic.c (unpack0, unpack0_char): Zero the array structures we pass to unpack_internal. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/ChangeLog-2004 trunk/libgfortran/ChangeLog-2005 trunk/libgfortran/ChangeLog-2006 trunk/libgfortran/intrinsics/cshift0.c trunk/libgfortran/intrinsics/unpack_generic.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31296
[Bug libfortran/31296] Uninitialized variable in _gfortran_unpack0_char
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-04-18 09:53 --- Fixed on mainline. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31296
[Bug libfortran/31286] cshift uses uninitialized variables
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-04-18 09:53 --- Fixed on mainline. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31286
[Bug tree-optimization/21462] if statement not converted to MIN_EXPR
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-04-18 10:00 --- Micha, this one should be catched by your conditional store patch. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org, matz at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21462
[Bug fortran/31298] Uninitialized variable in f951 (in read_module)
--- Comment #5 from burnus at gcc dot gnu dot org 2007-04-18 10:18 --- (In reply to comment #4) Another thing which needs to be supported: use mod, only: operator(foo) => operator(.op.), & operator(bar) => operator(.op.), & operator(op), & operator(+) => operator(.op.) namely: importing the same operator under different names. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31298
[Bug fortran/31615] testsuite failure in gfortran.dg/vect/vect-5.f90
--- Comment #3 from dorit at il dot ibm dot com 2007-04-18 10:18 --- > Created dump file using -fdump-tree-vect-details thanks. So I don't understand why we expect to version for 3 different data-references, since there are only 2 in the loop that is vectorized. But then I wonder why we don't see the same failure on ia64? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31615
[Bug fortran/31608] wrong types in array transfer
--- Comment #3 from burnus at gcc dot gnu dot org 2007-04-18 10:21 ---
(In reply to comment #1)
>
> if (any (Up ("AbCdEfGhIjKlM") .ne. (/"ABCDEFGHIJKLM"/))) call abort ()
> contains
> Character (len=20) Function Up (string)
>
>
> It looks like it's comparing a CHARACTER*20 (= Up's result) to an array of
> characters (= the array constructor).
I think this is not allowed in Fortran 95 mode, but I'm not 100% sure about
Fortran 2003; I think it is also not allowed, but one has to check the standard
(cf. PR30940).
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
CC||burnus at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31608
[Bug fortran/31608] wrong types in array transfer
--- Comment #4 from pault at gcc dot gnu dot org 2007-04-18 10:44 ---
(In reply to comment #2)
Changing the comparison to
if (Up ("AbCdEfGhIjKlM") .ne. "ABCDEFGHIJKLM") call abort ()
gets rid of the problem.
I have clearly exposed something extremely unpleasant in ANY or the comparison
that needs to be stopped by the front-end.
I will test and commit the modified testcase, under the "obvious" rule,
tonight. In addition, I will pin down the frontend bug and transmute this PR
to reflect that.
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31608
[Bug fortran/31197] [4.3/4.2 regression^2] TRANSPOSE/RESHAPE and strings
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-04-18 10:54 --- Hey, this has turned into an ICE on today's trunk. Cool, it's gonna be easier to work on! :) As I pointed out in http://gcc.gnu.org/ml/fortran/2007-04/msg00295.html, this makes it a potential double regression, which is nasty. Program received signal SIGSEGV, Segmentation fault. 0x0048048b in gfc_conv_function_call (se=0x7fbfffe750, sym=0xe372c0, arg=0xe004f0, append_args=0x0) at /utmp/coudert/gfortran/trunk/gcc/fortran/trans-expr.c:2053 2053 need_interface_mapping = ((sym->ts.type == BT_CHARACTER (gdb) where #0 0x0048048b in gfc_conv_function_call (se=0x7fbfffe750, sym=0xe372c0, arg=0xe004f0, append_args=0x0) at /utmp/coudert/gfortran/trunk/gcc/fortran/trans-expr.c:2053 #1 0x0048a685 in gfc_conv_intrinsic_funcall (se=0x7fbfffe750, expr=0xe35fe0) at /utmp/coudert/gfortran/trunk/gcc/fortran/trans-intrinsic.c:1514 #2 0x0048c341 in gfc_conv_intrinsic_function (se=0x7fbfffe750, expr=0xe35fe0) at /utmp/coudert/gfortran/trunk/gcc/fortran/trans-intrinsic.c:3945 #3 0x00480ae7 in gfc_conv_function_expr (se=0x7fbfffe750, expr=Variable "expr" is not available. ) at /utmp/coudert/gfortran/trunk/gcc/fortran/trans-expr.c:2698 #4 0x0046f449 in gfc_add_loop_ss_code (loop=0x7fbfffe920, ss=0xe37110, subscript=0 '\0') at /utmp/coudert/gfortran/trunk/gcc/fortran/trans-array.c:1803 #5 0x0046fcb6 in gfc_conv_loop_setup (loop=0x7fbfffe920) at /utmp/coudert/gfortran/trunk/gcc/fortran/trans-array.c:3232 #6 0x0048d881 in gfc_trans_transfer (code=Variable "code" is not available. ) at /utmp/coudert/gfortran/trunk/gcc/fortran/trans-io.c:1850 #7 0x00467ae5 in gfc_trans_code (code=0xe2b9a0) at /utmp/coudert/gfortran/trunk/gcc/fortran/trans.c:605 #8 0x0048fa82 in build_dt (function=0x2a984c5540, code=0xe36cc0) at /utmp/coudert/gfortran/trunk/gcc/fortran/trans-io.c:1507 #9 0x00467b09 in gfc_trans_code (code=0xe36cc0) at /utmp/coudert/gfortran/trunk/gcc/fortran/trans.c:581 #10 0x0047b437 in gfc_generate_function_code (ns=0xe2b1c0) at /utmp/coudert/gfortran/trunk/gcc/fortran/trans-decl.c:3181 -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org Severity|normal |major Keywords||ice-on-valid-code Known to fail||4.3.0 4.2.0 Known to work||4.1.2 Last reconfirmed|2007-03-16 13:25:05 |2007-04-18 10:54:17 date|| Summary|wrong code generated with |[4.3/4.2 regression^2] |TRANSPOSE/RESHAPE and |TRANSPOSE/RESHAPE and |strings |strings http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31197
[Bug libfortran/31604] Segfault at runtime on I/O with OpenMP and static linking
--- Comment #7 from dfranke at gcc dot gnu dot org 2007-04-18 11:14 --- See also: PR30471, PR30613 and PR31400 :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31604
[Bug fortran/31618] New: backspace intrinsic is not working on an unformatted file
Using backspace when reading an unformatted file after a read error does not
work except if it is on the first record.
The code below show the problem. This code write 3 couples of integer values in
an unformatted file called 'foo' and close it.
File is reopen for read.
Then it reads the first couple of values. It's OK.
Then it try to read 3 values and detects the error (only 2 values in the
record).
The code use backspace to go back at the begining of this record and try to
read again this record, but with only 2 values.
The values obtained are wrong.
Trying to read 3 values at the begining of the file, using backspace and
reading again only 2 values works.
Code:
PROGRAM gfort
IMPLICIT NONE
INTEGER :: x, z, count
INTEGER :: nx, nz,LocalTimeStep
OPEN (21,FILE='foo',form='UNFORMATTED',err=101)
REWIND(21)
x=140
z=170
WRITE(21) x,z
WRITE(6,*)'writing x (',x,') and z(',z,') in foo'
x=14
z=17
WRITE(21) x,z
WRITE(6,*)'writing x (',x,') and z(',z,') in foo'
x=1400
z=1700
WRITE(21) x,z
WRITE(6,*)'writing x (',x,') and z(',z,') in foo'
CLOSE(21)
OPEN (21,FILE='foo',form='UNFORMATTED',status='OLD',err=101)
REWIND(21)
WRITE(6,*)'reading first x, z in foo'
x=-1
z=-1
READ(21,err=103,end=103) x,z
WRITE(6,*)'x (',x,') and z(',z,')'
WRITE(6,*)'reading x, z and LocalTimeStep in foo'
nx=-1
nz=-1
READ(21,iostat=count) nx,nz,LocalTimeStep
WRITE(6,*)'x (',nx,') and z(',nz,') and LocalTimeStep(',
+ LocalTimeStep,')'
IF (count.NE.0) THEN
WRITE(6,*)'reading again x and z in foo'
BACKSPACE(21)
nx=-1
nz=-1
READ(21,err=103,end=103) nx,nz
LocalTimeStep=0.0
WRITE(6,*)'x (',nx,') and z(',nz,') and LocalTimeStep(',
+ LocalTimeStep,')'
ENDIF
CLOSE(21)
STOP 'OK'
101 WRITE(6,*) 'foo n''a pas ete trouve.'
STOP 'FAILED'
103 WRITE(6,*) 'Erreur de lecture'
CLOSE(21)
STOP 'FAILED'
END PROGRAM gfort
NORMAL RESULT:
./a.out
writing x ( 140 ) and z( 170 ) in foo
writing x ( 14 ) and z( 17 ) in foo
writing x (1400 ) and z(1700 ) in foo
reading first x, z in foo
x ( 140 ) and z( 170 )
reading x, z and LocalTimeStep in foo
x ( 14 ) and z( 17 ) and LocalTimeStep( 0 )
reading again x and z in foo
x ( 14 ) and z( 17 ) and LocalTimeStep( 0 )
OK
Gfortran RESULT (WRONG) :
./a.out
writing x ( 140 ) and z( 170 ) in foo
writing x ( 14 ) and z( 17 ) in foo
writing x (1400 ) and z(1700 ) in foo
reading first x, z in foo
x ( 140 ) and z( 170 )
reading x, z and LocalTimeStep in foo
x ( 14 ) and z( 17 ) and LocalTimeStep( 17 )
reading again x and z in foo
x ( 17 ) and z( 8 ) and LocalTimeStep( 0 )
STOP OK
--
Summary: backspace intrinsic is not working on an unformatted
file
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Patrick dot Begou at hmg dot inpg dot fr
GCC build triplet: gcc version 4.3.0 20070418 (experimental)
GCC target triplet: i386-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31618
[Bug tree-optimization/21463] min/max and references
--- Comment #9 from rguenth at gcc dot gnu dot org 2007-04-18 12:45 --- Subject: Bug 21463 Author: rguenth Date: Wed Apr 18 12:45:09 2007 New Revision: 123946 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123946 Log: 2007-04-18 Richard Guenther <[EMAIL PROTECTED]> PR tree-optimization/19431 PR tree-optimization/21463 * tree-pass.h (pass_phiprop): Declare. * passes.c (init_optimization_passes): New phiprop pass. * tree-ssa-forwprop.c (struct phiprop_d): New structure. (phivn_valid_p): New helper function. (phiprop_insert_phi): Likewise. (propagate_with_phi): Likewise. (tree_ssa_phiprop): New propagator propagating loads through phi nodes if profitable. * gcc.c-torture/execute/20070212-1.c: New testcase. * gcc.c-torture/execute/20070212-2.c: Likewise. * gcc.c-torture/execute/20070212-3.c: Likewise. * gcc.dg/tree-ssa/pr19431.c: Likewise. * gcc.dg/tree-ssa/pr21463.c: Likewise. * g++.dg/tree-ssa/pr21463.C: Likewise. * g++.dg/tree-ssa/pr30738.C: Likewise. Added: trunk/gcc/testsuite/g++.dg/tree-ssa/pr21463.C trunk/gcc/testsuite/g++.dg/tree-ssa/pr30738.C trunk/gcc/testsuite/gcc.c-torture/execute/20070212-1.c trunk/gcc/testsuite/gcc.c-torture/execute/20070212-2.c trunk/gcc/testsuite/gcc.c-torture/execute/20070212-3.c trunk/gcc/testsuite/gcc.dg/tree-ssa/pr19431.c trunk/gcc/testsuite/gcc.dg/tree-ssa/pr21463.c Modified: trunk/gcc/ChangeLog trunk/gcc/passes.c trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-pass.h trunk/gcc/tree-ssa-forwprop.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21463
[Bug tree-optimization/19431] missed optimization with ifs and deferencing
--- Comment #18 from rguenth at gcc dot gnu dot org 2007-04-18 12:45 --- Subject: Bug 19431 Author: rguenth Date: Wed Apr 18 12:45:09 2007 New Revision: 123946 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123946 Log: 2007-04-18 Richard Guenther <[EMAIL PROTECTED]> PR tree-optimization/19431 PR tree-optimization/21463 * tree-pass.h (pass_phiprop): Declare. * passes.c (init_optimization_passes): New phiprop pass. * tree-ssa-forwprop.c (struct phiprop_d): New structure. (phivn_valid_p): New helper function. (phiprop_insert_phi): Likewise. (propagate_with_phi): Likewise. (tree_ssa_phiprop): New propagator propagating loads through phi nodes if profitable. * gcc.c-torture/execute/20070212-1.c: New testcase. * gcc.c-torture/execute/20070212-2.c: Likewise. * gcc.c-torture/execute/20070212-3.c: Likewise. * gcc.dg/tree-ssa/pr19431.c: Likewise. * gcc.dg/tree-ssa/pr21463.c: Likewise. * g++.dg/tree-ssa/pr21463.C: Likewise. * g++.dg/tree-ssa/pr30738.C: Likewise. Added: trunk/gcc/testsuite/g++.dg/tree-ssa/pr21463.C trunk/gcc/testsuite/g++.dg/tree-ssa/pr30738.C trunk/gcc/testsuite/gcc.c-torture/execute/20070212-1.c trunk/gcc/testsuite/gcc.c-torture/execute/20070212-2.c trunk/gcc/testsuite/gcc.c-torture/execute/20070212-3.c trunk/gcc/testsuite/gcc.dg/tree-ssa/pr19431.c trunk/gcc/testsuite/gcc.dg/tree-ssa/pr21463.c Modified: trunk/gcc/ChangeLog trunk/gcc/passes.c trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-pass.h trunk/gcc/tree-ssa-forwprop.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19431
[Bug tree-optimization/21463] min/max and references
--- Comment #10 from rguenth at gcc dot gnu dot org 2007-04-18 12:46 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21463
[Bug tree-optimization/19431] missed optimization with ifs and deferencing
--- Comment #19 from rguenth at gcc dot gnu dot org 2007-04-18 12:48 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19431
[Bug tree-optimization/19431] missed optimization with ifs and deferencing
--- Comment #20 from pluto at agmk dot net 2007-04-18 13:02 --- (In reply to comment #19) > Fixed. > will it be backported to 4.2? it improves perf. of big stl-based apps. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19431
[Bug c/31619] New: runtime error after compiling - segmentaion fault
The following error occured when I try to run the c program after compiling
with gcc
Segmentation fault
The C program is as follows
//testr.c
#include
main () {
float rd[9331200];
int jd = 5;
printf("jd = %d\n",jd);
}
//Compile command
gcc testr.c
The output of the command gcc -v -save-temps testr.c is
Using built-in specs.
Target: i386-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-libgcj-multifile
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk
--disable-dssi --enable-plugin
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --with-cpu=generic
--host=i386-redhat-linux
Thread model: posix
gcc version 4.1.1 20070105 (Red Hat 4.1.1-52)
/usr/libexec/gcc/i386-redhat-linux/4.1.1/cc1 -E -quiet -v testr.c
-mtune=generic -fpch-preprocess -o testr.i
ignoring nonexistent directory
"/usr/lib/gcc/i386-redhat-linux/4.1.1/../../../../i386-redhat-linux/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/local/include
/usr/lib/gcc/i386-redhat-linux/4.1.1/include
/usr/include
End of search list.
/usr/libexec/gcc/i386-redhat-linux/4.1.1/cc1 -fpreprocessed testr.i -quiet
-dumpbase testr.c -mtune=generic -auxbase testr -version -o testr.s
GNU C version 4.1.1 20070105 (Red Hat 4.1.1-52) (i386-redhat-linux)
compiled by GNU C version 4.1.1 20070105 (Red Hat 4.1.1-52).
GGC heuristics: --param ggc-min-expand=98 --param ggc-min-heapsize=128403
Compiler executable checksum: 214030a0e6434d311d2ad3d31ac1aa7d
as -V -Qy -o testr.o testr.s
GNU assembler version 2.17.50.0.6-2.el5 (i386-redhat-linux) using BFD version
2.17.50.0.6-2.el5 20061020
/usr/libexec/gcc/i386-redhat-linux/4.1.1/collect2 --eh-frame-hdr -m elf_i386
--hash-style=gnu -dynamic-linker /lib/ld-linux.so.2
/usr/lib/gcc/i386-redhat-linux/4.1.1/../../../crt1.o
/usr/lib/gcc/i386-redhat-linux/4.1.1/../../../crti.o
/usr/lib/gcc/i386-redhat-linux/4.1.1/crtbegin.o
-L/usr/lib/gcc/i386-redhat-linux/4.1.1 -L/usr/lib/gcc/i386-redhat-linux/4.1.1
-L/usr/lib/gcc/i386-redhat-linux/4.1.1/../../.. testr.o -lgcc --as-needed
-lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed
/usr/lib/gcc/i386-redhat-linux/4.1.1/crtend.o
/usr/lib/gcc/i386-redhat-linux/4.1.1/../../../crtn.o
--
Summary: runtime error after compiling - segmentaion fault
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gourish2k at yahoo dot co dot in
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31619
[Bug fortran/31620] New: Zeroing one component of array of derived types zeros the whole structure.
If an array of a derived type is declared and one component is set to zero then all the components are set to zero. The following program illustrates the problem: program test_assign type my_type integer :: a integer :: b end type my_type type(my_type), dimension(1) :: mine mine%b=4 print *, "Should be 4: ", mine%b mine%a=1 print *, "Should be 4: ", mine%b mine%a=0 print *, "Should be 4: ", mine%b print *, "Should be 0: ", mine%a end program test_assign The output of this is: Should be 4:4 Should be 4:4 Should be 4:0 Should be 0:0 Note the third line. -- Summary: Zeroing one component of array of derived types zeros the whole structure. Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: David at ham dot dropbear dot id dot au GCC build triplet: RHEL4 x86_64 GCC host triplet: RHEL4 x86_64 GCC target triplet: RHEL4 x86_64 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31620
[Bug fortran/31620] [regression 4.3] Zeroing one component of array of derived types zeros the whole structure.
--- Comment #1 from dfranke at gcc dot gnu dot org 2007-04-18 14:09 --- Strange, indeed. Can confirm this behaviour for 4.3 (20070417), neither 4.1.1 nor 4.2 (20070417) exhibit the problem. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to fail||4.3.0 Known to work||4.1.1 4.2.0 Last reconfirmed|-00-00 00:00:00 |2007-04-18 14:09:12 date|| Summary|Zeroing one component of|[regression 4.3] Zeroing one |array of derived types zeros|component of array of |the whole structure.|derived types zeros the ||whole structure. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31620
[Bug bootstrap/31523] bootstrap xgcc internal compiler error (using -O3)
--- Comment #7 from anirkko at insel dot ch 2007-04-18 14:24 --- (In reply to comment #2) > Can you try without setting the CFLAGS, etc. because what might be happening > is > the base compiler miscompiling the new compiler? > The bootstrap works fine with all flags equal to '-O2' Still worrysome, because somewhere in the installation instructions, it is recommended to bootstrap the compiler with the flags one intends to later use it with. Sometime, will try to find out whether the offending flag is -O3 or -mcpu=supersparc. Does it mean the offending flag is broken and should never be used at all? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31523
[Bug fortran/31620] [regression 4.3] Zeroing one component of array of derived types zeros the whole structure.
--- Comment #2 from dfranke at gcc dot gnu dot org 2007-04-18 14:25 --- $> cat pr31620.f90 program test_assign type my_type integer :: a integer :: b end type my_type type(my_type), dimension(1) :: mine! note that MINE is an array mine%b=4 mine%a=1 print *, mine mine%a=0 print *, mine end program test_assign $> gfortran-svn -g -fdump-tree-original pr31620.f90 The dump shows between the print statements: [...] (void) __builtin_memset ((void *) &mine, 0, 8); [...] which obviously is the culprit. Adding Roger Sayle as CC as he worked on this a while ago. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||roger at eyesopen dot com Keywords||wrong-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31620
[Bug target/29826] __attribute__ dllimport makes optimization crash on cygwin
--- Comment #13 from arcangelpip at hotmail dot com 2007-04-18 14:34 --- I'm going to try again since it seems my last post was just ignored. The test case works fine on 4.2 but it still occurs under some circumstances. As I stated in my previous post Gettext is where it dies but I can compile the original test case with no problems. The compiler I am using is a linux to mingw cross compiler configured as I stated below. It was built from mondays source with a 4.2 bootstrap compiler and binutils 2.17. To reiterate, the simple testcase works fine, but I still have this bug appear while compiling gettext using the cross compiler targetted at mingw. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29826
[Bug bootstrap/31523] bootstrap xgcc internal compiler error (using -O3)
--- Comment #8 from ebotcazou at gcc dot gnu dot org 2007-04-18 14:35 --- > The bootstrap works fine with all flags equal to '-O2' Great, thanks for the confirmation. > Still worrysome, because somewhere in the installation instructions, it is > recommended to bootstrap the compiler with the flags one intends to later > use it with. Please point me to this and I'll immediately propose to delete it. 99% of the testing of the compiler is done with the default bootstrap settings. > Does it mean the offending flag is broken and should never be used at all? -mcpu=supersparc is totally untested these days so bugs can be expected, yes. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31523
[Bug tree-optimization/19431] missed optimization with ifs and deferencing
--- Comment #21 from rguenth at gcc dot gnu dot org 2007-04-18 14:45 --- Ha, sure not ;) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19431
[Bug fortran/31207] [4.2.1 only] advance="no" and tabs
--- Comment #11 from jvdelisle at gcc dot gnu dot org 2007-04-18 14:51 --- output.tar attachment should go to pr31409 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31207
[Bug fortran/31551] ice in fold_convert, at fold-const.c:2330
--- Comment #10 from zingale at gmail dot com 2007-04-18 14:58 --- Thanks for the help. I'll put together a tarball and pass it to you privately as instructed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31551
[Bug fortran/31618] backspace intrinsic is not working on an unformatted file
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2007-04-18 15:01 --- hmm, I will investigate. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31618
[Bug driver/31621] New: -x c++ causes failures with c language sources.
$ echo 'int main(){return 0;}' >tmp.c && gcc -xc++ tmp.c
/tmp/ccGESvie.o:(.eh_frame+0x12): undefined reference to `__gxx_personality_v0'
libstdc++'s configure missdetects in this way the -Wl,--gc-sections
support in the linker.
(...)
configure:8405: checking for ld that supports -Wl,--gc-sections
configure:8430:
/home/users/pluto/rpm/BUILD/gcc-4.2.0-20070316/builddir/./gcc/xgcc
-B/home/users/pluto/rpm/BUILD/gcc-4.2.0-20070316/builddir/./gcc/
-B/usr/x86_64-pld-linux/bin/ -B/usr/x86_64-pld-linux/lib/ -isystem
/usr/x86_64-pld-linux/include -isystem /usr/x86_64-pld-linux/sys-include -o
conftest -x c++ -Wl,--gc-sections -Wl,--as-needed conftest.c >&5
/tmp/ccobXMwl.o:(.eh_frame+0x12): undefined reference to `__gxx_personality_v0'
collect2: ld returned 1 exit status
configure:8436: $? = 1
--
Summary: -x c++ causes failures with c language sources.
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: driver
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pluto at agmk dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31621
[Bug tree-optimization/31602] Overflow warning causes GDB -Werror build failure
--- Comment #2 from ian at airs dot com 2007-04-18 15:14 --- Yes, the warning is happening because gcc relies on undefined signed overflow when assuming that it will execute the loop at least once. Of course when using -fwrapv the loop should not be executed at all when num > INT_MAX - 10. I'll try to figure out what to do about this. -- ian at airs dot com changed: What|Removed |Added CC|ian at gcc dot gnu dot org |ian at airs dot com Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-04-18 15:14:27 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31602
[Bug driver/31621] -x c++ causes failures with c language sources.
--- Comment #1 from schwab at suse dot de 2007-04-18 15:24 --- Either use g++ or link with -lstdc++. -- schwab at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31621
[Bug driver/31621] -x c++ causes failures with c language sources.
--- Comment #2 from schwab at suse dot de 2007-04-18 15:27 --- Reopening since it's a problem with libstdc++ configure. -- schwab at suse dot de changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31621
[Bug fortran/31197] [4.3/4.2 regression^2] TRANSPOSE/RESHAPE and strings
--- Comment #3 from tobi at gcc dot gnu dot org 2007-04-18 15:56 --- (In reply to comment #2) > 2053 need_interface_mapping = ((sym->ts.type == BT_CHARACTER My patch from r123924 (the one about magic numbers) touched gfc_add_interface_mapping. Can you try reverting it, otherwise I'll try tonight. In that case it would be a silly typo. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31197
[Bug c/31619] runtime error after compiling - segmentaion fault
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-04-18 15:59 --- You just happen to overflow the stack. The stack limit is too low for your array. This is not a GCC bug, either use limit or ulimit depening on the shell you use to figure out the stack limit. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID Summary|runtime error after|runtime error after |compiling - segmentaion |compiling - segmentaion |fault |fault http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31619
[Bug java/31622] New: Segment violation in the “toString” method on a mathematical expression
CONTEXT:
- GCC version: 4.3.0.
- Front end: gcj.
- Operating System: Linux Debian, kernel 2.6.17-2-686.
- Hardware: CPU Intel Pentium 4 Xeon, 3 GHz, 16 KB cache L1, 2 MB cache L2.
RAM: 1 GB.
There is a segment violation error when compiling the following code:
public class Fail
{
public static void main(String args[]) {
long a=5, b=2, r;
r=(a-b).toString();
}
}
The line number 5, r=(a-b).toString();, causes a segment violation during the
compilation:
gcj -C -Wall Fail.java
--
Summary: Segment violation in the “toString” method
on a mathematical expression
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: eduardo dot iniesta at aquiline dot es
GCC build triplet: i486-linux-gnu
GCC host triplet: Intel Pentium 4 Xeon
GCC target triplet: i486-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31622
[Bug c++/31623] New: Template Inheritance Regression from 3.3 (accessing protected member from sublcass)
The following code (simplified for clarity), does not compile on GCC versions
past 4.0, but compiles fine with gcc-3.3 and other non-GCC compilers (MSVC++,
etc):
#include
template
class VectorBase
{
protected:
char * memory;
public:
VectorBase()
{
memory = NULL;
}
};
template
struct Vector : public VectorBase
{
T * ptr()
{
return (T*)memory;
}
};
int main() {
return 0;
}
--
Summary: Template Inheritance Regression from 3.3 (accessing
protected member from sublcass)
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: myrd at projectmagma dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31623
[Bug gcov-profile/31624] New: gprof names are mangled under 64 bit compilation
Problem description
===
Function names are mangled in gprof output. Such name mangling in gprof
output only occurs when compiling with g++ under 64 bit modes
Compiler output
===
The name HelloWorld is mangled.
Flat profile:
Each sample counts as 0.01 seconds.
no time accumulated
% cumulative self self total
time seconds secondscalls Ts/call Ts/call name
0.00 0.00 0.007 0.00 0.00 ._Z10HelloWorldv
0.00 0.00 0.001 0.00 0.00 .__gmon_start__
^LCall graph
granularity: each sample hit covers 4 byte(s) no time propagated
index % timeself childrencalled name
0.000.00 7/7 .main [9]
[1] 0.00.000.00 7 ._Z10HelloWorldv [1]
---
1 .__gmon_start__ [2]
0.000.00 1/1 .atexit [8]
[2] 0.00.000.00 1+1 .__gmon_start__ [2]
1 .__gmon_start__ [2]
---
^L
Index by function name
[1] ._Z10HelloWorldv[2] .__gmon_start__Expected output
===
Flat profile:
Each sample counts as 0.01 seconds.
no time accumulated
% cumulative self self total
time seconds secondscalls Ts/call Ts/call name
0.00 0.00 0.007 0.00 0.00 HelloWorld()
0.00 0.00 0.001 0.00 0.00 global constructors keyed
to _Z10HelloWorldv
0.00 0.00 0.001 0.00 0.00
__static_initialization_and_destruction_0(int, int)
^L
Call graph
granularity: each sample hit covers 4 byte(s) no time propagated
index % timeself childrencalled name
0.000.00 7/7 main [10]
[11] 0.00.000.00 7 HelloWorld() [11]
---
0.000.00 1/1 __do_global_ctors_aux [14]
[12] 0.00.000.00 1 global constructors keyed to
_Z10HelloWorldv [12]
0.000.00 1/1
__static_initialization_and_destruction_0(int, int) [13]
---
0.000.00 1/1 global constructors keyed to
_Z10HelloWorldv [12]
[13] 0.00.000.00 1
__static_initialization_and_destruction_0(int, int) [13]
---
^L
Index by function name
[12] global constructors keyed to _Z10HelloWorldv [11] HelloWorld() [13]
__static_initialization_and_destruction_0(int, int)
Steps to reproduce the problem
==
#
/usr/bin/g++ -m64 -pg -o hello hello.C >STEP1.out 2>&1
#
./hello >hello.out 2>STEP2.out
#
/usr/bin/gprof -b hello gmon.out >gprof.out 2>STEP6.out
/* Listing of hello.C */
#include
void HelloWorld()
{
cout << "Hello, World\n";
}
int main()
{
for(int i=0; i<7; i++)
HelloWorld();
return(0);
}
--
Summary: gprof names are mangled under 64 bit compilation
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: gcov-profile
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vkywong at ca dot ibm dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31624
[Bug libfortran/27740] libgfortran should use versioned symbols
--- Comment #9 from dfranke at gcc dot gnu dot org 2007-04-18 17:06 --- What happend to this? I can't find the patch in the tracker anymore, but there's no indication in the ChangeLog(s) that is was applied. The ML discussion went somewhat off track after a while. Any indication to pursue this path further? -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27740
[Bug libfortran/31299] Use getpwuid(geteuid()) instead of getlogin() for GETLOG()
--- Comment #14 from dfranke at gcc dot gnu dot org 2007-04-18 17:26 --- As FX kindly provided a patch in comment #13, are there any plans to pick it up and commit it? -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31299
[Bug tree-optimization/31625] New: decimal float comparison after conversion no longer folded
Test gcc.dg/dfp/convert-dfp-fold.c started failing on powerpc-linux with this patch: http://gcc.gnu.org/viewcvs?view=rev&rev=123719 r123719 | dnovillo | 2007-04-11 16:14:06 + (Wed, 11 Apr 2007) The test, which is compiled with -O, converts between decimal and binary floating types, compares the results against constants, and calls link_error for miscompares. All of the values can be represented in both relevant data types and the original value is known, so the comparisons should always be folded. Since the patch above was added, a comparison for a _Decimal128 converted from double is not folded, and there are calls to __dpd_extenddftd, __dpd_netd2, and link_error. Oddly enough, removing almost any other comparison from the test causes the test to pass, so I wasn't able to come up with a smaller testcase. -- Summary: decimal float comparison after conversion no longer folded Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: janis at gcc dot gnu dot org GCC target triplet: powerpc-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31625
[Bug libfortran/31299] Use getpwuid(geteuid()) instead of getlogin() for GETLOG()
--- Comment #15 from fxcoudert at gcc dot gnu dot org 2007-04-18 17:57 --- (In reply to comment #14) > As FX kindly provided a patch in comment #13, are there any plans to pick it > up > and commit it? As I said, I'm not sure it's the best thing to do, because it gives a warning for static linking: ../../../../trunk/libgfortran/intrinsics/getlog.c:97: warning: Using 'getpwuid' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking I wonder if there's any way to avoid this warning by using other functions. (I tried the reentrant ones, but it gives the same warning.) I'll handle this. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-03-23 21:28:54 |2007-04-18 17:57:14 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31299
[Bug java/31622] Segment violation in the “toString” method on a mathematical expression
--- Comment #1 from tromey at gcc dot gnu dot org 2007-04-18 18:12 --- Are you sure you are using gcj 4.3? I see a SEGV with 4.1 and 4.2. But with 4.3 I see an error: opsy. gcj -C Fail.java Fail.java:5: error: Cannot invoke toString() on the primitive type long r=(a-b).toString(); 1 problem (1 error) (Note that, in all likelihood, we won't fix front end bugs of this nature in 4.1 or 4.2.) -- tromey at gcc dot gnu dot org changed: What|Removed |Added CC||tromey at gcc dot gnu dot ||org Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31622
[Bug fortran/31614] Inability to read ascii text with generic 'f' format
--- Comment #2 from Catherine dot M dot Moroney at jpl dot nasa dot gov 2007-04-18 18:16 --- Subject: Re: Inability to read ascii text with generic 'f' format read(10,*) doesn't work. I have access to two other compilers (SGI and Portland Group) and both of them accepted the read(10,(10x,f,f)') syntax and worked properly. read(10,'(a,f,f)') also doesn't work with gfortran, though it does with both of the other compilers. gfortran refuses to compile a formatting string with just an 'f', complaining that the format string doesn't have a non- negative width. Catherine On Apr 17, 2007, at 7:45 PM, jvdelisle at gcc dot gnu dot org wrote: > > > --- Comment #1 from jvdelisle at gcc dot gnu dot org 2007-04-18 > 03:44 --- > I think you should just use read(10,*) or better yet, read the whole > line into > a single string and search for the "=" in the string, noting > the_position, then > use read(stringname(the_position:),*) input list > > In other words you can specify a string section in the read to exclude > all the > junk in the front part. > > Others chime in. :) We can not change the behavior of fortran, but we > can use > it. > > > -- > > jvdelisle at gcc dot gnu dot org changed: > >What|Removed |Added > --- > - > Status|UNCONFIRMED |RESOLVED > Resolution||INVALID > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31614 > > --- You are receiving this mail because: --- > You reported the bug, or are watching the reporter. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31614
[Bug libfortran/27740] libgfortran should use versioned symbols
--- Comment #10 from burnus at gcc dot gnu dot org 2007-04-18 18:19 --- > What happend to this? I can't find the patch in the tracker anymore, but > there's no indication in the ChangeLog(s) that is was applied. The last patch was applied, i.e. gfortran uses now _gfortran_ prefixes to for the libgfortran symbols. However, what is missing are named symbols. That is: One may change the library, but one keeps the old version. Using the version information, old programs get the old version. This is used, e.g., by the glibc. If you use objdump -t libc.so.6, you find: [EMAIL PROTECTED] <--- old version for old programs sched_getaffinity@@GLIBC_2.3.4 <--- new interface This was done in the old patch http://gcc.gnu.org/ml/gcc-patches/2006-05/msg01186.html That patch got stuck with ISO_C_BINDINGS. We still don't have them, but we have _gfortran_ prefixes. Thus one could probably start updating that patch even though ISO_C_BINDING is not yet in gfortran. -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||burnus at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27740
[Bug c++/31623] Template Inheritance Regression from 3.3 (accessing protected member from sublcass)
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-04-18 18:19 --- This is not a GCC bug, please read: http://gcc.gnu.org/gcc-3.4/changes.html -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31623
[Bug tree-optimization/31625] [4.3 Regression] decimal float comparison after conversion no longer folded
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||missed-optimization Summary|decimal float comparison|[4.3 Regression] decimal |after conversion no longer |float comparison after |folded |conversion no longer folded Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31625
[Bug target/30572] [4.3 Regression] libstdc++ links against /libgcc_s.1.dylib instead of $(prefix)/lib/libgcc_s.1.dylib
--- Comment #3 from echristo at apple dot com 2007-04-18 18:44 --- As a note, this is due to the make install bit of libgcc when putting things back into the gcc build dir we set $(slibdir) to null and then the darwin install name ends up being set to $(slibdir)/libgcc_s.1.dylib which ends up being /libgcc_s.1.dylib. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30572
[Bug libfortran/31604] Segfault at runtime on I/O with OpenMP and static linking
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2007-04-18 18:47 --- *** This bug has been marked as a duplicate of 30471 *** -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31604
[Bug libgomp/30471] OpenMP with static linking fails in fortran on amd64
--- Comment #9 from fxcoudert at gcc dot gnu dot org 2007-04-18 18:47 --- *** Bug 31604 has been marked as a duplicate of this bug. *** -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30471
[Bug other/31400] enable static linking of support libraries through -static-libXY
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-04-18 18:48 --- I certainly agree that we should have an option to ask the driver to link libgfortran statically. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-04-18 18:48:48 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31400
[Bug libfortran/27740] libgfortran should use versioned symbols
--- Comment #11 from jb at gcc dot gnu dot org 2007-04-18 19:05 --- (In reply to comment #10) > > What happend to this? I can't find the patch in the tracker anymore, but > > there's no indication in the ChangeLog(s) that is was applied. > > The last patch was applied, i.e. gfortran uses now _gfortran_ prefixes to for > the libgfortran symbols. > > However, what is missing are named symbols. To use the proper term, symbol versioning is not yet implemented. Obviusly, symbols do have names. > That is: One may change the > library, but one keeps the old version. Using the version information, old > programs get the old version. This is used, e.g., by the glibc. If you use > objdump -t libc.so.6, you find: > [EMAIL PROTECTED] <--- old version for old programs > sched_getaffinity@@GLIBC_2.3.4 <--- new interface Yes. For the longer version see http://gcc.gnu.org/wiki/SymbolVersioning and links therein. > This was done in the old patch > http://gcc.gnu.org/ml/gcc-patches/2006-05/msg01186.html > That patch got stuck with ISO_C_BINDINGS. We still don't have them, but we > have > _gfortran_ prefixes. Thus one could probably start updating that patch even > though ISO_C_BINDING is not yet in gfortran. Actually, we don't need ISO_C_BINDING anymore for this; the original reason was that the Fortran standard doesn't allow procedure names to begin with "_", so the idea was to use ISO_C_BINDING to mangle the symbol name (to get the names to begin with "_gfortran"). However, as explained in #5, we now have -fallow-leading-underscore (undocumented, for internal use only) option for exactly this purpose. The reason why the patch is in limbo (besides me being busy with real life :( ) is that while it worked fine under Linux, it turned out that it doesn't work on many other platforms since on those platforms the C library don't contain all the C99 stuff that libgfortran needs and thus libgfortran apparently uses its own implementations instead. Or something like that. So to make the patch work one would have to, if it works, make the map file a superset of the needed symbols for all platforms we support. If that doesn't work, I guess one would have to generate the map file during build time (ugh). Or just disable symbol versioning for those [EMAIL PROTECTED] platforms that can't even get a C99 libc done correctly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27740
[Bug libfortran/31299] Use getpwuid(geteuid()) instead of getlogin() for GETLOG()
--- Comment #16 from dfranke at gcc dot gnu dot org 2007-04-18 19:15 --- FX, which version of glibc do you have installed? I applied your patch to an otherwise unpatched tree and do not get any warnings, neither at compile time of libgfortran(*) nor while compiling/linking a binary (a hello-world in this case, glibc-2.5). When exactly do you get that warning? (*) `rm getlog.*; make` in the build directory to make sure I didn't miss anything. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31299
[Bug tree-optimization/19431] missed optimization with ifs and deferencing
--- Comment #22 from pluto at agmk dot net 2007-04-18 19:18 --- (In reply to comment #21) > Ha, sure not ;) > and wait another years for 4.3 release. it sux. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19431
[Bug fortran/31627] New: -bounds-check doesn't check lower bound of assumed-sized array
The following code should tell us we have an out-of-bounds access at runtime: $ cat a.f90 subroutine foo(a) integer a(*), i i = 0 a(i) = 42 end subroutine foo program test integer x(42) call foo(x) end program test $ gfortran a.f90 -fbounds-check && ./a.out -- Summary: -bounds-check doesn't check lower bound of assumed-sized array Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: accepts-invalid, diagnostic Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fxcoudert at gcc dot gnu dot org OtherBugsDependingO 27766 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31627
[Bug fortran/31627] -bounds-check doesn't check lower bound of assumed-sized array
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Known to fail||4.3.0 Last reconfirmed|-00-00 00:00:00 |2007-04-18 19:19:42 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31627
[Bug libfortran/31299] Use getpwuid(geteuid()) instead of getlogin() for GETLOG()
--- Comment #17 from fxcoudert at gcc dot gnu dot org 2007-04-18 19:21 --- (In reply to comment #16) > nor while compiling/linking > a binary (a hello-world in this case, glibc-2.5) It happens when you compile and link statically a Fortran code that uses GETLOG(). I've ended up convincing myself that this was still the right thing to do. I'll test and commit the patch soon. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31299
[Bug tree-optimization/19431] missed optimization with ifs and deferencing
--- Comment #23 from pinskia at gcc dot gnu dot org 2007-04-18 19:21 --- (In reply to comment #22) > and wait another years for 4.3 release. it sux. GCC 4.3 is the one of the few compilers to do this optimization. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19431
[Bug fortran/31197] [4.3/4.2 regression^2] TRANSPOSE/RESHAPE and strings
--- Comment #4 from tobi at gcc dot gnu dot org 2007-04-18 19:29 --- The segfault is present with r123923, so it's not my patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31197
[Bug libfortran/31299] Use getpwuid(geteuid()) instead of getlogin() for GETLOG()
--- Comment #18 from dfranke at gcc dot gnu dot org 2007-04-18 19:39 --- > It happens when you compile and link statically a Fortran code > that uses GETLOG(). Confirmed. But if and only if it uses GETLOG(). Thus, it's not too bad. From comment #13, I assumed that the warning is issued all the time, whenever linking is done. > I'll test and commit the patch soon. The docs should be updated accordingly, especially the part referring to getlogin(3) ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31299
[Bug c/31628] New: stdcall function is miscompiled
Testcase is extracted from Wine. /home/marcus/projects/gcc/BIN/bin/gcc -m32 -fPIC -O2 -o reg reg.i ./reg Segmentation fault (I did not try the i586 version of the compiler.) Looking at the disassembly the stdcall function is compiled as: foo: pushl %ebp movl%esp, %ebp pushl %ebx call__i686.get_pc_thunk.bx addl$_GLOBAL_OFFSET_TABLE_, %ebx subl$4, %esp movl$0, (%esp) call[EMAIL PROTECTED] addl$4, %esp popl%ebx popl%ebp ret It does adjust the stackframe after the call to bar wrongly, either it should not do it, or just emit a "leave". -- Summary: stdcall function is miscompiled Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: marcus at jet dot franken dot de GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: i586-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31628
[Bug c/31628] stdcall function is miscompiled
--- Comment #1 from marcus at jet dot franken dot de 2007-04-18 19:44 --- Created an attachment (id=13389) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13389&action=view) reg.i gcc -fPIC -O2 -m32 reg.i -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31628
[Bug c/31628] stdcall function is miscompiled
--- Comment #2 from marcus at jet dot franken dot de 2007-04-18 19:45 --- i bisected gcc to find the regression and it was apparently introduced by revision 123146. 2007-03-22 Richard Henderson <[EMAIL PROTECTED]> * config/i386/i386.c (ix86_function_regparm): Early exit for 64-bit; don't increase local_regparm with force_align_arg_pointer check. (ix86_function_sseregparm): Assert 32-bit. (type_has_variadic_args_p): New. [...] -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31628
[Bug c/31628] stdcall function is miscompiled
--- Comment #3 from marcus at jet dot franken dot de 2007-04-18 19:46 --- the interesting part is that the declaration is just slightly incompatible with the actual definition. If I remove the prototype the problem goes away. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31628
[Bug libfortran/27740] libgfortran should use versioned symbols
--- Comment #12 from jb at gcc dot gnu dot org 2007-04-18 19:49 --- > The reason why the patch is in limbo (besides me being busy with real life :( > ) > is that while it worked fine under Linux, it turned out that it doesn't work > on > many other platforms since on those platforms the C library don't contain all > the C99 stuff that libgfortran needs and thus libgfortran apparently uses its > own implementations instead. Or something like that. So to make the patch work > one would have to, if it works, make the map file a superset of the needed > symbols for all platforms we support. Actually, it looks like this comparatively simple "superset" strategy could work, at least according to myself a few months ago: http://gcc.gnu.org/ml/gcc-patches/2006-11/msg00353.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27740
[Bug c++/30567] -fPIC -O3 optimizer bug (32-bit target only)
--- Comment #17 from hjl at lucon dot org 2007-04-18 20:00 ---
Testcase in comment #16 failed on ia32, x86-64 and ia64 with -O3. 051t.alias3
dump looks strange. 102t.final_cleanup dump is:
[EMAIL PROTECTED] bad]$ cat x.cc.102t.final_cleanup
;; Function int main() (main)
int main() ()
{
int SR.19;
:
return SR.19 == 1 == 0;
}
[EMAIL PROTECTED] bad]$
--
hjl at lucon dot org changed:
What|Removed |Added
CC||hjl at lucon dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30567
[Bug c++/30567] -fPIC -O3 optimizer bug (32-bit target only)
--- Comment #18 from hjl at lucon dot org 2007-04-18 20:02 ---
(In reply to comment #17)
> Testcase in comment #16 failed on ia32, x86-64 and ia64 with -O3. 051t.alias3
> dump looks strange. 102t.final_cleanup dump is:
>
> [EMAIL PROTECTED] bad]$ cat x.cc.102t.final_cleanup
>
> ;; Function int main() (main)
>
> int main() ()
> {
> int SR.19;
>
> :
> return SR.19 == 1 == 0;
>
> }
> [EMAIL PROTECTED] bad]$
>
I used a modified version to return 0 when success:
[EMAIL PROTECTED] 30567]$ cat x.cc
template
struct const_ref
{
const T* begin;
const_ref(const T* b) : begin(b) {}
};
template
T sum(const_ref const& a)
{
T result = 0;
for(unsigned i=0;i<1;i++) result += a.begin[i];
return result;
}
struct tiny_plain
{
int elems[2];
tiny_plain() { elems[0]=1; }
};
struct vec3 : tiny_plain {};
struct mat3
{
int type() const { return sum(const_ref(vec3().elems)) == 1; }
};
int main() { return mat3().type() ? 0 :1; }
[EMAIL PROTECTED] 30567]$
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30567
[Bug gcov-profile/31624] gprof names are mangled under 64 bit compilation
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-04-18 20:04 --- gprof is not part of GCC, it is part of binutils. The problem is that gprof is not stripping out the dot part of the symbol. Report this to the binutils folks. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31624
[Bug target/31628] stdcall function is miscompiled
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-04-18 20:16 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rth at gcc dot gnu dot org, ||rguenth at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-04-18 20:16:43 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31628
[Bug fortran/31629] New: option to make module entities PRIVATE by default
I prefer (but the Fortran standard does NOT require) that all module entities used outside the module should be explicitly declared PUBLIC. g95 has an option -fmodule-private such that g95 -fmodule-private for the code module foo_mod implicit none ! public :: i integer :: i end module foo_mod program main use foo_mod, only: i i = 1 print*,"i=",i end program main gives In file xmod_private.f90:8 use foo_mod, only: i 1 Error: Symbol 'i' referenced at (1) not found in module 'foo_mod' I'd like a similar option in gfortran. Vivek Rao -- Summary: option to make module entities PRIVATE by default Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: vivekrao4 at yahoo dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31629
[Bug fortran/31614] Inability to read ascii text with generic 'f' format
--- Comment #3 from kargl at gcc dot gnu dot org 2007-04-18 21:03 --- (In reply to comment #2) > Subject: Re: Inability to read ascii text with generic 'f' format > > read(10,*) doesn't work. I have access to two other compilers > (SGI and Portland Group) and both of them accepted the > read(10,(10x,f,f)') syntax and worked properly. You're obviously using a compiler extension. The Fortran standard clearly defines how the F edit descriptor works. gfortran implements that behavior. I'll note that gfortran implements the Fortran 2003 stream IO feature. This feature should enable you to easily write your own custom parsing routine. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31614
[Bug tree-optimization/31227] [4.3 Regression] -Warray-bounds doesn't play together with loop optimizations
--- Comment #6 from mueller at gcc dot gnu dot org 2007-04-18 21:09 --- Subject: Bug 31227 Author: mueller Date: Wed Apr 18 21:09:21 2007 New Revision: 123958 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123958 Log: 2007-04-18 Dirk Mueller <[EMAIL PROTECTED]> PR diagnostic/31227 * tree-vrp.c (search_for_addr_array): New. (check_array_bounds): Suppress warning about address taken of array refs if its not de-referenced. * gcc.dg/Warray-bounds-3.c: New. Added: trunk/gcc/testsuite/gcc.dg/Warray-bounds-3.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vrp.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31227
[Bug tree-optimization/31227] [4.3 Regression] -Warray-bounds doesn't play together with loop optimizations
--- Comment #7 from mueller at gcc dot gnu dot org 2007-04-18 21:10 --- Fixed in 4.3. -- mueller at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31227
[Bug c++/31617] [4.3 Regression] Segfault in integer_zerop, called via ipa-type-escape.c
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31617
[Bug middle-end/31617] [4.3 Regression] Segfault in integer_zerop, called via ipa-type-escape.c
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-04-18 21:38 --- 13207 return integer_zerop (int_const_binop (TRUNC_MOD_EXPR, 13208top, bottom, 0)); (gdb) p debug_generic_expr (top) 4 $1 = void (gdb) p debug_generic_expr (bottom) 0 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31617
[Bug c++/30567] -fPIC -O3 optimizer bug (32-bit target only)
--- Comment #19 from hjl at lucon dot org 2007-04-18 21:47 --- For for(unsigned i=0;i<1;i++) result += a.begin[i]; x.ii.004t.gimple looks like const int * D.2454; long unsigned int D.2455; long unsigned int D.2456; const int * D.2457; const int * D.2458; D.2455 = (long unsigned int) i; D.2456 = D.2455 * 4; D.2457 = (const int *) D.2456; D.2458 = D.2454 + D.2457; Why array index is a pointer? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30567
[Bug middle-end/31617] [4.3 Regression] Segfault in integer_zerop, called via ipa-type-escape.c
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-04-18 21:57 ---
1469tree size_of_op0_points_to = TYPE_SIZE_UNIT (TREE_TYPE
(op0type));
and size_of_op0_points_to is a zero constant.
Reduced testcase:
struct polynomial {
~polynomial ();
};
void spline_rep1()
{
new polynomial[0];
}
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2007-04-18 21:57:07
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31617
[Bug c++/30567] -fPIC -O3 optimizer bug
--- Comment #20 from hjl at lucon dot org 2007-04-18 22:11 --- build_array_ref calls return build_indirect_ref (cp_build_binary_op (PLUS_EXPR, ar, ind), "array indexing"); with ar as pointer and ind as integer. cp_build_binary_op turns ind into pointer and we wind up with D.2455 = (long unsigned int) i; D.2456 = D.2455 * 4; D.2457 = (const int *) D.2456; D.2458 = D.2454 + D.2457; -- hjl at lucon dot org changed: What|Removed |Added CC||mark at codesourcery dot com GCC build triplet|i686-pc-linux-gnu | GCC host triplet|i686-pc-linux-gnu | GCC target triplet|i686-pc-linux-gnu | Summary|-fPIC -O3 optimizer bug (32-|-fPIC -O3 optimizer bug |bit target only)| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30567
[Bug target/31628] stdcall function is miscompiled
--- Comment #5 from rth at gcc dot gnu dot org 2007-04-18 22:14 --- Reproducing the problem requires -maccumulate-outgoing-args, as implied by i686 tuning. -- rth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED GCC host triplet|x86_64-unknown-linux-gnu| GCC target triplet|i586-unknown-linux-gnu |i686-* Last reconfirmed|2007-04-18 20:16:43 |2007-04-18 22:14:05 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31628
[Bug fortran/31630] New: ICE on nasty derived types code
The following code (original code courtesy of Mike Zingale, reduced by yours
truly) gives an ICE with current mainline:
module box_module
type box
integer :: m = 0
end type box
end module box_module
module sort_box_module
contains
subroutine heapsort_box(cmp)
interface
subroutine cmp(a)
use box_module
type(box) :: a
end subroutine cmp
end interface
optional :: cmp
end subroutine heapsort_box
end module sort_box_module
module boxarray_module
use box_module
implicit none
type boxarray
type(box), allocatable :: bxs(:)
end type boxarray
contains
subroutine boxarray_build_l(ba)
type(boxarray) :: ba
allocate(ba%bxs(1))
end subroutine boxarray_build_l
subroutine boxarray_sort()
use sort_box_module
call heapsort_box
end subroutine boxarray_sort
end module boxarray_module
The ICE is:
boxarray.f90: In function boxarray_build_l:
boxarray.f90:34: internal compiler error: in fold_convert, at fold-const.c:2330
And its backtrace is:
Breakpoint 1, fold_convert (type=0xb7c2dbd0, arg=0xb7c2f33c)
at ../../../trunk/gcc/fold-const.c:2330
2330 gcc_unreachable ();
(gdb) where
#0 fold_convert (type=0xb7c2dbd0, arg=0xb7c2f33c)
at ../../../trunk/gcc/fold-const.c:2330
#1 0x080c8e25 in gfc_trans_scalar_assign (lse=0xbfb26f64, rse=0xbfb26f3c, ts=
{type = BT_DERIVED, kind = 0, derived = 0x88b79d0, cl = 0x0},
l_is_temp=1 '\001', r_is_var=0 '\0')
at ../../../trunk/gcc/fortran/trans-expr.c:3438
#2 0x080cda79 in gfc_trans_assignment_1 (expr1=0x88ce5d0, expr2=0x88cf018,
init_flag=1 '\001') at ../../../trunk/gcc/fortran/trans-expr.c:3833
#3 0x080cdd45 in gfc_trans_assignment (expr1=0x88ce5d0, expr2=0x88cf018,
init_flag=96 '`') at ../../../trunk/gcc/fortran/trans-expr.c:3973
#4 0x080ce911 in gfc_trans_init_assign (code=0x88cead8)
at ../../../trunk/gcc/fortran/trans-expr.c:3979
#5 0x080b0226 in gfc_trans_code (code=0x88cead8)
at ../../../trunk/gcc/fortran/trans.c:485
#6 0x080c6045 in gfc_generate_function_code (ns=0x88d0420)
at ../../../trunk/gcc/fortran/trans-decl.c:3217
#7 0x080af648 in gfc_generate_module_code (ns=0x887d7a0)
at ../../../trunk/gcc/fortran/trans.c:693
#8 0x0808b9e5 in gfc_parse_file () at ../../../trunk/gcc/fortran/parse.c:3256
#9 0x080ab10d in gfc_be_parse_file (set_yydebug=0)
at ../../../trunk/gcc/fortran/f95-lang.c:305
#10 0x082f4db2 in toplev_main (argc=13, argv=0xbfb27284)
at ../../../trunk/gcc/toplev.c:1050
#11 0x080ecf3f in main (argc=15, argv=0x0) at ../../../trunk/gcc/main.c:35
I couldn't reduce it further, I think the ICE needs the optional argument to
heapsort_box and the default initialization in type box.
--
Summary: ICE on nasty derived types code
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fxcoudert at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31630
[Bug fortran/31630] [4.3 regression] ICE on nasty derived types code
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-04-18 22:40 --- It's a 4.3 regression, because it compiles with 4.2 (although I haven't looked at the generated code). -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org, zingale at gmail dot ||com Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to fail||4.3.0 Known to work||4.2.0 Last reconfirmed|-00-00 00:00:00 |2007-04-18 22:40:32 date|| Summary|ICE on nasty derived types |[4.3 regression] ICE on |code|nasty derived types code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31630
[Bug c++/30567] -O3 optimizer bug
--- Comment #21 from rguenth at gcc dot gnu dot org 2007-04-18 22:47 --- Code in comment #19 is perfectly correct. I can reproduce the difference with the attached testcase and -O -fstrict-aliasing -finline-functions. -fno-strict-aliasing fixes it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30567
[Bug tree-optimization/30567] -O3 optimizer bug
--- Comment #22 from rguenth at gcc dot gnu dot org 2007-04-18 22:56
---
And this is the bug:
# SFT.0_29 = V_MAY_DEF ;
# SFT.1_30 = V_MAY_DEF ;
this_7->elems[0] = 1;
the following is supposed to read it.
# VUSE ;
D.2148_18 = *D.2147_17;
it's interesting that
Points-to sets
this_7 = { D.2141 D.2141.32 }
D.2147_17 = { ANYTHING D.2141 D.2141.32 }
but
Pointed-to sets for pointers in int main()
this_7, name memory tag: NMT.12, is dereferenced, points-to vars: { SFT.0 SFT.1
}
D.2147_17, is dereferenced, points-to anything
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Component|c++ |tree-optimization
Keywords||alias
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30567
[Bug libfortran/30694] minval/maxval with +/-Inf
--- Comment #14 from fxcoudert at gcc dot gnu dot org 2007-04-18 22:59 --- (In reply to comment #13) > The tree stuff is hard, btw. Still trying :-) Tree stuff? Do we generate inline code? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30694
[Bug libfortran/21468] vectorizing libfortran
--- Comment #11 from fxcoudert at gcc dot gnu dot org 2007-04-18 23:01 --- Closing this. We should really open new PRs for different intrinsics, when we have code and perf measurements. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21468
[Bug fortran/31608] wrong types in array transfer
--- Comment #5 from tobi at gcc dot gnu dot org 2007-04-18 23:56 --- For the record, the problem Richard is pointing out is in the body of the function Up, namely in the expression for MERGE, probably caused by TRANSFER. Nevertheless, the accepts-invalid is also an embarassing problem (unless we collectively misunderstand Fortran rules :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31608
[Bug java/27442] gcj segfaults on invalid code (related to 8923?)
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-04-19 02:27 --- *** Bug 31622 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||eduardo dot iniesta at ||aquiline dot es http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27442
[Bug java/31622] Segment violation in the “toString” method on a mathematical expression
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-04-19 02:27 --- This is the same problem as referenced in PR 27442. *** This bug has been marked as a duplicate of 27442 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31622
[Bug fortran/31618] backspace intrinsic is not working on an unformatted file
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2007-04-19 03:47 --- Confirming. g77 does not do it right either. :) -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-04-19 03:47:49 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31618
[Bug fortran/31616] testsuite failures in gfortran.dg/open_errors.f90
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2007-04-19 04:05 --- It looks like this platform has different error messages for a given error. I suggest that this test case be either marked as expected to fail for this platform or we could delete the test case altogether. Another possibility is to pre-process it to check for the different message instead. I am not sure how to do that within the testsuite. #ifdef do this #else do that for example. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31616
[Bug fortran/31616] testsuite failures in gfortran.dg/open_errors.f90
--- Comment #4 from ghazi at gcc dot gnu dot org 2007-04-19 04:49 ---
(In reply to comment #3)
> It looks like this platform has different error messages for a given error.
Yes that's correct. I ran open_errors.exe under the solaris truss command and
saw this:
open64("./", O_RDWR|O_CREAT, 0666) Err#22 EINVAL
So solaris generates EINVAL in this situation. I can easily change the
testcase to also expect this possibility. However I'm not sure how reliable it
is to string compare the english message from strerror as this testcase does.
Anyway, I'll create a patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31616
[Bug fortran/31615] testsuite failure in gfortran.dg/vect/vect-5.f90
--- Comment #4 from ghazi at gcc dot gnu dot org 2007-04-19 05:11 ---
(In reply to comment #3)
> But then I wonder why we don't see the same failure on ia64?
Because the failing part of the testcase is only done on ilp32 targets:
! { dg-final { scan-tree-dump-times "Alignment of access forced using
versioning." 3 "vect" { target { ilp32 && vect_no_align
} } } }
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31615
[Bug fortran/31630] [4.3 regression] ICE on nasty derived types code
--- Comment #2 from pault at gcc dot gnu dot org 2007-04-19 06:32 --- (In reply to comment #1) Move use sort_box_module up to module level and it compiles fine. This is yet another derived type association regression that I would swear is identical to one of the testcases:) It's mine. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2007-04-18 22:40:32 |2007-04-19 06:32:50 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31630
[Bug fortran/31615] testsuite failure in gfortran.dg/vect/vect-5.f90
--- Comment #5 from dorit at il dot ibm dot com 2007-04-19 07:27 ---
(In reply to comment #4)
> (In reply to comment #3)
> > But then I wonder why we don't see the same failure on ia64?
> Because the failing part of the testcase is only done on ilp32 targets:
> ! { dg-final { scan-tree-dump-times "Alignment of access forced using
> versioning." 3 "vect" { target { ilp32 && vect_no_align
> } } } }
ah, ok. so, in that case we probably want to just change the '3' to '2' in the
above test:
Index: testsuite/gfortran.dg/vect/vect-5.f90
===
--- testsuite/gfortran.dg/vect/vect-5.f90 (revision 123954)
+++ testsuite/gfortran.dg/vect/vect-5.f90 (working copy)
@@ -38,7 +38,7 @@
! { dg-final { scan-tree-dump-times "vectorized 1 loops" 1 "vect" } }
! { dg-final { scan-tree-dump-times "Alignment of access forced using peeling"
1 "vect" { xfail { vect_no_align } } } }
! { dg-final { scan-tree-dump-times "Vectorizing an unaligned access" 1 "vect"
{ xfail { vect_no_align } } } }
-! { dg-final { scan-tree-dump-times "Alignment of access forced using
versioning." 3 "vect" { target { ilp32 && vect_no_align } } } }
+! { dg-final { scan-tree-dump-times "Alignment of access forced using
versioning." 2 "vect" { target { ilp32 && vect_no_align } } } }
! We also expect to vectorize one loop for lp64 targets that support
! misaligned access:
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31615
[Bug fortran/31608] wrong types in array transfer
--- Comment #6 from burnus at gcc dot gnu dot org 2007-04-19 07:44 ---
> Nevertheless, the accepts-invalid is also an embarassing problem (unless we
> collectively misunderstand Fortran rules :)
Well, we do.
if (any (Up ("AbCdEfGhIjKlM") .ne. (/"ABCDEFGHIJKLM"/))) stop 'ERROR'
compiles with
- NAG f95 5.1(346)
- g95 -std=f95 -W -Wall -Wextra -pedantic 4.0.3 (g95 0.91!) Feb 23 2007
- ifort -stand f95 -warn all (9.1.040, 10.0.017beta)
- sunf95 -w4 8.3 Build35_2 2006/12/04
And, of cause, it does not have anything to do with Fortran 2003 (The following
would be: up("abcdef") -> function up(string); character(len=1), dimension(:)
:: string).
What we have here is:
7.1.5 Conformability rules for elemental operations
[...]
For all elemental binary operations, the two operands shall be in shape
conformance. In the case where one is a scalar and the other an array, the
scalar is treated as if it were an array of the same shape as the array operand
with every element, if any, of the array equal to the value of the scalar.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31608
