This is the mail archive of the
gcc-help@gcc.gnu.org
mailing list for the GCC project.
Re: Help working out where GCC decides the size of 0xFFFFFFFF
- From: Alex Brown <alex dot g dot brown at gmail dot com>
- To: Oleg Endo <oleg dot endo at t-online dot de>
- Cc: gcc-help at gcc dot gnu dot org
- Date: Tue, 21 Apr 2015 15:23:43 +1000
- Subject: Re: Help working out where GCC decides the size of 0xFFFFFFFF
- Authentication-results: sourceware.org; auth=none
- References: <CAB-RZVS3BoYB8d7GwtU82wUxiuowuFjbJWiv=sJbb4tw-Qswfw at mail dot gmail dot com> <1429463126 dot 6137 dot 91 dot camel at yam-132-YW-E178-FTW> <CAB-RZVTA5-=30EWKnaHGEvCpV93EqUt7svfPdE2MpAfJCYQfLw at mail dot gmail dot com>
On Mon, Apr 20, 2015 at 1:51 PM, Alex Brown <alex.g.brown@gmail.com> wrote:
> I think I am slowly narrowing down where the bad decision is being
> made. Seems an incorrect results comes from a call to:
>
> bool wi::fits_to_tree_p(const T &x, const_tree type)
>
> and more specifically the call to eq_p() after it does a zext
>
> I am not sure yet if the issue is in that call, or if the tree data is
> incorrectly formed going in, but at least for the time being I have
> some leads to follow.
So it turns out it was a bug in one of the instructions in my
simulator, so no problems with the GCC configuration.