I have been following this for a while, so maybe this helps you understand a 
bit better what you need to do.  While I respond to everything in your 
message, the important part is in the last two paragraphs.

> Nope, not all code can handle all levels of optimisations well. Lets
> assume, for the sake of argument, that Gcc 3.4.3 is stable, since we all
> use it ;).

Note that there are 166 bugs in 3.4.3 which were fixed in 3.4.4 alone.  Of 
course, if gcc is buggy or not has nothing to do with the problem at hand.

> Yet I know know numerous programs which can only be compiled
> using special flags, or without any Ox-flag at all.

Which is 99.9% of all cases indicates either a bug in the programs, the 
compiler performing certain optimizations or a user misunderstanding the 
proper configuration of compiler optimization options.  Of course, this also 
has nothing to do with the problem at hand.

> I did some physical modelling with a program called, p3d, which
> generated completely different results when compiled with different
> settings. This program too, like MegaPov, was dealing with floating
> numbers which could differ only in order of magnitude like 1e-7.
> Suddenly compiler option are not trivial anymore, although
> theoretically, it should be just fine.

Your statement, while being correct in the observation that certain compiler 
options may influence floating-point precision (for various reasons, non of 
which are bugs at all), has nothing to do with the problem at hand. In fact, 
it shows a clear misunderstanding of the nature of the problem.

> Always look in the mirror first. Especially if you compile with
> "-ffast-math". The compiler generates code which directly accesses the
> FPU to perform i.e sin,cos operations 

This is plain wrong, this is not what "-ffast-math" is about.  "-ffast-math" 
is nothing more than shortcut to enable various generally non-IEEE/ISO 
conforming floating-point optimizations (and the example you mention isn't 
one of them).  And it has, just like all the things you mentioned so far, 
nothing to do with the problem at hand.

> en there is no checking for NaN of
> Zero; this is responsibility of the programmer. Strange things can &
> will happen !!

Nothing strange can happen, the behavior is complete deterministic (except 
of certain generations of P1s, of course ;-) ) and completely predictable. 
And this also has nothing to do with the problem at hand.

> Anyway, interesting to see that all no-one (!) accepts the possibility
> that the MegaPov distribution could contain a error.

No, it is you who does not understand what many people have told you so far: 
  Somehow you have run into a dead end and are now pushing against a wall, 
not listing to anybody else who is trying to tell you to just turn around to 
get out of the deadened and find a solution to your problem ;-)

Nobody can reproduce your bug and you cannot expect help if you refuse to 
get a fixed kernel.  It has already been pointed out to you that you need to 
get a fixed kernel first.  A kernel panic isn't pov's fault no matter how 
you twist and turn it.

Once your kernel is fixed, one of two things can happen: Either MegaPOV 
works, or you get a reasonable crash of MegaPOV without a kernel panic.  In 
the former case you can just be happy, in the later you will need to come 
back with a bug report.  The neat thing is once your kernel no longer 
panics, and if there should indeed be a problem in MegaPOV, you can include 
a stack trace and other relevant information along with your report.

	Thorsten Froehlich, POV-Team

Post a reply to this message