This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [libfortran, patch] fix for PR 19106
- From: Tobias Schlüter <tobias dot schlueter at physik dot uni-muenchen dot de>
- To: Thomas Koenig <Thomas dot Koenig at online dot de>
- Cc: fortran at gcc dot gnu dot org, gcc-patches at gcc dot gnu dot org
- Date: Wed, 06 Apr 2005 19:54:02 +0200
- Subject: Re: [libfortran, patch] fix for PR 19106
- References: <20050313220945.GA30836@meiner.onlinehome.de> <4234DC13.7030400@physik.uni-muenchen.de> <20050316211936.GA26828@meiner.onlinehome.de> <4238B749.6000809@physik.uni-muenchen.de> <20050317204047.GA4678@meiner.onlinehome.de>
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