Created attachment 308709 [details] emerge --info media-video/ffmpeg-0.10.2 fails to compile with gcc-4.5.3 on x86 with: In file included from libavcodec/cabac.c:32:0: libavcodec/cabac_functions.h: In function ‘get_cabac_noinline’: libavcodec/x86/cabac.h:93:5: error: can't find a register in class ‘GENERAL_REGS’ while reloading ‘asm’ libavcodec/x86/cabac.h:93:5: error: ‘asm’ operand has impossible constraints The problematic part of code is: static av_always_inline int get_cabac_inline_x86(CABACContext *c, uint8_t *const state) { int bit, tmp; __asm__ volatile( BRANCHLESS_GET_CABAC("%0", "(%5)", "%1", "%w1", "%2", "%3", "%b3", "%4") :"=&r"(bit), "+&r"(c->low), "+&r"(c->range), "=&q"(tmp), "+m"(c->bytestream) :"r"(state) : "%"REG_c, "memory" ); return bit & 1; } This bug is very much resembling the following https://bugs.gentoo.org/show_bug.cgi?id=71360 According to the upstream FAQ (see doc/faq.texi:71), this is a known bug in gcc: @chapter Compilation @section @code{error: can't find a register in class 'GENERAL_REGS' while reloading 'asm'} This is a bug in gcc. Do not report it to us. Instead, please report it to the gcc developers. Note that we will not add workarounds for gcc bugs. Also note that (some of) the gcc developers believe this is not a bug or not a bug they should fix: @url{http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11203}. Then again, some of them do not know the difference between an undecidable problem and an NP-hard problem... As a minor note, the compiler issues a lot of "Warning: missing operand; zero assumed" messages for apparently clean assembly code.
Please attach the entire build log to this bug report.
Created attachment 308935 [details] build.log Jeroen, here you are. My CPU (since -march=native): >cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Core(TM)2 Duo CPU T5670 @ 1.80GHz stepping : 13 microcode : 0xa3 cpu MHz : 1200.000 cache size : 2048 KB physical id : 0 siblings : 2 core id : 0 cpu cores : 2 apicid : 0 initial apicid : 0 fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc arch_perfmon pebs bts aperfmperf pni dtes64 monitor ds_cpl est tm2 ssse3 cx16 xtpr pdcm lahf_lm ida dts bogomips : 3590.47 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: <SNIP>
CFLAGS="-combine -march=native -O2 -pipe -fomit-frame-pointer -finline-functions-called-once -ftree-vectorize -funroll-loops" please try with sane cflags first esp. whats this -combine cflag ?
(In reply to comment #3) > CFLAGS="-combine -march=native -O2 -pipe -fomit-frame-pointer > -finline-functions-called-once -ftree-vectorize -funroll-loops" > > please try with sane cflags first > > esp. whats this -combine cflag ? Alexis, sorry about forgetting to mention this at first. I tried it even before reporting the bug. I also tried with just "-O2" and "-O0" and even without passing any flags, among others. I also tried -march=generic, which theoretically might change the size of the coloring problem. The -combine flag enables IMO. For a well-formed program, if a build system supplies several filenames at once to the compiler, it may result in additional optimizations. Programs which violate the ODR may not compile (but they are not expected to, anyway). Besides that I don't see this flag insane, this flag has nothing to do with this (register allocation) problem, at least because files are supplied one by one by the make system.
(In reply to comment #4) > (In reply to comment #3) > > CFLAGS="-combine -march=native -O2 -pipe -fomit-frame-pointer > > -finline-functions-called-once -ftree-vectorize -funroll-loops" > > > > please try with sane cflags first > > > > esp. whats this -combine cflag ? > > Alexis, sorry about forgetting to mention this at first. I tried it even > before reporting the bug. I also tried with just "-O2" and "-O0" and even > without passing any flags, among others. I also tried -march=generic, which > theoretically might change the size of the coloring problem. > > The -combine flag enables IMO. For a well-formed program, if a build system > supplies several filenames at once to the compiler, it may result in > additional optimizations. Programs which violate the ODR may not compile > (but they are not expected to, anyway). Besides that I don't see this flag > insane, this flag has nothing to do with this (register allocation) problem, > at least because files are supplied one by one by the make system. ok, i asked about that flag because i didnt know about it. ftree-vectorize and funroll-loops were the ones i called 'not sane' :) please go to ffmpeg build dir and type 'make V=1' to get the exact compiler line executed and making the build fail.
(In reply to comment #4) > The -combine flag enables IMO. For a well-formed program, if a build system > supplies several filenames at once to the compiler, it may result in > additional optimizations. Programs which violate the ODR may not compile > (but they are not expected to, anyway). Besides that I don't see this flag > insane, this flag has nothing to do with this (register allocation) problem, > at least because files are supplied one by one by the make system. btw: $ gcc --version gcc (Gentoo 4.6.2 p1.4, pie-0.5.0) 4.6.2 $ gcc -combine gcc: error: unrecognized option ‘-combine’
Alexis, shame on me! I am closing this bug as INVALID. The culprit was that I made a typo in one rsync cron job and managed by mistake to rsync /etc/portage/env from a machine with a different (64-bit) architecture, which contained some settings and workarounds aimed at a specific Family/Stepping of Opteron processor from a host where this was important. Shame, shame! I am sorry about creating so much unnecessary noise!
