Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Mar 03 2017 15:52
    @dom96 banned @Octopoda7
  • Feb 12 2017 23:57
    @dom96 banned @zzz125
  • Dec 23 2016 19:43
    @dom96 banned @Izrab
Alexander Ivanov
@alehander92
narimiran oh nice
From IRC (bridge bot)
@FromIRC
<disruptek> if i showed you a scenario where it resulted in more efficient code, you'd consider it?
Alexander Ivanov
@alehander92
yeah cross compiling is cool
i have to try and see my problems .. i found it hard to cross compile nim to i386 because i somehow confused my 386 packages install
should this be something very simple
From IRC (bridge bot)
@FromIRC
<shashlick> well, all you really need to do is set export CC=musl-gcc -static
<shashlick> @kaushalmodi did a bunch of work on this with his config.nims
<shashlick> but i'm wondering if we can make this the defacto and not depend on libc
<shashlick> but one problem is that all dependencies also need to be compiled this way
Alexander Ivanov
@alehander92
hmmm
i actually dont need libc
From IRC (bridge bot)
@FromIRC
<disruptek> yeah, for good reason.
Alexander Ivanov
@alehander92
as i want to cross compile to bare metal program for qemu
so i have my own "libc" stub
From IRC (bridge bot)
@FromIRC
<shashlick> well, maybe not - if you link to a dep that uses libc, it should work as long as libc is present right?
<disruptek> need weak refs
<shashlick> yep csources compiled with musl-gcc
Alexander Ivanov
@alehander92
no idea, my programs should really use only the "standalone" parts
From IRC (bridge bot)
@FromIRC
<shashlick> okay koch builds
<shashlick> but koch doesn't have a way to set --gcc.exe, etc.
From IRC (bridge bot)
@FromIRC
<lesshaste> hi all
<FromDiscord> <Clyybber> heh, now that scenario
<FromDiscord> <Clyybber> I wonna see it
<FromDiscord> <Clyybber> since I find while else to be exceptionally ambiguous
Kaushal Modi
@kaushalmodi

shasklick:

is there interest in having musl-gcc as a tested backend for Nim

Yes!

From IRC (bridge bot)
@FromIRC
<shashlick> okay looks like bootstrap fails
<shashlick> undefined references to ___memcpy_chk_
<shashlick> sprintf_chk and longjmp_check
<disruptek> clyybber: it's an additional scope, you know.
From IRC (bridge bot)
@FromIRC
<lesshaste> what's the status of loop vectorization in nim?
<FromDiscord> <mratsim> what do you want to do/know?
<FromDiscord> <mratsim> it's basically the same as GCC/Clang though you can easily vectorize manually as well
<disruptek> clyybber: what was the idea behind having normal/sinkArg modes?
From IRC (bridge bot)
@FromIRC
<FromDiscord> <mratsim> I have a vectorization template here: https://github.com/numforge/laser/blob/master/laser/lux_compiler/backend/legacy/lux_codegen_transfo.nim#L244-L281 (and a tentative vectorization pass in a linear algebra/HPC/Deep Learning compiler)
<disruptek> is it just an artifact of refactoring?
<Araq> disruptek, well sinkArg means "passed to a sink parameter"
From IRC (bridge bot)
@FromIRC
<Araq> and normal means "normal"
<shashlick> okay got nim compiled but setting gcc.options.linker = "-static" doesn't work
<disruptek> yeah, i get it. but this proc could be broken up; it's just if ... else ... iirc
<shashlick> had to manually --passL:-static
<disruptek> why aren't obj constructors processed by handleNested?
<Araq> because.
<Araq> what bug are you trying to fix, disruptek ?
From IRC (bridge bot)
@FromIRC
<disruptek> yield foo(discriminator: ..., objref: ...) is destroying objref twice.
<disruptek> objref is from the enclosing scope.
<Araq> is it a .closure iterator?
<disruptek> nah.
<Araq> hmm ok
From IRC (bridge bot)
@FromIRC
<disruptek> makes sense, right?
<FromDiscord> <Clyybber> disruptek: handleNested handles the boring recursion