[Bug middle-end/57748] [4.8/4.9 Regression] ICE when expanding assignment to unaligned zero-sized array

2013-09-04 Thread bernd.edlinger at hotmail dot de 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748

--- Comment #27 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
(In reply to Martin Jambor from comment #22)
 Created attachment 30732 [details]
 Another attempt at a fix
 
 I simply moved the decision whether to go the misalignp path or not a
 bit down in the function, below the address adjustments done for
 non-NULL offset, strict volatile bit fields etc. and ran the
 testsuite, expecting some fallout.  But there was none the patch even
 survives a bootstrap on x86_64-linux.  I'm hesitant to call it the
 fix, I'd like to have a second look at it after the weekend but if
 someone wants to test meanwhile, such input would be highly welcome.

Martin, this patch is wrong:
consider this test example:

/* PR middle-end/57748 */
/* { dg-do run } */

#include stdlib.h

extern void abort (void);

typedef long long V
  __attribute__ ((vector_size (2 * sizeof (long long)), may_alias));

typedef double V1
  __attribute__ ((vector_size (1 * sizeof (double)), may_alias));

typedef struct S { V a; V1 b[0]; } P __attribute__((aligned (1)));

struct __attribute__((packed)) T { char c; P s; };

void __attribute__((noinline, noclone))
check (struct T *t)
{
  if (t-s.b[0][0] != 3)
abort ();
}

int __attribute__((noinline, noclone))
get_i (void)
{
  return 0;
}

void __attribute__((noinline, noclone))
foo (P *p)
{
  V1 a = { 3 };
  int i = get_i();
  p-b[i] = a;
}

int
main ()
{
  struct T *t = (struct T *) malloc (128);

  foo (t-s);
  check (t);

  return 0;
}

this example is designed to go thru the
if (bitsize != GET_MODE_BITSIZE (mode)) path.
Because the struct mode is derived from V but the bitsize
is from V1, only half of V.

the resulting code from this patch accesses out of bounds:

foo:
.LFB9:
.cfi_startproc
pushq   %rbx
.cfi_def_cfa_offset 16
.cfi_offset 3, -16
movq%rdi, %rbx
subq$16, %rsp
.cfi_def_cfa_offset 32
callget_i
cltq
movq.LC1(%rip), %xmm1
addq$2, %rax
movdqu  (%rbx,%rax,8), %xmm0
psrldq  $8, %xmm0
punpcklqdq  %xmm0, %xmm1
movdqu  %xmm1, (%rbx,%rax,8)
addq$16, %rsp
.cfi_def_cfa_offset 16
popq%rbx
.cfi_def_cfa_offset 8
ret
.cfi_endproc

while my latest patch (which meanwhile was boot-straped without regressions)
generates this:

foo:
.LFB9:
.cfi_startproc
pushq   %rbx
.cfi_def_cfa_offset 16
.cfi_offset 3, -16
movq%rdi, %rbx
callget_i
movsd   .LC0(%rip), %xmm0
cltq
movsd   %xmm0, 16(%rbx,%rax,8)
popq%rbx
.cfi_def_cfa_offset 8
ret
.cfi_endproc

[Bug middle-end/57748] [4.8/4.9 Regression] ICE when expanding assignment to unaligned zero-sized array

2013-09-04 Thread bernd.edlinger at hotmail dot de 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748

--- Comment #28 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
(In reply to Richard Biener from comment #19)
 Barking up wrong trees.  Hacky fix looks like:
 
 Index: gcc/expr.c
 ===
 --- gcc/expr.c  (revision 202043)
 +++ gcc/expr.c  (working copy)
 @@ -4753,6 +4753,9 @@ expand_assignment (tree to, tree from, b
 {
   enum machine_mode address_mode;
   rtx offset_rtx;
 + rtx saved_to_rtx = to_rtx;
 + if (misalignp)
 +   to_rtx = mem;
  
   if (!MEM_P (to_rtx))
 {
 @@ -4785,6 +4788,11 @@ expand_assignment (tree to, tree from, b
   to_rtx = offset_address (to_rtx, offset_rtx,
highest_pow2_factor_for_target (to,
offset));
 + if (misalignp)
 +   {
 + mem = to_rtx;
 + to_rtx = saved_to_rtx;
 +   }
 }
  
/* No action is needed if the target is not a memory and the field
 
 

this patch generates wrong code too:

foo:
.LFB9:
.cfi_startproc
pushq   %rbx
.cfi_def_cfa_offset 16
.cfi_offset 3, -16
movq%rdi, %rbx
subq$16, %rsp
.cfi_def_cfa_offset 32
callget_i
movdqu  (%rbx), %xmm0
cltq
movq.LC1(%rip), %xmm1
psrldq  $8, %xmm0
punpcklqdq  %xmm0, %xmm1
movdqu  %xmm1, 16(%rbx,%rax,8)
addq$16, %rsp
.cfi_def_cfa_offset 16
popq%rbx
.cfi_def_cfa_offset 8
ret
.cfi_endproc

loads *s into xmm0, modifies low part,
writes back at s-b[0] and s-b[1].

[Bug middle-end/57748] [4.8/4.9 Regression] ICE when expanding assignment to unaligned zero-sized array

2013-09-04 Thread rguenth at gcc dot gnu.org 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748

Richard Biener rguenth at gcc dot gnu.org changed:

   What|Removed |Added

 CC||uros at gcc dot gnu.org

--- Comment #29 from Richard Biener rguenth at gcc dot gnu.org ---
(In reply to Bernd Edlinger from comment #28)
 (In reply to Richard Biener from comment #19)
  Barking up wrong trees.  Hacky fix looks like:
  
  Index: gcc/expr.c
  ===
  --- gcc/expr.c  (revision 202043)
  +++ gcc/expr.c  (working copy)
  @@ -4753,6 +4753,9 @@ expand_assignment (tree to, tree from, b
  {
enum machine_mode address_mode;
rtx offset_rtx;
  + rtx saved_to_rtx = to_rtx;
  + if (misalignp)
  +   to_rtx = mem;
   
if (!MEM_P (to_rtx))
  {
  @@ -4785,6 +4788,11 @@ expand_assignment (tree to, tree from, b
to_rtx = offset_address (to_rtx, offset_rtx,
 highest_pow2_factor_for_target (to,
 offset));
  + if (misalignp)
  +   {
  + mem = to_rtx;
  + to_rtx = saved_to_rtx;
  +   }
  }
   
 /* No action is needed if the target is not a memory and the field
  
  
 
 this patch generates wrong code too:
 
 foo:
 .LFB9:
 .cfi_startproc
 pushq   %rbx
 .cfi_def_cfa_offset 16
 .cfi_offset 3, -16
 movq%rdi, %rbx
 subq$16, %rsp
 .cfi_def_cfa_offset 32
 callget_i
 movdqu  (%rbx), %xmm0
 cltq
 movq.LC1(%rip), %xmm1
 psrldq  $8, %xmm0
 punpcklqdq  %xmm0, %xmm1
 movdqu  %xmm1, 16(%rbx,%rax,8)
 addq$16, %rsp
 .cfi_def_cfa_offset 16
 popq%rbx
 .cfi_def_cfa_offset 8
 ret
 .cfi_endproc
 
 loads *s into xmm0, modifies low part,
 writes back at s-b[0] and s-b[1].

This bug is latent because we use the mode of the base object to query
for movmisalign_optab (and use it).  It highlights the issue I raised
in my last comment.

So, new, completely untested patch:

Index: gcc/expr.c
===
--- gcc/expr.c  (revision 202240)
+++ gcc/expr.c  (working copy)
@@ -4646,10 +4646,12 @@ expand_assignment (tree to, tree from, b

   /* Handle misaligned stores.  */
   mode = TYPE_MODE (TREE_TYPE (to));
-  if ((TREE_CODE (to) == MEM_REF
-   || TREE_CODE (to) == TARGET_MEM_REF)
-   mode != BLKmode
-   !mem_ref_refers_to_non_mem_p (to)
+  if (mode != BLKmode
+   (DECL_P (to)
+ || handled_component_p (to)
+ || ((TREE_CODE (to) == MEM_REF
+  || TREE_CODE (to) == TARGET_MEM_REF)
+  !mem_ref_refers_to_non_mem_p (to)))
((align = get_object_alignment (to))
   GET_MODE_ALIGNMENT (mode))
(((icode = optab_handler (movmisalign_optab, mode))
@@ -4696,7 +4698,6 @@ expand_assignment (tree to, tree from, b
   int unsignedp;
   int volatilep = 0;
   tree tem;
-  bool misalignp;
   rtx mem = NULL_RTX;

   push_temp_slots ();
@@ -4707,40 +4708,7 @@ expand_assignment (tree to, tree from, b
   DECL_BIT_FIELD_TYPE (TREE_OPERAND (to, 1)))
get_bit_range (bitregion_start, bitregion_end, to, bitpos, offset);

-  /* If we are going to use store_bit_field and extract_bit_field,
-make sure to_rtx will be safe for multiple use.  */
-  mode = TYPE_MODE (TREE_TYPE (tem));
-  if (TREE_CODE (tem) == MEM_REF
-  mode != BLKmode
-  ((align = get_object_alignment (tem))
-  GET_MODE_ALIGNMENT (mode))
-  ((icode = optab_handler (movmisalign_optab, mode))
- != CODE_FOR_nothing))
-   {
- struct expand_operand ops[2];
-
- misalignp = true;
- to_rtx = gen_reg_rtx (mode);
- mem = expand_expr (tem, NULL_RTX, VOIDmode, EXPAND_WRITE);
-
- /* If the misaligned store doesn't overwrite all bits, perform
-rmw cycle on MEM.  */
- if (bitsize != GET_MODE_BITSIZE (mode))
-   {
- create_input_operand (ops[0], to_rtx, mode);
- create_fixed_operand (ops[1], mem);
- /* The movmisalignmode pattern cannot fail, else the assignment
-would silently be omitted.  */
- expand_insn (icode, 2, ops);
-
- mem = copy_rtx (mem);
-   }
-   }
-  else
-   {
- misalignp = false;
- to_rtx = expand_expr (tem, NULL_RTX, VOIDmode, EXPAND_WRITE);
-   }
+  to_rtx = expand_expr (tem, NULL_RTX, VOIDmode, EXPAND_WRITE);

   /* If the bitfield is volatile, we want to access it in the
 field's mode, not the

[Bug middle-end/57748] [4.8/4.9 Regression] ICE when expanding assignment to unaligned zero-sized array

2013-09-03 Thread rguenth at gcc dot gnu.org 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748

--- Comment #25 from Richard Biener rguenth at gcc dot gnu.org ---
I think that

  tem = get_inner_reference (to, bitsize, bitpos, offset, mode1,
 unsignedp, volatilep, true);

  if (TREE_CODE (to) == COMPONENT_REF
   DECL_BIT_FIELD_TYPE (TREE_OPERAND (to, 1)))
get_bit_range (bitregion_start, bitregion_end, to, bitpos, offset);

  /* If we are going to use store_bit_field and extract_bit_field,
 make sure to_rtx will be safe for multiple use.  */
  mode = TYPE_MODE (TREE_TYPE (tem));
  if (TREE_CODE (tem) == MEM_REF
   mode != BLKmode
   ((align = get_object_alignment (tem))
   GET_MODE_ALIGNMENT (mode))
   ((icode = optab_handler (movmisalign_optab, mode))
  != CODE_FOR_nothing))

is overly pessimistic.  What matters is the mode of the access, not that
of the access base object!

Which means the pre-handling of

  /* Handle misaligned stores.  */
  mode = TYPE_MODE (TREE_TYPE (to));
  if ((TREE_CODE (to) == MEM_REF
   || TREE_CODE (to) == TARGET_MEM_REF)
   mode != BLKmode
   !mem_ref_refers_to_non_mem_p (to)

should be made to trigger for all 'to', not just bare MEM_REF/TARGET_MEM_REF.
Then the other movmisalign path can be completely removed.

[Bug middle-end/57748] [4.8/4.9 Regression] ICE when expanding assignment to unaligned zero-sized array

2013-09-03 Thread bernd.edlinger at hotmail dot de 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748

--- Comment #26 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
(In reply to Richard Biener from comment #25)
 I think that
 
   tem = get_inner_reference (to, bitsize, bitpos, offset, mode1,
  unsignedp, volatilep, true);
 
   if (TREE_CODE (to) == COMPONENT_REF
DECL_BIT_FIELD_TYPE (TREE_OPERAND (to, 1)))
 get_bit_range (bitregion_start, bitregion_end, to, bitpos,
 offset);
 
   /* If we are going to use store_bit_field and extract_bit_field,
  make sure to_rtx will be safe for multiple use.  */
   mode = TYPE_MODE (TREE_TYPE (tem));
   if (TREE_CODE (tem) == MEM_REF
mode != BLKmode
((align = get_object_alignment (tem))
GET_MODE_ALIGNMENT (mode))
((icode = optab_handler (movmisalign_optab, mode))
   != CODE_FOR_nothing))
 
 is overly pessimistic.  What matters is the mode of the access, not that
 of the access base object!
 
 Which means the pre-handling of
 
   /* Handle misaligned stores.  */
   mode = TYPE_MODE (TREE_TYPE (to));
   if ((TREE_CODE (to) == MEM_REF
|| TREE_CODE (to) == TARGET_MEM_REF)
mode != BLKmode
!mem_ref_refers_to_non_mem_p (to)
 
 should be made to trigger for all 'to', not just bare MEM_REF/TARGET_MEM_REF.
 Then the other movmisalign path can be completely removed.

struct s
{
  int x:19;
} __attribute__((packed));
int foo(struct s *s)
{
  s-x=1;
}

in this case of a packed field the TREE_CODE (to) will be COMPONENT_REF
TYPE_MODE (TREE_TYPE (to)) will be SImode.
If this would go to the pre-handling, this will not work for packed bit-fields.

this handling is just for: int *x;

*x = 1;

or: struct s *x, *y;

*x = *y; //if struct s is not BLKmode.

[Bug middle-end/57748] [4.8/4.9 Regression] ICE when expanding assignment to unaligned zero-sized array

2013-09-02 Thread bernd.edlinger at hotmail dot de 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748

--- Comment #24 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
Created attachment 30743
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30743action=edit
Yet another untested fix

Ok, this is somewhat similar to Martin's very first attempt
to fix this.

After staring at the code for quite a long time,
I believe the misalign code path is meant for structures
or unions that can be accessed in a mode != BLKmode which
is the mode of the largest member of a union for instance.

But if that mode has a movmisalign op that should be used.
However that is only an optimization, store_field will always
be able to store the value byte by byte if necessary.

If offset != 0 we have a non-constant (or maybe negative)
array index here.
If volatile we have a volatile access.
If bitpos + bitsize  GET_MODE_BITSIZE we probably
have an array with a constant index.
If any of these happens, better not go the misalign code path.

The second hunk is necessary because the if block
sets bitpos = 0, but leaves bitregion_start and bitregion_end untouched,
creating an inconsistent bitregion, which may or may not assert later.
Therefore check that this is no bitregion. If it is a bit region
store_field can handle it.

How do you like this patch?

[Bug middle-end/57748] [4.8/4.9 Regression] ICE when expanding assignment to unaligned zero-sized array

2013-08-31 Thread bernd.edlinger at hotmail dot de 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748

--- Comment #23 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
Martin, one of the errors with strict volatile bitfields
was with a structure like this.

struct S0 {
   signed a : 7;
   unsigned b : 28;
} __attribute__((packed));

here the member b is using SImode but the data are spread over 5 bytes.

This stucture access does not go thru the misalign code path.
But it it did, then I think we could get into trouble.

The code in the misalign code path assumes, that bitpos == 0.
Otherwise the condition if (bitsize != GET_MODE_BITSIZE (mode))
will not do the right thing.

And the misalign code path will break the
-fstrict-volatile-bitfields if the access is volatile.

What I mean is if we could find an example where this code path
is executed for a bit field it will break the strict volatile bitfileds
once again, even with Sandra Loosemore's patch.

Probably there is a reason why this can not happen but I do not see
it. At least there should be some assertions here.

[Bug middle-end/57748] [4.8/4.9 Regression] ICE when expanding assignment to unaligned zero-sized array

2013-08-30 Thread jamborm at gcc dot gnu.org 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748

--- Comment #22 from Martin Jambor jamborm at gcc dot gnu.org ---
Created attachment 30732
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30732action=edit
Another attempt at a fix

I simply moved the decision whether to go the misalignp path or not a
bit down in the function, below the address adjustments done for
non-NULL offset, strict volatile bit fields etc. and ran the
testsuite, expecting some fallout.  But there was none the patch even
survives a bootstrap on x86_64-linux.  I'm hesitant to call it the
fix, I'd like to have a second look at it after the weekend but if
someone wants to test meanwhile, such input would be highly welcome.

[Bug middle-end/57748] [4.8/4.9 Regression] ICE when expanding assignment to unaligned zero-sized array

2013-08-29 Thread bernd.edlinger at hotmail dot de 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748

--- Comment #21 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
Richard, I have one question:
does this code at expr.c line 4717 look right?
I mean does the code in the if block use the offset at all?

  misalignp = true;
  to_rtx = gen_reg_rtx (mode);
  mem = expand_expr (tem, NULL_RTX, VOIDmode, EXPAND_WRITE);

  /* If the misaligned store doesn't overwrite all bits, perform
 rmw cycle on MEM.  */
  if (bitsize != GET_MODE_BITSIZE (mode))
{
  create_input_operand (ops[0], to_rtx, mode);
  create_fixed_operand (ops[1], mem);
  /* The movmisalignmode pattern cannot fail, else the assignment
 would silently be omitted.  */
  expand_insn (icode, 2, ops);

  mem = copy_rtx (mem);
}

what must be done to execute in that block?
create a struct with an array of struct of bitfields or something?
that happens to be unaligned, and have BLKmode?

[Bug middle-end/57748] [4.8/4.9 Regression] ICE when expanding assignment to unaligned zero-sized array

2013-08-28 Thread rguenth at gcc dot gnu.org 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748

--- Comment #19 from Richard Biener rguenth at gcc dot gnu.org ---
Barking up wrong trees.  Hacky fix looks like:

Index: gcc/expr.c
===
--- gcc/expr.c  (revision 202043)
+++ gcc/expr.c  (working copy)
@@ -4753,6 +4753,9 @@ expand_assignment (tree to, tree from, b
{
  enum machine_mode address_mode;
  rtx offset_rtx;
+ rtx saved_to_rtx = to_rtx;
+ if (misalignp)
+   to_rtx = mem;

  if (!MEM_P (to_rtx))
{
@@ -4785,6 +4788,11 @@ expand_assignment (tree to, tree from, b
  to_rtx = offset_address (to_rtx, offset_rtx,
   highest_pow2_factor_for_target (to,
   offset));
+ if (misalignp)
+   {
+ mem = to_rtx;
+ to_rtx = saved_to_rtx;
+   }
}

   /* No action is needed if the target is not a memory and the field


volatile bitfield case to be audited as well:

  /* If the bitfield is volatile, we want to access it in the
 field's mode, not the computed mode.
 If a MEM has VOIDmode (external with incomplete type),
 use BLKmode for it instead.  */
  if (MEM_P (to_rtx))
{
  if (volatilep  flag_strict_volatile_bitfields  0)
to_rtx = adjust_address (to_rtx, mode1, 0);
  else if (GET_MODE (to_rtx) == VOIDmode)
to_rtx = adjust_address (to_rtx, BLKmode, 0);
}

checks the wrong RTX if it got the movmisalign path.  Or rather,
-fstrict-volatile bitfields doesn't seem to work properly for
misaligned accesses?

[Bug middle-end/57748] [4.8/4.9 Regression] ICE when expanding assignment to unaligned zero-sized array

2013-08-28 Thread bernd.edlinger at hotmail dot de 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748

--- Comment #20 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
(In reply to Richard Biener from comment #19)
 volatile bitfield case to be audited as well:
 
   /* If the bitfield is volatile, we want to access it in the
  field's mode, not the computed mode.
  If a MEM has VOIDmode (external with incomplete type),
  use BLKmode for it instead.  */
   if (MEM_P (to_rtx))
 {
   if (volatilep  flag_strict_volatile_bitfields  0)
 to_rtx = adjust_address (to_rtx, mode1, 0);
   else if (GET_MODE (to_rtx) == VOIDmode)
 to_rtx = adjust_address (to_rtx, BLKmode, 0);
 }
 
 checks the wrong RTX if it got the movmisalign path.  Or rather,
 -fstrict-volatile bitfields doesn't seem to work properly for
 misaligned accesses?

Definitely. -fstrict-volatile-bitfields does not work at all.
Especially not fo misaligned accesses, or packed structures.
That's what Sanda Loosemore's patch is trying to fix.
As I repeatedly told. Please have a look at it if you can.

If flag_struct_volatile_bitfilds  0 the
mode1 is diffent here than without.

[Bug middle-end/57748] [4.8/4.9 Regression] ICE when expanding assignment to unaligned zero-sized array

2013-08-06 Thread david.abdurachmanov at gmail dot com 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748

--- Comment #18 from David Abdurachmanov david.abdurachmanov at gmail dot com 
---
Tested the patch on top of final 4.8.1 Cortex-A9 NEON FPU. GCC no more ICE'ing
while compiling scipy.

[Bug middle-end/57748] [4.8/4.9 Regression] ICE when expanding assignment to unaligned zero-sized array

2013-08-03 Thread david.abdurachmanov at gmail dot com 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748

David Abdurachmanov david.abdurachmanov at gmail dot com changed:

   What|Removed |Added

 CC||david.abdurachmanov at gmail 
dot c
   ||om

--- Comment #17 from David Abdurachmanov david.abdurachmanov at gmail dot com 
---
Just for the record.

I hit the same bug on Cortex-A9 NEON GCC 4.8.1 hard floats, while compiling
scipy 0.8.0 RPM. There was not issue on 4.8.0 and pre-4.9.0 w/o NEON as FPU.

scipy/spatial/ckdtree.c: In function
'__pyx_f_5scipy_7spatial_7ckdtree_7cKDTree___query':
scipy/spatial/ckdtree.c:4194:66: internal compiler error: in expand_assignment,
at expr.c:4761
 (__pyx_v_inf2-side_distances[__pyx_v_inode-split_dim]) =
__pyx_f_5scipy_7spatial_7ckdtree_dabs((__pyx_v_inode-split -
(__pyx_v_x[__pyx_v_inode-split_dim])));
  ^
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
error: Command gcc -pthread -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv
-O3 -Wall -Wstrict-prototypes -fPIC
-I/build/davidlt/481-ext/a/fc18_armv7hl_gcc481/external/py2-numpy/1.6.1/lib/python2.7/site-packages/numpy/core/include
-I/build/davidlt/481-ext/a/fc18_armv7hl_gcc481/external/python/2.7.3/include/python2.7
-c scipy/spatial/ckdtree.c -o
build/temp.linux-armv7l-2.7/scipy/spatial/ckdtree.o failed with exit status 1

### GCC configuration ###

Target: armv7hl-redhat-linux-gnueabi
Configured with: ../configure
--prefix=/build/davidlt/481/b/tmp/BUILDROOT/4464b4bee054158584ab26d304d9b1a8/opt/cmssw/fc18_armv7hl_gcc481/external/gcc/4.8.1
--disable-multilib --disable-nls --with-zlib=no
--enable-languages=c,c++,fortran --enable-gold=yes --enable-ld=default
--enable-lto
--with-gmp=/build/davidlt/481/b/tmp/BUILDROOT/4464b4bee054158584ab26d304d9b1a8/opt/cmssw/fc18_armv7hl_gcc481/external/gcc/4.8.1
--with-mpfr=/build/davidlt/481/b/tmp/BUILDROOT/4464b4bee054158584ab26d304d9b1a8/opt/cmssw/fc18_armv7hl_gcc481/external/gcc/4.8.1
--with-mpc=/build/davidlt/481/b/tmp/BUILDROOT/4464b4bee054158584ab26d304d9b1a8/opt/cmssw/fc18_armv7hl_gcc481/external/gcc/4.8.1
--with-isl=/build/davidlt/481/b/tmp/BUILDROOT/4464b4bee054158584ab26d304d9b1a8/opt/cmssw/fc18_armv7hl_gcc481/external/gcc/4.8.1
--with-cloog=/build/davidlt/481/b/tmp/BUILDROOT/4464b4bee054158584ab26d304d9b1a8/opt/cmssw/fc18_armv7hl_gcc481/external/gcc/4.8.1
--enable-checking=release --build=armv7hl-redhat-linux-gnueabi
--host=armv7hl-redhat-linux-gnueabi --enable-libstdcxx-time=rt
--enable-bootstrap --enable-threads=posix --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--with-linker-hash-style=gnu --enable-plugin --enable-initfini-array
--enable-linker-build-id --disable-build-with-cxx
--disable-build-poststage1-with-cxx --with-cpu=cortex-a9 --with-tune=cortex-a9
--with-arch=armv7-a --with-float=hard --with-fpu=neon --with-abi=aapcs-linux
--disable-sjlj-exceptions --enable-shared CC='gcc -fPIC' CXX='c++ -fPIC'
CPP=cpp CXXCPP='c++ -E'
Thread model: posix

[Bug middle-end/57748] [4.8/4.9 Regression] ICE when expanding assignment to unaligned zero-sized array

2013-08-02 Thread bernd.edlinger at hotmail dot de 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748

--- Comment #14 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
Martin,

Your patch is of course OK, but the MALLOC_ABI_ALIGNMENT is probably wrong too.
At least in targets with neon processor it should be raised to 64 bits.

If the malloc would really return 4 byte aligned pointers, and you
pass such a pointer to an external function, that function may assume
naturally 8 byte aligned pointers and fault at runtime, right?

I've just re-read the relevant ARM ABI document AAPCS:
http://infocenter.arm.com/help/topic/com.arm.doc.ihi0042e/IHI0042E_aapcs.pdf

I have not found specific alignment requirements for malloc,
but they specify alignments of different basic types up to 8 byte.
Therefore I assume that the default value for MALLOC_ABI_ALIGNMENT is
generally too low for the ARM architecture.

The usual Doug Lee Malloc implementation has by design a lowest possible
alignment of 8 bytes.

What I mean is, maybe the defautlt for MALOC_ABI_ALIGNMENT
should changed to BIGGEST_ALIGNMENT. What do You think?

[Bug middle-end/57748] [4.8/4.9 Regression] ICE when expanding assignment to unaligned zero-sized array

2013-08-02 Thread jamborm at gcc dot gnu.org 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748

--- Comment #15 from Martin Jambor jamborm at gcc dot gnu.org ---
I have submitted the patch to the mailing list for review:

http://gcc.gnu.org/ml/gcc-patches/2013-08/msg00082.html


(In reply to Bernd Edlinger from comment #14)
 What I mean is, maybe the defautlt for MALOC_ABI_ALIGNMENT
 should changed to BIGGEST_ALIGNMENT. What do You think?

If ARM can trap accessing an 8 byte variable of a type that can be
defined without any fancy attributes, then unambiguously yes, malloc
has to return memory aligned to at least 8 bytes and
MALLOC_ABI_ALIGNMENT needs to be bumped to at least 64.

I am not sure whether BIGGEST_ALIGNMENT is the right value, e.g. on
x86_64 the value of MALLOC_ABI_ALIGNMENT is 64 whereas
BIGGEST_ALIGNMENT is 128.  Of course, on ARM the latter is also 64, so
at the moment it would not make a real difference.

Anyway, the policy of GCC seems to be that the default of
MALLOC_ABI_ALIGNMENT is ultra-safe and targets should override it.  So
I would suggest, again :-), that you open a separate bug and CC ARM
maintainers that should take care of it.

[Bug middle-end/57748] [4.8/4.9 Regression] ICE when expanding assignment to unaligned zero-sized array

2013-08-02 Thread bernd.edlinger at hotmail dot de 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748

--- Comment #16 from Bernd Edlinger bernd.edlinger at hotmail dot de ---
(In reply to Martin Jambor from comment #15)
 Anyway, the policy of GCC
 seems to be that the default of MALLOC_ABI_ALIGNMENT is ultra-safe and
 targets should override it.  So I would suggest, again :-), that you open a
 separate bug and CC ARM maintainers that should take care of it.

Done. Bug#58065

[Bug middle-end/57748] [4.8/4.9 Regression] ICE when expanding assignment to unaligned zero-sized array

2013-08-01 Thread jamborm at gcc dot gnu.org 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748

--- Comment #13 from Martin Jambor jamborm at gcc dot gnu.org ---
Created attachment 30583
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30583action=edit
Untested fix

This is how I'd like to fix the problem if the patch passes bootstrap
and testing (on x86_64-linux, any additional testing welcome).

I believe that the problem is that while compute_record_mode in
stor-layout.c makes sure it assigns BLK mode to structs with flexible
arrays, it has no such provisions for zero length arrays
(http://gcc.gnu.org/onlinedocs/gcc-4.8.1/gcc/Zero-Length.html).  I
think that in order to avoid problems and surprises like this one, we
should assign both variable array possibilities the same mode.