From: Pedro Alves <palves@redhat.com>
To: "Maciej W. Rozycki" <macro@imgtec.com>, gdb-patches@sourceware.org
Subject: Re: [PATCH] tilegx-tdep: Correct aliasing errors in `tilegx_analyze_prologue'
Date: Mon, 17 Oct 2016 15:46:00 -0000 [thread overview]
Message-ID: <c089fa37-700c-406a-904b-ac5393a9871d@redhat.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1610150200220.31859@tp.orcam.me.uk>
On 10/17/2016 04:18 PM, Maciej W. Rozycki wrote:
> Fix a load of aliasing build errors:
>
> cc1plus: warnings being treated as errors
> .../gdb/tilegx-tdep.c: In function 'CORE_ADDR tilegx_analyze_prologue(gdbarch*, CORE_ADDR, CORE_ADDR, tilegx_frame_cache*, frame_info*)':
> .../gdb/tilegx-tdep.c:609: error: dereferencing pointer 'operands' does break strict-aliasing rules
> .../gdb/tilegx-tdep.c:592: error: dereferencing pointer 'operands' does break strict-aliasing rules
> .../gdb/tilegx-tdep.c:571: error: dereferencing pointer 'operands' does break strict-aliasing rules
> [...]
> .../gdb/tilegx-tdep.c:601: error: dereferencing pointer '<anonymous>' does break strict-aliasing rules
> .../gdb/tilegx-tdep.c:601: note: initialized from here
> cc1plus: error: dereferencing pointer 'operands' does break strict-aliasing rules
> cc1plus: error: dereferencing pointer 'operands' does break strict-aliasing rules
> .../gdb/tilegx-tdep.c:452: note: initialized from here
> cc1plus: error: dereferencing pointer 'pretmp.896' does break strict-aliasing rules
> cc1plus: note: initialized from here
> cc1plus: error: dereferencing pointer 'pretmp.896' does break strict-aliasing rules
> cc1plus: note: initialized from here
> make[1]: *** [tilegx-tdep.o] Error 1
>
> from an attempt to cast a `long long' pointer to an `int64_t' pointer,
> which may not necessarily be compatible types. Use the `long long' type
> for the auxiliary variable then as this is the type of the structure
> member referred.
>
> gdb/
> * tilegx-tdep.c (tilegx_analyze_prologue): Use the `long long'
> type for `operands'.
> ---
> Hi,
>
> This was discovered in an `--enable-targets=all' `mips-mti-linux-gnu'
> build and may be dependent on the host type and compiler version, which
> are `x86_64-linux' and 4.4.7 here, respectively. OK to apply?
>
Sure, please do ahead.
I'd be better if tilegx.h used uint32_t/uint64_t, etc,
but that can always be done separately by someone motivated.
Thanks,
Pedro Alves
next prev parent reply other threads:[~2016-10-17 15:46 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-17 15:18 Maciej W. Rozycki
2016-10-17 15:46 ` Pedro Alves [this message]
2016-10-18 3:50 ` Maciej W. Rozycki
2016-10-18 9:22 ` Pedro Alves
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=c089fa37-700c-406a-904b-ac5393a9871d@redhat.com \
--to=palves@redhat.com \
--cc=gdb-patches@sourceware.org \
--cc=macro@imgtec.com \
/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