Jump to content

  • Log In with Google      Sign In   
  • Create Account

Matias Goldberg

Member Since 02 Jul 2006
Offline Last Active Yesterday, 04:39 PM

Posts I've Made

In Topic: Problem with Constant Buffer Size.

Yesterday, 10:07 AM

The 48 bytes comes from a mistake in your C++ code, not in your HLSL code.

In Topic: Cache coherence and containers

21 September 2014 - 10:14 PM

std::map< int* > mymap;

That is not valid code. std::map requires a key and a value.

In Topic: Why does divison by 0 always result in negative NaN?

17 September 2014 - 02:29 PM

The C++ standard does not mandate that the IEEE standard should be used for floating point.

Case in point, the PS2 did not follow it and anything divided by 0 returned 0, even 0 / 0 (which was a nice property for normalizing vectors and quaternions without having to check for null length).


Perhaps it's unfortunate that the C++ std says "undefined behavior", instead of "implementation defined". But that's how it is.

If it were implementation defined, I would rest assured MSVC, GCC & Clang would compile my code fine in an x86 machine, because it follows the IEEE. But unfortunately, it's UB, not ID.


In real world though, I would be very mad if the compiler optimizes my UB code away without any warning because the amount of UB scenarios the C++ standard can have are gigantic, and mistakes like this happen every time.

The ever lasting struggle of compiler writers who want to take advantage of the UB for optimization and are very picky/elitist about following the Std; vs the average programmer who wants to develop a program that isn't broken by technicalities like this.

In Topic: GPU Perfstudio error

16 September 2014 - 06:09 PM

There is a hacked version of PIX to make it work on newer systems.

In Topic: Why does divison by 0 always result in negative NaN?

16 September 2014 - 06:07 PM

However, in general it's not true. At the risk of beating a dead horse by bringing up the same topic again as two weeks ago: No, the compiler, in general, cannot just do whatever it wants. If you divide some float by some other float, the compiler has to, and will, emit code that does just that.
Although it may, of course, add supplementary code to every division which checks whether the denominator is zero and calls an error handler (or similar), but it may not just do just about anything. That includes eliminating branches. Unless it can prove that the denominator will be zero at compile-time already, it may not optimize out code (or... format your hard disk tongue.png ).

I'm not sure what you mean.
The following snippet triggers UB:

int result = numerator / denominator;
if( denominator == 0 ) //UB: Denominator couldn't be 0 by now. Branch can be left out.
    result = 0;

float result = numerator / denominator;
if( denominator == 0 ) //UB: On architectures that don't follow IEEE, Denominator couldn't be 0 by now. Branch can be left out.
    result = 0.0f;
There has been way too many security bugs in real world code caused by optimizing compilers removing important pieces of code due to them being executed after invoking undefined behavior instead of being executed earlier.