Re: [alsa-devel] [PATCH] ASoC: prevent compilers from optimising pll calculation into __aeabi__uldivmod
2011/4/27 Mark Brown broonie@opensource.wolfsonmicro.com
On Wed, Apr 27, 2011 at 04:50:12PM +0800, Barry Song wrote:
Marking pll_factors() as noinline or putting asm("" : "+r"(source)); before the call to do_div() works around the problem.
If we do have to do something in the callers rather than in do_div() the annotation seems substantially more taseful than inserting a random asm into the code.
I agree. for this patch which will not be applied, people can just get information about how to workaround the gcc issue while they have the same problem. google can find there are other people who failed to compile wm8974 module too. eg. http://irclogs.ubuntu.com/2010/03/30/%23ubuntu-arm.txt
Andrew Stubbs, Michael Hope in Linaro's toolchain team are working hard on this gcc issue. there have been many update today: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48783
On Wed, Apr 27, 2011 at 11:00:18PM +0800, Barry Song wrote:
2011/4/27 Mark Brown broonie@opensource.wolfsonmicro.com
If we do have to do something in the callers rather than in do_div() the annotation seems substantially more taseful than inserting a random asm into the code.
I agree. for this patch which will not be applied, people can just get information about how to workaround the gcc issue while they have the same problem. google can find there are other people who failed to compile wm8974 module too. eg. http://irclogs.ubuntu.com/2010/03/30/%23ubuntu-arm.txt
Andrew Stubbs, Michael Hope in Linaro's toolchain team are working hard on this gcc issue. there have been many update today: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48783
Is this just some Linaro toolchain that has the issue rather than a vanilla GCC release? If so and they fix the compiler bug it doesn't seem terribly useful to bodge it in mainline.
2011/4/27 Mark Brown broonie@opensource.wolfsonmicro.com:
On Wed, Apr 27, 2011 at 11:00:18PM +0800, Barry Song wrote:
2011/4/27 Mark Brown broonie@opensource.wolfsonmicro.com
If we do have to do something in the callers rather than in do_div() the annotation seems substantially more taseful than inserting a random asm into the code.
I agree. for this patch which will not be applied, people can just get information about how to workaround the gcc issue while they have the same problem. google can find there are other people who failed to compile wm8974 module too. eg. http://irclogs.ubuntu.com/2010/03/30/%23ubuntu-arm.txt
Andrew Stubbs, Michael Hope in Linaro's toolchain team are working hard on this gcc issue. there have been many update today: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48783
Is this just some Linaro toolchain that has the issue rather than a vanilla GCC release? If so and they fix the compiler bug it doesn't seem terribly useful to bodge it in mainline.
i am guessing it is a generic gcc issue since Michael posted it at http://gcc.gnu.org/bugzilla not Linaro's Launchpad. not sure :-)
2011/4/27 Barry Song 21cnbao@gmail.com:
2011/4/27 Mark Brown broonie@opensource.wolfsonmicro.com:
On Wed, Apr 27, 2011 at 11:00:18PM +0800, Barry Song wrote:
2011/4/27 Mark Brown broonie@opensource.wolfsonmicro.com
If we do have to do something in the callers rather than in do_div() the annotation seems substantially more taseful than inserting a random asm into the code.
I agree. for this patch which will not be applied, people can just get information about how to workaround the gcc issue while they have the same problem. google can find there are other people who failed to compile wm8974 module too. eg. http://irclogs.ubuntu.com/2010/03/30/%23ubuntu-arm.txt
Andrew Stubbs, Michael Hope in Linaro's toolchain team are working hard on this gcc issue. there have been many update today: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48783
Is this just some Linaro toolchain that has the issue rather than a vanilla GCC release? If so and they fix the compiler bug it doesn't seem terribly useful to bodge it in mainline.
i am guessing it is a generic gcc issue since Michael posted it at http://gcc.gnu.org/bugzilla not Linaro's Launchpad. not sure :-)
Linaro doesn't exist yet when the discussion happened at http://irclogs.ubuntu.com/2010/03/30/%23ubuntu-arm.txt discussion:
" [19:03] <nosse1> I got this while compiling: "ERROR: "__aeabi_uldivmod" [sound/soc/codecs/snd-soc-wm8974.ko] undefined!" [19:04] <nosse1> Now, I can disable the driver alltogether, but is this related to the CSL cross compiler? [19:04] <hrw> nosse1: google should give answer - common problem it was [19:04] <nosse1> hehe - sorry, you're right "
Hi Mark. The fault exists in FSF GCC 4.5.2 and Linaro GCC 4.5-2011.04. The fault does not exist in FSF GCC 4.6.0 or Linaro GCC 4.6-2011.04.
-- Michael
On Thu, Apr 28, 2011 at 3:12 AM, Mark Brown broonie@opensource.wolfsonmicro.com wrote:
On Wed, Apr 27, 2011 at 11:00:18PM +0800, Barry Song wrote:
2011/4/27 Mark Brown broonie@opensource.wolfsonmicro.com
If we do have to do something in the callers rather than in do_div() the annotation seems substantially more taseful than inserting a random asm into the code.
I agree. for this patch which will not be applied, people can just get information about how to workaround the gcc issue while they have the same problem. google can find there are other people who failed to compile wm8974 module too. eg. http://irclogs.ubuntu.com/2010/03/30/%23ubuntu-arm.txt
Andrew Stubbs, Michael Hope in Linaro's toolchain team are working hard on this gcc issue. there have been many update today: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48783
Is this just some Linaro toolchain that has the issue rather than a vanilla GCC release? If so and they fix the compiler bug it doesn't seem terribly useful to bodge it in mainline.
linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
On Thu, Apr 28, 2011 at 10:30:24AM +1200, Michael Hope wrote:
Don't top post!
Hi Mark. The fault exists in FSF GCC 4.5.2 and Linaro GCC 4.5-2011.04. The fault does not exist in FSF GCC 4.6.0 or Linaro GCC 4.6-2011.04.
Given that nobody's reported it previously and there's already a new GCC release I'm not sure it's worth worry about - it's a fairly clear compiler bug.
linaro-toolchain@lists.linaro.org
-
Barry Song -
Mark Brown -
Michael Hope