www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - stops compiling

reply debugger <debugger_member pathlink.com> writes:
dmd 0.149,Win stops compiling without messsage if number of statements is too
large.

void init1(){}
void init2(){
init1();
// ... 16,000 times -> stops 
//     only 8,000 times -> compiles
init1();
}
void init3(){}

The effect can be seen with the -v option, because init4 does not get code
generated
Mar 18 2006
next sibling parent reply Thomas Kuehne <thomas-dloop kuehne.cn> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

debugger schrieb am 2006-03-19:
 dmd 0.149,Win stops compiling without messsage if number of statements is too
 large.

 void init1(){}
 void init2(){
 init1();
 // ... 16,000 times -> stops 
 //     only 8,000 times -> compiles
 init1();
 }
 void init3(){}

 The effect can be seen with the -v option, because init4 does not get code
 generated

I can't reproduce this. Are you sure the code above is complete (I see no "init4")? Thomas -----BEGIN PGP SIGNATURE----- iD8DBQFEH0jH3w+/yD4P9tIRApmUAJ9yw9hU7Cgqbi/Zq1yy1I7PxjzJ1gCfYede LCFszuRP2cCbmNa97H4wuW0= =BAB7 -----END PGP SIGNATURE-----
Mar 20 2006
next sibling parent reply Deewiant <deewiant.doesnotlike.spam gmail.com> writes:
Thomas Kuehne wrote:
 debugger schrieb am 2006-03-19:
 dmd 0.149,Win stops compiling without messsage if number of statements is too
 large.

 void init1(){}
 void init2(){
 init1();
 // ... 16,000 times -> stops 
 //     only 8,000 times -> compiles
 init1();
 }
 void init3(){}

 The effect can be seen with the -v option, because init4 does not get code
 generated


I can't reproduce this. Are you sure the code above is complete (I see no "init4")? Thomas

I think he typoed and was talking about init3, as that's the behaviour I get. I used code like this: void init1(){} void init2(){ // around 16 000 calls to init1() } void init3(){ printf("hello"); } void main() { init3(); } And nothing was printed when I ran the program - in fact, -v claimed that even main() had no code generated. Approximately halving the number of calls to init1() (I wasn't counting how many, just going by his approximate 16 and 8 thousand) made it work fine.
Mar 20 2006
parent reply Thomas Kuehne <thomas-dloop kuehne.cn> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Deewiant schrieb am 2006-03-21:
 Thomas Kuehne wrote:
 debugger schrieb am 2006-03-19:


[snip]
 I can't reproduce this. Are you sure the code above is complete
 (I see no "init4")?

I think he typoed and was talking about init3, as that's the behaviour I get. I used code like this: void init1(){} void init2(){ // around 16 000 calls to init1() } void init3(){ printf("hello"); } void main() { init3(); } And nothing was printed when I ran the program - in fact, -v claimed that even main() had no code generated. Approximately halving the number of calls to init1() (I wasn't counting how many, just going by his approximate 16 and 8 thousand) made it work fine.

Seems to be a Windows specific bug. Does http://dstress.kuehne.cn/run/m/many_functions_02.d show the same behaviour? Thomas -----BEGIN PGP SIGNATURE----- iD8DBQFEH90A3w+/yD4P9tIRAh54AJ4gBR3KCaNAXzxbG3ZpvqFe7Ph0tQCfQiBg thOuEeVNRR09uRqD22qbwhk= =B+ii -----END PGP SIGNATURE-----
Mar 21 2006
parent Deewiant <deewiant.doesnotlike.spam gmail.com> writes:
Thomas Kuehne wrote:
 Deewiant schrieb am 2006-03-21:
 Thomas Kuehne wrote:
 debugger schrieb am 2006-03-19:



[snip]
 I can't reproduce this. Are you sure the code above is complete
 (I see no "init4")?

used code like this: void init1(){} void init2(){ // around 16 000 calls to init1() } void init3(){ printf("hello"); } void main() { init3(); } And nothing was printed when I ran the program - in fact, -v claimed that even main() had no code generated. Approximately halving the number of calls to init1() (I wasn't counting how many, just going by his approximate 16 and 8 thousand) made it work fine.


Seems to be a Windows specific bug. Does http://dstress.kuehne.cn/run/m/many_functions_02.d show the same behaviour? Thomas

Yes, it does. D:\Main>dmd asdf.d -v parse asdf semantic many_functions_02 semantic2 many_functions_02 semantic3 many_functions_02 code many_functions_02 generating code for function 'init1' generating code for function 'init2' And no .exe is generated. In my previous post, I already had an old asdf.exe which is why "nothing was printed when I ran the program", instead of no program appearing there at all, like in this case.
Mar 21 2006
prev sibling parent debugger <debugger_member pathlink.com> writes:
In article <avt3f3-ode.ln1 birke.kuehne.cn>, Thomas Kuehne says...
I can't reproduce this. Are you sure the code above is complete
(I see no "init4")?

Seems, that D sources without UI calls, which are runnable under linux, have already lost there capability to be runnable under windows also. Have a good day.
Mar 24 2006
prev sibling parent reply "Walter Bright" <newshound digitalmars.com> writes:
"debugger" <debugger_member pathlink.com> wrote in message 
news:dvj2tg$2i3s$1 digitaldaemon.com...
 dmd 0.149,Win stops compiling without messsage if number of statements is 
 too
 large.

 void init1(){}
 void init2(){
 init1();
 // ... 16,000 times -> stops
 //     only 8,000 times -> compiles
 init1();
 }
 void init3(){}

It's a stack overflow in the compiler. No big deal, it'll be fixed in the next update. I kinda wonder, though, what purpose 16,000 statements serves?
Mar 22 2006
next sibling parent reply Kyle Furlong <kylefurlong gmail.com> writes:
Walter Bright wrote:
 "debugger" <debugger_member pathlink.com> wrote in message 
 news:dvj2tg$2i3s$1 digitaldaemon.com...
 dmd 0.149,Win stops compiling without messsage if number of statements is 
 too
 large.

 void init1(){}
 void init2(){
 init1();
 // ... 16,000 times -> stops
 //     only 8,000 times -> compiles
 init1();
 }
 void init3(){}

It's a stack overflow in the compiler. No big deal, it'll be fixed in the next update. I kinda wonder, though, what purpose 16,000 statements serves?

To try and make a perfect compiler of course! <g> Or did you just increase the stack size? Could I still smash it with say... a million statements?
Mar 22 2006
parent reply "Walter Bright" <newshound digitalmars.com> writes:
"Kyle Furlong" <kylefurlong gmail.com> wrote in message 
news:dvsp6s$23r8$10 digitaldaemon.com...
 To try and make a perfect compiler of course! <g> Or did you just increase 
 the stack size? Could I still smash it with say... a million statements?

No, I didn't increase the stack size. I put in an exception handler for the stack overflow exception. It still quits, it just gives a message first.
Mar 22 2006
next sibling parent Kyle Furlong <kylefurlong gmail.com> writes:
Brad Roberts wrote:
 On Wed, 22 Mar 2006, Walter Bright wrote:
 
 "Kyle Furlong" <kylefurlong gmail.com> wrote in message 
 news:dvsp6s$23r8$10 digitaldaemon.com...
 To try and make a perfect compiler of course! <g> Or did you just increase 
 the stack size? Could I still smash it with say... a million statements?

stack overflow exception. It still quits, it just gives a message first.

Did you check the results on linux? That sounds like you're catching a structured exception under windows that doesn't have an analog under any unix system. Too bad it's not actually making it so it's capable of handling a seriously long function.. in some auto-code generation scenarios this isn't that odd a case. I see it come up from time to time on the gcc developers list. Obviously, failing gracefully is better than failing catastrophically, but it's still failing. - Brad

I agree, what about the future, i.e. metaprogramming? I can also think of some reasons for having such a long function. Do templates also use such a statement stack?
Mar 23 2006
prev sibling parent "Walter Bright" <newshound digitalmars.com> writes:
"Brad Roberts" <braddr puremagic.com> wrote in message 
news:Pine.LNX.4.64.0603230012080.5795 bellevue.puremagic.com...
 On Wed, 22 Mar 2006, Walter Bright wrote:
 No, I didn't increase the stack size. I put in an exception handler for 
 the
 stack overflow exception. It still quits, it just gives a message first.

Did you check the results on linux? That sounds like you're catching a structured exception under windows that doesn't have an analog under any unix system.

Yes, that's exactly what's done. I don't know what the linux analog is.
 Too bad it's not actually making it so it's capable of handling a
 seriously long function.. in some auto-code generation scenarios this
 isn't that odd a case.  I see it come up from time to time on the gcc
 developers list.  Obviously, failing gracefully is better than failing
 catastrophically, but it's still failing.

The algorithms used in the compiler are fundamentally recursive, which means they use stack. I could bump up the stack, but then it's just a longer function that fails. The trouble is, you must decide *in advance* how much stack space to allocate (it's not like malloc/realloc). Once you run out, there's no recovery. The only thing to do is pick a reasonable size, that will cover all but extreme cases, and error out on the rest.
Mar 23 2006
prev sibling next sibling parent reply debugger <debugger_member pathlink.com> writes:
Walter Bright says...
It's a stack overflow in the compiler. No big deal, it'll be fixed in the 
next update. I kinda wonder, though, what purpose 16,000 statements serves? 

Wow, His Majesty is visiting the populace--and what seems He to be thinking: My bugs are manna for My choosen people, without Me they would starve in the desert. What is the reason to stack a sequence of statements---and what is the reason for the runtime, that seems to be quadratic in the number of statements within the analyzed function? No answers please, He is the almighty. 16,00 statemenst are too much? Forgive me Master, that was an inadequate try to initialize one of the prides of your creation, an associative array, with some 10,000 elements. Do not try to make Your novices convenient with your pride, You are almighty.
Mar 22 2006
next sibling parent "Regan Heath" <regan netwin.co.nz> writes:
On Thu, 23 Mar 2006 05:02:48 +0000 (UTC), debugger  
<debugger_member pathlink.com> wrote:

 Walter Bright says...
 It's a stack overflow in the compiler. No big deal, it'll be fixed in  
 the
 next update. I kinda wonder, though, what purpose 16,000 statements  
 serves?


<snip puerile garbage> Troll. Regan
Mar 22 2006
prev sibling parent reply "Unknown W. Brackets" <unknown simplemachines.org> writes:
I'm guessing it has to do with inlining or something similar where it's 
counting functions, but maybe I'm wrong.

Either way, 16,000 statements in the same scope are an obvious example 
of bad coding style ::).

And, my good sir, I strongly suggest you read this page:

http://redwing.hutman.net/~mreed/

Can you figure out which one you are :)?

-[Unknown]


 Walter Bright says...
 It's a stack overflow in the compiler. No big deal, it'll be fixed in the 
 next update. I kinda wonder, though, what purpose 16,000 statements serves? 

Wow, His Majesty is visiting the populace--and what seems He to be thinking: My bugs are manna for My choosen people, without Me they would starve in the desert. What is the reason to stack a sequence of statements---and what is the reason for the runtime, that seems to be quadratic in the number of statements within the analyzed function? No answers please, He is the almighty. 16,00 statemenst are too much? Forgive me Master, that was an inadequate try to initialize one of the prides of your creation, an associative array, with some 10,000 elements. Do not try to make Your novices convenient with your pride, You are almighty.

Mar 22 2006
parent reply debugger <debugger_member pathlink.com> writes:
In article <dvtehj$1pj$1 digitaldaemon.com>, Unknown W. Brackets says...
Either way, 16,000 statements in the same scope are an obvious example 
of bad coding style ::).

restriction. You have to code a script used by a generator that offers you three definition facilities: PRE, POST and ITEM and you must implement a sparsely populated function f from natural numbers to natural numbers. Where sparsely means at most 10,000,000 elements out of 4,000,000,000 possible elements and the values of the pairs for the function are given as $(x) and $(y) My _bad_ style looks like this: <script> PRE: define uint X; define uint Y; Y[X] f; void init( uint x, uint y){ f[cast(X)x]=cast(Y)y; } static this(){ POST: } ITEM: init($(x)u,$(y)u); </script> That are nine lines to understand and maintain. In case you will accept this invitation in addition to your coding solution I expect a sound argument, why your proposed _better_ coding style will spare a significant amount of maintenance man time. Otherwise it should be clear who of us is a warrior.
Mar 24 2006
next sibling parent BCS <BCS_member pathlink.com> writes:
load the data into an array and stream it into the AA at runtime.

uint[2][] foo =
[
[1,2],
[3,4],
[5,6],
...
];

uint[uint] f;
static this()
{
	foreach(uint a; foo)
		f[a[0]]=a[1];
}

pros:
	fewer function calls
	less code
	no scripting needed
	well maybe a bit of formatting, awk, sed or your scripting engine
	...


Before you say it, an array of struct could be used to make this work with any 
set of types.


<script>
PRE:
define uint X;
X[X] f;
static this()
{
	foreach(X a; foo)
		f[a[0]]=a[1];
}
uint[2][] foo = [
POST:
];
ITEM:
[$(x)u,$(y)u],
</script>



debugger wrote:
 In article <dvtehj$1pj$1 digitaldaemon.com>, Unknown W. Brackets says...
 
Either way, 16,000 statements in the same scope are an obvious example 
of bad coding style ::).

I invite you to describe your _better_ coding style under aproximately following restriction. You have to code a script used by a generator that offers you three definition facilities: PRE, POST and ITEM and you must implement a sparsely populated function f from natural numbers to natural numbers. Where sparsely means at most 10,000,000 elements out of 4,000,000,000 possible elements and the values of the pairs for the function are given as $(x) and $(y) My _bad_ style looks like this: <script> PRE: define uint X; define uint Y; Y[X] f; void init( uint x, uint y){ f[cast(X)x]=cast(Y)y; } static this(){ POST: } ITEM: init($(x)u,$(y)u); </script> That are nine lines to understand and maintain. In case you will accept this invitation in addition to your coding solution I expect a sound argument, why your proposed _better_ coding style will spare a significant amount of maintenance man time. Otherwise it should be clear who of us is a warrior.

Mar 24 2006
prev sibling parent "Unknown W. Brackets" <unknown simplemachines.org> writes:
That's just bad design.  I thought they still taught basic looping and 
scripting in schools these days.

But, in the end, you'll have to understand that being "a warrior" on the 
internet is not a good thing.  Instead, I much prefer to have pleasant 
working relationships with people.

I understand if you prefer to fight, and to argue.  But I'm just not 
interested in arguing with people like you.  Especially since you, as 
much posturing as you may go through, don't sound like someone I would 
contract work out to.

But, really, I mean no offense by that comment.  I'm sure you're a 
reasonable guy, and just don't like dealing with us "open source types." 
  And that is, of course, your right.

-[Unknown]


 In article <dvtehj$1pj$1 digitaldaemon.com>, Unknown W. Brackets says...
 Either way, 16,000 statements in the same scope are an obvious example 
 of bad coding style ::).

restriction. You have to code a script used by a generator that offers you three definition facilities: PRE, POST and ITEM and you must implement a sparsely populated function f from natural numbers to natural numbers. Where sparsely means at most 10,000,000 elements out of 4,000,000,000 possible elements and the values of the pairs for the function are given as $(x) and $(y) My _bad_ style looks like this: <script> PRE: define uint X; define uint Y; Y[X] f; void init( uint x, uint y){ f[cast(X)x]=cast(Y)y; } static this(){ POST: } ITEM: init($(x)u,$(y)u); </script> That are nine lines to understand and maintain. In case you will accept this invitation in addition to your coding solution I expect a sound argument, why your proposed _better_ coding style will spare a significant amount of maintenance man time. Otherwise it should be clear who of us is a warrior.

Mar 24 2006
prev sibling parent Brad Roberts <braddr puremagic.com> writes:
On Wed, 22 Mar 2006, Walter Bright wrote:

 "Kyle Furlong" <kylefurlong gmail.com> wrote in message 
 news:dvsp6s$23r8$10 digitaldaemon.com...
 To try and make a perfect compiler of course! <g> Or did you just increase 
 the stack size? Could I still smash it with say... a million statements?

No, I didn't increase the stack size. I put in an exception handler for the stack overflow exception. It still quits, it just gives a message first.

Did you check the results on linux? That sounds like you're catching a structured exception under windows that doesn't have an analog under any unix system. Too bad it's not actually making it so it's capable of handling a seriously long function.. in some auto-code generation scenarios this isn't that odd a case. I see it come up from time to time on the gcc developers list. Obviously, failing gracefully is better than failing catastrophically, but it's still failing. - Brad
Mar 23 2006