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 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
