From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugs-return-427017-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 21784 invoked by alias); 30 Jul 2013 22:53:01 -0000
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
Received: (qmail 21698 invoked by uid 48); 30 Jul 2013 22:52:58 -0000
From: "bernd.edlinger at hotmail dot de" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/57748] [4.8/4.9 Regression] ICE on ARM with -mfloat-abi=softfp -mfpu=neon
Date: Tue, 30 Jul 2013 22:53: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-Version: 4.8.0
X-Bugzilla-Keywords: ice-on-valid-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: bernd.edlinger at hotmail dot de
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.8.2
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-57748-4-bzxCd1RPAi@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-57748-4@http.gcc.gnu.org/bugzilla/>
References: <bug-57748-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-07/txt/msg01524.txt.bz2

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748

--- Comment #8 from Bernd Edlinger <bernd.edlinger at hotmail dot de> ---
(In reply to Martin Jambor from comment #7)
> In any event, it is clear that
> the code in expand_assignment cannot cope with unaligned tem and non-NULL
> offset.  So currently I'm considering the following patch, although I am not
> really sure it is enough (it does fix the ICE, though).  If you can run the
> testcase on the platform, would you run it with this patch applied, please?

No, unfortunately I can only look at the assembler listing.

But wait a moment...

If the object is assumed to be unaligned here this patch will
likely just compute the unaligned address, add the offset,
and store the result there without any special precautions.
While the code in the if statement seems to store the expression
on a register and move that register to the final destination.

Well, I believe this unaligned arrays are generally broken.

consider this example:

struct test
{
  char x;
  long long y[10];
} __attribute__((packed));

long long foo(struct test *x, long long y, long long z)
{
   long long a = x->y[y];
   x->y[y] = z;
   return a;
}

gets compiled to:

foo:
        @ Function supports interworking.
        @ args = 8, pretend = 0, frame = 0
        @ frame_needed = 0, uses_anonymous_args = 0
        @ link register save eliminated.
        stmfd   sp!, {r4, r5}
        add     r5, sp, #8
        ldmia   r5, {r4-r5}
        add     r2, r0, r2, asl #3
        add     r1, r2, #1
        ldmia   r1, {r0-r1}
        str     r4, [r2, #1]
        str     r5, [r2, #5]
        ldmfd   sp!, {r4, r5}
        bx      lr

Won't these ldmia statements statements fault on unaligned
addresses, even on a cortex-a9 ?

Furthermore str on odd addresses are always there, regardless of the
-mno-unaligned-access setting.