This is the mail archive of the
mailing list for the GCC project.
RE: [PATCH, PR 57748] Check for out of bounds access
- From: Bernd Edlinger <bernd dot edlinger at hotmail dot de>
- To: Richard Biener <richard dot guenther at gmail dot com>, Eric Botcazou <ebotcazou at adacore dot com>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>, Martin Jambor <mjambor at suse dot cz>
- Date: Thu, 24 Oct 2013 12:10:35 +0200
- Subject: RE: [PATCH, PR 57748] Check for out of bounds access
- Authentication-results: sourceware.org; auth=none
- References: <DUB122-W396D54115D70C9FF68A8D2E43C0 at phx dot gbl>,<DUB122-W209385567C3551814F6331E4020 at phx dot gbl>,<CAFiYyc3PWncBNCA4eG41FZOa6mObYU25NjV95H4QXUyRzLakvA at mail dot gmail dot com>,<12926210 dot 0Og1E00UsZ at polaris>,<CAFiYyc0rquUu6SEQYGObmHZh-DSvThyUcBNHEPfL0paghj5WCA at mail dot gmail dot com>
On Thu, 24 Oct 2013 11:56:52, Richard Biener wrote:
> On Thu, Oct 24, 2013 at 10:37 AM, Eric Botcazou <email@example.com> wrote:
>>> if bitregion_start/end are used after the adjust_address call then they have
>>> to be adjusted (or bitpos left in place). In fact why we apply byte-parts
>>> of bitpos here only if offset != 0 is weird.
>> Presumably to be able to do arithmetic on symbols when the offset is variable,
>> which can save one addition in the final code.
> Doesn't that also apply to arithmetic on symbols when the offset is NULL?
> But yes, the codegen example posted shows this kind of difference
> (though it doesn't seem to save anything for that case). I'd have expected
> a more explicit guarding of this case, like with MEM_P (to_rtx)
> && SYMBOL_REF_P (XEXP (to_rtx, 0)) though, eventually even looking
> whether the resulting address is legitimate. But ... doesn't forwprop
> fix this up later anyway?
> Either way, bitregion_start/end is clearly wrong after we hit this case.
> I'm always fast approving removal of "odd" code (less-code-is-better
> doctrine...), but in this case maybe the code can be improved instead.
> The comment before it is also odd and likely only applies to later
> added restrictions. Just to quote it again:
> if (offset != 0)
> /* A constant address in TO_RTX can have VOIDmode, we must not try
> to call force_reg for that case. Avoid that case. */
> if (MEM_P (to_rtx)
> && GET_MODE (to_rtx) == BLKmode
> && GET_MODE (XEXP (to_rtx, 0)) != VOIDmode
> && bitsize> 0
> && (bitpos % bitsize) == 0
> && (bitsize % GET_MODE_ALIGNMENT (mode1)) == 0
> && MEM_ALIGN (to_rtx) == GET_MODE_ALIGNMENT (mode1))
> to_rtx = adjust_address (to_rtx, mode1, bitpos / BITS_PER_UNIT);
> bitpos = 0;
> to_rtx = offset_address (to_rtx, offset_rtx,
> highest_pow2_factor_for_target (to,
In the initial commit from 1998 where this was introduced that
block contained an explicit force_reg call, but not that comment.
>> Eric Botcazou