On Mon, Sep 26, 2011 at 08:41:13AM -0400, Chris Ball wrote: > Hi, > > On Mon, Sep 26 2011, Uwe Kleine-König wrote: > >> Thanks, pushed to mmc-next for 3.2 with a reworded commit message: > > This (i.e. ee9e0e0 (mmc: card: Remove duplicated constants) in next) > > makes gcc emit a reference to __aeabi_uldivmod in one of my nightly > > builds which isn't defined. > > > > The final linking stage fails with: > > > > LD .tmp_vmlinux1 > > drivers/built-in.o: In function `mmc_blk_getgeo': > > clkdev.c:(.text+0xd1528): undefined reference to `__aeabi_uldivmod' > > make[2]: *** [.tmp_vmlinux1] Error 1 > > make[1]: *** [sub-make] Error 2 > > make: *** [all] Error 2 > > Interesting, thanks. It builds fine here on my (gcc-4.6) ARM toolchains. > Looking online, I think you're hitting an old gcc-4.3 bug? Check your setting of CONFIG_LBDAF - the return type from get_capacity depends on this (which may be either unsigned long or u64). Now, the thing about a constant division by (16*4) is that its relatively easy for gcc to spot that this is the same as a shift - and use a shift instead of a divide for both the unsigned long and u64 cases. However, the change may result in gcc no longer realizing that it's a constant division by a power-of-2, and that optimization can be applied. If you want to eliminate these constants, I'd suggest two definitions MMC_GEO_SECTORS MMC_GEO_HEADS and just subsituting the '4' and '16' in the function with the appropriate symbolic constants. That'd avoid causing this regression. -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html