On Mon, Nov 20, 2017 at 8:29 PM, Thomas Koenig <tkoe...@netcologne.de> wrote: > Am 20.11.2017 um 09:30 schrieb Janne Blomqvist: >> >> On Sun, Nov 19, 2017 at 11:11 PM, Thomas Koenig <tkoe...@netcologne.de> >> wrote: >>> >>> There is one question regarding the ABI. Apparently, the string length >>> is passed as an int even on a 64-bit system. I verified that this >>> is indeed the case by doing the actual work on a >>> powerpc64-unknown-linux-gnu box (gcc110 on the gcc compile farm), >>> which is big-endian. If we were actually passing an eight-byte >>> quantity, and only getting the upper bytes, we would crash & burn. >>> >>> Now, I _thought_ we were passing string lengths as size_t now (Janne?), >>> but maybe something was missing in that change. >> >> >> Unfortunately I had to revert the charlen->size_t patch since it >> caused regressions on aix/power (presumably due to endianness issues). > > > Ah, that explains it. I had forgotten the reversion part. > >> There's apparently some other process for getting compile farm >> accounts nowadays, and we have broken the ABI again for gcc 8, so >> maybe I should dust off the patch and try again. Or what do you think? > > > You can apply at https://cfarm.tetaneutral.net/ . These machines are > indeed quite nice to work on, especially because of the different > architectures (and because there are some very powerful machines > there). > > So, any other comments about my patch? OK for trunk?
- In many cases the copyright notice has "This file is part of the GNU Fortran 95 runtime library (libgfortran)." It's a while since we've called ourselves "GNU Fortran 95", so just remove the "95". - It seems in the library you're using int for string lengths? Please use gfc_charlen_type instead (in the frontend, gfc_charlen_type_node). (Most of the charlen->size_t patch is fixing up places where we're accidentally using int instead of gfc_charlen_type..). - Why are you using GFC_INTEGER_1 / GFC_INTEGER_4 to loop over the arrays rather than char/gfc_char4_t? Not sure if it makes any difference in practice, but it sure seems confusing.. - Not really related to your patch, but memcmp_char4 sure looks redundant. Isn't it the same as memcmp(a, b, size*4), in which case we could use optimized memcmp implementations? -- Janne Blomqvist
