From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugs-return-429289-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 3835 invoked by alias); 9 Sep 2013 06:41:40 -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 3775 invoked by uid 48); 9 Sep 2013 06:41:37 -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.7/4.8/4.9 Regression] ICE when expanding assignment to unaligned zero-sized array
Date: Mon, 09 Sep 2013 06:41: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, wrong-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-bJJnG0m934@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-09/txt/msg00529.txt.bz2

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

--- Comment #34 from Bernd Edlinger <bernd.edlinger at hotmail dot de> ---
Hmm, this was looking like a working example ((if it is valid C at all)),
but after some thougt, I saw now it exposes a data store race:

#include <stdio.h>
#include <string.h>

typedef long long V
  __attribute__ ((vector_size (2 * sizeof (long long)), may_alias));
union x
{
   long long a;
   float b;
} __attribute__((aligned(1))) ;

struct s
{
  union x xx[0];
  V x;

} __attribute__((packed));

void __attribute__((noinline, noclone))
foo(struct s * x)
{
  x->xx[0].a = -1;
  x->xx[0].b = 3.14;
  x->x[1] = 0x123456789ABCDEF;
}

int
main()
{
  struct s ss;
  memset(&ss, 0, sizeof(ss));
  foo (&ss);
  printf("%f %llX\n", ss.xx[0].b, ss.xx[0].a);
  printf("%llX %llX\n", ss.x[0], ss.x[1]);
}

the resulting code is:

foo:
.LFB23:
        .cfi_startproc
        movdqu  (%rdi), %xmm0
        movabsq $-4294967296, %rdx
        movq    .LC1(%rip), %xmm1
        psrldq  $8, %xmm0
        punpcklqdq      %xmm0, %xmm1
        movdqu  %xmm1, (%rdi)
        movdqu  (%rdi), %xmm2
        movdqa  %xmm2, -24(%rsp)
        movq    -24(%rsp), %rax
        andq    %rdx, %rax
        orq     $1078523331, %rax
        movq    %rax, -24(%rsp)
        movdqa  -24(%rsp), %xmm3
        movdqu  %xmm3, (%rdi)
        movdqu  (%rdi), %xmm0
        movhps  .LC2(%rip), %xmm0
        movdqu  %xmm0, (%rdi)
        ret

Which shows all read/write accesses are 16 byte at a time and this creates
a forbidden data store race.
Looks like I shot my own patch down now :-)