[Bug target/65342] New: [5 Regression] FAIL: gfortran.dg/intrinsic_(un)?pack_1.f90 -O1 execution test on powerpc-apple-darwin9 after r210201

[Bug target/65342] New: [5 Regression] FAIL: gfortran.dg/intrinsic_(un)?pack_1.f90 -O1 execution test on powerpc-apple-darwin9 after r210201

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65342

            Bug ID: 65342
           Summary: [5 Regression] FAIL:
                    gfortran.dg/intrinsic_(un)?pack_1.f90   -O1  execution
                    test on powerpc-apple-darwin9 after r210201
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: dominiq at lps dot ens.fr
                CC: amodra at gcc dot gnu.org, iains at gcc dot gnu.org
              Host: powerpc-apple-darwin9
            Target: powerpc-apple-darwin9
             Build: powerpc-apple-darwin9

On powerpc-apple-darwin9 I see the following failures with -m64 after r210201

FAIL: gfortran.dg/intrinsic_pack_1.f90   -O1  execution test
FAIL: gfortran.dg/intrinsic_pack_1.f90   -O2  execution test
FAIL: gfortran.dg/intrinsic_unpack_1.f90   -O1  execution test
FAIL: gfortran.dg/intrinsic_unpack_1.f90   -O2  execution test
FAIL: gfortran.dg/intrinsic_unpack_1.f90   -O3 -fomit-frame-pointer  execution
test
FAIL: gfortran.dg/intrinsic_unpack_1.f90   -O3 -fomit-frame-pointer
-funroll-loops  execution test
FAIL: gfortran.dg/intrinsic_unpack_1.f90   -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions  execution test
FAIL: gfortran.dg/intrinsic_unpack_1.f90   -O3 -g  execution test

The failures occur only in the following reduced codes

program intrinsic_unpack
   implicit none
   integer(kind=2), dimension(3, 3) :: a2, b2

   logical, dimension(3, 3) :: mask
   character(len=500) line1, line2
   integer i

   mask = reshape ((/.false.,.true.,.false.,.true.,.false.,.false.,&
                    &.false.,.false.,.true./), (/3, 3/));
   a2 = reshape ((/1, 0, 0, 0, 1, 0, 0, 0, 1/), (/3, 3/));
   b2 = unpack ((/2_2, 3_2, 4_2/), mask, a2)
   print *, b2
   if (any (b2 .ne. reshape ((/1, 2, 0, 3, 1, 0, 0, 0, 4/), (/3, 3/)))) &
      call abort

end program

program main
  implicit none
  integer :: i
  integer(kind=2), dimension(3,3) :: i2
  integer(kind=2), dimension(9) :: vi2
  integer(kind=2), dimension(9) :: ri2

  vi2 = (/(i+10,i=1,9)/)
  i2 = reshape((/1_2, -1_2, 2_2, -2_2, 3_2, -3_2, 4_2, -4_2, 5_2/), shape(i2))
  ri2 = pack(i2,i2>0,vi2)
  if (any(ri2 /= (/1_2, 2_2, 3_2, 4_2, 5_2, 16_2, 17_2, 18_2, 19_2/))) &
       & call abort

end program main

all the other checks in the original tests succeed.

The difference between the assembly generated by r210200 (-) and r210201 (+) is

--- intrinsic_unpack_1_red.s    2015-03-07 10:11:12.000000000 +0100
+++ intrinsic_unpack_1_red_b.s    2015-03-07 10:10:46.000000000 +0100
@@ -26,18 +26,14 @@ L1$pb:
     std r10,172(r1)
     lwz r2,32(r2)
     stw r2,180(r1)
-    addis r9,r31,ha16(_A.1.1600-L1$pb)
-    la r2,lo16(_A.1.1600-L1$pb)(r9)
-    lwz r7,lo16(_A.1.1600-L1$pb)(r9)
-    lwz r8,4(r2)
-    lwz r10,8(r2)
-    lwz r9,12(r2)
-    stw r7,112(r1)
-    stw r8,116(r1)
-    stw r10,120(r1)
-    stw r9,124(r1)
-    lhz r2,16(r2)
-    sth r2,128(r1)
+    addis r2,r31,ha16(_A.1.1600-L1$pb)
+    la r9,lo16(_A.1.1600-L1$pb)(r2)
+    ld r2,lo16(_A.1.1600-L1$pb)(r2)
+    ld r10,8(r9)
+    lhz r9,16(r9)
+    std r2,112(r1)
+    std r10,120(r1)
+    sth r9,128(r1)
     li r25,138
     std r25,752(r1)
     li r30,1

[Bug target/65342] [5 Regression] FAIL: gfortran.dg/intrinsic_(un)?pack_1.f90 -O1 execution test on powerpc-apple-darwin9 after r210201

[amodra at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65342

Alan Modra <amodra at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2015-03-07
                 CC|                            |amodra at gmail dot com
     Ever confirmed|0                           |1

--- Comment #1 from Alan Modra <amodra at gmail dot com> ---
Confirmed.  The problem occurs in fwprop1 where instructions corresponding to
the following assembly
    addis r2,r31,ha16(_A.1.1600-L1$pb)
    la r9,lo16(_A.1.1600-L1$pb)(r2)
    ld r2,0(r9)
are combined to
    addis r2,r31,ha16(_A.1.1600-L1$pb)
    la r9,lo16(_A.1.1600-L1$pb)(r2)
    ld r2,lo16(_A.1.1600-L1$pb)(r2)
ie. the offset is propagated into the memory load.  This ought to give you an
error at assembly or link time.  If not, you have a bad assembler or linker..

movdi_low is the culprit, I think.  It should require a suitably aligned offset
(operand 2).

[Bug target/65342] [5 Regression] FAIL: gfortran.dg/intrinsic_(un)?pack_1.f90 -O1 execution test on powerpc-apple-darwin9 after r210201

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65342

--- Comment #2 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> Confirmed.  The problem occurs in fwprop1 where instructions corresponding to the
> following assembly
>	addis r2,r31,ha16(_A.1.1600-L1$pb)
>	la r9,lo16(_A.1.1600-L1$pb)(r2)
>	ld r2,0(r9)
> are combined to
>	addis r2,r31,ha16(_A.1.1600-L1$pb)
>	la r9,lo16(_A.1.1600-L1$pb)(r2)
>	ld r2,lo16(_A.1.1600-L1$pb)(r2)
> ie. the offset is propagated into the memory load.  This ought to give you
> an error at assembly or link time.

No error at assembly or link time.

> If not, you have a bad assembler or linker..

Well, we'll have to live with them!-(EOL target).

> movdi_low is the culprit, I think.  It should require a suitably aligned
> offset (operand 2).

How?
>From gcc-bugs-return-479647-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Mar 07 14:46:06 2015
Return-Path: <gcc-bugs-return-479647-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 35719 invoked by alias); 7 Mar 2015 14:46:06 -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
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 35677 invoked by uid 48); 7 Mar 2015 14:46:02 -0000
From: "redi at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libstdc++/65343] unexpected exception thrown during destruction of static object in debug mode
Date: Sat, 07 Mar 2015 14:46:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: libstdc++
X-Bugzilla-Version: 4.9.1
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: redi at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-65343-4-m6JUryoRLQ@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-65343-4@http.gcc.gnu.org/bugzilla/>
References: <bug-65343-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: 2015-03/txt/msg00791.txt.bz2
Content-length: 398

https://gcc.gnu.org/bugzilla/show_bug.cgi?ide343

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Maybe we want to placement-new the mutexes into a buffer so they are never
destroyed, although on mingw that will show up as leaked resources at program
shutdown (and this is only really a problem on mingw as we don't need to run
any destructor on the mutexes for most targets).

[Bug target/65342] [5 Regression] FAIL: gfortran.dg/intrinsic_(un)?pack_1.f90 -O1 execution test on powerpc-apple-darwin9 after r210201

[iains at gcc dot gnu.org]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 9038 bytes --]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65342

--- Comment #3 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Dominique d'Humieres from comment #2)
> > Confirmed.  The problem occurs in fwprop1 where instructions corresponding to the
> > following assembly
> >	addis r2,r31,ha16(_A.1.1600-L1$pb)
> >	la r9,lo16(_A.1.1600-L1$pb)(r2)
> >	ld r2,0(r9)
> > are combined to
> >	addis r2,r31,ha16(_A.1.1600-L1$pb)
> >	la r9,lo16(_A.1.1600-L1$pb)(r2)
> >	ld r2,lo16(_A.1.1600-L1$pb)(r2)
> > ie. the offset is propagated into the memory load.  This ought to give you
> > an error at assembly or link time.
> 
> No error at assembly or link time.

> > If not, you have a bad assembler or linker..
> 
> Well, we'll have to live with them!-(EOL target).

The system as is based on gas-1.38 and doesn't warn for this :-(
ld64 is slightly better and does catch a few more cases (where they resolve at
link-time).

.. there's some hope for my WIP GAS port and an updated ld64 (yeah, I know it's
taking a long time for these to appear) ..

> > movdi_low is the culprit, I think.  It should require a suitably aligned
> > offset (operand 2).
> 
> How?

In the mdynamic-no-pic case, the literal value should work the same as for
linux.

In the case of PIC, I suspect we need to look through the uspecs that wrap
mach-o PIC offsets and try to determine if the alignment of the referenced
symbol is guaranteed to be "enough".  The alignment of the picbase will always
be >= 4.

Some time ago I had a WIP patch to try and deal with this … but it's bit-rotted
so needs a significant re-visit.
>From gcc-bugs-return-479655-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Mar 07 17:16:19 2015
Return-Path: <gcc-bugs-return-479655-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 68161 invoked by alias); 7 Mar 2015 17:16:18 -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
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 68148 invoked by uid 48); 7 Mar 2015 17:16:14 -0000
From: "jezz at hkfree dot org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/65344] New: Exception is not catched on AIX - class with more ancestors, virtual method throws
Date: Sat, 07 Mar 2015 17:16:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 4.8.3
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jezz at hkfree dot org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter attachments.created
Message-ID: <bug-65344-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: 2015-03/txt/msg00799.txt.bz2
Content-length: 5401

https://gcc.gnu.org/bugzilla/show_bug.cgi?ide344

            Bug ID: 65344
           Summary: Exception is not catched on AIX - class with more
                    ancestors, virtual method throws
           Product: gcc
           Version: 4.8.3
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jezz at hkfree dot org

Created attachment 34983
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id4983&actioníit
Sources for reproducing

In my program exception is not catched, when it is compiled with gcc newer than
4.4 (4.2.4 & 4.4.7 works). I have created sample (sample with Makefile in in
attachment). I have tested the sample with 4.5.4 and 4.8.3 - both fails. All
compilers are from http://www.perzl.org/aix/index.php?n=Main.Gcc

This is output from sample compiled with 4.4.7:

./main
Case 1:

Case 2:
(Class*)ThrowingClass=0x0x200013b8
(DoThrowIface*)this=0x0x200013bc
(DoThrowIface*)ThrowingClass=0x0x200013bc
Called doThrow.
Thrown && catched BaseException.
End.

This is output from sample compiled with 4.8.3:
 ./main
Case 1:

Case 2:
(Class*)ThrowingClass=0x0x20001ab8
(DoThrowIface*)this=0x0x20001abc
(DoThrowIface*)ThrowingClass=0x0x20001abc
Called doThrow.
terminate called after throwing an instance of 'Exception'

(gdb) where
#0  0xd37bd440 in raise () from /usr/lib/libc.a(shr.o)
#1  0xd384bca8 in abort () from /usr/lib/libc.a(shr.o)
#2  0xd8055610 in __gnu_cxx::__verbose_terminate_handler () at  _start_ :95
#3  0xd80609ec in __cxxabiv1::__terminate (handler=<incomplete type>)
    at  _start_ :38
#4  0xd8055404 in std::terminate () at  _start_ :48
#5  0xd8060d7c in __cxa_throw (obj=<incomplete type>,
    tinfo=<incomplete type>, dest=<incomplete type>) at  _start_ :87
#6  0x10001604 in ThrowingClass::doThrow (this=0x20001ab8)
    at throwing_class.cc:24
#7  0x100006a8 in main (argc=1, argv=0x2ff22af4) at main.cc:39

g++ -v:
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/opt/freeware/libexec/gcc/powerpc-ibm-aix6.1.0.0/4.8.3/lto-wrapper
Target: powerpc-ibm-aix6.1.0.0
Configured with: ../gcc-4.8.3/configure --with-as=/usr/bin/as
--with-ld=/usr/bin/ld --enable-languages=c,c++,fortran --prefix=/opt/freeware
--mandir=/opt/freeware/man --infodir=/opt/freeware/info
--enable-version-specific-runtime-libs --disable-nls --enable-decimal-float=dpd
--host=powerpc-ibm-aix6.1.0.0
Thread model: aix
gcc version 4.8.3 (GCC)


Sample sources:

base.hh:
#ifndef BASE_HH
#define BASE_HH 1

class Exception
   {
   public:
      Exception() {}
   };

class Iface
   {
   public:
      virtual ~Iface() {}
   };

class Class
   {
   public:
      virtual ~Class() {}
      virtual Iface *getIface() = 0;
   };

class DoThrowIface
   : public Iface
   {
   public:
      virtual void doThrow() = 0;
   };

class Registrator
   {
   public:
      virtual Class* getClass() = 0;
   };

#endif /* BASE_HH */

throwing_class.hh:
#ifndef THROWING_CLASS_HH
#define THROWING_CLASS_HH 1

class ThrowingClass
   : public Class
   , public DoThrowIface
   {
   public:
      virtual void doThrow();
      virtual Iface *getIface();
   };

#endif /* THROWING_CLASS_HH */

throwing_class.cc:
#include <iostream>
#include "base.hh"
#include "throwing_class.hh"

extern Registrator *reg;

// This class must be in separate object file
class ThrowingClassRegistrator : public Registrator
   {
   public:
      ThrowingClassRegistrator()
         {
         reg = this;
         }
      virtual Class *getClass()
         {
         return new ThrowingClass();
         }
   } ThrowingClassRegistrator_I;

void ThrowingClass::doThrow()
   {
   std::cout << "Called doThrow." << std::endl;
   throw Exception();
   }

Iface *ThrowingClass::getIface()
   {
   std::cout << "(DoThrowIface*)this=0x" << (DoThrowIface*)this << std::endl;
   return static_cast<DoThrowIface*>(this);
   }


main.cc:
#include <iostream>
#include <exception>
#include "base.hh"
#include "throwing_class.hh"

Registrator *reg;

int
main(int argc, char *argv[])
   {
   std::cout << "Case 1:" << std::endl;
   try
      {
      // This always works, but if I uncomment this, case 2 is also working.
      /*
      Class *throwingClass = new ThrowingClass();
      std::cout << "(Class*)ThrowingClass=0x" << throwingClass << std::endl;
      DoThrowIface *throwIface = (DoThrowIface *)throwingClass->getIface();
      std::cout << "(DoThrowIface*)ThrowingClass=0x" << throwIface <<
std::endl;
      throwIface->doThrow();
      //*/
      }
   catch (Exception const& e)
      {
      std::cout << "Thrown && catched BaseException." << std::endl;
      }
   catch (...)
      {
      std::cout << "General catch." << std::endl;
      }

   std::cout << std::endl << "Case 2:" << std::endl;
   try
      {
      Class *throwingClass = reg->getClass();
      std::cout << "(Class*)ThrowingClass=0x" << throwingClass << std::endl;
      DoThrowIface *throwIface = (DoThrowIface *)throwingClass->getIface();
      std::cout << "(DoThrowIface*)ThrowingClass=0x" << throwIface <<
std::endl;
      throwIface->doThrow();
      }
   catch (Exception const& e)
      {
      std::cout << "Thrown && catched BaseException." << std::endl;
      }
   catch (...)
      {
      std::cout << "General catch." << std::endl;
      }
   std::cout << "End." << std::endl;
   return 0;
   }

[Bug target/65342] [5 Regression] FAIL: gfortran.dg/intrinsic_(un)?pack_1.f90 -O1 execution test on powerpc-apple-darwin9 after r210201

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65342

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |5.0

[Bug target/65342] [5 Regression] FAIL: gfortran.dg/intrinsic_(un)?pack_1.f90 -O1 execution test on powerpc-apple-darwin9 after r210201

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65342

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

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

[Bug target/65342] [5 Regression] FAIL: gfortran.dg/intrinsic_(un)?pack_1.f90 -O1 execution test on powerpc-apple-darwin9 after r210201

[amodra at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65342

Alan Modra <amodra at gmail dot com> changed:

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

--- Comment #4 from Alan Modra <amodra at gmail dot com> ---
Here's another failing powerpc-darwin testcase due to movdi_low (movdf_low_di
and their store counterparts have the same problem of course).

/* -m64 -O1 -S -fno-pic  */
struct {
  char c;
  long l;
} __attribute__ ((__packed__)) x;

long get_x (void)
{
  return x.l;
}

[Bug target/65342] [5 Regression] FAIL: gfortran.dg/intrinsic_(un)?pack_1.f90 -O1 execution test on powerpc-apple-darwin9 after r210201

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65342

--- Comment #5 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Alan Modra from comment #4)
> Here's another failing powerpc-darwin testcase due to movdi_low
> (movdf_low_di and their store counterparts have the same problem of course).
> 
> /* -m64 -O1 -S -fno-pic  */

for Darwin, -mdynamic-no-pic ^ would be a real-life User case.

> struct {
>   char c;
>   long l;
> } __attribute__ ((__packed__)) x;
> 
> long get_x (void)
> {
>   return x.l;
> }

Thanks, Alan.
I took a quick look over the weekend (out of the office last week).

So, do you think I need to split things up so that the d-mode and ds-mode insn
fragments can have different match conditions? - or is the issue that these
patterns have no reload constraints (in which case I could at least investigate
adding Y to the relevant cases)?

[Bug target/65342] [5 Regression] FAIL: gfortran.dg/intrinsic_(un)?pack_1.f90 -O1 execution test on powerpc-apple-darwin9 after r210201

[amodra at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65342

--- Comment #6 from Alan Modra <amodra at gmail dot com> ---
Created attachment 35001
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35001&action=edit
workaround

You might like to consider this patch that effectively reverts r210201 for
Darwin.  This should cure the regression.

[Bug target/65342] [5 Regression] FAIL: gfortran.dg/intrinsic_(un)?pack_1.f90 -O1 execution test on powerpc-apple-darwin9 after r210201

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65342

--- Comment #7 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Alan Modra from comment #6)
> Created attachment 35001 [details]
> workaround
> 
> You might like to consider this patch that effectively reverts r210201 for
> Darwin.  This should cure the regression.

Yeah. I did something similar as a fall-back .. but (unless we run out of time)
I'd rather fix the underlying problem - since it occurs in other places too.

[if we do run out of time, then I'm fine with applying the fallback].

[Bug target/65342] [5 Regression] FAIL: gfortran.dg/intrinsic_(un)?pack_1.f90 -O1 execution test on powerpc-apple-darwin9 after r210201

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65342

--- Comment #8 from Iain Sandoe <iains at gcc dot gnu.org> ---
BTW, is:

(define_insn "movdi_low_st"
  [(set (mem:DI (lo_sum:DI (match_operand:DI 1 "gpc_reg_operand" "b,b,b")
                           (match_operand 2 "" "Y,,")))
    (match_operand:DI 0 "gpc_reg_operand" "r,r,*!d"))]
  "TARGET_MACHO && TARGET_64BIT"
  "*
{
  switch (which_alternative)
    {
      case 0:
    return \"std %0,lo16(%2)(%1)\";
      case 1:
    {
      output_asm_insn (\"la %1,lo16(%2)(%1)\", operands);

^^^^^
permitted? (i.e. modifying %1, which is an input operand)
      return (\"std %0,0(%1)\");
    }
      case 2:
    return \"stfd %0,lo16(%2)(%1)\";
      default:
    gcc_unreachable ();
    }
}"
  [(set_attr "type" "store")
   (set_attr "length" "4")])

[Bug target/65342] [5 Regression] FAIL: gfortran.dg/intrinsic_(un)?pack_1.f90 -O1 execution test on powerpc-apple-darwin9 after r210201

[amodra at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65342

--- Comment #9 from Alan Modra <amodra at gmail dot com> ---
As far as fixing the real underlying problem goes, I'm not so familiar with the
darwin support that I can state with certainty that you need to fix movdi_low
and friends.

It might help to explain why powerpc64-linux -mcmodel=medium code doesn't hit
the intrinsic_unpack problem even though the resultant code looks very similar
to darwin code.  We don't see a similar propagation of offset into memory load
because legitimate_addres_p() says that isn't valid.  It isn't valid because
legitimate_constant_pool_address_p (also handles toc-relative medium model
addresses) checks alignment.  So fwprop and combine don't create the problem
memory loads in the first place.  However, if we did see such a memory load,
reload would fix it for us due to the predicate and constraints in
movdi_internal64.  Note that having legitimate_address_p() prevent these
addresses does mean we lose some optimization opportunites, but on the other
hand, if we allowed everything early we'd end up with lots of reloads and
probably worse code.

You may be able to do something similar in legitimate_address_p for darwin.

[Bug target/65342] [5 Regression] FAIL: gfortran.dg/intrinsic_(un)?pack_1.f90 -O1 execution test on powerpc-apple-darwin9 after r210201

[amodra at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65342

--- Comment #10 from Alan Modra <amodra at gmail dot com> ---
> permitted? (i.e. modifying %1, which is an input operand)

Yes.  You're outputting assembly, practically anything goes.

[Bug target/65342] [5 Regression] FAIL: gfortran.dg/intrinsic_(un)?pack_1.f90 -O1 execution test on powerpc-apple-darwin9 after r210201

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65342

--- Comment #11 from Iain Sandoe <iains at gcc dot gnu.org> ---
Created attachment 35039
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35039&action=edit
Patch for discussion

OK so this is a frustrating area to debug.  One can see the problem easily
enough - but finding where it's introduced ... 

Question:
 Is there a reason that we don't have a constraint for DS-mode operands?
 Since there are so few constraint letters left, I have not attempted to add
one - but curious about the reason.

The patch is intended to do the following:
 1. record that macho-pic indirections are always sufficiently aligned that a
ds-mode offset is applicable (they reside in special sections with guaranteed
alignment) - the picbase is also guaranteed to be aligned to 32b since it's a
code label.
 - changes to config/darwin.{c,h}

 2. I've added a new predicate (put it in darwin.md, for now since I'm just
testing).
 - the predicate tries to look through the various cases to determine when a
ds-mode operand is safe.

 3. This is the bit that is in generic code and needs review:

ISTM that the Y constraint code needs an additional check - at least for Darwin
- if *only* for darwin, then I'm happy to conditionalise it on TARGET_MACHO. 
However, it's not obvious to me that no other target could be affected.

What can happen is that the offset to the mem returns NULL_RTX (no offset) but
there's actually quite a complex address expression - and that might not
resolve to a sufficiently aligned object.  Presently, the code just assumes
that no offset means it's OK.


--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -6378,11 +6378,20 @@ mem_operand_gpr (rtx op, machine_mode mode)
 {
   unsigned HOST_WIDE_INT offset;
   int extra;
+  unsigned align = MEM_ALIGN (op);
   rtx addr = XEXP (op, 0);
-
   op = address_offset (addr);
   if (op == NULL_RTX)
-    return true;
+    {
+      /* No offset:
+         A naked reg is OK - any alignment works.  */
+      if (REG_P (addr))
+        return true ;
+      /* Otherwise, we assume there will be a relocation, and we can't
+        guarantee it will fit unless the object referred to is sufficiently
+        aligned.  */
+      return align >= 32;
+    }


NOTE: there are some debug changes in the patch - this is not intended for
submission until point 3 is reviewed.

[Bug target/65342] [5 Regression] FAIL: gfortran.dg/intrinsic_(un)?pack_1.f90 -O1 execution test on powerpc-apple-darwin9 after r210201

[amodra at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65342

--- Comment #12 from Alan Modra <amodra at gmail dot com> ---
We won't want that mem_operand_gpr change for Linux or AIX as we do the
alignment checking of more complex expressions in legitimate_address_p.
Do take heed to the comment about accepting odd rtl generated by reload..

[Bug target/65342] [5 Regression] FAIL: gfortran.dg/intrinsic_(un)?pack_1.f90 -O1 execution test on powerpc-apple-darwin9 after r210201

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65342

--- Comment #13 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Alan Modra from comment #12)
> We won't want that mem_operand_gpr change for Linux or AIX as we do the
> alignment checking of more complex expressions in legitimate_address_p.
> Do take heed to the comment about accepting odd rtl generated by reload..

Hmm.. OK.
FWIW, I did try to track through legitimate_address_p to see if i could
identify where the problem was being introduced (without much luck). Will have
to look again.

[Bug target/65342] [5 Regression] FAIL: gfortran.dg/intrinsic_(un)?pack_1.f90 -O1 execution test on powerpc-apple-darwin9 after r210201

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65342

--- Comment #14 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
Results with the patch in comment 11 at

https://gcc.gnu.org/ml/gcc-testresults/2015-03/msg02484.html

Note that the patch in comment 6 also fixes this PR. It is probably the best
short term solution. Could it be committed for 5.1?

[Bug target/65342] [5 Regression] FAIL: gfortran.dg/intrinsic_(un)?pack_1.f90 -O1 execution test on powerpc-apple-darwin9 after r210201

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65342

--- Comment #15 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Dominique d'Humieres from comment #14)
> Results with the patch in comment 11 at
> 
> https://gcc.gnu.org/ml/gcc-testresults/2015-03/msg02484.html
> 
> Note that the patch in comment 6 also fixes this PR. It is probably the best
> short term solution. Could it be committed for 5.1?

I concur, there's no way I'm going to get any more cycles on this before GCC5
RC1 is built (probably in the next day or two).

Will try to find some time to address it properly (since there is a real
underlying issue) for 6/5.2.

[Bug target/65342] [5 Regression] FAIL: gfortran.dg/intrinsic_(un)?pack_1.f90 -O1 execution test on powerpc-apple-darwin9 after r210201

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65342

--- Comment #16 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> Note that the patch in comment 6 also fixes this PR. It is probably the best
> short term solution. Could it be committed for 5.1?

Results with this patch at
https://gcc.gnu.org/ml/gcc-testresults/2015-04/msg00483.html. The failures are
also present without the patch.

[Bug target/65342] [5/6 Regression] FAIL: gfortran.dg/intrinsic_(un)?pack_1.f90 -O1 execution test on powerpc-apple-darwin9 after r210201

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65342

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|5.0                         |5.2

--- Comment #17 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 5.1 has been released.

[Bug target/65342] [5/6 Regression] FAIL: gfortran.dg/intrinsic_(un)?pack_1.f90 -O1 execution test on powerpc-apple-darwin9 after r210201

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65342

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|5.2                         |5.3

--- Comment #18 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 5.2 is being released, adjusting target milestone to 5.3.