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/co
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 h
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
> interp
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
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
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
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 behav
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 by
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 s
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:
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 doe
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
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 w
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
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
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
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
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->visibi
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
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 visi
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,
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 objec
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);
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106977
Iain Sandoe changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Keywords|
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 try
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/
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 t
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 mainlin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106977
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |13.0
Priority|P3
31 matches
Mail list logo
