[Bug middle-end/56341] GCC produces unaligned data access

["bernd.edlinger at hotmail dot de" <gcc-bugzilla@gcc.gnu.org>]

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?