[Bug fortran/38082] string truncated on return from subroutine (calling mkdtemp bind(c))
--- Comment #3 from holst at matmech dot com 2008-11-11 14:25 --- I tried with gcc version: gcc version 4.4.0 20081021 (experimental) [trunk revision 141258] (GCC) and then it works as expected. I will hope Ubuntu will upgrade to 4.3.3 soon! :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38082
[Bug fortran/33664] New: crash on invalid program
gfortran crashes on the compile of the following (invalid) Fortran module. There are two obvious faults with the program: 1. there is no intent 2. there is no dimension to N -- Summary: crash on invalid program Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: holst at matmech dot com GCC build triplet: x86_64-unknown-linux GCC host triplet: x86_64-unknown-linux GCC target triplet: x86_64-unknown-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33664
[Bug fortran/33664] crash on invalid program
--- Comment #1 from holst at matmech dot com 2007-10-05 09:51 --- Created an attachment (id=14301) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14301&action=view) invalid program which crashes latest trunk (gcc (GCC) 4.3.0 20070927 (experimental) [trunk revision 128829]) test.f:0: internal compiler error: Segmentation fault -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33664
[Bug fortran/38082] string truncated on return from subroutine (calling mkdtemp bind(c))
--- Comment #1 from holst at matmech dot com 2008-11-11 13:29 --- Created an attachment (id=16651) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16651&action=view) callbug.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38082
[Bug fortran/38082] New: string truncated on return from subroutine (calling mkdtemp bind(c))
Hi!
I am using the gfortran compiler in Ubuntu 8.10 (gfortran 4.3.2).
I ran into a bug with calling mkdtemp(3) via the BIND(C) feature.
In some way gfortran truncates the string on return from the
Fortran subroutine. All results seems to be Ok inside
the Fortran subroutine but the caller does not get the proper value?
Please look at the examples below and mkdtemp(3) as they explain
better than I can with my poor English. :-)
Wrong results from gfortran:
na56:1d_longtime>gfortran -o callbug callbug.f90
na56:1d_longtime>./callbug
ctemp = /tmp/foo.XX
ctemp after call: /tmp/foo.HMq3kW
template = [/tmp/foo.HMq3kW]
template = .HMq3kW
na56:1d_longtime>
Correct results from sunstudio 12
na56:1d_longtime>sunf95 -o callbug callbug.f90
na56:1d_longtime>./callbug
ctemp = /tmp/foo.XX
ctemp after call: /tmp/foo.lEniI6
template = [/tmp/foo.lEniI6]
template = /tmp/foo.lEniI6
na56:1d_longtime>
I will attach the source code in another post.
Thank you for a great compiler!
Henrik Holst
--
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.3.2-1ubuntu11'
--with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3
--program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug
--enable-objc-gc --enable-mpfr --enable-targets=all --enable-checking=release
--build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu
Thread model: posix
gcc version 4.3.2 (Ubuntu 4.3.2-1ubuntu11)
--
Summary: string truncated on return from subroutine (calling
mkdtemp bind(c))
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: holst at matmech dot com
GCC target triplet: i486-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38082
[Bug fortran/62283] New: SSE optimization fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62283 Bug ID: 62283 Summary: SSE optimization fails Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: holst at matmech dot com If the `value` specifier below is removed, GFortran generates scalar code instead of vectorized code as it should. $ cat saxpy.f subroutine saxpy(alpha,x,y) value alpha real x(4),y(4) y(1)=y(1)+alpha*x(1) y(2)=y(2)+alpha*x(2) y(3)=y(3)+alpha*x(3) y(4)=y(4)+alpha*x(4) end $ gfortran -S -msse2 -O3 saxpy.f $ more saxpy.s
[Bug fortran/62283] SSE optimization fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62283 --- Comment #1 from Henrik Holst --- (forgot to indent the end statement above.) The expected assembler code should be something like: movaps%xmm0, %xmm1 movups(%rdi), %xmm0 shufps$0, %xmm1, %xmm1 movups(%rsi), %xmm2 mulps%xmm1, %xmm0 addps%xmm2, %xmm0 movups%xmm0, (%rsi) ret
[Bug fortran/62283] basic-block vectorization fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62283 --- Comment #4 from Henrik Holst --- Thank you Richard for looking into this issue. You probably know already exactly why this bug appeared. I just wanted to stress the severity of this issue, and especially for Fortran which is often used in "number crunching" applications AND subroutine arguments are passed by reference by default. The following F2008 code works as expected: subroutine test1(x,y) real x(4),y(4) gamma=3.141593 block beta=gamma y(1)=y(1)+beta*x(1) y(2)=y(2)+beta*x(2) y(3)=y(3)+beta*x(3) y(4)=y(4)+beta*x(4) end block end but when `beta=gamma` is replaced with `beta=alpha` it again fails and generates scalar code. So I ask: Does this bug force *ALL* computations which involves directly or indirectly parameter values to subroutines and functions, to be done in scalar? If so, its pretty bad. Related or not, the following codes also generates scalar code: subroutine test2(x,y) real x(4),y(4) beta=3.141593 do i=1,4 y(i)=y(i)+beta*x(i) end do end and subroutine test3(x,y) real x(4),y(4) beta=3.141593 y=y+beta*x end as well. I can create another bug for this if you think they are unrelated.
[Bug fortran/62283] basic-block vectorization fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62283 --- Comment #5 from Henrik Holst --- The `alpha` argument in test1 subroutine went missing. (Visual copy-paste between two machines... :-))
[Bug fortran/34568] New: Inplace algorithm too slow when using array notation
I was helping a friend debug some code and I gave him some louzy suggestions
based on what I saw in gfortran. It was regarding the inplace swap algorithm. I
suggested to him that he won't benefit from using it on a modern system. This
was because I used a "fancy notation" in my inplace algorithm:
I did like this
ARR((/J,N-J/)) = ARR((/N-J,J/))
Instead of doing this explicitly:
TEMP = ARR(N-J)
ARR(N-J) = ARR(J)
ARR(J) = TEMP
The algorithms should be equally fast, I am right?
A few benchmark tests (I will attach test code)
na56:/tmp>gfortran -O0 inplace.f90
na56:/tmp>./a.out
2.812175
9.240579
na56:/tmp>gfortran -O3 inplace.f90
na56:/tmp>./a.out
0.5120320
0.9320580
Let's compare with the Intel compiler:
Intel(R) Fortran Compiler for applications running on IA-32, Version 10.1
Build 20070913 Package ID: l_fc_p_10.1.008
na56:/tmp>ifort -O0 inplace.f90
na56:/tmp>./a.out
2.160135
2.852178
na56:/tmp>ifort -fast inplace.f90
ipo: remark #11001: performing single-file optimizations
ipo: remark #11005: generating object file /tmp/ipo_ifortgSsRZ7.o
inplace.f90(10): (col. 17) remark: LOOP WAS VECTORIZED.
na56:/tmp>./a.out
0.3720230
0.2120130
Notice that line 10 is the array assignment and not the inplace method. It is
not hard to understand why -O0 is slower (the inner loop must be unrolled)
Now let's try the "fixed" version with a explicit TEMP variable,
na56:/tmp>gfortran -O0 inplacefix.f90
na56:/tmp>./a.out
2.760172
0.8600540
na56:/tmp>gfortran -O3 inplacefix.f90
na56:/tmp>./a.out
0.5080310
0.2280150
(Almost at par with ifort, nice!)
I do not know if this is fixed in 4.3. If so, sorry for the duplicate bug.
Have a nice Xmas!
/Henrik Holst
--
PROGRAM INPLACE
IMPLICIT NONE
INTEGER, PARAMETER :: N = 2**15
INTEGER, PARAMETER :: M = 1
INTEGER:: I, J
REAL :: ARR(N)
REAL :: T0, T1, T2
CALL CPU_TIME(T0)
DO I = 1, M
ARR = ARR(N:1:-1)
END DO
CALL CPU_TIME(T1)
DO I = 1, M
DO J = 1, N/2
ARR((/J,N-J/)) = ARR((/N-J,J/))
END DO
END DO
CALL CPU_TIME(T2)
PRINT *, T1 - T0
PRINT *, T2 - T1
END PROGRAM INPLACE
PROGRAM INPLACEFIX
IMPLICIT NONE
INTEGER, PARAMETER :: N = 2**15
INTEGER, PARAMETER :: M = 1
INTEGER:: I, J
REAL :: ARR(N), TEMP
REAL :: T0, T1, T2
CALL CPU_TIME(T0)
DO I = 1, M
ARR = ARR(N:1:-1)
END DO
CALL CPU_TIME(T1)
DO I = 1, M
DO J = 1, N/2
TEMP = ARR(N-J)
ARR(N-J) = ARR(J)
ARR(J) = TEMP
END DO
END DO
CALL CPU_TIME(T2)
PRINT *, T1 - T0
PRINT *, T2 - T1
END PROGRAM INPLACEFIX
--
Summary: Inplace algorithm too slow when using array notation
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: holst at matmech dot com
GCC target triplet: i486-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34568
[Bug fortran/34633] New: Compiler crash on FORALL loop
Hi GCC Fortran developers!
I was playing with some CaSe changing routines and I ran into a crash when I
tried to use a FORALL statement instead of a DO loop.
The routine that is failing (from my perspective) is SUBROUTINE TO_UPPER(STR).
--
MODULE CASECONV
CONTAINS
SUBROUTINE TO_UPPER(STR)
CHARACTER(*) STR
INTEGER I
FORALL (I = 1:LEN(STR))
!DO I = 1, LEN(STR)
STR(I:I) = UC(STR(I:I))
!END DO
END FORALL
CONTAINS
ELEMENTAL FUNCTION UC(C)
CHARACTER, INTENT(IN) :: C
CHARACTER :: UC
INTEGER, PARAMETER:: DELTA = ICHAR('A') - ICHAR('a')
IF (LLE(C, 'z') .AND. LGE(C, 'a')) THEN
UC = ACHAR(ICHAR(C) + DELTA)
ELSE
UC = C
END IF
END FUNCTION UC
END SUBROUTINE TO_UPPER
END MODULE CASECONV
PROGRAM UCBUG
USE CASECONV
IMPLICIT NONE
CHARACTER(132) :: TESTSTR
TESTSTR = 'Hello, World!'
PRINT *, TRIM(TESTSTR)
CALL TO_UPPER(TESTSTR)
PRINT *, TRIM(TESTSTR)
END PROGRAM UCBUG
--
Summary: Compiler crash on FORALL loop
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: holst at matmech dot com
GCC host triplet: x86_64-unknown-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34633
