[Bug d/106977] New: [13 regression] d21 dies with SIGBUS on 32-bit Darwin

[Bug d/106977] New: [13 regression] d21 dies with SIGBUS on 32-bit Darwin

[ro at gcc dot gnu.org]

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

            Bug ID: 106977
           Summary: [13 regression] d21 dies with SIGBUS on 32-bit Darwin
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: d
          Assignee: ibuclaw at gdcproject dot org
          Reporter: ro at gcc dot gnu.org
                CC: iains at gcc dot gnu.org
  Target Milestone: ---
            Target: i386-apple-darwin11.4.2

Between 20220610 (5940b4e59f8e198dbf7e8b733561ef72a9ba2cbc) and 20220624
(3b8794302b52a819ca3ea78238e9b5025d1c56dd),
32-bit bootstrap started to fail on 32-bit Darwin (Mac OS X 10.7): when
configuring the stage 2 libphobos, d21 dies with

$ cat conftest.d
module object;

extern(C) int main() {
  return 0;
}
$ d21 conftest.d -I <path to>/libphobos/libdruntime -o conftest.s
conftest.d:3:15: internal compiler error: Bus error: 10
    3 | extern(C) int main() {
      |               ^

I had a hard time getting more information out of this crash:

* With gdb 9.1 I get

Program received signal SIGBUS, Bus error.
0x00055398 in _ZN11Declaration7visibleEv (this=0x7)
(gdb) bt
#0  0x00055398 in _ZN11Declaration7visibleEv (this=warning: (Internal error: pc
0x7 in read in psymtab, but not in symtab.)

0x7)
#1  0x001ed871 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

  which is Declaration::visible()

* With /usr/bin/gdb:

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x0000004b
_ZN11Declaration7visibleEv (this=0x7) at
/vol/gcc/src/hg/master/darwin/gcc/d/dmd/declaration.d:547
547             return visibility;
(gdb) bt
#0  _ZN11Declaration7visibleEv (this=0x7) at
/vol/gcc/src/hg/master/darwin/gcc/d/dmd/declaration.d:547
#1  0x001ed871 in get_symbol_decl () at parsetimevisitor.d:26

* With /usr/bin/lldb:

Process 133 stopped
* thread #1: tid = 0x1f03, 0x00055398 d21`Declaration::visible(this=0x00000007)
+ 8 at declaration.d:547, stop reason = EXC_BAD_ACCESS (code=2, address=0x4b)
    frame #0: 0x00055398 d21`Declaration::visible(this=0x00000007) + 8 at
declaration.d:547
   544  
   545      override final Visibility visible() pure nothrow @nogc @safe
   546      {
-> 547          return visibility;
   548      }
   549  
   550      override final inout(Declaration) isDeclaration() inout pure
nothrow @nogc @safe
(lldb) bt
* thread #1: tid = 0x1f03, 0x00055398 d21`Declaration::visible(this=0x00000007)
+ 8 at declaration.d:547, stop reason = EXC_BAD_ACCESS (code=2, address=0x4b)
    frame #0: 0x00055398 d21`Declaration::visible(this=0x00000007) + 8 at
declaration.d:547
    frame #1: 0x001ed871 d21`get_symbol_decl(Declaration*) (.part.0) + 833

I haven't tried reghunting yet.

[Bug d/106977] [13 regression] d21 dies with SIGBUS on 32-bit Darwin

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |13.0
           Priority|P3                          |P4

[Bug d/106977] [13 regression] d21 dies with SIGBUS on 32-bit Darwin

[ibuclaw at gdcproject dot org]

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

--- Comment #1 from Iain Buclaw <ibuclaw at gdcproject dot org> ---
Is there a (sort of simple) bootstrap process one can follow for 32-bit OSX?

I have the means to test locally, but I can't get much further than building
gdc-11 -m32 - using said compiler to bootstrap mainline fails for non-D related
reasons when building stage1.

[Bug d/106977] [13 regression] d21 dies with SIGBUS on 32-bit Darwin

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #1 from Iain Buclaw <ibuclaw at gdcproject dot org> ---
> Is there a (sort of simple) bootstrap process one can follow for 32-bit OSX?
>
> I have the means to test locally, but I can't get much further than building
> gdc-11 -m32 - using said compiler to bootstrap mainline fails for non-D related
> reasons when building stage1.

I'm just using gdc 11.2.1 as of
1250dcee74985eaeacae3b85e5ec78937225d322, configure with

/vol/gcc/src/hg/gcc-11-branch/local/configure --prefix=/vol/gcc-11
--enable-objc-gc --with-gmp-include=/vol/gcc/include
--with-gmp-lib=/vol/gcc/lib/amd64 --with-mpfr-include=/vol/gcc/include
--with-mpfr-lib=/vol/gcc/lib/amd64 --with-mpc-include=/vol/gcc/include
--with-mpc-lib=/vol/gcc/lib/amd64 --with-target-bdw-gc-include=/vol/gcc/include
--with-target-bdw-gc-lib=/vol/gcc/lib/amd64,i386=/vol/gcc/lib
--enable-libphobos --enable-languages=c,ada,c++,d,fortran,lto,objc,obj-c++

Most of this can be ignored for the issue at hand.  I think only
--enable-languages=d (if at all) and --enable-libphobos are required.

The 11.3 release should do just fine, I believe.

Apart from that, nothing springs to mind immediately.

My builds are on Mac OS X 10.7/Darwin 11 still.  What macOS version are
you trying this on?  FWIW, I gave up on 32-bit builds with macOS
10.14/Darwin 18 when Apple made it close to impossible to build 32-bit
software.

[Bug d/106977] [13 regression] d21 dies with SIGBUS on 32-bit Darwin

[ibuclaw at gdcproject dot org]

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

--- Comment #3 from Iain Buclaw <ibuclaw at gdcproject dot org> ---
(In reply to ro@CeBiTec.Uni-Bielefeld.DE from comment #2)
> My builds are on Mac OS X 10.7/Darwin 11 still.  What macOS version are
> you trying this on?  FWIW, I gave up on 32-bit builds with macOS
> 10.14/Darwin 18 when Apple made it close to impossible to build 32-bit
> software.
I've got stage1 link failures on 10.10/Darwin 14, using gcc-11.3 built with
CC='gcc -m32' CXX='g++ -m32' as the bootstrap compiler.  I'll have to check
where the failures are, as I don't recall from memory.

I've also got a box with a clean 10.8/Darwin 12 install on it, hence the
question.

[Bug d/106977] [13 regression] d21 dies with SIGBUS on 32-bit Darwin

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #3 from Iain Buclaw <ibuclaw at gdcproject dot org> ---
> (In reply to ro@CeBiTec.Uni-Bielefeld.DE from comment #2)
>> My builds are on Mac OS X 10.7/Darwin 11 still.  What macOS version are
>> you trying this on?  FWIW, I gave up on 32-bit builds with macOS
>> 10.14/Darwin 18 when Apple made it close to impossible to build 32-bit
>> software.
> I've got stage1 link failures on 10.10/Darwin 14, using gcc-11.3 built with
> CC='gcc -m32' CXX='g++ -m32' as the bootstrap compiler.  I'll have to check
> where the failures are, as I don't recall from memory.

I'm actually a 64-bit gcc 11.2.1 as bootstrap compiler, building with
gcc/g++/gdc -m32.

> I've also got a box with a clean 10.8/Darwin 12 install on it, hence the
> question.

That's pretty close to my 10.7 system.  Btw., I just remembered that you
need a relatively new (for that system) version of Xcode on those ancient
systems.  I'm using the Xcode 4.6.2 command line tools on 10.7.  In a
10.8 VM I used Xcode 5.1.1 instead.  It may well be that you get weird
errors with earlier versions.  Iain Sandoe also has a patched version of
cctools at

        https://github.com/iains/darwin-xtools

However, I got along with the unmodified Xcode versions so far.

[Bug d/106977] [13 regression] d21 dies with SIGBUS on 32-bit Darwin

[iains at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
           Keywords|                            |ice-on-valid-code
     Ever confirmed|0                           |1
             Target|i386-apple-darwin11.4.2     |i?86-apple-darwin*
   Last reconfirmed|                            |2023-02-22

--- Comment #5 from Iain Sandoe <iains at gcc dot gnu.org> ---
with the latest D updates (as of 2023-02-22) this seems to be still present:

* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS
(code=1, address=0x43)
    frame #0: 0x00054e38 d21`Declaration::visible(this=0x00000007) at
declaration.d:562
   559  
   560      override final Visibility visible() pure nothrow @nogc @safe
   561      {
-> 562          return visibility;
   563      }
   564  
   565      override final inout(Declaration) isDeclaration() inout pure
nothrow @nogc @safe
Target 0: (d21) stopped.
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS
(code=1, address=0x43)
  * frame #0: 0x00054e38 d21`Declaration::visible(this=0x00000007) at
declaration.d:562
    frame #1: 0x00200841 d21`get_symbol_decl(Declaration*) (.part.0) + 849
    frame #2: 0x00203b27 d21`DeclVisitor::visit(FuncDeclaration*) + 775
    frame #3: 0x001fdf0c d21`DeclVisitor::visit(AttribDeclaration*) + 92
    frame #4: 0x001fed8c d21`build_decl_tree(Dsymbol*) + 92
    frame #5: 0x00212a39 d21`build_module_tree(Module*) + 137
    frame #6: 0x001fcaa7 d21`DeclVisitor::visit(Module*) + 23
    frame #7: 0x001fed8c d21`build_decl_tree(Dsymbol*) + 92
    frame #8: 0x001f9469 d21`d_parse_file() + 3897
    frame #9: 0x01420234 d21`compile_file() + 36
    frame #10: 0x01c5f870 d21`toplev::main(int, char**) + 5696
    frame #11: 0x01c60cc4 d21`main + 36
    frame #12: 0xa7273611 libdyld.dylib`start + 1

[Bug d/106977] [13 regression] d21 dies with SIGBUS on 32-bit Darwin

[ibuclaw at gcc dot gnu.org]

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

ibuclaw at gcc dot gnu.org changed:

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

--- Comment #6 from ibuclaw at gcc dot gnu.org ---
There's r13-1113 with introduced the use of visible().

Can't see anything odd about the virtual function declaration that would
suggest there's a mismatch between C++/D.

It does return a struct though.  Is there maybe something special done in the
way structs are returned on 32-bit OSX that doesn't occur on 32-bit Linux?

I could also just revert to accessing the underlying `->visibility` field
directly, if it really is just that function call that's problematic.

[Bug d/106977] [13 regression] d21 dies with SIGBUS on 32-bit Darwin

[iains at gcc dot gnu.org]

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

--- Comment #7 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to ibuclaw from comment #6)
> There's r13-1113 with introduced the use of visible().
> 
> Can't see anything odd about the virtual function declaration that would
> suggest there's a mismatch between C++/D.
> 
> It does return a struct though.  Is there maybe something special done in
> the way structs are returned on 32-bit OSX that doesn't occur on 32-bit
> Linux?

Well, I can re-check (there _are_ some differences between x86 Darwin / Linux,
where x86_64 is supposed to be the same).

 - but is that not the province of the middle & back-ends?
   why would it make any difference what the FE language does?

> I could also just revert to accessing the underlying `->visibility` field
> directly, if it really is just that function call that's problematic.

We cannot really tell, since the build does not get beyond stage1 - so that
we're nowhere near running the testsuite.

This was on Darwin17, for reference - so the most modern supported 32b case.

[Bug d/106977] [13 regression] d21 dies with SIGBUS on 32-bit Darwin

[iains at gcc dot gnu.org]

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

--- Comment #8 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to ibuclaw from comment #6)
> There's r13-1113 with introduced the use of visible().

+      /* Visibility attributes are used by the debugger.  */
+      set_visibility_for_decl (decl->csym, decl);
+
       DECL_INSTANTIATED (decl->csym) = (decl->isInstantiated () != NULL);
       set_linkage_for_decl (decl->csym);
     }
@@ -2447,3 +2433,37 @@ set_linkage_for_decl (tree decl)
   if (DECL_ARTIFICIAL (decl))
     return d_weak_linkage (decl);
 }
+
+/* NODE is a FUNCTION_DECL, VAR_DECL or RECORD_TYPE for the declaration SYM.
+   Set flags to reflect visibility that NODE will get in the object file.  */
+
+void
+set_visibility_for_decl (tree node, Dsymbol *sym)

hmmm.. should the call be "set_visibility_for_decl (decl, decl->csym); ?

or should the signature of set_visibility_for_decl() be
set_visibility_for_decl (Dsymbol *sym, tree node)?

or maybe I misread the comment....

[Bug d/106977] [13 regression] d21 dies with SIGBUS on 32-bit Darwin

[ibuclaw at gcc dot gnu.org]

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

--- Comment #9 from ibuclaw at gcc dot gnu.org ---
(In reply to Iain Sandoe from comment #8)
> +
> +/* NODE is a FUNCTION_DECL, VAR_DECL or RECORD_TYPE for the declaration SYM.
> +   Set flags to reflect visibility that NODE will get in the object file. 
> */
> +
> +void
> +set_visibility_for_decl (tree node, Dsymbol *sym)
> 
> hmmm.. should the call be "set_visibility_for_decl (decl, decl->csym); ?
> 
> or should the signature of set_visibility_for_decl() be
> set_visibility_for_decl (Dsymbol *sym, tree node)?
> 
> or maybe I misread the comment....
I might be unclear, first parameter (NODE) is a tree *_DECL representation for
the second parameters (SYM) that is the associated front-end symbol.

[Bug d/106977] [13 regression] d21 dies with SIGBUS on 32-bit Darwin

[ibuclaw at gcc dot gnu.org]

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

--- Comment #10 from ibuclaw at gcc dot gnu.org ---
Without using `->visible()` would be something like:

--- a/gcc/d/decl.cc
+++ b/gcc/d/decl.cc
@@ -2559,10 +2561,17 @@ set_linkage_for_decl (tree decl)
 void
 set_visibility_for_decl (tree node, Dsymbol *sym)
 {
-  Visibility visibility = sym->visible ();
-  if (visibility.kind == Visibility::private_)
+  Visibility::Kind kind;
+  if (AggregateDeclaration *ad = sym->isAggregateDeclaration ())
+    kind = ad->visibility.kind;
+  else if (Declaration *d = sym->isDeclaration ())
+    kind = d->visibility.kind;
+  else
+    gcc_unreachable ();
+
+  if (kind == Visibility::private_)
     TREE_PRIVATE (node) = 1;
-  else if (visibility.kind == Visibility::protected_)
+  else if (kind == Visibility::protected_)
     TREE_PROTECTED (node) = 1;

   /* If the declaration was declared `export', append either the dllimport

[Bug d/106977] [13 regression] d21 dies with SIGBUS on 32-bit Darwin

[iains at gcc dot gnu.org]

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

--- Comment #11 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to ibuclaw from comment #9)
> (In reply to Iain Sandoe from comment #8)
> > +
> > +/* NODE is a FUNCTION_DECL, VAR_DECL or RECORD_TYPE for the declaration SYM.
> > +   Set flags to reflect visibility that NODE will get in the object file. 
> > */
> > +
> > +void
> > +set_visibility_for_decl (tree node, Dsymbol *sym)
> > 
> > hmmm.. should the call be "set_visibility_for_decl (decl, decl->csym); ?
> > 
> > or should the signature of set_visibility_for_decl() be
> > set_visibility_for_decl (Dsymbol *sym, tree node)?
> > 
> > or maybe I misread the comment....
> I might be unclear, first parameter (NODE) is a tree *_DECL representation
> for the second parameters (SYM) that is the associated front-end symbol.

yeah but the definition of set_visibility_for_decl() is:
+void
+set_visibility_for_decl (tree node, Dsymbol *sym)

which seems to be the opposite order (so if that's intended ... then the
comment definitely needs to distinguish between D nodes and other cases)

[Bug d/106977] [13 regression] d21 dies with SIGBUS on 32-bit Darwin

[ibuclaw at gcc dot gnu.org]

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

--- Comment #12 from ibuclaw at gcc dot gnu.org ---
Looks like a bad mismatch between C++ and D.

When C++ calls the method, it pushes one register.  When D calls it, pushes
two.

Looks like the method itself returns the result in 2 registers as well - or
maybe uses return slot optimization.
---
// C++ Caller code
#include "tree.h"
#include "dmd/dsymbol.h"
#include "dmd/aggregate.h"
void
set_visibility_for_decl (tree node, Dsymbol *sym)
{
  Visibility visibility = sym->visible ();

// C++ Caller asm
        pushl   %ebx
        subl    $20, %esp
        .loc 1 2561 1
        movl    32(%esp), %eax
        movl    28(%esp), %ebx
        .loc 1 2562 40
        movl    (%eax), %edx
        pushl   %eax
        call    *104(%edx)

// D Caller code
import dmd.dsymbol;
import dmd.aggregate;
import dmd.gluelayer;
extern(C++)
void
set_visibility_for_decl (tree_node* node, Dsymbol sym)
{
  Visibility visibility = sym.visible();
}
// D Caller asm
        subl    $28, %esp
        .loc 1 5 1
        movl    36(%esp), %eax
        .loc 1 8 27
        leal    8(%esp), %ecx
        subl    $8, %esp
        movl    (%eax), %edx
        pushl   %eax
        pushl   %ecx
        call    *104(%edx)

// D Callee code
override final Visibility visible() pure nothrow @nogc @safe
{
  return visibility;
}
// D Callee asm
        movl    8(%esp), %edx
        movl    4(%esp), %eax
        .loc 1 789 9
        movl    208(%edx), %ecx
        movl    212(%edx), %edx
        movl    %ecx, (%eax)
        movl    %edx, 4(%eax)
        .loc 1 790 5
        ret     $4

[Bug d/106977] [13 regression] d21 dies with SIGBUS on 32-bit Darwin

[ibuclaw at gcc dot gnu.org]

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

--- Comment #13 from ibuclaw at gcc dot gnu.org ---
Confirmed, D is doing NRVO return whereas C++ isn't.

gdc-11 codegen of the `visible` method:

---
struct Visibility visible (struct AggregateDeclaration * const this)
{
  return <retval> = this->visibility;
}
---

vs. gdc-mainline
---
struct Visibility visible (struct AggregateDeclaration * const this)
{
  <retval> = this->visibility;
  return <retval>;
}
---

[Bug d/106977] [13 regression] d21 dies with SIGBUS on 32-bit Darwin

[iains at gcc dot gnu.org]

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

--- Comment #14 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to ibuclaw from comment #13)
> Confirmed, D is doing NRVO return whereas C++ isn't.

I am not sure that the NVRO is the issue (it is correct ABI for an 8 byte
struct to be returned in EAX:EDX).  The value can be "created" in the return
slot (i.e. doing the NVRO) without altering that.

------

If the caller is passing two regs it seems to me likely that (for some reason
it thinks that the value is returned via an sret pointer).

The callee then get s the set pointer in the register it is expecting *this to
be in... and boom .. we are broken at some point,

So it would seem that we might want to find a reproducer that we can look at
the various tree dumps and see if/where an sret is introduced?

(if that's not the cause, then we'll have to find a new hypothesis)

[Bug d/106977] [13 regression] d21 dies with SIGBUS on 32-bit Darwin

[pinskia at gcc dot gnu.org]

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

--- Comment #15 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Iain Sandoe from comment #14)
> So it would seem that we might want to find a reproducer that we can look at
> the various tree dumps and see if/where an sret is introduced?
> 
> (if that's not the cause, then we'll have to find a new hypothesis)

POD vs non-POD (I think TYPE_ADDRESSABLE causes the difference but I am not
100% sure ...)

[Bug d/106977] [13 regression] d21 dies with SIGBUS on 32-bit Darwin

[iains at gcc dot gnu.org]

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

--- Comment #16 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Iain Sandoe from comment #14)
> (In reply to ibuclaw from comment #13)

> If the caller is passing two regs it seems to me likely that (for some
> reason it thinks that the value is returned via an sret pointer).
> 
> The callee then get s the set pointer in the register it is expecting *this
> to be in... and boom .. we are broken at some point,
> 
> So it would seem that we might want to find a reproducer that we can look at
> the various tree dumps and see if/where an sret is introduced?
> 
> (if that's not the cause, then we'll have to find a new hypothesis)

oops I misread the D callee asm .. it looks like the D callee is expecting an
sret.

So ISTM that somehow D is not getting the right answer to "does this ABI pass
by sret for this size of struct"?

[Bug d/106977] [13 regression] d21 dies with SIGBUS on 32-bit Darwin

[iains at gcc dot gnu.org]

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

--- Comment #17 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #15)
> (In reply to Iain Sandoe from comment #14)
> > So it would seem that we might want to find a reproducer that we can look at
> > the various tree dumps and see if/where an sret is introduced?
> > 
> > (if that's not the cause, then we'll have to find a new hypothesis)
> 
> POD vs non-POD (I think TYPE_ADDRESSABLE causes the difference but I am not
> 100% sure ...)

I think the visibility type is POD (assuming D has that concept)

struct Visibility
{
   enum Kind
   {
       undefined,
       none,           // no access
       private_,
       package_,
       protected_,
       public_,
       export_
   };
   Kind kind;
   void *pkg;
};

[Bug d/106977] [13 regression] d21 dies with SIGBUS on 32-bit Darwin

[pinskia at gcc dot gnu.org]

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

--- Comment #18 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Iain Sandoe from comment #17)
> (In reply to Andrew Pinski from comment #15)
> > (In reply to Iain Sandoe from comment #14)
> > > So it would seem that we might want to find a reproducer that we can look at
> > > the various tree dumps and see if/where an sret is introduced?
> > > 
> > > (if that's not the cause, then we'll have to find a new hypothesis)
> > 
> > POD vs non-POD (I think TYPE_ADDRESSABLE causes the difference but I am not
> > 100% sure ...)
> 
> I think the visibility type is POD (assuming D has that concept)

Something is TREE_ADDRESSABLE on the D Visibility  type ...

This is the mismatch that is happening.

[Bug d/106977] [13 regression] d21 dies with SIGBUS on 32-bit Darwin

[pinskia at gcc dot gnu.org]

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

--- Comment #19 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #18)
> > I think the visibility type is POD (assuming D has that concept)

At least the front-end does.
See dmd/dstruct.d:443

if isPOD return false, TREE_ADDRESSABLE is set on the struct.
I have not gone through the code otherwise.

[Bug d/106977] [13 regression] d21 dies with SIGBUS on 32-bit Darwin

[ibuclaw at gcc dot gnu.org]

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

--- Comment #20 from ibuclaw at gcc dot gnu.org ---
(In reply to Andrew Pinski from comment #19)
> (In reply to Andrew Pinski from comment #18)
> > > I think the visibility type is POD (assuming D has that concept)
> 
> At least the front-end does.
> See dmd/dstruct.d:443
> 
> if isPOD return false, TREE_ADDRESSABLE is set on the struct.
> I have not gone through the code otherwise.
See d/decl.cc:950

It's not TREE_ADDRESSABLE, but on 32-bit the struct is considered to be
'aggregate_value_p', which in turn sets up return by hidden reference.

This effects how the return is handled later (around toir.cc:1044), which
splits up the init and return expression.  Returning this way I guess is fine
for extern(D) functions, however we should not be so eager to do rvo/sret for
other extern language functions.

Having a quick look at C++ front-end, they require both `aggregate_value_p` and
for a named variable to be in the return expression.

```
  if (current_function_return_value)
    {
      tree r = current_function_return_value;
      tree outer;

      if (r != error_mark_node
          /* This is only worth doing for fns that return in memory--and
             simpler, since we don't have to worry about promoted modes.  */
          && aggregate_value_p (TREE_TYPE (TREE_TYPE (fndecl)), fndecl)
```

So for the current gate in D:
```
    if (TREE_ADDRESSABLE (TREE_TYPE (resdecl))
        || aggregate_value_p (TREE_TYPE (resdecl), fndecl))
```

I think tightening that to (its late, and my parentheses may be wrong).
```
    if (TREE_ADDRESSABLE (TREE_TYPE (resdecl))
        || ((d->resolvedLinkage () == LINK::d
             || (d->resolvedLinkage () == LINK::cpp && d->nrvo_var))
            && aggregate_value_p (TREE_TYPE (resdecl), fndecl)))
```
Which is:
1. TREE_ADDRESSABLE
2. extern(D) and aggregate_value_p
3. extern(C++) and have NVRO variable and aggregate_value_p

I guess for extern(C) functions we should just forget even attempting to do any
(N)RVO/SRET returns and let tree-nrv.cc decide whether to optimize or not.

[Bug d/106977] [13 regression] d21 dies with SIGBUS on 32-bit Darwin

[ibuclaw at gcc dot gnu.org]

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

--- Comment #21 from ibuclaw at gcc dot gnu.org ---
There is something about the Darwin ABI I'm just not getting from looking at
the front-end alone though:

C++ Darwin 32-bit calling a method that returns an 8 byte struct:
```
__Z4testP3Bar:
        subl    $24, %esp
        movl    28(%esp), %eax
        movl    (%eax), %edx
        pushl   %eax            // <--
        call    *(%edx)
```

C++ Linux 32-bit calling a method that returns an 8 byte struct:
```
_Z4testP3Bar:
        subl    $44, %esp
        movl    %gs:20, %edx
        movl    %edx, 28(%esp)
        xorl    %edx, %edx
        movl    48(%esp), %eax
        leal    8(%esp), %ecx
        subl    $8, %esp
        movl    (%eax), %edx
        pushl   %eax            // <--
        pushl   %ecx            // <--
        call    *(%edx)
```

[Bug d/106977] [13 regression] d21 dies with SIGBUS on 32-bit Darwin

[ibuclaw at gcc dot gnu.org]

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

--- Comment #22 from ibuclaw at gcc dot gnu.org ---
(In reply to ibuclaw from comment #21)
> There is something about the Darwin ABI I'm just not getting from looking at
> the front-end alone though:
Taken from a test Iain had sent me, and I've subsequently modified.
```
struct Visibility
{
    enum Kind
    {
        undefined, none, private_,
        package_, protected_,
        public_, export_
    };
    Kind kind;
    void *pkg;
};

class Bar
{
public:
    int x;
    virtual Visibility vis ();
};

Visibility Bar::vis () { return Visibility (); }

class Foo  : public Bar
{
public:
    Visibility v;
    int y;
    Visibility vis () override final;
};

Visibility Foo::vis () { return v; }

int test (Bar *foo)
{
    Visibility vis;
    vis = foo->vis ();
    return vis.kind;
}
```

[Bug d/106977] [13 regression] d21 dies with SIGBUS on 32-bit Darwin

[iains at gcc dot gnu.org]

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

--- Comment #23 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to ibuclaw from comment #21)
> There is something about the Darwin ABI I'm just not getting from looking at
> the front-end alone though:
> 
> C++ Darwin 32-bit calling a method that returns an 8 byte struct:
> ```
> __Z4testP3Bar:
>         subl    $24, %esp
>         movl    28(%esp), %eax
>         movl    (%eax), %edx
>         pushl   %eax            // <--
>         call    *(%edx)
> ```

Darwin does not need an "sret" parameter since it will return the struct in
registers.
So it only passes "this".

> C++ Linux 32-bit calling a method that returns an 8 byte struct:
> ```
> _Z4testP3Bar:
>         subl    $44, %esp
>         movl    %gs:20, %edx
>         movl    %edx, 28(%esp)
>         xorl    %edx, %edx
>         movl    48(%esp), %eax
>         leal    8(%esp), %ecx
>         subl    $8, %esp
>         movl    (%eax), %edx
>         pushl   %eax            // <--
>         pushl   %ecx            // <--
>         call    *(%edx)
> ```

The Linux (SysV ABI arch-specific addition) says that structures are returned
via an sret param - for all size of struct.


So the ABIs differ in this (as noted on IRC, the Darwin 32b ABIs are not the
same as Linux).

[Bug d/106977] [13 regression] d21 dies with SIGBUS on 32-bit Darwin

[ibuclaw at gcc dot gnu.org]

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

--- Comment #24 from ibuclaw at gcc dot gnu.org ---
(In reply to Iain Sandoe from comment #23)
> So the ABIs differ in this (as noted on IRC, the Darwin 32b ABIs are not the
> same as Linux).
I'm still yet to work out why D on 32-bit Darwin behaves the same as 32-bit
Linux though.  I would have assumed the decision to generate an sret would
occur long after the front-end has freed itself from the compilation process.

Regardless, the ABI issue can be raised in a separate PR. Because of it though,
that means for this bootstrap PR we just have to avoid calling any extern(C++)
method implemented in D that returns a struct by value.

[Bug d/106977] [13 regression] d21 dies with SIGBUS on 32-bit Darwin

[iains at gcc dot gnu.org]

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

--- Comment #25 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to ibuclaw from comment #24)
> (In reply to Iain Sandoe from comment #23)
> > So the ABIs differ in this (as noted on IRC, the Darwin 32b ABIs are not the
> > same as Linux).
> I'm still yet to work out why D on 32-bit Darwin behaves the same as 32-bit
> Linux though.  I would have assumed the decision to generate an sret would
> occur long after the front-end has freed itself from the compilation process.

there should be some target hook to query whether a struct returns in regs.

> Regardless, the ABI issue can be raised in a separate PR. Because of it
> though, that means for this bootstrap PR we just have to avoid calling any
> extern(C++) method implemented in D that returns a struct by value.

Note that this would affect any interface to libc or external C++ that returns
a small struct.  AFAIR, X86 Darwin is not the only platform that returns small
structs in regs.

[Bug d/106977] [13 regression] d21 dies with SIGBUS on 32-bit Darwin

[ibuclaw at gcc dot gnu.org]

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

--- Comment #26 from ibuclaw at gcc dot gnu.org ---
Comparing the D and C++ trees side by side.

At the point of `finish_function` for the ::vis() method, I see the following:

D:   type <record_type 0x7ffff6f91888 Visibility cxx-odr-p BLK
C++: type <record_type 0x7ffff700aa80 Visibility cxx-odr-p type_5 DI

When does TYPE_MODE get set, and why is it that value?

Setting watchers in both language compilers...

- C++/D: make_node() sets the memory to E_VOIDmode
- C++/D: entrypoint to compute_record_type() sets BLKmode
- D:     returns early because all fields still have DECL_SIZE = null
- C++:   exit to compute_record_type() sets E_DImode 

In D, this is finish_aggregate_type() which calls compute_record_mode() before
calling layout_decl() on all fields.  This was not the 

Looking at history between 2022/06/10 .. 2022/06/24, I think we have a clear
commit that introduced this wrong code/behaviour - r13-1104.

The loop added in r13-1104 that sets DECL_SIZE on all fields was added after
the call to compute_record_mode.

Looks like this is the mistake, it should have been put before
compute_record_mode.

So then, I think we finally have a fix:

--- a/gcc/d/types.cc
+++ b/gcc/d/types.cc
@@ -615,9 +615,6 @@ finish_aggregate_type (unsigned structsize, unsigned
alignsize, tree type)
   SET_TYPE_ALIGN (type, alignsize * BITS_PER_UNIT);
   TYPE_PACKED (type) = (alignsize == 1);

-  /* Set the back-end type mode.  */
-  compute_record_mode (type);
-
   /* Layout all fields now the type is complete.  */
   for (tree field = TYPE_FIELDS (type); field; field = DECL_CHAIN (field))
     {
@@ -662,6 +659,9 @@ finish_aggregate_type (unsigned structsize, unsigned
alignsize, tree type)
        }
     }

+  /* Set the back-end type mode after all fields have had their size set.  */
+  compute_record_mode (type);
+
   /* Fix up all forward-referenced variants of this aggregate type.  */
   for (tree t = TYPE_MAIN_VARIANT (type); t; t = TYPE_NEXT_VARIANT (t))
     {

[Bug d/106977] [13 regression] d21 dies with SIGBUS on 32-bit Darwin

[iains at gcc dot gnu.org]

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

--- Comment #27 from Iain Sandoe <iains at gcc dot gnu.org> ---
great!

we make more progress now - at least past libphobos configure:

we now fail building druntime/core/atomic.d and I am not quite sure how to
interpret the backtrace (from b internal_error).


(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS
(code=EXC_I386_GPFLT)
  * frame #0: 0xa7273850 libdyld.dylib`misaligned_stack_error_
    frame #1: 0xa9847000 libsystem_malloc.dylib
    frame #2: 0x01a2e40b d21`backtrace_simple + 75
    frame #3: 0x01bfcca4
d21`_D3gcc9backtrace12LibBacktrace6__ctorMFNiiZCQBqQBpQBi(this=0x052c3800,
firstFrame=4) at backtrace.d:207
    frame #4: 0x01c3370a
d21`_D4core8lifetime__T7emplaceTC3gcc9backtrace12LibBacktraceTiZQBpFNiQBmKiZQBs(chunk=0x052c3800,
_param_1=0xbfffefa4) at lifetime.d:126
    frame #5: 0x01c3373a
d21`_D4core7runtime19defaultTraceHandlerFPvZ__T8allocateTC3gcc9backtrace12LibBacktraceTiZQBqFNiiZQBo(_param_0=<unavailable>)
at runtime.d:752
    frame #6: 0x01c3374a
d21`_D4core7runtime19defaultTraceHandlerFPvZC6object9Throwable9TraceInfo(ptr=0x00000000)
at runtime.d:762
    frame #7: 0x01c1f560 d21`_d_createTrace(t=0x04615108, context=0x00000000)
at deh.d:51
    frame #8: 0x01c013cb d21`_d_throw(object=0x04615108) at deh.d:484
    frame #9: 0x00002a18
d21`_D4core9exception__T15__switch_errorTZQsFNaNbNiNeAyakZv(file=<unavailable>,
line=<unavailable>) at exception.d:17
    frame #10: 0x000029d5
d21`_D4core9exception__T15__switch_errorTZQsFNaNbNiNeAyakZv(file=(length = 40,
ptr = "/src-local/gcc-master/gcc/d/dmd/access.d"), line=296) at exception.d:13
    frame #11: 0x00002c8b
d21`_D3dmd6access17checkSymbolAccessFPSQBh6dscope5ScopeCQBy7dsymbol7DsymbolZb(sc=<unavailable>,
s=<unavailable>) at access.d:296



====

[Bug d/106977] [13 regression] d21 dies with SIGBUS on 32-bit Darwin

[iains at gcc dot gnu.org]

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

--- Comment #28 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Iain Sandoe from comment #27)
> great!
> 
> we make more progress now - at least past libphobos configure:
> 
> we now fail building druntime/core/atomic.d and I am not quite sure how to
> interpret the backtrace (from b internal_error).


> ====

frame #9: 0x00002a18
d21`_D4core9exception__T15__switch_errorTZQsFNaNbNiNeAyakZv(file=<unavailable>,
line=<unavailable>) at exception.d:17
   14   {
   15       // Consider making this a compile time check.
   16       version (D_Exceptions)
-> 17           throw staticError!SwitchError("No appropriate switch clause
found", file, line, null);
   18       else
   19           assert(0, "No appropriate switch clause found");

[Bug d/106977] [13 regression] d21 dies with SIGBUS on 32-bit Darwin

[ibuclaw at gcc dot gnu.org]

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

--- Comment #29 from ibuclaw at gcc dot gnu.org ---
(In reply to Iain Sandoe from comment #27)
> great!
> 
> we make more progress now - at least past libphobos configure:
> 
> we now fail building druntime/core/atomic.d and I am not quite sure how to
> interpret the backtrace (from b internal_error).
>
> d21`_D3dmd6access17checkSymbolAccessFPSQBh6dscope5ScopeCQBy7dsymbol7DsymbolZb
> (sc=<unavailable>, s=<unavailable>) at access.d:296
>
My fear is that now it's corrupting the return in other ways now, this time
within D itself.

access.d:296: final switch (s.visible().kind)

[Bug d/106977] [13 regression] d21 dies with SIGBUS on 32-bit Darwin

[iains at gcc dot gnu.org]

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

--- Comment #30 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to ibuclaw from comment #29)
> (In reply to Iain Sandoe from comment #27)
> > great!
> > 
> > we make more progress now - at least past libphobos configure:
> > 
> > we now fail building druntime/core/atomic.d and I am not quite sure how to
> > interpret the backtrace (from b internal_error).
> >
> > d21`_D3dmd6access17checkSymbolAccessFPSQBh6dscope5ScopeCQBy7dsymbol7DsymbolZb
> > (sc=<unavailable>, s=<unavailable>) at access.d:296
> >
> My fear is that now it's corrupting the return in other ways now, this time
> within D itself.

I see.. that might be the tricky aspect of trying to have a different ABI
internally and for accessing C/C++.  Not sure how to solve it (are functions
with C-family interfaces marked as such?)

[Bug d/106977] [13/14 regression] d21 dies with SIGBUS on 32-bit Darwin

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|13.0                        |13.2

--- Comment #31 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 13.1 is being released, retargeting bugs to GCC 13.2.

[Bug d/106977] [13/14 regression] d21 dies with SIGBUS on 32-bit Darwin

[cvs-commit at gcc dot gnu.org]

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

--- Comment #32 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Iain Buclaw <ibuclaw@gcc.gnu.org>:

https://gcc.gnu.org/g:c201cd3be0d9ab887fafb0c33a9fc287c405c21c

commit r14-2169-gc201cd3be0d9ab887fafb0c33a9fc287c405c21c
Author: Iain Buclaw <ibuclaw@gdcproject.org>
Date:   Wed Jun 28 18:30:31 2023 +0200

    d: Fix wrong code-gen when returning structs by value.

    Since r13-1104, structs have have compute_record_mode called too early
    on them, causing them to return differently depending on the order that
    types are generated in, and whether there are forward references.

    This patch moves the call to compute_record_mode into its own function,
    and calls it after all fields have been given a size.

            PR d/106977
            PR target/110406

    gcc/d/ChangeLog:

            * types.cc (finish_aggregate_mode): New function.
            (finish_incomplete_fields): Call finish_aggregate_mode.
            (finish_aggregate_type): Replace call to compute_record_mode with
            finish_aggregate_mode.

    gcc/testsuite/ChangeLog:

            * gdc.dg/torture/pr110406.d: New test.

[Bug d/106977] [13/14 regression] d21 dies with SIGBUS on 32-bit Darwin

[cvs-commit at gcc dot gnu.org]

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

--- Comment #33 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-13 branch has been updated by Iain Buclaw
<ibuclaw@gcc.gnu.org>:

https://gcc.gnu.org/g:f2eeda5652438fe783d4e3878139481a1b8606b6

commit r13-7496-gf2eeda5652438fe783d4e3878139481a1b8606b6
Author: Iain Buclaw <ibuclaw@gdcproject.org>
Date:   Wed Jun 28 18:30:31 2023 +0200

    d: Fix wrong code-gen when returning structs by value.

    Since r13-1104, structs have have compute_record_mode called too early
    on them, causing them to return differently depending on the order that
    types are generated in, and whether there are forward references.

    This patch moves the call to compute_record_mode into its own function,
    and calls it after all fields have been given a size.

            PR d/106977
            PR target/110406

    gcc/d/ChangeLog:

            * types.cc (finish_aggregate_mode): New function.
            (finish_incomplete_fields): Call finish_aggregate_mode.
            (finish_aggregate_type): Replace call to compute_record_mode with
            finish_aggregate_mode.

    gcc/testsuite/ChangeLog:

            * gdc.dg/torture/pr110406.d: New test.

    (cherry picked from commit c201cd3be0d9ab887fafb0c33a9fc287c405c21c)

[Bug d/106977] [13/14 regression] d21 dies with SIGBUS on 32-bit Darwin

[ibuclaw at gcc dot gnu.org]

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

--- Comment #34 from ibuclaw at gcc dot gnu.org ---
I think this should be fixed now.  I'll let @Iain Sandoe confirm, as there are
likely other fixes he has relating to the testsuite.

[Bug d/106977] [13/14 regression] d21 dies with SIGBUS on 32-bit Darwin

[iains at gcc dot gnu.org]

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

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

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

--- Comment #35 from Iain Sandoe <iains at gcc dot gnu.org> ---
fixed for 13 and current trunk (14.0)