[Bug d/106977] [13 regression] d21 dies with SIGBUS on 32-bit Darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106977 --- Comment #30 from Iain Sandoe --- (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=, s=) 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 regression] d21 dies with SIGBUS on 32-bit Darwin
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=, s=) 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106977
--- Comment #28 from Iain Sandoe ---
(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: 0x2a18
d21`_D4core9exception__T15__switch_errorTZQsFNaNbNiNeAyakZv(file=,
line=) 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106977 --- Comment #27 from Iain Sandoe --- 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=) at runtime.d:752 frame #6: 0x01c3374a d21`_D4core7runtime19defaultTraceHandlerFPvZC6object9Throwable9TraceInfo(ptr=0x) at runtime.d:762 frame #7: 0x01c1f560 d21`_d_createTrace(t=0x04615108, context=0x) at deh.d:51 frame #8: 0x01c013cb d21`_d_throw(object=0x04615108) at deh.d:484 frame #9: 0x2a18 d21`_D4core9exception__T15__switch_errorTZQsFNaNbNiNeAyakZv(file=, line=) at exception.d:17 frame #10: 0x29d5 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: 0x2c8b d21`_D3dmd6access17checkSymbolAccessFPSQBh6dscope5ScopeCQBy7dsymbol7DsymbolZb(sc=, s=) at access.d:296
[Bug d/106977] [13 regression] d21 dies with SIGBUS on 32-bit Darwin
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
[Bug d/106977] [13 regression] d21 dies with SIGBUS on 32-bit Darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106977 --- Comment #25 from Iain Sandoe --- (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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106977 --- Comment #23 from Iain Sandoe --- (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 > movl28(%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 > movl48(%esp), %eax > leal8(%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
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
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 movl28(%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 movl48(%esp), %eax leal8(%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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106977 --- Comment #19 from Andrew Pinski --- (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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106977 --- Comment #18 from Andrew Pinski --- (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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106977
--- Comment #17 from Iain Sandoe ---
(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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106977 --- Comment #16 from Iain Sandoe --- (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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106977 --- Comment #15 from Andrew Pinski --- (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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106977 --- Comment #14 from Iain Sandoe --- (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
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 = this->visibility;
}
---
vs. gdc-mainline
---
struct Visibility visible (struct AggregateDeclaration * const this)
{
= this->visibility;
return ;
}
---
[Bug d/106977] [13 regression] d21 dies with SIGBUS on 32-bit Darwin
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
movl32(%esp), %eax
movl28(%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
movl36(%esp), %eax
.loc 1 8 27
leal8(%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
movl8(%esp), %edx
movl4(%esp), %eax
.loc 1 789 9
movl208(%edx), %ecx
movl212(%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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106977 --- Comment #11 from Iain Sandoe --- (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
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106977 --- Comment #8 from Iain Sandoe --- (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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106977 --- Comment #7 from Iain Sandoe --- (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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106977
Iain Sandoe 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 ---
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=0x0007) 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=0x0007) 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106977 --- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #3 from Iain Buclaw --- > (In reply to r...@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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106977 --- Comment #3 from Iain Buclaw --- (In reply to r...@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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106977 --- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #1 from Iain Buclaw --- > 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106977 --- Comment #1 from Iain Buclaw --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106977 Richard Biener changed: What|Removed |Added Target Milestone|--- |13.0 Priority|P3 |P4
