[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