[Bug tree-optimization/53708] New: [4.8 Regression] Many failures of the objc tests with -O3 -fnext-runtime and -m32

[Bug tree-optimization/53708] New: [4.8 Regression] Many failures of the objc tests with -O3 -fnext-runtime and -m32

[dominiq at lps dot ens.fr]

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

             Bug #: 53708
           Summary: [4.8 Regression] Many failures of the objc tests with
                    -O3 -fnext-runtime and -m32
    Classification: Unclassified
           Product: gcc
           Version: 4.8.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: dominiq@lps.ens.fr
                CC: iains@gcc.gnu.org, rguenth@gcc.gnu.org
              Host: *-apple-darwin*
            Target: *-apple-darwin*
             Build: *-apple-darwin*


Between revisions 188187 (OK) and 188246 over one hundred tests failed with
-m32 and -O3 -fnext-runtime on *-apple-darwin*:

Running target unix/-m32
FAIL: objc/execute/exceptions/catchall-1.m compilation,  -O3
-fomit-frame-pointer -fnext-runtime
UNRESOLVED: objc/execute/exceptions/catchall-1.m execution,  -O3
-fomit-frame-pointer -fnext-runtime
FAIL: objc/execute/exceptions/catchall-1.m compilation,  -O3 -g -fnext-runtime
UNRESOLVED: objc/execute/exceptions/catchall-1.m execution,  -O3 -g
-fnext-runtime
FAIL: objc/execute/exceptions/finally-1.m compilation,  -O3
-fomit-frame-pointer -fnext-runtime
UNRESOLVED: objc/execute/exceptions/finally-1.m execution,  -O3
-fomit-frame-pointer -fnext-runtime
FAIL: objc/execute/exceptions/finally-1.m compilation,  -O3 -g -fnext-runtime
...
FAIL: objc.dg/torture/tls/thr-init-3.m  -O3 -fomit-frame-pointer 
-fnext-runtime (test for excess errors)
WARNING: objc.dg/torture/tls/thr-init-3.m  -O3 -fomit-frame-pointer 
-fnext-runtime compilation failed to produce executable
FAIL: objc.dg/torture/tls/thr-init-3.m  -O3 -g  -fnext-runtime (test for excess
errors)
WARNING: objc.dg/torture/tls/thr-init-3.m  -O3 -g  -fnext-runtime compilation
failed to produce executable

        === objc Summary for unix/-m32 ===

# of expected passes        5891
# of unexpected failures    104
# of expected failures        6
# of unresolved testcases    92
# of unsupported tests        85

On x86_64-apple-darwin10 I also see the following failures with -m64

Running target unix/-m64
FAIL: objc/execute/formal_protocol-4.m compilation,  -O3 -fomit-frame-pointer
-fnext-runtime
UNRESOLVED: objc/execute/formal_protocol-4.m execution,  -O3
-fomit-frame-pointer -fnext-runtime
FAIL: objc/execute/formal_protocol-4.m compilation,  -O3 -g -fnext-runtime
UNRESOLVED: objc/execute/formal_protocol-4.m execution,  -O3 -g -fnext-runtime
FAIL: objc/execute/protocol-isEqual-2.m execution,  -O3 -fomit-frame-pointer
-fnext-runtime
FAIL: objc/execute/protocol-isEqual-2.m execution,  -O3 -g -fnext-runtime

        === objc Summary for unix/-m64 ===

# of expected passes        6045
# of unexpected failures    4
# of expected failures        14
# of unresolved testcases    2
# of unsupported tests        91

while on powerpc-apple-darwin9 I only see the execution failures. The
compilation failures are all of the kind

ld: in /var/tmp//ccVsf9ME.o, S_LITERAL_POINTERS section __OBJC,__message_refs
missing relocs
collect2: error: ld returned 1 exit status

They disappear if I compile the tests with '-O3 -fno-tree-vectorize', but
reappear with '-O2 -ftree-vectorize'.

According to Iain Sandoe, this is due to revisions 188235/188243.

[Bug tree-optimization/53708] [4.8 Regression] Many failures of the objc tests with -O3 -fnext-runtime and -m32

[iains at gcc dot gnu.org]

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

Iain Sandoe <iains at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2012-06-17
     Ever Confirmed|0                           |1

--- Comment #1 from Iain Sandoe <iains at gcc dot gnu.org> 2012-06-17 14:12:35 UTC ---
it is because (some, if not all) the ObjC Meta-data alignment is being changed
from 2 to 4.  (presumably so that they become eligible for vector ops).

However, the size/organization of the meta-data are fixed by the runtime,
external to GCC - thus we cannot adjust in this manner.

I think (but have yet to check) that the ObjC FE explicitly sets the alignment
of the items.  Presumably, the ME should honor that?

If not, some suggestion about how to enforce what is needed would be helpful.

[Bug middle-end/53708] [4.8 Regression] Many failures of the objc tests with -O3 -fnext-runtime and -m32

[rguenth at gcc dot gnu.org]

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

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.8.0

--- Comment #2 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-06-18 08:51:33 UTC ---
I suppose vect_can_force_dr_alignment_p should be restricted more.  Can you
try

Index: gcc/tree-vect-data-refs.c
===================================================================
--- gcc/tree-vect-data-refs.c   (revision 188662)
+++ gcc/tree-vect-data-refs.c   (working copy)
@@ -4731,6 +4720,12 @@ vect_can_force_dr_alignment_p (const_tre
   if (TREE_ASM_WRITTEN (decl))
     return false;

+  /* Do not override explicit alignment set by the user or the alignment
+     as specified by the ABI when the used attribute is set.  */
+  if (DECL_USER_ALIGN (decl)
+      || DECL_PRESERVE_P (decl))
+    return false;
+
   if (TREE_STATIC (decl))
     return (alignment <= MAX_OFILE_ALIGNMENT);
   else

ok if it passes bootstrap & regtesting for you.

[Bug middle-end/53708] [4.8 Regression] Many failures of the objc tests with -O3 -fnext-runtime and -m32

[dominiq at lps dot ens.fr]

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

--- Comment #3 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2012-06-18 09:59:55 UTC ---
> ok if it passes bootstrap & regtesting for you.

Clean bootstrap&regtesting scheduled for tonight. Meanwhile with a simple
update of revision 188723 and objc testing only, the patch in comment #2 fixes
the failures:

        === objc Summary for unix/-m64 ===

# of expected passes        6051
# of expected failures        14
# of unsupported tests        91

        === objc Summary ===

# of expected passes        12150
# of expected failures        20
# of unsupported tests        176

Thanks for the quick fix.

[Bug middle-end/53708] [4.8 Regression] Many failures of the objc tests with -O3 -fnext-runtime and -m32

[dominiq at lps dot ens.fr]

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

--- Comment #4 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2012-06-18 12:42:12 UTC ---
A clean bootstrap of revision 188725 with the patch in comment #2 just finished
without any problem. In addition the patch fixed the following failures in the
tests of obj-c++

Running target unix/-m32
...
FAIL: obj-c++.dg/torture/trivial.mm  -O3 -fomit-frame-pointer  -fnext-runtime
(test for excess errors)
WARNING: obj-c++.dg/torture/trivial.mm  -O3 -fomit-frame-pointer 
-fnext-runtime compilation failed to produce executable
FAIL: obj-c++.dg/torture/trivial.mm  -O3 -g  -fnext-runtime (test for excess
errors)
WARNING: obj-c++.dg/torture/trivial.mm  -O3 -g  -fnext-runtime compilation
failed to produce executable
FAIL: obj-c++.dg/torture/strings/const-str-7.mm  -O3 -fomit-frame-pointer 
-fnext-runtime (test for excess errors)
WARNING: obj-c++.dg/torture/strings/const-str-7.mm  -O3 -fomit-frame-pointer 
-fnext-runtime compilation failed to produce executable
FAIL: obj-c++.dg/torture/strings/const-str-7.mm  -O3 -g  -fnext-runtime (test
for excess errors)
WARNING: obj-c++.dg/torture/strings/const-str-7.mm  -O3 -g  -fnext-runtime
compilation failed to produce executable
FAIL: obj-c++.dg/torture/strings/const-str-8.mm  -O3 -fomit-frame-pointer 
-fnext-runtime (test for excess errors)
WARNING: obj-c++.dg/torture/strings/const-str-8.mm  -O3 -fomit-frame-pointer 
-fnext-runtime compilation failed to produce executable
FAIL: obj-c++.dg/torture/strings/const-str-8.mm  -O3 -g  -fnext-runtime (test
for excess errors)
WARNING: obj-c++.dg/torture/strings/const-str-8.mm  -O3 -g  -fnext-runtime
compilation failed to produce executable
FAIL: obj-c++.dg/torture/tls/thr-init-3.mm  -O3 -fomit-frame-pointer 
-fnext-runtime (test for excess errors)
WARNING: obj-c++.dg/torture/tls/thr-init-3.mm  -O3 -fomit-frame-pointer 
-fnext-runtime compilation failed to produce executable
FAIL: obj-c++.dg/torture/tls/thr-init-3.mm  -O3 -g  -fnext-runtime (test for
excess errors)
WARNING: obj-c++.dg/torture/tls/thr-init-3.mm  -O3 -g  -fnext-runtime
compilation failed to produce executable

[Bug middle-end/53708] [4.8 Regression] Many failures of the objc tests with -O3 -fnext-runtime and -m32

[iains at gcc dot gnu.org]

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

--- Comment #5 from Iain Sandoe <iains at gcc dot gnu.org> 2012-06-18 20:11:01 UTC ---
Thanks,
works for me, i686-darwin9 all langs bootstrap & check, fixes the ObjC fails.

[Bug middle-end/53708] [4.8 Regression] Many failures of the objc tests with -O3 -fnext-runtime and -m32

[dominiq at lps dot ens.fr]

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

--- Comment #6 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2012-06-19 08:46:49 UTC ---
Works for me too on x86_64-apple-darwin10 and powerpc-apple-darwin9.

[Bug middle-end/53708] [4.8 Regression] Many failures of the objc tests with -O3 -fnext-runtime and -m32

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-06-19 09:19:17 UTC ---
Author: rguenth
Date: Tue Jun 19 09:19:07 2012
New Revision: 188771

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188771
Log:
2012-06-19  Richard Guenther  <rguenther@suse.de>

    PR tree-optimization/53708
    * tree-vect-data-refs.c (vect_can_force_dr_alignment_p): Preserve
    user-supplied alignment and alignment of decls with the used
    attribute.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/tree-vect-data-refs.c

[Bug middle-end/53708] [4.8 Regression] Many failures of the objc tests with -O3 -fnext-runtime and -m32

[rguenth at gcc dot gnu.org]

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

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #8 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-06-19 09:20:49 UTC ---
Fixed.

[Bug middle-end/53708] [4.8 Regression] Many failures of the objc tests with -O3 -fnext-runtime and -m32

[bergner at gcc dot gnu.org]

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

Peter Bergner <bergner at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
                 CC|                            |bergner at gcc dot gnu.org
         Resolution|FIXED                       |

--- Comment #9 from Peter Bergner <bergner at gcc dot gnu.org> 2012-10-30 15:47:57 UTC ---
Richard, I'm seeing this same bug in GCC 4.7 on powerpc64-linux when compiling
GLIBC.  Is there a chance we can get your patch backported to 4.7?  I
bootstrapped and regtested the backport with no regressions and can confirm it
fixes the bug I'm running into, which can be seen with the reduced test case
from glibc:

bergner@bns:~/gcc/BUGS> cat foo.i 
static void (*const init_array []) (void)
  __attribute__ ((section (".init_array"), aligned (sizeof (void *)), used))
= { 0 };

bergner@bns:~/gcc/BUGS> /home/bergner/gcc/build/gcc-fsf-4_7-base/gcc/xgcc
-B/home/bergner/gcc/build/gcc-fsf-4_7-base/gcc -S -m64 -O3 -maltivec foo.i -o
bad.s

bergner@bns:~/gcc/BUGS> /home/bergner/gcc/build/gcc-fsf-4_7-pr53708/gcc/xgcc
-B/home/bergner/gcc/build/gcc-fsf-4_7-pr53708/gcc -S -m64 -O3 -maltivec foo.i
-o good.s

bergner@bns:~/gcc/BUGS> diff -u bad.s good.s 
--- bad.s    2012-10-30 10:41:15.000000000 -0500
+++ good.s    2012-10-30 10:41:23.000000000 -0500
@@ -2,7 +2,7 @@
     .section    ".toc","aw"
     .section    ".text"
     .section    .init_array,"a"
-    .align 4
+    .align 3
     .type    init_array, @object
     .size    init_array, 8
 init_array:

The above is bad, because the extra alignment causes the linker to add some
null padding to the init_array and the loader isn't expecting that and ends up
segv'ing.

[Bug middle-end/53708] [4.8 Regression] Many failures of the objc tests with -O3 -fnext-runtime and -m32

[rguenther at suse dot de]

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

--- Comment #10 from rguenther at suse dot de <rguenther at suse dot de> 2012-10-30 17:10:52 UTC ---
On Tue, 30 Oct 2012, bergner at gcc dot gnu.org wrote:

> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53708
> 
> Peter Bergner <bergner at gcc dot gnu.org> changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>              Status|RESOLVED                    |REOPENED
>                  CC|                            |bergner at gcc dot gnu.org
>          Resolution|FIXED                       |
> 
> --- Comment #9 from Peter Bergner <bergner at gcc dot gnu.org> 2012-10-30 15:47:57 UTC ---
> Richard, I'm seeing this same bug in GCC 4.7 on powerpc64-linux when compiling
> GLIBC.  Is there a chance we can get your patch backported to 4.7?  I
> bootstrapped and regtested the backport with no regressions and can confirm it
> fixes the bug I'm running into, which can be seen with the reduced test case
> from glibc:
> 
> bergner@bns:~/gcc/BUGS> cat foo.i 
> static void (*const init_array []) (void)
>   __attribute__ ((section (".init_array"), aligned (sizeof (void *)), used))
> = { 0 };
> 
> bergner@bns:~/gcc/BUGS> /home/bergner/gcc/build/gcc-fsf-4_7-base/gcc/xgcc
> -B/home/bergner/gcc/build/gcc-fsf-4_7-base/gcc -S -m64 -O3 -maltivec foo.i -o
> bad.s
> 
> bergner@bns:~/gcc/BUGS> /home/bergner/gcc/build/gcc-fsf-4_7-pr53708/gcc/xgcc
> -B/home/bergner/gcc/build/gcc-fsf-4_7-pr53708/gcc -S -m64 -O3 -maltivec foo.i
> -o good.s
> 
> bergner@bns:~/gcc/BUGS> diff -u bad.s good.s 
> --- bad.s    2012-10-30 10:41:15.000000000 -0500
> +++ good.s    2012-10-30 10:41:23.000000000 -0500
> @@ -2,7 +2,7 @@
>      .section    ".toc","aw"
>      .section    ".text"
>      .section    .init_array,"a"
> -    .align 4
> +    .align 3
>      .type    init_array, @object
>      .size    init_array, 8
>  init_array:
> 
> The above is bad, because the extra alignment causes the linker to add some
> null padding to the init_array and the loader isn't expecting that and ends up
> segv'ing.

Certainly - but can you check there wasn't a followup for fallout?
ISTR something here ...

[Bug middle-end/53708] [4.8 Regression] Many failures of the objc tests with -O3 -fnext-runtime and -m32

[bergner at gcc dot gnu.org]

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

--- Comment #11 from Peter Bergner <bergner at gcc dot gnu.org> 2012-10-30 18:27:36 UTC ---
Do you mean Richard Sandiford's comment regarding your patch and then your
reply?

  http://gcc.gnu.org/ml/gcc-patches/2012-06/msg01229.html

Hmmm, if attribute((__aligned__)) really only sets the minimum alignment value
and we're free to increase it arbitrarily, then maybe it's GLIBC's fault for
not being able to handle null values due to padding while processing the
init_array?

[Bug middle-end/53708] [4.8 Regression] Many failures of the objc tests with -O3 -fnext-runtime and -m32

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #12 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-10-30 18:38:14 UTC ---
I'm not sure if DECL_USER_ALIGN || DECL_P is the right test for this, I'd say
instead
  if (DECL_SECTION_NAME (decl) != NULL_TREE
      && !DECL_HAS_IMPLICIT_SECTION_NAME_P (decl))
is what is the problem here, this is what I'm using in asan.c to find out
whether it is ok to increase alignment and/or add padding after the decl.
It is a common way of filling arrays to just put variables into user defined
sections, and expect the whole section to contain an array of those decls.  Any
alignment increases there or additional paddings of course break that
assumption.

[Bug middle-end/53708] [4.8 Regression] Many failures of the objc tests with -O3 -fnext-runtime and -m32

[law at redhat dot com]

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

Jeffrey A. Law <law at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |law at redhat dot com

--- Comment #13 from Jeffrey A. Law <law at redhat dot com> 2012-10-31 15:33:16 UTC ---
Just a note -- backporting the final fix to 4.7 should be considered a high
priority item.  If I'm reading everything correctly, we can't build a working
PPC glibc right now with the desired optimizations using a GCC 4.7 compiler.

[Bug middle-end/53708] [4.8 Regression] Many failures of the objc tests with -O3 -fnext-runtime and -m32

[bergner at gcc dot gnu.org]

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

--- Comment #14 from Peter Bergner <bergner at gcc dot gnu.org> 2012-11-01 02:48:10 UTC ---
Author: bergner
Date: Thu Nov  1 02:48:07 2012
New Revision: 193058

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193058
Log:
2012-10-31  Jakub Jelinek  <jakub@redhat.com>

    PR tree-optimization/53708
    * tree-vect-data-refs.c (vect_can_force_dr_alignment_p): Preserve
    user-supplied alignment when used with an explicit section name.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/tree-vect-data-refs.c

[Bug middle-end/53708] [4.8 Regression] Many failures of the objc tests with -O3 -fnext-runtime and -m32

[bergner at gcc dot gnu.org]

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

--- Comment #15 from Peter Bergner <bergner at gcc dot gnu.org> 2012-11-03 14:02:20 UTC ---
Author: bergner
Date: Sat Nov  3 14:02:13 2012
New Revision: 193121

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193121
Log:
    Backport from mainline
    2012-10-31  Jakub Jelinek  <jakub@redhat.com>

    PR tree-optimization/53708
    * tree-vect-data-refs.c (vect_can_force_dr_alignment_p): Preserve
    user-supplied alignment when used with an explicit section name.

Modified:
    branches/gcc-4_7-branch/gcc/ChangeLog
    branches/gcc-4_7-branch/gcc/tree-vect-data-refs.c

[Bug middle-end/53708] [4.8 Regression] Many failures of the objc tests with -O3 -fnext-runtime and -m32

[bergner at gcc dot gnu.org]

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

Peter Bergner <bergner at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|                            |FIXED

--- Comment #16 from Peter Bergner <bergner at gcc dot gnu.org> 2012-11-03 14:05:59 UTC ---
Backported to 4.7.