<oriansj>gbrlwck: the code is currently identical and unfortunately I don't know what zf->r means in this exact context; perhaps janneke should shed some light on it <siraben>There was some recent interest in Nix-land about reducing the bootstrap, it made me wonder if the most recent version of gcc can be boostrapped with stage0? <siraben>IIRC only up to the last version of GCC to not use C++ can be bootstrapped <fossy><siraben> There was some recent interest in Nix-land about reducing the bootstrap, it made me wonder if the most recent version of gcc can be boostrapped with stage0? <fossy>you go to gcc 4.7.4 and then to new <stikonas>so at least if you don't care about pre-generated files, then it should just work <stikonas>it's slightly more annoying if you want to rebuild top-level Makefile.in's in binutils and gcc <stikonas>those use autogen which is a bootstrap nightmare <stikonas>siraben: although, keep in mind that stage0-posix->gcc bootstrap is x86 only <gbrlwck>ok, i let that "we increase the stack pointer to allocate memory" sink in. only question: don't we need a SYS_brk or mmap/malloc to make sure we don't (accidentally) grow our stack into "foreign" memory? <stikonas>gbrlwck: SYS_brk is for heap allocations <stikonas>there is no need to call anything for stack <stikonas>I guess there is some bound set by the kernel <stikonas>but yes, if you try to use more than what is available you'll have stack overflow <stikonas>but we shouldn't hit recursion this deep in bootstrapping <gbrlwck>:) so, if i understand correctly: we increase the stack pointer a bunch to allocate space for local variables (for each function call). we decrease to stack pointer to store the variables. and a stack overflow would actually mean colliding with the process <oriansj>gbrlwck: by default the kernel will allocate 8KB for the stack, you can override that for larger values via: ulimit -s #### and what will stop it is an unallocated block of memory which the memory access will cause a page fault. Which the kernel will see the faulting instruction is a stack instruction and thus it was a stack fault <oriansj>the reason for updating the stack pointer is so that we don't trample the previous stack values until after we are done using them (for example after we returned back from a function call) <river>ok I will check the loop situtaion on meson and ninja this weekend ***stikonas_ is now known as stikonas