commit 166d77a440a5 and b5f8b4ff16fb does not compile with gfortran

Issue #670 closed
Roland Haas created an issue

I get the following error messages (the second commit changes make.code.defn to activate code from the first commit):

 In file /home/rhaas/ET/configs/et/build/Carpet/LoadBalanceReal/carpet_region.f90:59

      type(superregion2), pointer, intent(out) :: sregion
                                1
Error: POINTER attribute conflicts with INTENT attribute at (1)

this happens with gfortran 4.2 on a red hat 5.7 system (eg. the cct machines or my workstation at Caltech or (former workstation at) GT). I attach the full make output (with many more errors).

Looking at the fortran code it states that:

  ! Note that using intent on pointer arguments requires fortran 2003.
  ! It is not allowed in fortran 90 or 95.

I tried setting std=f2003 in gfortran (see make.log) but apparently this is not sufficient for gfortran 4.1.2

I am not which other fortran compilers are affected. If we keep this then we will have to make very clear all user realise that Carpet requires Fortran 2003 and a fairly new gfortran compiler (or intel) not just Fortran 90.

Keyword:

Comments (12)

  1. Peter Diener
    • removed comment

    The intent(out) was added to help the compiler detect cases where the pointer was already allocated or associated before being passed to the routine. The code compiles with gfortran 4.3.2 (from 2008) and gfortran 4.4.1 (from 2009) so doesn't require a very recent gfortran compiler. If we want to make it compatible with gfortran 4.1.2 I expect we can just remove the intent(out) from the declaration of the pointer argument. Roland can you try if that works for you?

  2. Roland Haas reporter
    • removed comment

    I tried that (actually before I send the original ticket) and tried again right now. I get

    In file /home/rhaas/ET/configs/et/build/Carpet/LoadBalanceReal/carpet_boxtypes.f90:261

    type(ptr), dimension(:), allocatable, intent(in) :: sregions 1 Error: ALLOCATABLE attribute conflicts with DUMMY attribute at (1) I removed those as well next and actually had to remove the -std=f2003 (otherwise it complains about Cactus' CCTK_POINTER being a non-standard integer*8 type). It then compiles but I have no idea if it is still doing the right thing in this case (since I had to remove the allocatable not just the intent). I am not very familiar with Fortan at all :-(

    gcc 4.1 is certainly very very old by now, it does not even support OpenMP. The only reason why I think we mights still care about it is that it still is the compiler used in RedHat 5 systems. Since I expect that some groups still use this version on their workstations (Caltech, GT that I know of) at least for a while (RedHat 6 is out and uses a newer version). I don't know if it is a good idea to have a base component (Carpet) that does not compile out of the box with the OS supplied compiler. If there was a simple way to work around the issue (eg. if removing just the intent from the pointers would have been enough) I would have preferred that.

  3. Erik Schnetter
    • removed comment

    gfortran 4.1 is very old; the first usable gfortran was 4.2, released in 2007.

    Since this is about the development version of Carpet, I would at the moment rather add a requirement for people to install a different compiler. Before the next release we may address this again.

  4. Peter Diener
    • removed comment

    The allocatable attribute is there for consistency with the declaration in the calling routine. The allocation in the code is actually done in the calling routine and I just tested that it seems to be safe to remove the allocatable attribute in the called routine (keeping the intent(in) though). So it is possible (if this is the last issue) to make the code compile with older versions of gfortran in a fairly easy and safe way.

  5. Erik Schnetter
    • removed comment

    In this case, the allocatable attribute should not be there -- it indicates that the called routine may change the allocation status, which it won't.

    Roland, does this solve your gfortran 4.1 problems?

  6. Roland Haas reporter
    • removed comment

    yes, I could compile with the attached patches (and as long as I did '''not''' add -std=f2003). The patch is only for informational purposes, do not suggest to apply it.

  7. Peter Diener
    • removed comment

    The test program gives identical results before and after applying Roland's patch. I'll leave it up to Erik to decide if he wants to commit it.

  8. Peter Diener
    • removed comment

    I just pushed a patch based on your patch Roland. Roland can you try it and see if I got it right. If so we can close this bug report.

  9. Roland Haas reporter
    • changed status to resolved
    • removed comment

    I ran the testsuites and get no testsuites failures using Carpet (with the exception of the CarpetIOASCII::compact test though that one is development anyway). I get errors in RotatingSymetry180/90 though. I am unsure where those come from. They don't go away if I back out of the this commit though so this ticket can be closed.

  10. Log in to comment