[Patch, Fortran] PR34262 - Fix MVBITS with arrays

[Tobias Burnus]

Paul Richard Thomas wrote:
>> It is more elegant, but it does not work. You get an invalid value for
>> iname if only one argument is passed. This causes a segmentation fault
>> in gfortran.fortran-torture/execute/date_time_1.f90 (-> valgrind).
>>     
> Then I haven't understood the variable arg-list macros.
>   
Well, there is no information about how many arguments are passed and
what type they have.

If you know that there is an argument of type x at n-th argument, you
can use the arg-list macros to retrieve it.

I think "printf(format, ...)" is a good example: In the first argument
you tell what to expect in which order and then you retrieve it.

See also "man stdarg.h". From the POSIX version:

"The  va_arg()  macro shall return the next argument [...] If there is
no actual next argument, or if type is not compatible with the type of
the actual next argument [...], the behavior is undefined, except for
the following cases" (Exceptions do not apply here as they are about
type compatibility.)

"APPLICATION USAGE  It  is up to the calling routine to communicate to
the called routine how many arguments there are, since it is not always
possible for the called routine to determine this in any other way.  For
example, execl() is passed  a  null pointer  to  signal  the end of the
list. The printf() function can tell how many arguments are there by the
format argument."


> I also said that your patch is OK:)
>   
I saw it. But I did not like my patch ;-)

>> a) A hackish one:
>>     c->resolved_sym = gfc_get_intrinsic_sub_symbol (name);
>> +  c->resolved_sym->elemental = 1;
>>     
> Truthfully, this would do and, in some ways, is the least hackish!
> After all, the requisite subroutines are not suddenly going to not be
> elemental.
>   
As FX preferred this version and both of us had no preferences, I
decided to go for this version.

Committed as Rev. 130513.

Tobias