Bug 1516 – Code generation bug with recursive call

the attached code compile and seg-vs the first time the function goes recursive. removing the notes lines from before the call fixes this. Also using "-O" fixes it. I suspect a issue with register selection because at the ASM level the differences seems to only be the choice of register. confirmed on Linux BTW, the when the code works it runs into a stack overflow because I skipped the terminal case in the function. That is Not the seg-v that is at issue.

umm, where's the "attached code" ^^ , hehe

Created attachment 184 the file a test case sorry I took so long. My browser took so long getting back to me I forgot to finish the post.

Reply to kris, > Bill Baxter wrote: > >> [email protected] wrote: >> >>> http://d.puremagic.com/issues/show_bug.cgi?id=1516 >>> >>> Summary: code gen bug with reclusive call >>> >> I don't think this word means what you think it means. :-) >> >> --bb >> > Yeah, I wondered about that too: has visions of cockroaches heading up > the hill to pay the hermits a visit > wouldn't it be the recluse making the call on the cockroaches? > :p >

Marking as invalid: you're using "r.users.length" when r is null. Change the condition within Part to "if (r && r.users.length == 0)" and it works.

Also this is a bug despite that because "-O" changes the behavior of the code. OTOH if what you are pointing to IS the issue, then there is another bug in that the first scope(failure) is ignored. In fact with a bit of checking, by dropping the nulls from the recursion, it seems that is the case. Alternately, it might still be a code gen issue, just fixed by another minor tweak. I'd have to look at the asm later. So, however you look at it, there is still a bug, just possibly not the but I originally saw. I'm reopening because it /might/ be a code gen bug. If someone can confirm it is not, Go ahead an close it again and I'll post another bug with regards to the "scope(failure) issue".

Woops, didn't notice the bit about -O. I would guess that -O realizes that the foreach loop does absolutely nothing and thus optimizes it away, but I can't be sure without checking the asm. Even if it's not that, it's a different issue, since the code here is correctly failing on a null pointer dereference. If you can reproduce the behaviour of -O with a loop which actually does something and shouldn't be optimized away, file another issue for that. Keeping this as INVALID.

Reply to [email protected], > Even if it's not that, it's a different issue, since the code here is > correctly failing on a null pointer dereference. I'm not shure that is where the seg-v is. But I'm to lazy to check right now.