This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
RE: [PATCH, PR 57748] Check for out of bounds access, Part 2
- From: Bernd Edlinger <bernd dot edlinger at hotmail dot de>
- To: Eric Botcazou <ebotcazou at adacore dot com>
- Cc: "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, Martin Jambor <mjambor at suse dot cz>, Richard Biener <richard dot guenther at gmail dot com>
- Date: Wed, 9 Oct 2013 00:12:00 +0200
- Subject: RE: [PATCH, PR 57748] Check for out of bounds access, Part 2
- Authentication-results: sourceware.org; auth=none
- References: <20130910193228 dot GE6732 at virgil dot suse> <2557640 dot s7jgdhfLQs at polaris> <DUB122-W4934D7B6A1D7196E2D6913E41C0 at phx dot gbl>,<2243204 dot JyA3NMmzTd at polaris>
Hi,
On Tue, 8 Oct 2013 22:50:21, Eric Botcazou wrote:
>
>> I agree, that assigning a non-BLKmode to structures with zero-sized arrays
>> should be considered a bug.
>
> Fine, then let's apply Martin's patch, on mainline at least.
>
That would definitely be a good move. Maybe someone should approve it?
> But this testcase is invalid on STRICT_ALIGNMENT platforms: xx is pointer to a
> type with 4-byte alignment so its value must be a multiple of 4.
Then you probably win. But I still have some doubts.
I had to use this silly alignment/pack(4) to circumvent this statement
in compute_record_mode:
/* If structure's known alignment is less than what the scalar
mode would need, and it matters, then stick with BLKmode. */
if (TYPE_MODE (type) != BLKmode
&& STRICT_ALIGNMENT
&& ! (TYPE_ALIGN (type)>= BIGGEST_ALIGNMENT
|| TYPE_ALIGN (type)>= GET_MODE_ALIGNMENT (TYPE_MODE (type))))
{
/* If this is the only reason this type is BLKmode, then
don't force containing types to be BLKmode. */
TYPE_NO_FORCE_BLK (type) = 1;
SET_TYPE_MODE (type, BLKmode);
}
But there are at least two targets where STRICT_ALIGNMENT = 0
and SLOW_UNALIGNED_ACCESS != 0: rs6000 and alpha.
This example with a byte-aligned structure will on one of these targets
likely execute this code path in expand_expr_real_1/case MEM_REF:
else if (SLOW_UNALIGNED_ACCESS (mode, align))
temp = extract_bit_field (temp, GET_MODE_BITSIZE (mode),
0, TYPE_UNSIGNED (TREE_TYPE (exp)),
(modifier == EXPAND_STACK_PARM
? NULL_RTX : target),
mode, mode);
This looks wrong, but unfortunately I cannot test on these targets...
Regards
Bernd.