This is the mail archive of the
mailing list for the GCC project.
RE: [patch 2/4] fix -fstrict-volatile-bitfields bugs, v3
- From: Bernd Edlinger <bernd dot edlinger at hotmail dot de>
- To: Sandra Loosemore <sandra at codesourcery dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Cc: Richard Biener <richard dot guenther at gmail dot com>, Eric Botcazou <ebotcazou at adacore dot com>
- Date: Mon, 1 Jul 2013 23:27:58 +0200
- Subject: RE: [patch 2/4] fix -fstrict-volatile-bitfields bugs, v3
- References: <51D0F67D dot 6050803 at codesourcery dot com>
I tested with arm-none-eabi.
Now both variants, with and without -fstrict-volatile-bitfields
produce the expected results for EABI-compliant structures,
and still create reasonable code with non-compliant packed structures.
> I think there is still a case where this version of the patch could
> still end up reading or writing past the end of an object. For example,
> consider a packed struct that is 3 bytes long, with a bitfield that has
> int type. I am not sure how to detect this situation at this point in
> the code, but leaving just that case un-fixed for now seems better than
> leaving the current mess in place. Perhaps it could be addressed by a
> follow-up patch. Also, assuming the change in part 4 of the new series
> to make -fstrict-volatile-bitfields not be the default on any target any
> more is required as a condition of due to overriding the new memory
> model, programmers at least will be less likely to be taken by surprise
> when it does something weird with packed structures.
> Is this version OK to commit, or at least getting closer? I'd like to
> wind this project up soon, somehow or another.
The patch fixes both aspects of PR56341 (unaligned access fault and write
incorrect value). Regardless of -fstrict-volatile-bitfields setting.
Fixes also PR48748 + PR56997, except for the access outside the structure.
Apparently these accesses do not happen if the struct is an external object,
they only happen if the struct is a comdat object (and the compiler possibly
knows the extra bytes exist and are not used by anything?).
Nevertheless this patch is a significant improvement, and those left-overs
should be fixed after this is committed.