[Bug middle-end/56341] GCC produces unaligned data access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56341 --- Comment #18 from jye2 at gcc dot gnu.org --- Author: jye2 Date: Thu Feb 27 07:28:06 2014 New Revision: 208195 URL: http://gcc.gnu.org/viewcvs?rev=208195root=gccview=rev Log: 2014-02-27 Joey Ye joey...@arm.com Backport mainline strict-volatile-bitfields fixes 2013-09-28 Sandra Loosemore san...@codesourcery.com gcc/ * expr.h (extract_bit_field): Remove packedp parameter. * expmed.c (extract_fixed_bit_field): Remove packedp parameter from forward declaration. (store_split_bit_field): Remove packedp arg from calls to extract_fixed_bit_field. (extract_bit_field_1): Remove packedp parameter and packedp argument from recursive calls and calls to extract_fixed_bit_field. (extract_bit_field): Remove packedp parameter and corresponding arg to extract_bit_field_1. (extract_fixed_bit_field): Remove packedp parameter. Remove code to issue warnings. (extract_split_bit_field): Remove packedp arg from call to extract_fixed_bit_field. * expr.c (emit_group_load_1): Adjust calls to extract_bit_field. (copy_blkmode_from_reg): Likewise. (copy_blkmode_to_reg): Likewise. (read_complex_part): Likewise. (store_field): Likewise. (expand_expr_real_1): Likewise. * calls.c (store_unaligned_arguments_into_pseudos): Adjust call to extract_bit_field. * config/tilegx/tilegx.c (tilegx_expand_unaligned_load): Adjust call to extract_bit_field. * config/tilepro/tilepro.c (tilepro_expand_unaligned_load): Adjust call to extract_bit_field. * doc/invoke.texi (Code Gen Options): Remove mention of warnings and special packedp behavior from -fstrict-volatile-bitfields documentation. 2013-12-11 Bernd Edlinger bernd.edlin...@hotmail.de * expr.c (expand_assignment): Remove dependency on flag_strict_volatile_bitfields. Always set the memory access mode. (expand_expr_real_1): Likewise. 2013-12-11 Sandra Loosemore san...@codesourcery.com PR middle-end/23623 PR middle-end/48784 PR middle-end/56341 PR middle-end/56997 gcc/ * expmed.c (strict_volatile_bitfield_p): New function. (store_bit_field_1): Don't special-case strict volatile bitfields here. (store_bit_field): Handle strict volatile bitfields here instead. (store_fixed_bit_field): Don't special-case strict volatile bitfields here. (extract_bit_field_1): Don't special-case strict volatile bitfields here. (extract_bit_field): Handle strict volatile bitfields here instead. (extract_fixed_bit_field): Don't special-case strict volatile bitfields here. Simplify surrounding code to resemble that in store_fixed_bit_field. * doc/invoke.texi (Code Gen Options): Update -fstrict-volatile-bitfields description. gcc/testsuite/ * gcc.dg/pr23623.c: New test. * gcc.dg/pr48784-1.c: New test. * gcc.dg/pr48784-2.c: New test. * gcc.dg/pr56341-1.c: New test. * gcc.dg/pr56341-2.c: New test. * gcc.dg/pr56997-1.c: New test. * gcc.dg/pr56997-2.c: New test. * gcc.dg/pr56997-3.c: New test. 2013-12-11 Bernd Edlinger bernd.edlin...@hotmail.de Sandra Loosemore san...@codesourcery.com PR middle-end/23623 PR middle-end/48784 PR middle-end/56341 PR middle-end/56997 * expmed.c (strict_volatile_bitfield_p): Add bitregion_start and bitregion_end parameters. Test for compliance with C++ memory model. (store_bit_field): Adjust call to strict_volatile_bitfield_p. Add fallback logic for cases where -fstrict-volatile-bitfields is supposed to apply, but cannot. (extract_bit_field): Likewise. Use narrow_bit_field_mem and extract_fixed_bit_field_1 to do the extraction. (extract_fixed_bit_field): Revert to previous mode selection algorithm. Call extract_fixed_bit_field_1 to do the real work. (extract_fixed_bit_field_1): New function. testsuite: * gcc.dg/pr23623.c: Update to test interaction with C++ memory model. 2013-12-11 Bernd Edlinger bernd.edlin...@hotmail.de PR middle-end/59134 * expmed.c (store_bit_field): Use narrow_bit_field_mem and store_fixed_bit_field_1 for -fstrict-volatile-bitfields. (store_fixed_bit_field): Split up. Call store_fixed_bit_field_1 to do the real work. (store_fixed_bit_field_1): New function. (store_split_bit_field): Limit the unit size to the memory mode size, to prevent recursion. testsuite: * gcc.c-torture/compile/pr59134.c: New test. * gnat.dg/misaligned_volatile.adb: New test. Added:
[Bug middle-end/56341] GCC produces unaligned data access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56341 Bernd Edlinger bernd.edlinger at hotmail dot de changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #17 from Bernd Edlinger bernd.edlinger at hotmail dot de --- fixed on trunk
[Bug middle-end/56341] GCC produces unaligned data access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56341 --- Comment #15 from edlinger at gcc dot gnu.org --- Author: edlinger Date: Wed Dec 11 16:50:05 2013 New Revision: 205896 URL: http://gcc.gnu.org/viewcvs?rev=205896root=gccview=rev Log: 2013-12-11 Sandra Loosemore san...@codesourcery.com PR middle-end/23623 PR middle-end/48784 PR middle-end/56341 PR middle-end/56997 gcc/ * expmed.c (strict_volatile_bitfield_p): New function. (store_bit_field_1): Don't special-case strict volatile bitfields here. (store_bit_field): Handle strict volatile bitfields here instead. (store_fixed_bit_field): Don't special-case strict volatile bitfields here. (extract_bit_field_1): Don't special-case strict volatile bitfields here. (extract_bit_field): Handle strict volatile bitfields here instead. (extract_fixed_bit_field): Don't special-case strict volatile bitfields here. Simplify surrounding code to resemble that in store_fixed_bit_field. * doc/invoke.texi (Code Gen Options): Update -fstrict-volatile-bitfields description. gcc/testsuite/ * gcc.dg/pr23623.c: New test. * gcc.dg/pr48784-1.c: New test. * gcc.dg/pr48784-2.c: New test. * gcc.dg/pr56341-1.c: New test. * gcc.dg/pr56341-2.c: New test. * gcc.dg/pr56997-1.c: New test. * gcc.dg/pr56997-2.c: New test. * gcc.dg/pr56997-3.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr23623.c trunk/gcc/testsuite/gcc.dg/pr48784-1.c trunk/gcc/testsuite/gcc.dg/pr48784-2.c trunk/gcc/testsuite/gcc.dg/pr56341-1.c trunk/gcc/testsuite/gcc.dg/pr56341-2.c trunk/gcc/testsuite/gcc.dg/pr56997-1.c trunk/gcc/testsuite/gcc.dg/pr56997-2.c trunk/gcc/testsuite/gcc.dg/pr56997-3.c Modified: trunk/gcc/ChangeLog trunk/gcc/doc/invoke.texi trunk/gcc/expmed.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/56341] GCC produces unaligned data access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56341 --- Comment #16 from edlinger at gcc dot gnu.org --- Author: edlinger Date: Wed Dec 11 16:59:24 2013 New Revision: 205897 URL: http://gcc.gnu.org/viewcvs?rev=205897root=gccview=rev Log: 2013-12-11 Bernd Edlinger bernd.edlin...@hotmail.de Sandra Loosemore san...@codesourcery.com PR middle-end/23623 PR middle-end/48784 PR middle-end/56341 PR middle-end/56997 * expmed.c (strict_volatile_bitfield_p): Add bitregion_start and bitregion_end parameters. Test for compliance with C++ memory model. (store_bit_field): Adjust call to strict_volatile_bitfield_p. Add fallback logic for cases where -fstrict-volatile-bitfields is supposed to apply, but cannot. (extract_bit_field): Likewise. Use narrow_bit_field_mem and extract_fixed_bit_field_1 to do the extraction. (extract_fixed_bit_field): Revert to previous mode selection algorithm. Call extract_fixed_bit_field_1 to do the real work. (extract_fixed_bit_field_1): New function. testsuite: * gcc.dg/pr23623.c: Update to test interaction with C++ memory model. Modified: trunk/gcc/ChangeLog trunk/gcc/expmed.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/pr23623.c
[Bug middle-end/56341] GCC produces unaligned data access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56341 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |NEW Last reconfirmed||2013-10-30 CC||ramana at gcc dot gnu.org Ever confirmed|0 |1 Known to fail||4.7.3, 4.8.0, 4.8.1, 4.9.0 --- Comment #14 from Ramana Radhakrishnan ramana at gcc dot gnu.org --- well, confirmed.
[Bug middle-end/56341] GCC produces unaligned data access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56341 --- Comment #13 from Sandra Loosemore sandra at codesourcery dot com --- Updated patch series: http://gcc.gnu.org/ml/gcc-patches/2013-09/msg02057.html http://gcc.gnu.org/ml/gcc-patches/2013-09/msg02058.html http://gcc.gnu.org/ml/gcc-patches/2013-09/msg02059.html Unfortunately, it seems that fixing bugs with -fstrict-volatile-bitfields has been blocked by disagreement between global reviewers and target maintainers who can't agree on whether the C/C++11 memory model should take precedence over target-specific ABIs by default. :-(
[Bug middle-end/56341] GCC produces unaligned data access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56341 --- Comment #12 from Sandra Loosemore sandra at codesourcery dot com --- Patch for the first problem posted here: http://gcc.gnu.org/ml/gcc-patches/2013-06/msg00750.html
[Bug middle-end/56341] GCC produces unaligned data access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56341 --- Comment #11 from Bernd Edlinger bernd.edlinger at hotmail dot de --- Created attachment 30248 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30248action=edit another example of the alignment faults Hello Sandra, good that you continue to work on that bug again. I agree that there may be two completely different aspects of this bug. Attached you'll find a new test program that came in my mind when I looked at PR 41809, the structure s is aligned 2 and packed. If you make it an array of size 10, each second call of f is given an odd pointer. But the compiler should know that because of the aligned(2) attribute. What is the difference to PR 41809 is this: 1. PR 41809 is not a correct C-program at all, and has never been. While this attached new test program is correct C program. previous GCC versions did compile that correctly, current GCC does not even emit a warning. 2. PR 41809 is not about volatile at all. However if you remove the volatile in the test program(s), the code is correct and does no longer use unaligned addresses. On the other hand, volatile might mean that the compiler should try not to optimize the read instructions, for instance in loops. But of course not to an extent that the generated code is no longer valid.
[Bug middle-end/56341] GCC produces unaligned data access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56341 --- Comment #10 from Sandra Loosemore sandra at codesourcery dot com --- I'm working on a new patch that addresses the first problem, the failure in test(). I think the second failure is not in test1() at all, and has nothing to do with -fstrict-volatile-bitfields. Looks to me like problem is that the expression x1-t1 is returning an unaligned pointer due to the packed attribute on struct test2. It should probably not be allowed to take the address of a packed struct field, at least on targets that require strict alignment. H, that bug is already filed as PR 41809. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41809
[Bug middle-end/56341] GCC produces unaligned data access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56341 --- Comment #9 from Bernd Edlinger bernd.edlinger at hotmail dot de 2013-03-27 10:36:48 UTC --- Hello GCC-Maintainers, what do you think? Should'nt this patch be in the 4.6.4 release?
[Bug middle-end/56341] GCC produces unaligned data access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56341 Bernd Edlinger bernd.edlinger at hotmail dot de changed: What|Removed |Added Attachment #29506|0 |1 is obsolete|| --- Comment #8 from Bernd Edlinger bernd.edlinger at hotmail dot de 2013-02-26 18:24:58 UTC --- Created attachment 29546 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29546 proposed patch, cleaned up in the last version of this patch the packedp parameter had only an impact on the generated warning. if packedp==true the warning is: multiple accesses to volatile structure member/bitfield because of packed attribute if packedp==false the warning is: mis-aligned access used for structure member/bitfield when a volatile object spans multiple type-sized locations, the compiler must choose between using a single mis-aligned access to preserve the volatility, or using multiple aligned accesses to avoid runtime faults; this code may fail at runtime if the hardware does not allow this access The second warning says in short: I am going to generate mis-aligned code, and I know it will fail at runtime. However this patch is supposed to avoid mis-aligned code, at least for ARM. Therefore it is only natural that the second warning is no longer needed. Now I removed all packedp code in extract_bit_field and store_bit_field, including the second warning. Fortunately that makes the patch much smaller. I did boot-strap the patched compiler several times, and everything looks good. TODO: remove translations of the obsolete warnings. (I dont know how to)
[Bug middle-end/56341] GCC produces unaligned data access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56341 Bernd Edlinger bernd.edlinger at hotmail dot de changed: What|Removed |Added Attachment #29465|0 |1 is obsolete|| --- Comment #7 from Bernd Edlinger bernd.edlinger at hotmail dot de 2013-02-20 01:38:04 UTC --- Created attachment 29506 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29506 proposed patch this patch uses packedp only for the warn_misaligned_bitfield() but does always use multiple load or stores. So even if the packedp may be unreliable it will only have influence on the warning text. reason: if packedp == false the code will always use a single but mis-aligned instruction which is known to abort at runtime. So that is always wrong. note: there are two almost identical formula used for packedp. packedp as it is used in extract_bit_field (old code): if (TYPE_PACKED (TREE_TYPE (TREE_OPERAND (exp, 0))) || (TREE_CODE (TREE_OPERAND (exp, 1)) == FIELD_DECL DECL_PACKED (TREE_OPERAND (exp, 1 packedp = true; packedp as it is used in store_field (new code): if (TREE_CODE(to) == COMPONENT_REF (TYPE_PACKED (TREE_TYPE (TREE_OPERAND (to, 0))) || (TREE_CODE (TREE_OPERAND (to, 1)) == FIELD_DECL DECL_PACKED (TREE_OPERAND (to, 1) packedp = true; However if we can not trust the second one why should we trust the first one? Therefore the packedp should not have influence on the code generation at all. That would only take unnecessary risks. Well, I think that should resolve your objections... Right?
[Bug middle-end/56341] GCC produces unaligned data access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56341 --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org 2013-02-18 11:20:43 UTC --- There is now better ways of implementing -fstrict-volatile-bitfields which I repeatedly told the arm people. Not for 4.6, but for 4.7 and trunk.
[Bug middle-end/56341] GCC produces unaligned data access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56341 Sandra Loosemore sandra at codesourcery dot com changed: What|Removed |Added CC||sandra at codesourcery dot ||com --- Comment #5 from Sandra Loosemore sandra at codesourcery dot com 2013-02-18 15:30:16 UTC --- The patch linked from the initial message was rejected. I did not (and still do not) have the time to rewrite it; if someone else can figure out how to fix this in a way that's acceptable to the maintainers, that would be great.
[Bug middle-end/56341] GCC produces unaligned data access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56341 --- Comment #6 from Bernd Edlinger bernd.edlinger at hotmail dot de 2013-02-18 18:41:55 UTC --- hhmm... could some one give an example where packedp would be false but the value is packed or unaligned?
[Bug middle-end/56341] GCC produces unaligned data access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56341 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Target||arm*-*-* Component|c |middle-end Version|unknown |4.6.3 Severity|major |normal
