Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Apr 04 12:26
    @dom96 banned @acroobat
  • 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
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
<FromDiscord> <Clyybber> in stmtlists and such
<FromDiscord> <Clyybber> disruptek: Does it work when you make the return type lent?
<disruptek> no.
<FromDiscord> <Clyybber> actually destroying objref shouldn't hurt
<FromDiscord> <Clyybber> because its refcounted
<FromDiscord> <Clyybber> It shouldn't double free because of that
From IRC (bridge bot)
@FromIRC
<disruptek> bugs begin in the unfortunately state of implemented.
<disruptek> the way it works is, if we sink foo(), we destroy foo.objref.
<FromDiscord> <Clyybber> what?
<FromDiscord> <Clyybber> only if we sink to foo.objref
<FromDiscord> <Clyybber> is the code to reproduce the same as in your issue?
From IRC (bridge bot)
@FromIRC
<FromDiscord> <Clyybber> and if so which snippet, the first or the second?