vielleicht kann irgendjemand foldende information verarbeiten...


aktueller C++-Compiler mitunter fehlerhafte Kompilate. Der Raytracer Povray 


der komplette artikel findet sich bei Heise unter:

http://www.heise.de/newsticker/data/hes-11.11.01-000/

Post a reply to this message

I don't like the sound of what Altavista just translated that to...

Post a reply to this message

On Mon, 12 Nov 2001 12:29:03 -0500, "Tony[B]" <ben### [at] catholicorg> wrote:

> I don't like the sound of what Altavista just translated that to...

As I understand (but mostly I don't understend) there is something wrong with
Intel compiler. It produces wrong image for POV 3.1 (I recognized 3.1 becose no
switch line within bar). But I wonder - could it be bug within POV not within
compiler? How they verified this? There is always possibility of bug in POV (but
I hope not).

ABX
--
#declare _=function(a,b,x){((a^2)+(b^2))^.5-x}#default {pigment{color rgb 1}}
union{plane{y,-3}plane{-x,-3}finish{reflection 1 ambient 0}}isosurface{ //ABX
function{_(x-2,y,1)|_((x+y)*.7,z,.1)|_((x+y+2)*.7,z,.1)|_(x/2+y*.8+1.5,z,.1)}
contained_by{box{<0,-3,-.1>,<3,0,.1>}}translate z*15finish{ambient 1}}//POV35

Post a reply to this message

<6k10vtknk68m8lht0gotvc0noqvjlrf7sm@4ax.com>...
>On Mon, 12 Nov 2001 12:29:03 -0500, "Tony[B]" <ben### [at] catholicorg> wrote:
>
>> I don't like the sound of what Altavista just translated that to...
>
>As I understand (but mostly I don't understend) there is something wrong
with
>Intel compiler. It produces wrong image for POV 3.1 (I recognized 3.1
becose no
>switch line within bar).

They say, it produces wrong code if you use -ipo (inter procedural
optimization). This way, some subroutines are not called as procedures
(call/return), but are inserted directly in the code. This fails in some
cases, as in Pov. And even if it might be faster in some cases, it should be
avoided, esp. as the compiler produces fast code even without that switch.

> But I wonder - could it be bug within POV not within
>compiler? How they verified this? There is always possibility of bug in POV
(but
>I hope not).

I think they took to versions of Pov, one with -ipo one w/o. As the later
renders the scene correct, but that one with -ipo does not, isn't it obvious
that the compiler switch is responsible?

Marc-Hendrik

Post a reply to this message

Marc-Hendrik Bremer wrote:
[...]
> 
> They say, it produces wrong code if you use -ipo (inter procedural
> optimization). This way, some subroutines are not called as procedures
> (call/return), but are inserted directly in the code. This fails in some
> cases, as in Pov. And even if it might be faster in some cases, it should
> be avoided, esp. as the compiler produces fast code even without that
> switch.

it does not fail every time you render scenes with Intel-compiled POVRay. 
in some pictures it is possible that scenes are wrong-colored.

Post a reply to this message

marabou schrieb in Nachricht <3bf01e2b@news.povray.org>...

>it does not fail every time you render scenes with Intel-compiled POVRay.
>in some pictures it is possible that scenes are wrong-colored.


Yes, but it seems to be reproducible for a scenefile. I.e. if you get a
wrong colored picture once you get it always - that's at least how I
understand it.

Marc-Hendrik

Post a reply to this message

On Mon, 12 Nov 2001 22:40:57 +0100, "Marc-Hendrik Bremer"
<Mar### [at] t-onlinede> wrote:

> marabou schrieb in Nachricht <3bf01e2b@news.povray.org>...
>
> >it does not fail every time you render scenes with Intel-compiled POVRay.
> >in some pictures it is possible that scenes are wrong-colored.
>
> Yes, but it seems to be reproducible for a scenefile. I.e. if you get a
> wrong colored picture once you get it always - that's at least how I
> understand it.

if the behaviour is reproduced with other software then it could be compiler, if
it wasn't reproduced who knows where is bug ?

ABX
--
#declare _=function(a,b,x){((a^2)+(b^2))^.5-x}#default {pigment{color rgb 1}}
union{plane{y,-3}plane{-x,-3}finish{reflection 1 ambient 0}}isosurface{ //ABX
function{_(x-2,y,1)|_((x+y)*.7,z,.1)|_((x+y+2)*.7,z,.1)|_(x/2+y*.8+1.5,z,.1)}
contained_by{box{<0,-3,-.1>,<3,0,.1>}}translate z*15finish{ambient 1}}//POV35

Post a reply to this message

Skiba <abx### [at] babilonorg>  wrote:

> if the behaviour is reproduced with other software then it could be compiler,
> if it wasn't reproduced who knows where is bug ?

What kind of logic is that?  The probability that any other program will
also change the color output in the same way POV-Ray does (provided the
program has not at least been derived from the POV-Ray source code) is zero.

    Thorsten

Post a reply to this message

On Tue, 13 Nov 2001 13:54:53 +0100, "Thorsten Froehlich" <tho### [at] trfde>
wrote:

>> if the behaviour is reproduced with other software then it could be compiler,
>> if it wasn't reproduced who knows where is bug ?
>
> What kind of logic is that?  The probability that any other program will
> also change the color output in the same way POV-Ray does (provided the
> program has not at least been derived from the POV-Ray source code) is zero.

I'm not talking about result "changing of color". I talk about result "not
expected". Perhaps wrong meaning is result of my english. If my affraid is not
logic why in beta-testing should we add compiler version in reports? Are there
bugs showed by intel compiler not visible before?

ABX
--
#declare _=function(a,b,x){((a^2)+(b^2))^.5-x}#default {pigment{color rgb 1}}
union{plane{y,-3}plane{-x,-3}finish{reflection 1 ambient 0}}isosurface{ //ABX
function{_(x-2,y,1)|_((x+y)*.7,z,.1)|_((x+y+2)*.7,z,.1)|_(x/2+y*.8+1.5,z,.1)}
contained_by{box{<0,-3,-.1>,<3,0,.1>}}translate z*15finish{ambient 1}}//POV35

Post a reply to this message