From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [207.211.31.120]) by sourceware.org (Postfix) with ESMTP id 2734C388A001 for ; Thu, 2 Apr 2020 10:39:48 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 2734C388A001 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-405-SaRlkc1WOkG59YrWQg0JGg-1; Thu, 02 Apr 2020 06:39:44 -0400 X-MC-Unique: SaRlkc1WOkG59YrWQg0JGg-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 0234E18CA241; Thu, 2 Apr 2020 10:39:43 +0000 (UTC) Received: from tucnak.zalov.cz (ovpn-113-52.ams2.redhat.com [10.36.113.52]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 6447A60C05; Thu, 2 Apr 2020 10:39:42 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.15.2/8.15.2) with ESMTP id 032AddcD022339; Thu, 2 Apr 2020 12:39:40 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.15.2/8.15.2/Submit) id 032AdcqH022338; Thu, 2 Apr 2020 12:39:38 +0200 Date: Thu, 2 Apr 2020 12:39:38 +0200 From: Jakub Jelinek To: "Kewen.Lin" Cc: GCC Patches , Bill Schmidt , Segher Boessenkool Subject: Re: [PATCH] Fix PR94401 by considering reverse overrun Message-ID: <20200402103938.GR2212@tucnak> Reply-To: Jakub Jelinek References: <20200402082834.GO2212@tucnak> <5e92fc81-bd24-d866-26ee-48a251e69b82@linux.ibm.com> MIME-Version: 1.0 In-Reply-To: <5e92fc81-bd24-d866-26ee-48a251e69b82@linux.ibm.com> User-Agent: Mutt/1.11.3 (2019-02-01) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Status: No, score=-15.0 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2020 10:39:53 -0000 On Thu, Apr 02, 2020 at 06:07:55PM +0800, Kewen.Lin wrote: > > The above is misformatted. The ? and : shouldn't be indented further t= han > > the dataref_offset, but usually e.g. for the sake of emacs we add ()s a= round > > the expression in this case. So: > > =09=09=09tree offset =3D (dataref_offset > > =09=09=09=09 ? dataref_offset > > =09=09=09=09 : build_int_cst (ref_type, 0)); > > or > > =09=09=09tree offset > > =09=09=09 =3D (dataref_offset > > =09=09=09 ? dataref_offset : build_int_cst (ref_type, 0)); > >=20 >=20 > Thanks Jakub! I'll follow this by add () for ternary expression. > With manual added "()", clang-format can get below: Note, the () isn't about ternary expressions, if everything fits on one line, there is no reason to add ()s, so tree offset =3D dataref_offset ? dataref_offset : build_int_cst (ref_type= , 0); is just fine that way, on the other side =09=09=09=09=09int whatever =3D HOST_WIDE_INT_1U =09=09=09=09=09=09 + foobarbaz (qux); should have them too, like: =09=09=09=09=09int whatever =3D (HOST_WIDE_INT_1U =09=09=09=09=09=09=09+ foobarbaz (qux)); or =09=09=09=09=09int whatever =09=09=09=09=09 =3D HOST_WIDE_INT_1U + foobarbaz (qux); I don't use emacs, but was told that emacs without the ()s would misindent it like (I think): =09=09=09=09=09int whatever =3D HOST_WIDE_INT_1U =09=09=09=09=09 + foobarbaz (qux); which is what we do not want. >=20 > =09=09=09tree offset > =09=09=09 =3D (dataref_offset ? dataref_offset > =09=09=09=09=09 : build_int_cst (ref_type, 0)); >=20 > contrib/check_GNU_style.sh didn't complain this, I'm not sure whether > it's possible to add this kind of convention into contrib/clang-format. clang-format is not our official indentation style; I have no problem with the above formatting from readability POV, though unsure what emacs will do with that (but if it moves that : right below the first dataref_offset, no big deal, that is also fine and probably more appropriate if the build_int_cst... is long and would need more wrapping). =09Jakub