From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugs-return-415856-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 6109 invoked by alias); 20 Feb 2013 01:38:24 -0000
Received: (qmail 5858 invoked by uid 48); 20 Feb 2013 01:38:06 -0000
From: "bernd.edlinger at hotmail dot de" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/56341] GCC produces unaligned data access
Date: Wed, 20 Feb 2013 01:38:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: middle-end
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: bernd.edlinger at hotmail dot de
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Changed-Fields: Attachment #29465 is obsolete
Message-ID: <bug-56341-4-Em7bcLV8CT@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-56341-4@http.gcc.gnu.org/bugzilla/>
References: <bug-56341-4@http.gcc.gnu.org/bugzilla/>
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
Content-Type: text/plain; charset="UTF-8"
MIME-Version: 1.0
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
X-SW-Source: 2013-02/txt/msg02021.txt.bz2


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?