[drivesoslow]

Cool, that is sort of good news. Can you generate a patch I can try?

[malloc]

why do you believe this is a rounding issue? what's your code look like so far? what did it look like before?

[davilla]

It's 100% in the rounding code, I have it narrowed down to needing a way to tell gcc NOT to optimize the damn fuction. What I have ATM actually works fine on 64bit debug/release and 32bit debug, but breaks to all hell 32bit release so is not an option.

I had same problem with OSX build, __volatile__ in the asm and volatile in the function defs is supposed to tell gcc not to optimize but it did not fix the issue. Ended up just going back to the original non-asm routines.

[malloc]

Why is gcc optimizing assembly code?

[althekiller]

Code:

inline int round_int (float x) {
  int i = 0;
  __asm__ __volatile__ (
      "fadd %%st\n\t"
      "fadd %%st(1)\n\t"
      "fistpl %0\n\t"
      "sarl $1, %0\n"
      : "=m"(i) : "f"(0.5), "f"(x)
  );
  return i;
}

The asm is fine, it works 100 when not inlined (defeats the purpose). The problems come when gcc optimizes the inlined code. I managed to get nearly everything working last night, with -O2 we also need -ffloat-store and -fno-gcse. There is still an instance (in CFreeTypeLibrary::LoadFont()) which is giving me trouble. I think gcc is swapping the load order of operands onto the fpu stack, so instead of doubling the float, adding 0.5 then storing as int and dividing by two; it's doubling 0.5, adding to the float, storing and dividing by two (the result is always half the input). If gcc 4.4 were out we'd be in business there's going to be an "optimize" attribute so we can just __attribute__((__optimize__("O0"))) in the function declaration and be done with the whole thing (I hope).

[malloc]

and how does this cause the gl viewport to be screwed up? have you looked into mmx or sse instructions? not dealing with the stack could make things easier.

[althekiller]

It never screwed with the viewport, merely screwed with the scaling do to the ordering of the operands on the stack.

I think I have it sorted now, there are constraints "t" and "u" that put operands in the top and second fpu stack elements respectively as apposed to "f" which is just _some_ fpu register. This cured my test prog on all optimization levels w/o screwing with removing optimizations. Testings with XBMC now...

[althekiller]

Ok tested working on both 32bit and 64bit, with both debug and release builds. Committed in r15213.

[drivesoslow]

Does this need and special CXXFLAGS or anything? I just checkout r15214 and did a

Code:

make clean

and a

Code:

make distclean

and then rebuilt it with the same weird scaling issue.

[althekiller]

No, make sure you're running the correct binary. If so try a "make reallyclean" and reconfigure (shouldn't be needed), then a full "make uninstall" and "make install".

[tslayer]

And then provide log so we can be sure you are at the correct rev.

[malloc]

Does it have the strange font scaling also or just the viewport scaling or both?

[drivesoslow]

Got it fixed. For some reasons running parallel jobs was not compiling a fresh xbmc.bin. So I stopped using 'make -j 2' and it made a fresh binary that works. Thanks for all the help.

[drivesoslow]

I should note that 'make -j 2' was not throwing an error about not compiling xbmc.bin either.

[malloc]

now i'm curious if this was actually fixed by something else. please let us know if you post your rpm's publicly so we can link to them (with your permission).