www.digitalmars.com         C & C++   DMDScript  

D.gnu - What gcc to use for gdc master?

reply Dan Olson <gorox comcast.net> writes:
Starting a pull request for ARM and grabbed gdc master, but not sure
what gcc it likes.  I tried gcc-5.1 but

$ ./setup-gcc.sh ../gcc-5.1.0
found gcc version 5
This version of GCC (5) is not supported.

-- 
Dan
Jun 04 2015
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Thu, 04 Jun 2015 00:15:37 -0700, Dan Olson wrote:


 Starting a pull request for ARM and grabbed gdc master, but not sure
 what gcc it likes.  I tried gcc-5.1 but
=20
 $ ./setup-gcc.sh ../gcc-5.1.0 found gcc version 5 This version of GCC
 (5) is not supported.


make sure that you switched to 'gdc-5' branch.=
Jun 04 2015
parent reply Dan Olson <gorox comcast.net> writes:
ketmar <ketmar ketmar.no-ip.org> writes:


 On Thu, 04 Jun 2015 00:15:37 -0700, Dan Olson wrote:


 Starting a pull request for ARM and grabbed gdc master, but not sure
 what gcc it likes.  I tried gcc-5.1 but
 
 $ ./setup-gcc.sh ../gcc-5.1.0 found gcc version 5 This version of GCC
 (5) is not supported.


 make sure that you switched to 'gdc-5' branch.


Does gdc-5 get folded back into master then, isn't it a release branch?
I assume pull requests should be based on master?
Jun 04 2015
next sibling parent reply "Iain Buclaw via D.gnu" <d.gnu puremagic.com> writes:
On 4 June 2015 at 15:49, Dan Olson via D.gnu <d.gnu puremagic.com> wrote:


 ketmar <ketmar ketmar.no-ip.org> writes:


 On Thu, 04 Jun 2015 00:15:37 -0700, Dan Olson wrote:


 Starting a pull request for ARM and grabbed gdc master, but not sure
 what gcc it likes.  I tried gcc-5.1 but

 $ ./setup-gcc.sh ../gcc-5.1.0 found gcc version 5 This version of GCC
 (5) is not supported.


 make sure that you switched to 'gdc-5' branch.


 Does gdc-5 get folded back into master then, isn't it a release branch?
 I assume pull requests should be based on master?


All PRs should be based on master, and they get trickled down to release
branches as needed.

Master only works (or at least, has been tested) with the development
snapshot listed in gcc.version.  Which would be version gcc-6 now.
Jun 04 2015
parent reply Dan Olson <gorox comcast.net> writes:
"Iain Buclaw via D.gnu" <d.gnu puremagic.com> writes:


 All PRs should be based on master, and they get trickled down to
 release branches as needed.

 Master only works (or at least, has been tested) with the development
 snapshot listed in gcc.version. Which would be version gcc-6 now.


Ok, thanks.

As a sanity step before switching to gcc-6, tried to build gdc-5 branch
on OSX X86_64 with gcc-5.1.  I must be missing something because no
versions are satisfied for thread.d fiber_switchContext().  Should
D_InlineAsm_X86* versions be defined in GDC?  They are not in my build.

Making all in libdruntime
/Users/dan/projects/gdc-dev/gdc/objdir/./gcc/gdc
-B/Users/dan/projects/gdc-dev/gdc/objdir/./gcc/
-B/Users/dan/projects/gdc-dev/install/x86_64-apple-darwin14.3.0/bin/
-B/Users/dan/projects/gdc-dev/install/x86_64-apple-darwin14.3.0/lib/ -isystem
/Users/dan/projects/gdc-dev/install/x86_64-apple-darwin14.3.0/include -isystem
/Users/dan/projects/gdc-dev/install/x86_64-apple-darwin14.3.0/sys-include -o
core/thread.o -Wall -Werror -g -frelease -O2 -nostdinc -pipe -Wno-deprecated -I
../../../../gcc-5.1.0/libphobos/libdruntime -I ./x86_64-apple-darwin14.3.0 -I .
 -c ../../../../gcc-5.1.0/libphobos/libdruntime/core/thread.d
../../../../gcc-5.1.0/libphobos/libdruntime/core/thread.d:3550:13: error:
static assert  "Not implemented"
             static assert(0, "Not implemented");
Jun 04 2015
parent reply "Iain Buclaw via D.gnu" <d.gnu puremagic.com> writes:
On 4 June 2015 at 17:33, Dan Olson via D.gnu <d.gnu puremagic.com> wrote:


 "Iain Buclaw via D.gnu" <d.gnu puremagic.com> writes:


 All PRs should be based on master, and they get trickled down to
 release branches as needed.

 Master only works (or at least, has been tested) with the development
 snapshot listed in gcc.version. Which would be version gcc-6 now.


 Ok, thanks.

 As a sanity step before switching to gcc-6, tried to build gdc-5 branch
 on OSX X86_64 with gcc-5.1.  I must be missing something because no
 versions are satisfied for thread.d fiber_switchContext().  Should
 D_InlineAsm_X86* versions be defined in GDC?  They are not in my build.


No.  Someone should port them to Asm_External and implement it in thread.S

This should be trivial except for the X32 target, which needs to be looked
at for the correct way to switch fibers.
Jun 04 2015
parent reply Dan Olson <gorox comcast.net> writes:
"Iain Buclaw via D.gnu" <d.gnu puremagic.com> writes:


 On 4 June 2015 at 17:33, Dan Olson via D.gnu <d.gnu puremagic.com>
 wrote:
     
     As a sanity step before switching to gcc-6, tried to build gdc-5
     branch
     on OSX X86_64 with gcc-5.1. I must be missing something because no
     versions are satisfied for thread.d fiber_switchContext(). Should
     D_InlineAsm_X86* versions be defined in GDC? They are not in my
     build.
     
     

 No. Someone should port them to Asm_External and implement it in
 thread.S

 This should be trivial except for the X32 target, which needs to be
 looked at for the correct way to switch fibers.


Are you saying gdc doesn't currently build a native compiler on OS X?
Why do I think I built it before?  Foggy memory...
Jun 04 2015
parent reply Dan Olson <gorox comcast.net> writes:
Dan Olson <gorox comcast.net> writes:


 "Iain Buclaw via D.gnu" <d.gnu puremagic.com> writes:


 On 4 June 2015 at 17:33, Dan Olson via D.gnu <d.gnu puremagic.com>
 wrote:
     
     As a sanity step before switching to gcc-6, tried to build gdc-5
     branch
     on OSX X86_64 with gcc-5.1. I must be missing something because no
     versions are satisfied for thread.d fiber_switchContext(). Should
     D_InlineAsm_X86* versions be defined in GDC? They are not in my
     build.
     
     

 No. Someone should port them to Asm_External and implement it in
 thread.S

 This should be trivial except for the X32 target, which needs to be
 looked at for the correct way to switch fibers.


 Are you saying gdc doesn't currently build a native compiler on OS X?
 Why do I think I built it before?  Foggy memory...


Ok, I have these in threadasm.S now, compiler cranking away. Trying
check-d ...

Looks like I need to track down missing symbols from rt.tlsgc now. I
think it is becoming a fun puzzle :-) The arm stuff can wait.
Jun 04 2015
parent reply Dan Olson <gorox comcast.net> writes:
Dan Olson <gorox comcast.net> writes:


 Looks like I need to track down missing symbols from rt.tlsgc now. I
 think it is becoming a fun puzzle :-) The arm stuff can wait.


How do I tell gdc that OS X needs target specific underscore "_" prefix
added to pragma(mangle, name)?  thread.d uses
core.internal.traits.externDFunc.  That is cause.  For now I worked
around with:

pragma(mangle, "_"~mangleFunc!T(fqn)) mixin(decl);
Jun 04 2015
next sibling parent reply Dan Olson <gorox comcast.net> writes:
Sorry for a long chain on OSX.  But one last unresolved symbol from make
check-d: "_d_osx_image_init".  Is it just a placeholder or is it hidden
somewhere.  Does gdc still need the code to set setup gc scanning?  How
is TLS on OSX? - if not ready, would emutls work?
-- 
Dan
Jun 04 2015
parent reply "Iain Buclaw via D.gnu" <d.gnu puremagic.com> writes:
On 5 June 2015 at 08:40, Dan Olson via D.gnu <d.gnu puremagic.com> wrote:

 Sorry for a long chain on OSX.  But one last unresolved symbol from make
 check-d: "_d_osx_image_init".  Is it just a placeholder or is it hidden
 somewhere.  Does gdc still need the code to set setup gc scanning?  How
 is TLS on OSX? - if not ready, would emutls work?
 --
 Dan


I hope I'm not shying you away by saying, this is what someone needs to
find out.

I'd first suggest to build gcc only and test what is outputted.  Use a test
program such as __thread int tls;  and a main program that sets it's value
to 0xdeadbeef then build with -S and check if the output shows calls to
emutls like functions.

GDC already has GC support for emutls, so the interesting part is if GCC
does native tls on osx.
Jun 06 2015
next sibling parent Dan Olson <gorox comcast.net> writes:
"Iain Buclaw via D.gnu" <d.gnu puremagic.com> writes:


 I hope I'm not shying you away by saying, this is what someone needs
 to find out.


No, not at all. I've gotten pretty used to puzzling through TLS
implementations for LDC porting.


 I'd first suggest to build gcc only and test what is outputted. Use a
 test program such as __thread int tls; and a main program that sets
 it's value to 0xdeadbeef then build with -S and check if the output
 shows calls to emutls like functions.

 GDC already has GC support for emutls, so the interesting part is if
 GCC does native tls on osx.


Yep, I'll try it.
Jun 06 2015
prev sibling parent reply Dan Olson <gorox comcast.net> writes:
"Iain Buclaw via D.gnu" <d.gnu puremagic.com> writes:


 On 5 June 2015 at 08:40, Dan Olson via D.gnu <d.gnu puremagic.com>
 wrote:

 Sorry for a long chain on OSX. But one last unresolved symbol from


 make

 check-d: "_d_osx_image_init". Is it just a placeholder or is it


 hidden

 somewhere. Does gdc still need the code to set setup gc scanning?


 How

 is TLS on OSX? - if not ready, would emutls work?
 --
 Dan


 I hope I'm not shying you away by saying, this is what someone needs
 to find out.

 I'd first suggest to build gcc only and test what is outputted. Use a
 test program such as __thread int tls; and a main program that sets
 it's value to 0xdeadbeef then build with -S and check if the output
 shows calls to emutls like functions.

 GDC already has GC support for emutls, so the interesting part is if
 GCC does native tls on osx.


GCC with vanilla configure is generating emutls calls for OSX.
Jun 06 2015
next sibling parent "Iain Buclaw via D.gnu" <d.gnu puremagic.com> writes:
On 6 June 2015 at 18:18, Dan Olson via D.gnu <d.gnu puremagic.com> wrote:


 "Iain Buclaw via D.gnu" <d.gnu puremagic.com> writes:


 On 5 June 2015 at 08:40, Dan Olson via D.gnu <d.gnu puremagic.com>
 wrote:

 Sorry for a long chain on OSX. But one last unresolved symbol from


 make

 check-d: "_d_osx_image_init". Is it just a placeholder or is it


 hidden

 somewhere. Does gdc still need the code to set setup gc scanning?


 How

 is TLS on OSX? - if not ready, would emutls work?
 --
 Dan


 I hope I'm not shying you away by saying, this is what someone needs
 to find out.

 I'd first suggest to build gcc only and test what is outputted. Use a
 test program such as __thread int tls; and a main program that sets
 it's value to 0xdeadbeef then build with -S and check if the output
 shows calls to emutls like functions.

 GDC already has GC support for emutls, so the interesting part is if
 GCC does native tls on osx.


 GCC with vanilla configure is generating emutls calls for OSX.


So, we can safely remove all references to _d_osx_image_init from
rt.memory, but keep the second version(OSX) as you don't want a static
assert. ;-)
Jun 06 2015
prev sibling parent "Iain Buclaw via D.gnu" <d.gnu puremagic.com> writes:
On 6 June 2015 at 18:33, Iain Buclaw <ibuclaw gdcproject.org> wrote:


 On 6 June 2015 at 18:18, Dan Olson via D.gnu <d.gnu puremagic.com> wrote:


 "Iain Buclaw via D.gnu" <d.gnu puremagic.com> writes:


 On 5 June 2015 at 08:40, Dan Olson via D.gnu <d.gnu puremagic.com>
 wrote:

 Sorry for a long chain on OSX. But one last unresolved symbol from


 make

 check-d: "_d_osx_image_init". Is it just a placeholder or is it


 hidden

 somewhere. Does gdc still need the code to set setup gc scanning?


 How

 is TLS on OSX? - if not ready, would emutls work?
 --
 Dan


 I hope I'm not shying you away by saying, this is what someone needs
 to find out.

 I'd first suggest to build gcc only and test what is outputted. Use a
 test program such as __thread int tls; and a main program that sets
 it's value to 0xdeadbeef then build with -S and check if the output
 shows calls to emutls like functions.

 GDC already has GC support for emutls, so the interesting part is if
 GCC does native tls on osx.


 GCC with vanilla configure is generating emutls calls for OSX.


 So, we can safely remove all references to _d_osx_image_init from
 rt.memory, but keep the second version(OSX) as you don't want a static
 assert. ;-)


But just to self reflect on that, maybe in it's place inline the old
memory_osx but with TLS sections/handling removed:
https://github.com/D-Programming-GDC/GDC/blob/0907d30b8a45036a7497d284d3210b899122cce6/libphobos/libdruntime/rt/memory_osx.d

Is probably something like this:  http://dpaste.dzfl.pl/e55824cab9c3
Jun 06 2015
prev sibling parent reply "Iain Buclaw via D.gnu" <d.gnu puremagic.com> writes:
On 5 Jun 2015 08:05, "Dan Olson via D.gnu" <d.gnu puremagic.com> wrote:

 Dan Olson <gorox comcast.net> writes:


 Looks like I need to track down missing symbols from rt.tlsgc now. I
 think it is becoming a fun puzzle :-) The arm stuff can wait.


 How do I tell gdc that OS X needs target specific underscore "_" prefix
 added to pragma(mangle, name)?  thread.d uses
 core.internal.traits.externDFunc.  That is cause.  For now I worked
 around with:

 pragma(mangle, "_"~mangleFunc!T(fqn)) mixin(decl);


That's interesting, it should do that for you automatically, there should
be only one reason why that doesn't happen, and I don't use it for pragma
mangle.
Jun 06 2015
parent reply Dan Olson <gorox comcast.net> writes:
"Iain Buclaw via D.gnu" <d.gnu puremagic.com> writes:


 On 5 Jun 2015 08:05, "Dan Olson via D.gnu" <d.gnu puremagic.com>
 wrote:

 That's interesting, it should do that for you automatically, there
 should be only one reason why that doesn't happen, and I don't use it
 for pragma mangle.


That is what I expected too based on previous digitalmars.D
thread when you described gdc mangle and mangleof.
Jun 06 2015
parent reply "Iain Buclaw via D.gnu" <d.gnu puremagic.com> writes:
On 6 June 2015 at 16:53, Dan Olson via D.gnu <d.gnu puremagic.com> wrote:


 "Iain Buclaw via D.gnu" <d.gnu puremagic.com> writes:


 On 5 Jun 2015 08:05, "Dan Olson via D.gnu" <d.gnu puremagic.com>
 wrote:

 That's interesting, it should do that for you automatically, there
 should be only one reason why that doesn't happen, and I don't use it
 for pragma mangle.


 That is what I expected too based on previous digitalmars.D
 thread when you described gdc mangle and mangleof.


Alas, after looking at backend, it turns out that the answer is no.

In the glue sources (d-decls.cc), replace 'set_user_assembler_name' with
'SET_DECL_ASSEMBLER_NAME' and rebuild the module without your workaround.

Regards
Iain.
Jun 06 2015
parent reply Dan Olson <gorox comcast.net> writes:
"Iain Buclaw via D.gnu" <d.gnu puremagic.com> writes:


 Alas, after looking at backend, it turns out that the answer is no.

 In the glue sources (d-decls.cc), replace 'set_user_assembler_name'
 with 'SET_DECL_ASSEMBLER_NAME' and rebuild the module without your
 workaround.


Ok, that works for data.  Functions (stuff in text section) still
missing _.  Is that handled by same function? (VarDeclaration::toSymbol)
Jun 06 2015
parent reply "Iain Buclaw via D.gnu" <d.gnu puremagic.com> writes:
On 6 June 2015 at 18:54, Dan Olson via D.gnu <d.gnu puremagic.com> wrote:


 "Iain Buclaw via D.gnu" <d.gnu puremagic.com> writes:


 Alas, after looking at backend, it turns out that the answer is no.

 In the glue sources (d-decls.cc), replace 'set_user_assembler_name'
 with 'SET_DECL_ASSEMBLER_NAME' and rebuild the module without your
 workaround.


 Ok, that works for data.  Functions (stuff in text section) still
 missing _.  Is that handled by same function? (VarDeclaration::toSymbol)



There are two uses of set_user_assembler_name in d-decls.cc.  One for
variables, the other for functions. ;-)
Jun 06 2015
parent reply Dan Olson <gorox comcast.net> writes:
"Iain Buclaw via D.gnu" <d.gnu puremagic.com> writes:


 On 6 June 2015 at 18:54, Dan Olson via D.gnu <d.gnu puremagic.com>
 wrote:

     "Iain Buclaw via D.gnu" <d.gnu puremagic.com> writes:
     
     > Alas, after looking at backend, it turns out that the answer is
     no.
     >
     > In the glue sources (d-decls.cc), replace
     'set_user_assembler_name'
     > with 'SET_DECL_ASSEMBLER_NAME' and rebuild the module without
     your
     > workaround.
     
     Ok, that works for data. Functions (stuff in text section) still
     missing _. Is that handled by same function?
     (VarDeclaration::toSymbol)
     

 There are two uses of set_user_assembler_name in d-decls.cc. One for
 variables, the other for functions. ;-)


Ooops.  Yeah that did it.  I'll try later this weekend to get working
with emutls and make pull requests for these.

Thanks for all the real-time help.

P.S. I am building against gcc-6-20150503 fine.  I tried gcc-6-20150531
yesterday and get ICE right away when compiling object_.d or
object.di, don't remember which.
-- 
Dan
Jun 06 2015
parent reply "Iain Buclaw via D.gnu" <d.gnu puremagic.com> writes:
On 6 June 2015 at 19:12, Dan Olson via D.gnu <d.gnu puremagic.com> wrote:


 "Iain Buclaw via D.gnu" <d.gnu puremagic.com> writes:


 On 6 June 2015 at 18:54, Dan Olson via D.gnu <d.gnu puremagic.com>
 wrote:

     "Iain Buclaw via D.gnu" <d.gnu puremagic.com> writes:

     > Alas, after looking at backend, it turns out that the answer is
     no.
     >
     > In the glue sources (d-decls.cc), replace
     'set_user_assembler_name'
     > with 'SET_DECL_ASSEMBLER_NAME' and rebuild the module without
     your
     > workaround.

     Ok, that works for data. Functions (stuff in text section) still
     missing _. Is that handled by same function?
     (VarDeclaration::toSymbol)


 There are two uses of set_user_assembler_name in d-decls.cc. One for
 variables, the other for functions. ;-)


 Ooops.  Yeah that did it.  I'll try later this weekend to get working
 with emutls and make pull requests for these.

 Thanks for all the real-time help.

 P.S. I am building against gcc-6-20150503 fine.  I tried gcc-6-20150531
 yesterday and get ICE right away when compiling object_.d or
 object.di, don't remember which.
 --
 Dan


I've only tested up to gcc-6-20150412, so YMMV on later snapshots.
Jun 06 2015
parent Dan Olson <gorox comcast.net> writes:
Seems to be working good now.  Unittests for druntime all pass so Fiber
switching code is working.  Unittests for phobos fails in biguintcore,
but I don't suppose that is an OS X specific thing.

Iain, I am going to make separate pull requests for each OS X topic
(fibers, symbol mangling, gc data scanning) unless you prefer in one.
Jun 07 2015
prev sibling parent ketmar <ketmar ketmar.no-ip.org> writes:
On Thu, 04 Jun 2015 06:49:00 -0700, Dan Olson wrote:


 ketmar <ketmar ketmar.no-ip.org> writes:
=20

 On Thu, 04 Jun 2015 00:15:37 -0700, Dan Olson wrote:


 Starting a pull request for ARM and grabbed gdc master, but not sure
 what gcc it likes.  I tried gcc-5.1 but
=20
 $ ./setup-gcc.sh ../gcc-5.1.0 found gcc version 5 This version of GCC
 (5) is not supported.


 make sure that you switched to 'gdc-5' branch.


=20
 Does gdc-5 get folded back into master then, isn't it a release branch?
 I assume pull requests should be based on master?


master is for upcoming gcc6.=
Jun 04 2015