From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 70965 invoked by alias); 21 Nov 2017 16:07:35 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 70901 invoked by uid 89); 21 Nov 2017 16:07:34 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,KB_WAM_FROM_NAME_SINGLEWORD,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=no version=3.3.2 spammy=HTo:U*tkoenig, accounts X-Spam-User: qpsmtpd, 2 recipients X-HELO: mail-yb0-f174.google.com Received: from mail-yb0-f174.google.com (HELO mail-yb0-f174.google.com) (209.85.213.174) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 21 Nov 2017 16:07:32 +0000 Received: by mail-yb0-f174.google.com with SMTP id y14so4669461ybi.0; Tue, 21 Nov 2017 08:07:32 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=eyBQllyiGoTd9SZgKc7soagzz0NUluz7zQD/zr2JPgQ=; b=l/4FE+7JrLUk4HiL4kG+OH31BQJT7Bf/oHwTbwbwWWCFlACwFin/eDMxQOEHSB59ZI Jba0ZmSFA286AhRLdAYaKHjqJmksa/191/Ncko+NAQKM5XQvjRndpe1PSK20W0zwAt/0 2mka0clZEIweytjsuzfG40SY0/GiFQEd6FILsUnbNAxuotFHfLuJ4qgckxtBS8+6hYv7 TpnSyMQ+Rf7O7l7GnOT54JfsMzGv3M3NiN+pIS/CO+JiwU/+sRMIr12tJ5NHAQiIOC4N uSKJVJbMlI0F0hYmJszqfEoWNtUJ1AQnRtD66sEaMcOi2xpv9bBNNentWRZL+/n1OoNb Y4oQ== X-Gm-Message-State: AJaThX60TDgI95NVnWHGwGlU4+wTTfek5ojs5141rTVrp8Fnid8l1PyQ 2FIX4ynLORIv022GCM461QP6PzahyeclIhU33vfx4A== X-Google-Smtp-Source: AGs4zMYSG97qw0FFs1nozdfwgYluQFrLAmTEuYarbV2vtd5nvtT3pN/Qq4YLEVbjqxe7mlYxyrZBlcjL/AoyKg3Fiyw= X-Received: by 10.37.216.208 with SMTP id p199mr10739966ybg.429.1511280450763; Tue, 21 Nov 2017 08:07:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.163.146 with HTTP; Tue, 21 Nov 2017 08:07:30 -0800 (PST) In-Reply-To: <03e85917-b506-0d8b-78b0-263c371cba6a@netcologne.de> References: <44c7b39b-d849-e31a-7175-80bf1a348908@netcologne.de> <03e85917-b506-0d8b-78b0-263c371cba6a@netcologne.de> From: Janne Blomqvist Date: Tue, 21 Nov 2017 16:25:00 -0000 Message-ID: Subject: Re: [patch, fortran] Implement maxloc and minloc for character To: Thomas Koenig Cc: "fortran@gcc.gnu.org" , gcc-patches Content-Type: text/plain; charset="UTF-8" X-SW-Source: 2017-11/txt/msg01913.txt.bz2 On Mon, Nov 20, 2017 at 8:29 PM, Thomas Koenig wrote: > Am 20.11.2017 um 09:30 schrieb Janne Blomqvist: >> >> On Sun, Nov 19, 2017 at 11:11 PM, Thomas Koenig >> 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