From owner-freebsd-current@FreeBSD.ORG Tue Jul 9 04:40:52 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D44B54BA for ; Tue, 9 Jul 2013 04:40:52 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id B7989172A for ; Tue, 9 Jul 2013 04:40:51 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r694eiD6039264; Tue, 9 Jul 2013 04:40:44 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.123] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id mc6hrzs7aavxtheweh8rdnqdb6; Tue, 09 Jul 2013 04:40:44 +0000 (UTC) (envelope-from tim@kientzle.com) Subject: Re: another -Wunsequenced topic Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Tim Kientzle In-Reply-To: <51DAA5FE.4040505@gmx.com> Date: Mon, 8 Jul 2013 21:40:42 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6AC1186D-3D9C-4B7A-B5E4-4EA9CB120517@kientzle.com> References: <51CEEC34.2010308@gmx.com> <51D03D27.3020100@gmx.com> <51DAA5FE.4040505@gmx.com> To: dt71@gmx.com X-Mailer: Apple Mail (2.1283) Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 04:40:52 -0000 On Jul 8, 2013, at 4:43 AM, dt71@gmx.com wrote: > Well, this turned out to be a semi-false alarm. A week ago, for a = short time, there was a bug in Clang. There is no undefined behavior in >=20 > ptr =3D func(++ptr);, No, there is not. However, this does have an implicit redundant store, so changing it to ptr =3D func(ptr + 1); is still a good idea, just not for the reason Clang was claiming. > partially because a function call introduces a sequence point in C, = but Clang did not respect this at that time. However, >=20 > x =3D func1(++ptr) + func2(++ptr); >=20 > is compiler-dependent. Code like this is badly broken. The order of evaluation here can even change across compiler versions (optimizers use a variety of criteria to reorganize code, which can easily change from version to version). > Additionally, if func() turns out to be a macro, rather than a native = function, then undefined behavior (due to unsequencedness) occurs. Replacing functions with macros is a common way to optimize code, which is yet another reason the idiom above should generally be avoided. > So in the end, Clang has accidentally pointed me to an irrelated bug, = and induced some unnecessary code changes. Not strictly necessary for correctness, but still good changes for the = most part. Tim