Build failure on gfortran 4.8.2 about datetime-fortran HOT 14 CLOSED

https://github.com/milancurcic/datetime-fortran/blob/master/src/lib/mod_datetime.f90#L831-L846

pure elemental function datetime_plus_timedelta(d0,t) result(d)
  class(datetime),intent(in) :: d0
  class(timedelta),intent(in) :: t
  type(datetime)             :: d

  d = d0

I'm 50% sure this is a datetime bug.... I don't have my copy of MRC "Modern Fortran" handy, but I think that we need a type gaurd statement here....

EDIT: to elaborate, there is not guarantee that d0 is actually type datetime it could be a type that extends datetime, although I haven't searched through the code to see if there is a user defined assignment happening here... I'll try to take a look later when I'm back in my office

from datetime-fortran.

Thanks, I am 107% sure that this is a datetime bug. This mess started when I switched from module procedure operators to type-bound generic operators. Obviously I didn't do this right. I will take a look.

from datetime-fortran.

@zbeekman I don't have an assignment operator overloaded for datetimes. Maybe we should.

@blippy Can you try this? (see replaced datetime initialization below). I think this should work. I can't reproduce your problem with gfortran 5.3.1, so I am not sure if type(datetime) =class(datetime)` is actually allowed or there exists a bug in later versions of gfortran that fails to detect this.

pure elemental function datetime_plus_timedelta(d0,t) result(d)
!=======================================================================
!
! Adds a timedelta instance to a datetime instance.
! Returns a new datetime instance. Overloads the operator +.
!
!=======================================================================

  class(datetime), intent(in) :: d0
  class(timedelta),intent(in) :: t
  type(datetime)              :: d

  integer :: milliseconds,seconds,minutes,hours,days

  ! initialize:
  !d = d0

  d = datetime(year        = d0 % getYear(),       &
               month       = d0 % getMonth(),      &
               day         = d0 % getDay(),        &
               hour        = d0 % getHour(),       &
               minute      = d0 % getMinute(),     &
               second      = d0 % getSecond(),     &
               millisecond = d0 % getMillisecond(),&
               tz          = d0 % getTz())

from datetime-fortran.

Just to confirm, both the original code and the suggested code in my snippet above compile and run successfully with gfortran 5.3.1.

from datetime-fortran.

LGTM, assuming that datetime is a structure constructor. If it's an overloaded (function) structure constructor there could be problems if it returns a class rather than a type.

from datetime-fortran.

BTW, I tried compiling the distributed code with gfortran 4.9.3 on cygwin, and I produced 114 tests passed, and 56 tests failed.

from datetime-fortran.

Back on my cubietruck box, with gfortran 4.8.2, with mod_datetime.f90:

pure elemental function datetime_plus_timedelta(d0,t) result(d)
!=======================================================================
!
! Adds a timedelta instance to a datetime instance.
! Returns a new datetime instance. Overloads the operator +.
!
!=======================================================================
  class(datetime),intent(in) :: d0
  class(timedelta),intent(in) :: t
  type(datetime)             :: d
  integer :: milliseconds,seconds,minutes,hours,days
  ! initialize:
  !d = d0
  d = datetime(year        = d0 % getYear(),       &
               month       = d0 % getMonth(),      &
               day         = d0 % getDay(),        &
               hour        = d0 % getHour(),       &
               minute      = d0 % getMinute(),     &
               second      = d0 % getSecond(),     &
               millisecond = d0 % getMillisecond(),&
               tz          = d0 % getTz())
  milliseconds = t % getMilliseconds()
  seconds      = t % getSeconds()
  minutes      = t % getMinutes()
  hours        = t % getHours()
  days         = t % getDays()
  if(milliseconds /= 0)call d % addMilliseconds(milliseconds)
  if(seconds      /= 0)call d % addSeconds(seconds)
  if(minutes      /= 0)call d % addMinutes(minutes)
  if(hours        /= 0)call d % addHours(hours)
  if(days         /= 0)call d % addDays(days)
endfunction datetime_plus_timedelta

it passes all 170 tests. No failures.

So are we saying that gfortran introduced a bug after 4.8.2?

from datetime-fortran.

@zbeekman Yes, it's a function that overloads the datetime name and returns type(datetime):

pure elemental type(datetime) function datetime_constructor(year,month,&
  day,hour,minute,second,millisecond,tz)

  integer,          intent(in),optional :: year
  integer,          intent(in),optional :: month
  integer,          intent(in),optional :: day
  integer,          intent(in),optional :: hour
  integer,          intent(in),optional :: minute
  integer,          intent(in),optional :: second
  integer,          intent(in),optional :: millisecond
  real(kind=real64),intent(in),optional :: tz

from datetime-fortran.

So are we saying that gfortran introduced a bug after 4.8.2?

No, I wouldn't rush to make this conclusion. We need to first check the literature to see if type(datetime) =class(datetime)kind of assignment is allowed. Maybe there is a special case where ifd1is an extended type, this kind of assignment is supposed to work as ifd1wastype(datetime)`. We can check this in the standard, but I don't have time right now to look into that.

from datetime-fortran.

BTW, I tried compiling the distributed code with gfortran 4.9.3 on cygwin, and I produced 114 tests passed, and 56 tests failed.

Wow, I think this is the first test of datetime-fortran on a Windows machine, at least AFAIK. Many procedures (and their corresponding tests) are chained, and it's possible that one broken thing could cause a chain of 50 failed tests that use that functionality under the hood.

Though my first guess gut feeling is that the strftime and strptime interfaces in mod_strftime.f90 are for some reason not compatible with Cygwin. More research is needed. It would be great if you open this as a separate issue and paste the whole output of the test suite.

from datetime-fortran.

@milancurcic Issue raised here: #28

You know what? I'm actually glad we went down the autotools route (although I'm not being dismissive of CMake).

from datetime-fortran.

I should also mention that the build that failed was compiled on an ARM machine:

Welcome to Ubuntu 14.04 LTS (GNU/Linux 3.4.79 armv7l)

from datetime-fortran.

@blippy Cool, all worth looking into. Last year I had all tests pass on ARM with Android (Nexus 7 2013 tablet), but that was version 1.1.0 prior to restructure, encapsulation, overloaded constructors and generic operators.

from datetime-fortran.

Resolved by commit 73a48ce. Thank you.

from datetime-fortran.