This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [patch, libfortran] Use flexible array members for array descriptor
Am 05.02.2018 um 13:09 schrieb Janne Blomqvist:
On Sun, Feb 4, 2018 at 9:49 PM, Thomas Koenig <tkoenig@netcologne.de> wrote:
Hello world,
in the attached patch, I have used flexible array members for
using the different descriptor types (following Richi's advice).
This does not change the binary ABI, but the library code
maches what we are actually doing in the front end. I have
not yet given up hope of enabling LTO for the library :-)
and this, I think, will be a prerequisite.
OK for trunk?
Given that Jakub and Richi apparently weren't yet unanimous in their
recommendations on the best path forward, maybe wait a bit for the
smoke to clear?
Make sense. Depending on what the solution is, this (or a variant)
will probably part of the patch.
In the meantime, a few comments:
1) Is there some particular benefit to all those macroized
descriptors, given that the only thing different is the type of the
base_addr pointer? Wouldn't it be simpler to just have a single
descriptor type with base_addr a void pointer, then typecast that
pointer to whatever type is needed?
I don't particulary like going through void* pointers - it is
clearer to leave an int* as an int*.
2)
Index: intrinsics/date_and_time.c
===================================================================
--- intrinsics/date_and_time.c (Revision 257347)
+++ intrinsics/date_and_time.c (Arbeitskopie)
@@ -268,7 +268,7 @@ secnds (GFC_REAL_4 *x)
GFC_REAL_4 temp1, temp2;
/* Make the INTEGER*4 array for passing to date_and_time. */
- gfc_array_i4 *avalues = xmalloc (sizeof (gfc_array_i4));
+ gfc_array_i4 *avalues = xmalloc (sizeof (gfc_full_array_i4));
Since date_and_time requires the values array to always be rank 1,
can't this be "xmalloc (sizeof (gfc_array_i4) +
sizeof(dimension_data))" ?
I think we can be fairly sure that this would be OK at the moment, since
(I think) there are no gaps in our descriptors at the moment. Anybody
invents an architecture where this is not the case, we introduce
a bug. This way is safer.
Regards
Thomas