Incorrect return types when parsing Fortran intrinsic functions

Firstly, thanks so much for this wonderful tool! It has proved immensely useful.

I am observing instances in which calling get_type() on an SgFunctionCallExp node returns an incorrect return type. For example, ROSE thinks that the type of the expression trim(myString) is SgTypeFloat

After doing some digging, I've found the following:
Looking at src/frontend/OpenFortranParser_SAGE_Connection/fortran_support.C, and specifically the function generateIntrinsicFunctionReturnType:

SgType*
generateIntrinsicFunctionReturnType( string s , SgExprListExp* argumentList )
   {
  // Maybe this function should break out the subroutines and procedures that 
  // would be associated with a "call" statement.

  // Intrinsic function return types depend on there arguments and also on the
  // specific intrinsic function.  

     SgType* returnType = NULL;

     bool isIntrinsicFunction = matchAgainstIntrinsicFunctionList(s);
     ROSE_ASSERT(isIntrinsicFunction == true);

     if (argumentList != NULL)
        {
       // Use the type of the arguments in the argumentList to figure out what type to return.
          if (isIntrinsicFunctionReturningNonmatchingType(s) == true)
             {
            // This may have to be handled on a case by case basis.

            // For now, lets just use the implicit type rules, I will fix this later.
               returnType = generateImplicitType(s);
             }
            else
             {
            // If we have an expression list, then I assum it is non-empty, but check to make sure.
               ROSE_ASSERT(argumentList->get_expressions().empty() == false);

            // As I recall all the argument types are the same and the return type of the 
            // implicit function matches the argument type.
               returnType = argumentList->get_expressions()[0]->get_type();
             }
        }
       else
        {
       // I can't think of anything else to do but compute the type using the implicit type rules.
       // If the user changes the implicit type rules then this would be incorrect, so we have to 
       // have something better eventually.
          returnType = generateImplicitType(s);
        }

  // Use the implicit type rules, however that is not likely good enough since 
  // many intrinsic functions have explicitly predefined types.
  // return generateImplicitType(s);

     ROSE_ASSERT(returnType != NULL);
     return returnType;
   }

While this appears to be under development, I have observed that the control flow is not matching what might be expected given the current code. In all cases I have tested, generateImplicitType is called, i.e., argumentList has always been NULL even when the original source code certainly has listed arguments. (note that isIntrinsicFunctionReturningNonmatchingType is hard-coded to return false)