From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id Pn+3L6AMq2DLRQAAWB0awg (envelope-from ) for ; Sun, 23 May 2021 22:17:04 -0400 Received: by simark.ca (Postfix, from userid 112) id B38C41F11C; Sun, 23 May 2021 22:17:04 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id EC92E1E01F for ; Sun, 23 May 2021 22:17:03 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 262913857835; Mon, 24 May 2021 02:17:03 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 262913857835 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1621822623; bh=63bMb5cKy+Hrmj4sT0mESQKIB+TZPoOJZOe5xzbGfOk=; h=Date:To:Subject:References:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=yeKXJhU5GZAnLz0sPr/GcH0WdqXzykzvK1C7NLWvMjAwl9KDbrQoq/MDwqovOLs0E wS11hkq2mV3jIPZfN5oPqQwX2zVPX/Hq1tEh+m20YiZnjq1lcQV8um4+ZS2AHT0oXM KeXlbiWd8bGuJWnT5qVe9SWVZ+79kGP8ewhknG50= Received: from smtp.gentoo.org (mail.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) by sourceware.org (Postfix) with ESMTP id 1DD7E3857835 for ; Mon, 24 May 2021 02:17:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 1DD7E3857835 Received: from vapier (localhost [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTPS id 083AD340775; Mon, 24 May 2021 02:16:58 +0000 (UTC) Date: Sun, 23 May 2021 22:16:58 -0400 To: Simon Marchi Subject: Re: Sim bfin build failure with gcc 11 Message-ID: Mail-Followup-To: Simon Marchi , gdb-patches@sourceware.org References: <3e083bf0-ce0b-9e9c-4fc5-954d569bdea1@polymtl.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Mike Frysinger via Gdb-patches Reply-To: Mike Frysinger Cc: gdb-patches@sourceware.org Errors-To: gdb-patches-bounces@sourceware.org Sender: "Gdb-patches" On 23 May 2021 21:41, Simon Marchi via Gdb-patches wrote: > On 2021-05-23 9:37 p.m., Mike Frysinger wrote: > > On 23 May 2021 20:51, Simon Marchi via Gdb-patches wrote: > >> I see this with gcc 11: > >> > >> $ ccache gcc -DHAVE_CONFIG_H -DWITH_DEFAULT_MODEL=3D'"bf537"' -DWITH_= DEFAULT_ALIGNMENT=3DSTRICT_ALIGNMENT -DWITH_TARGET_BYTE_ORDER=3DBFD_ENDIAN= _LITTLE -DWITH_HW=3D1 -DDEFAULT_INLINE=3D0 -Wall -Wdeclaration-after-sta= tement -Wpointer-arith -Wpointer-sign -Wno-unused -Wunused-value -Wunused-f= unction -Wno-switch -Wno-char-subscripts -Wmissing-prototypes -Wdeclaration= -after-statement -Wempty-body -Wmissing-parameter-type -Wold-style-declarat= ion -Werror -I. -I/home/simark/src/binutils-gdb/sim/bfin -I../common -I/ho= me/simark/src/binutils-gdb/sim/bfin/../common -I../../include -I/home/simar= k/src/binutils-gdb/sim/bfin/../../include -I../../bfd -I/home/simark/src/bi= nutils-gdb/sim/bfin/../../bfd -I../../opcodes -I/home/simark/src/binutils-g= db/sim/bfin/../../opcodes -I/usr/include/SDL -D_GNU_SOURCE=3D1 -D_REENTRAN= T -DHAVE_SDL -g3 -O0 -fsanitize=3Daddress -fmax-errors=3D1 -c -o dv-bf= in_otp.o -MT dv-bfin_otp.o -MMD -MP -MF .deps/dv-bfin_otp.Tpo /home/simark/= src/binutils-gdb/sim/bfin/dv-bfin_otp.c > >> /home/simark/src/binutils-gdb/sim/bfin/dv-bfin_otp.c: In function =E2= =80=98bfin_otp_write_page=E2=80=99: > >> /home/simark/src/binutils-gdb/sim/bfin/dv-bfin_otp.c:94:3: error: =E2= =80=98bfin_otp_write_page_val=E2=80=99 accessing 16 bytes in a region of si= ze 4 [-Werror=3Dstringop-overflow=3D] > >> 94 | bfin_otp_write_page_val (otp, page, (void *)&otp->data0); > >> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > >> /home/simark/src/binutils-gdb/sim/bfin/dv-bfin_otp.c:94:3: note: refer= encing argument 3 of type =E2=80=98bu64 *=E2=80=99 {aka =E2=80=98long unsig= ned int *=E2=80=99} > >> /home/simark/src/binutils-gdb/sim/bfin/dv-bfin_otp.c:81:1: note: in a = call to function =E2=80=98bfin_otp_write_page_val=E2=80=99 > >> 81 | bfin_otp_write_page_val (struct bfin_otp *otp, bu16 page, bu64= val[2]) > >> | ^~~~~~~~~~~~~~~~~~~~~~~ > >> > >> It's not immediately obvious to me why it says that. > >=20 > > gcc really wants its pointer types to be in harmony. i cheated here. > >=20 > > write_page_val wants a pointer to an array of 2 64-bit values. i know = the > > otp struct has "bu64 data0, data1, data2, data3;", and taking the addre= ss > > of data0 has the same memory layout as if it were "bu64 data[3];". but= with > > the fortify work gcc has long been doing, they've stopped accepting the= se > > kinds of hacks. > >=20 > > this code is not perf sensitive, so i can be less "clever" while keepin= g the > > compiler happy. >=20 > Ah, I see. Well if what you want is make sure the fields are > contiguous, why not make that an array of four bu32 instead? i'm not worried about the ordering ... it's a struct, so that's guaranteed. the code uses a style to make it easy to compare against the datasheets and to make it easy to access individual fields. the datasheets have "DATA0" an "DATA1" and such as explicit MMRs, not DATA[3]. but i misread the code and thought it said bu64 data0... when it's really bu32 as you point out. which is why i was being clever in the first place, and the patch i just pushed is incorrect. i guess the existing code was assuming the host cpu was little endian, so doing a manual construction of the 64bit fields is unavoidable. so let's try this again. -mike commit d699be882b42f36677836c320edbf7db24021a30 Author: Mike Frysinger Date: Sun May 23 22:15:01 2021 -0400 sim: bfin: fix the otp fix =20 I misread the code and thought data0/... were bu64 when they were actually bu32. Fix the call to assemble the 2 64-bit values instead of passing the 2 halves of the first 64-bit value. diff --git a/sim/bfin/ChangeLog b/sim/bfin/ChangeLog index 9c517d20bbeb..29dfde8fe6e3 100644 --- a/sim/bfin/ChangeLog +++ b/sim/bfin/ChangeLog @@ -1,3 +1,8 @@ +2021-05-23 Mike Frysinger + + * dv-bfin_otp.c (bfin_otp_write_page): Fix args to + bfin_otp_write_page_val2. + 2021-05-23 Mike Frysinger =20 * dv-bfin_otp.c (bfin_otp_write_page): Call bfin_otp_write_page_val2. diff --git a/sim/bfin/dv-bfin_otp.c b/sim/bfin/dv-bfin_otp.c index 65afdf58b27f..cdc010ae551b 100644 --- a/sim/bfin/dv-bfin_otp.c +++ b/sim/bfin/dv-bfin_otp.c @@ -91,7 +91,8 @@ bfin_otp_write_page_val2 (struct bfin_otp *otp, bu16 page= , bu64 lo, bu64 hi) static void bfin_otp_write_page (struct bfin_otp *otp, bu16 page) { - bfin_otp_write_page_val2 (otp, page, otp->data0, otp->data1); + bfin_otp_write_page_val2 (otp, page, (bu64)otp->data1 | otp->data0, + (bu64)otp->data3 | otp->data2); } =20 static unsigned