From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 51915 invoked by alias); 22 Nov 2017 19:22:54 -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 51897 invoked by uid 89); 22 Nov 2017 19:22:54 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 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 X-Spam-User: qpsmtpd, 2 recipients X-HELO: mail-yw0-f177.google.com Received: from mail-yw0-f177.google.com (HELO mail-yw0-f177.google.com) (209.85.161.177) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 22 Nov 2017 19:22:53 +0000 Received: by mail-yw0-f177.google.com with SMTP id p74so7608799ywe.2; Wed, 22 Nov 2017 11:22:53 -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=IParYdkDgxIqHb/PkhJUCBX9DQjf5JOsVdEoLaFuz3U=; b=WIIIYiF0ompMdq+meWtHcVSKVP1kyoL2weW1MgfmJHPXOFiUPLOQhmMXXk84XxZT5f dIyRQT997UC80De7L9v8yNGND6RlYL8ottY+zWKBWS79AlpzkACodqly4/B63ezEGIEE rURJkT32WxYSxIyYXEZwsX+Ek/MnHAtuBpGcjaH6dcehJmUEYBZuGBB5JBZffEgTNxzx 5p27aATOYpfLYBHqlcFRXgCulKL4Mc8RKEAURNjxB/MXBKBkuab1cDAWa/v7L2boLdxH DZWSncDtnIosOXk3k11njdq+qb39jv88cH0Fg5pkUx59GQYRMq2lEuK7fgavWz5aAGz2 Y58Q== X-Gm-Message-State: AJaThX48z4/8BmvI4JQXuwd1U8W20sis5DJ/QGMB4Bv4huo8wQlZVkQW T3//4BPkGosveIrY1WOJz1J+qQBd4fUfiKXcDQp0UQ== X-Google-Smtp-Source: AGs4zMadAtTA0tmgGb4i3fKjqTu0siHTCe/7LCbPh4PEgNTNhlnXvT+AHChB4w68ajxUJCxeBIp38XrIJA5E3+XRSNM= X-Received: by 10.129.229.2 with SMTP id s2mr13925835ywl.90.1511378571329; Wed, 22 Nov 2017 11:22:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.163.146 with HTTP; Wed, 22 Nov 2017 11:22:50 -0800 (PST) In-Reply-To: <984714d2-9243-c60a-adb8-7b92cd9cae3e@netcologne.de> References: <1511354047-32527-1-git-send-email-blomqvist.janne@gmail.com> <984714d2-9243-c60a-adb8-7b92cd9cae3e@netcologne.de> From: Janne Blomqvist Date: Wed, 22 Nov 2017 20:03:00 -0000 Message-ID: Subject: Re: [PATCH] Use __BYTE_ORDER__ predefined macro instead of runtime check To: Thomas Koenig Cc: Fortran List , GCC Patches Content-Type: text/plain; charset="UTF-8" X-SW-Source: 2017-11/txt/msg02075.txt.bz2 On Wed, Nov 22, 2017 at 8:16 PM, Thomas Koenig wrote: > Hi janne, > >> Regtested on x86_64-pc-linux-gnu, Ok for trunk? > > > Jerry already OK'd this, so you can commit if you want. > What you could do is to hide the macro invocation behind > a macro in libgfortran.h, something like > > #define BIG_ENDIAN (__BYTE_ORDER__ == __ORDER_BIG_ENDIAN__) > > Also, I have opened PR libfortran/83097 for this, you > can mention this in the ChangeLog entry. > > Regards > > Thomas Hi, in light of Andreas comments, and also since the meaning of the old big_endian variable was apparently confusing enough that somebody had deemed it necessary to explain it in multiple places where it was used, I committed the original patch as r255072. Having the conditional explicitly where it's used at least makes it pretty clear what we're testing. Also thanks for opening a PR, I mentioned this in the ChangeLog and commit msg. -- Janne Blomqvist