Re: GCC 7.0.1 Status Report (2017-04-20)

[Andreas Krebbel]

On 04/20/2017 12:02 PM, Jakub Jelinek wrote:
> Status
> ==
> 
> We have reached zero P1 regressions today (and < 100 important
> regressions) and the branches/gcc-7-branch has been created;
> GCC 7.1-rc1 will be built and announced likely tomorrow.
> The branch is now frozen for blocking regressions and documentation
> fixes only, all changes to the branch require a RM approval now.

I would like to apply the following patches to GCC 7 release branch before the 
7.1 release:

It took us a few more review cycles than expected.  The patches are important 
to get reasonable code
for the C11 atomics now being used in Glibc:

S/390: Optimize atomic_compare_exchange and atomic_compare builtins.
https://gcc.gnu.org/ml/gcc-patches/2017-04/msg00524.html

These fixes for two GCC 7 regressions:

S/390: PR80464: Split MEM->GPR vector moves
https://gcc.gnu.org/ml/gcc-patches/2017-04/msg01050.html

S/390: PR79895: Fix TImode constant handling
https://gcc.gnu.org/ml/gcc-patches/2017-04/msg01049.html

Any objections?

-Andreas-

Alias analysis and zero-sized arrays vs. flexible arrays

[Steve Ellcey]

I was wondering if someone could help me understand a bug involving
aliasing, this is happening on aarch64 but I don't think it is architecure
specific.  The problem involves flexible arrays vs. zero sized arrays at
the end of a structure.

In the original code, a zero size array is used and the program does not
behave correctly, if the zero sized array is changed to a C99 flexible
array it does work.  Are there any reasons why a zero-size array and
a flexible array should behave differently?

I was able to cut the test case down into the attached (non-runnable) test
case which when compiled with -O2 for aarch64 generates different code
with -DFLEX and -UFLEX.  In the code for the main loop GCC generates a
ldr/str/ldr/str sequence (with other instructions) when using a flexible
array and a ldr/ldr/str/str sequence when using a zero size array.  Moving
the second ldr ahead of the first str is what is causing the problem in the
original test case.

I have tracked the change in behaviour to differences in alias analysis
and to the get_ref_base_and_extent routine in tree-dfa.c and it looks
like the 'tree exp' argument is different between the two versions but
I am not sure if it should be different and, if the difference is OK,
should that affect how get_ref_base_and_extent behaves, as it apparently
does.

Steve Ellcey
sell...@cavium.com



Test case, compiling with '-O2 -DFLEX' generates different code than
'-O2 -UFLEX' on aarch64 using ToT GCC.  A cross compiler built on x86
can reproduce the problem too.

---


struct q {
int b;
};
struct r {
   int n;
   struct q slot[0];
};
struct s {
   int n;
#ifdef FLEX
 long int o[];
#else
 long int o[0];
#endif
};
extern int x, y, m;
extern struct s *a;
extern struct r *b;
extern void bar();
int foo() {
   int i,j;
   for (i = 0; i < m; i++) {
a->o[i] = sizeof(*a);
b = ((struct r *)(((char *)a) + a->o[a->n]));
for (j = 0; j < 10; j++) {
b->slot[j].b = 0;
}
bar();
  }
}