Re: 6 gfortran bugs

From: James Van Buskirk (not_valid_at_comcast.net)
Date: 01/26/05

  • Next message: James Giles: "Re: Precedence" 
    Date: Tue, 25 Jan 2005 18:30:21 -0700

    "Richard E Maine" <nospam@see.signature> wrote in message
    news:nospam-344FD2.13561825012005@news.supernews.com...

    > I was hit by gcc bug 17298, but that ons is already in bugzilla.

    And you warn me about using transfer too much. I thought transfer
    was implemented before the great schism, but I guess not. Curiously
    the usage of transfer in Additional Comment #2 is unnecessary; in my
    generic modification of BLAS

    http://home.comcast.net/~kmbtib/Fortran_stuff/GENERIC_BLAS.ZIP

    the usage of dcabs1 gets turned into a statement function from
    the single precision versions which propagates into the double
    and quadruple precision versions. However, GENERIC_BLAS.ZIP
    won't work under gfortran:

    1) No gfortran-specific *.bat file included to build it, and
    2) It now fails dues to

    http://home.comcast.net/~kmbtib/gfortran_bugs/REF_JVB_GFTN_007.html

    which should be much easier to fix, however. Transformational
    intrinsics seem to be much more difficult to implement than
    others: check out how vendors will throw in a lot of extra
    elemental intrinsics (do they usually allow them in specification
    expressions?) but even basic transformational intrinsic extensions
    like FIRST never happen.

    > ----------------------------
    > Bug 1.

    > program stuff
    > integer :: i_do
    > integer :: i(101) = (/ (i_do, i_do=1,101) /)
    > write (*,*) i
    > end program stuff

    > bug1.f90:4: internal compiler error:

    One of my favorite sources of bugs: initialization expressions.
    There is tons of code out there that does lots of 'interesting'
    stuff in ordinary expressions and it's a pity that there is no
    way to automatically detect which of those expressions could
    be also specification or initialization expressions and make up
    some code to test each expression in those contexts as well.
    Until someone figures out a way to achieve this, non-ordinary
    expressions will get short shrift in testing and will remain
    the source of many compiler bugs.

    > ----------------------------
    > Bug 3.

    > module fdas_command
    > contains
    > function lower_case (string) result(result)
    > character*(*), intent(in) :: string
    > character*(len(string)) :: result
    > result = string
    > return
    > end function lower_case
    > subroutine ask_help (topic)
    > character*(*), intent(in) :: topic
    > character :: topic_tmp*16
    > topic_tmp = lower_case(topic)
    > return
    > end subroutine ask_help
    > end module fdas_command

    > bug3.f90: In function 'ask_help':
    > bug3.f90:3: internal compiler error:

    Yep, a specification expression of any stripe!

    http://home.comcast.net/~kmbtib/gfortran_bugs/REF_JVB_GFTN_005.html

    is another example -- I think that gfortran just doesn't
    implement specification expressions.

    > ----------------------------
    > Bug 6.

    > subroutine bug6
    > integer(1) :: i = 32
    > write (*,*) achar(i)
    > end

    > In file bug6.f90:3

    > write (*,*) achar(i)
    > 1
    > Error: Type of argument 'i' in call to 'achar' at (1) should be
    > INTEGER(4), not INTEGER(1)

    Darn, I was trying to trip up ACHAR and found something that
    wasn't really ACHAR's fault in

    http://home.comcast.net/~kmbtib/gfortran_bugs/REF_JVB_GFTN_004.html

    I knew I should have persevered with nondefault integers! g95
    actually failed with default integers, but Andy says that is
    fixed now although a Windoze version hasn't come out since then. 

    -- 
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end
  • Next message: James Giles: "Re: Precedence"

    Relevant Pages

    • Re: Center myLayer relative to scroll...
      ... it did update in Internet Explorer 5.5 and 6. ... that supposedly works around a bug in IE6 and under. ... more efficient than calling parseInt. ... These expressions are evaluated ...
      (comp.lang.javascript)
    • Re: Bug in HP-35S?
      ... Best regards. ... Some minor changes ... in the expressions still demonstrates the error, ... Is this a well-known bug somehow? ...
      (comp.sys.hp48)
    • Column Expression Bug in VS.NET 2003
      ... I could not get aggregate child column expressions to work when they ... were defined in a DataSet using the DataSet designer. ... Expressions that did not use relations seemed to work OK. ... This bug should be more widely documented. ...
      (microsoft.public.dotnet.framework.adonet)
    • Re: Floating point run time error
      ... between immediate and run time in how the expressions are evaluated, ... the "bug" was elsewhere. ... Danny ... Remove NOSPAMFOR before emailing.) ...
      (microsoft.public.vb.syntax)
    Loading