This wasn't on my own computer, so I didn't have time to build a patch, but I think my notes here should be enough to make one easily. The errant code is in the file work/xine-lib-1-rc3a/src/post/goom/zoom_filter_xmmx.c on line 123: "addl %0,%%ebx". gcc picked %xmm0, which (according to an as error) is invalid for the addl instruction. I don't have the details like gcc version, etc; all I know is that it was on an x86 architecture. In the .c file, operand %0 is specified as "X"(precalCoef). On a hunch, I changed it to "g"(precalCoef) and it compiled fine. I'm not sure if that's the best solution or not; I don't know much about recent (MMX and beyond) x86 architecture stuff. It may be best to bounce this off of the libxine guys. Sorry this PR is so sparse, but I hope there's enough here to get a resolution.
Responsible Changed From-To: freebsd-ports-bugs->nobutaka Over to maintainer.
Ran into exactly the same problem on my P4 on FreeBSD-CURRENT. After commenting out CPUTYPE=p4 in /etc/make.conf it compiled without any problems. Seems to be a gcc-related problem. Haven't tried other gcc versions(eg. 3.4) with CPUTYPE=p4 set, though. Hope this hint helps.
> Ran into exactly the same problem on my P4 on FreeBSD-CURRENT. After > commenting out CPUTYPE=p4 in /etc/make.conf it compiled without any > problems. Yes, since %xmm0 doesn't exist on (for instance) the 386, gcc won't try to use it without knowing the CPU type. > Seems to be a gcc-related problem. Well, only to a limited degree. The original code said, "use any register whatsoever", when it really wasn't built to allow absolutely any register whatsoever. It was the compiler that exposed the problem, but I wouldn't really consider it a gcc-related problem. Specifically, gcc is behaving appropriately, and doesn't need to be changed. joelh
State Changed From-To: open->closed Fixed, thanks!