This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [libfortran, patch] fix for PR 19106


Thomas Koenig wrote:
>>the alternative being a semi-filled
>>in array descriptor, but I hadn't thought of the fact that ...
>>
>>
>>>The array descriptors are typed.  Using gfc_array_void would be
>>>very ugly, require unnecessary casts and probably cause breakage.
>>>It would probably best to generate these functions, too.  Hmm...
>>
>>We use gfc_array_char in cases where we're not type-safe, see e.g.
>>intrinsic/pack_generic.c, and I think there's no risk in type-casting
>>descriptors (they carry information on the type in the dtype field anyway),
> 
> 
> I don't like casting pointers (or structures of pointers) that
> way.  This is undefined by the C standard, because it assumes
> identical size and identical bit patterns for char* and int*.
> This For word-oriented machines such as Crays this isn't true,
> and I wouldn't want to hardcode such an assumption into libfortran
> without a strong reason.
> 
> Also, this would require the size as an additional parameter.  Again,
> not elegant.
> 
> 
>>nor do I think there's much value in generating those functions.  You could
>>put a bunch of correctly typed stub functions which simply typecast the
>>descriptor.  But I'd like to hear what Paul Brook recommends on this.
> 
> 
> Me too.  Paul, are you reading this?

I think we can also delay the decision on how to do this to 4.1, and accept
your patch as is (modulo my other comments) for the time being.  Making 4.0
work as well as possible certainly has a higher priority than finding the
cleanest implementation for everything.

- Tobi


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]