From: Mike Frysinger via Gdb-patches <gdb-patches@sourceware.org>
To: Simon Marchi <simon.marchi@polymtl.ca>
Cc: gdb-patches@sourceware.org
Subject: Re: Sim bfin build failure with gcc 11
Date: Sun, 23 May 2021 22:16:58 -0400 [thread overview]
Message-ID: <YKsMmgp4Y2bDEt7h@vapier> (raw)
In-Reply-To: <da55c43e-6666-b811-a472-a86f19f90246@polymtl.ca>
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='"bf537"' -DWITH_DEFAULT_ALIGNMENT=STRICT_ALIGNMENT -DWITH_TARGET_BYTE_ORDER=BFD_ENDIAN_LITTLE -DWITH_HW=1 -DDEFAULT_INLINE=0 -Wall -Wdeclaration-after-statement -Wpointer-arith -Wpointer-sign -Wno-unused -Wunused-value -Wunused-function -Wno-switch -Wno-char-subscripts -Wmissing-prototypes -Wdeclaration-after-statement -Wempty-body -Wmissing-parameter-type -Wold-style-declaration -Werror -I. -I/home/simark/src/binutils-gdb/sim/bfin -I../common -I/home/simark/src/binutils-gdb/sim/bfin/../common -I../../include -I/home/simark/src/binutils-gdb/sim/bfin/../../include -I../../bfd -I/home/simark/src/binutils-gdb/sim/bfin/../../bfd -I../../opcodes -I/home/simark/src/binutils-gdb/sim/bfin/../../opcodes -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT -DHAVE_SDL -g3 -O0 -fsanitize=address -fmax-errors=1 -c -o dv-bfin_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 ‘bfin_otp_write_page’:
> >> /home/simark/src/binutils-gdb/sim/bfin/dv-bfin_otp.c:94:3: error: ‘bfin_otp_write_page_val’ accessing 16 bytes in a region of size 4 [-Werror=stringop-overflow=]
> >> 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: referencing argument 3 of type ‘bu64 *’ {aka ‘long unsigned int *’}
> >> /home/simark/src/binutils-gdb/sim/bfin/dv-bfin_otp.c:81:1: note: in a call to function ‘bfin_otp_write_page_val’
> >> 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.
> >
> > gcc really wants its pointer types to be in harmony. i cheated here.
> >
> > 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 address
> > 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 these
> > kinds of hacks.
> >
> > this code is not perf sensitive, so i can be less "clever" while keeping the
> > compiler happy.
>
> 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 <vapier@gentoo.org>
Date: Sun May 23 22:15:01 2021 -0400
sim: bfin: fix the otp fix
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 <vapier@gentoo.org>
+
+ * dv-bfin_otp.c (bfin_otp_write_page): Fix args to
+ bfin_otp_write_page_val2.
+
2021-05-23 Mike Frysinger <vapier@gentoo.org>
* 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);
}
static unsigned
next prev parent reply other threads:[~2021-05-24 2:17 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-24 0:51 Simon Marchi via Gdb-patches
2021-05-24 1:37 ` Mike Frysinger via Gdb-patches
2021-05-24 1:41 ` Simon Marchi via Gdb-patches
2021-05-24 2:16 ` Mike Frysinger via Gdb-patches [this message]
2021-05-29 1:52 ` Simon Marchi via Gdb-patches
2021-05-29 3:32 ` Mike Frysinger via Gdb-patches
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YKsMmgp4Y2bDEt7h@vapier \
--to=gdb-patches@sourceware.org \
--cc=simon.marchi@polymtl.ca \
--cc=vapier@gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox