On 03/31/2013 09:36 PM, Ján Veselý wrote: > Hi, > the memcpy optimisation was introduced in this commit: > http://gcc.gnu.org/viewcvs/gcc?view=revision&revision=188261 > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53081 > > I confirmed that adding -fno-tree-loop-distribute-patterns > makes helenos boot on amd64 (with bzr merge ./ -r1786..1783) > > builds that use -O2 -ftree-loop-distribute-patterns show the original problem
Thanks, this helped. I committed the fix to mainline,1789. Looks like there can be a problem with memmove() too. Jakub > > jan > > On Sun, Mar 31, 2013 at 7:06 PM, Jakub Jermar <[email protected]> wrote: >> On 03/31/2013 06:04 PM, Zbigniew Halas wrote: >>> I guess the first thing we should do is to investigate the mechanism of the >>> problem. And then if it's us misusing gcc we should fix it, otherwise we >>> should file a bug. >> >> Looks like Martin has already spent some time on it during the past two >> weeks. Could be that gcc with -ffreestanding assumes that it will not be >> compiling memcpy and memset because those are expected to be already >> available in the freestanding mode. It almost looks as if those >> functions were expected to be implemented in asm. We can have a similar >> issue with eg. memmove(). >> >>> I don't think it's an urgent issue, so we shouldn't make >>> any rapid moves to workaround it. I haven't had time to look at it, as I >>> want >>> to use my spare time now to finish Python port (or at least bring it to some >>> publishable state, which hopefully will happen tomorrow), but when I'm done >>> with it, I'm volunteering to investigate the issue in detail. >> >> It's a little bit urgent issue because currently half of the >> architectures are broken (the other was already fixed by providing asm >> implementations). Providing all the implementations in asm won't hurt, >> but is not the most convenient way of implementing memset and memcpy on >> earth. >> >>> Also is it about userland memcpy? If so I don't see it being defined in >>> terms >>> of __builtin_memcpy (just a quick grep, so I may be wrong). >> >> It's about boot, kernel and uspace memset and memcpy. The problem stays >> even when we keep -fno-builtin and remove the macros that define memcpy >> as __builitin_memcpy (and analogously for memset). >> >> Jakub >> >> >> _______________________________________________ >> HelenOS-devel mailing list >> [email protected] >> http://lists.modry.cz/cgi-bin/listinfo/helenos-devel > > _______________________________________________ > HelenOS-devel mailing list > [email protected] > http://lists.modry.cz/cgi-bin/listinfo/helenos-devel > _______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/cgi-bin/listinfo/helenos-devel
