<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-dev/include/asm-x86_64/string.h, branch master</title>
<subtitle>Linux kernel development work - see feature branches</subtitle>
<id>https://git.zx2c4.com/linux-dev/atom/include/asm-x86_64/string.h?h=master</id>
<link rel='self' href='https://git.zx2c4.com/linux-dev/atom/include/asm-x86_64/string.h?h=master'/>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/'/>
<updated>2007-10-11T09:20:03Z</updated>
<entry>
<title>i386/x86_64: move headers to include/asm-x86</title>
<updated>2007-10-11T09:20:03Z</updated>
<author>
<name>Thomas Gleixner</name>
<email>tglx@linutronix.de</email>
</author>
<published>2007-10-11T09:20:03Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=96a388de5dc53a8b234b3fd41f3ae2cedc9ffd42'/>
<id>urn:sha1:96a388de5dc53a8b234b3fd41f3ae2cedc9ffd42</id>
<content type='text'>
Move the headers to include/asm-x86 and fixup the
header install make rules

Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Signed-off-by: Ingo Molnar &lt;mingo@elte.hu&gt;
</content>
</entry>
<entry>
<title>x86_64: Always use builtin memcpy on gcc 4.3</title>
<updated>2007-07-22T01:37:08Z</updated>
<author>
<name>Andi Kleen</name>
<email>ak@suse.de</email>
</author>
<published>2007-07-21T15:09:58Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=aac57f81eb16d56afb5bd5a31ff325b5d1615580'/>
<id>urn:sha1:aac57f81eb16d56afb5bd5a31ff325b5d1615580</id>
<content type='text'>
Jan asked to always use the builtin memcpy on gcc 4.3 mainline because
it should generate better code than the old macro. Let's try it.

Cc: Jan Hubicka &lt;jh@suse.cz&gt;
Signed-off-by: Andi Kleen &lt;ak@suse.de&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
</entry>
<entry>
<title>[PATCH] x86_64: Use __always_inline for __inline_memcpy</title>
<updated>2006-06-26T17:48:14Z</updated>
<author>
<name>Andi Kleen</name>
<email>ak@suse.de</email>
</author>
<published>2006-06-26T11:56:07Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=79121ea9f098934850347eeed3857ffd836810c3'/>
<id>urn:sha1:79121ea9f098934850347eeed3857ffd836810c3</id>
<content type='text'>
Inspired from i386 changes

Signed-off-by: Andi Kleen &lt;ak@suse.de&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@osdl.org&gt;
</content>
</entry>
<entry>
<title>[PATCH] x86_64: Don't define string functions to builtin</title>
<updated>2006-03-25T17:10:53Z</updated>
<author>
<name>Andi Kleen</name>
<email>ak@suse.de</email>
</author>
<published>2006-03-25T15:29:49Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=6edfba1b33c701108717f4e036320fc39abe1912'/>
<id>urn:sha1:6edfba1b33c701108717f4e036320fc39abe1912</id>
<content type='text'>
gcc should handle this anyways, and it causes problems when
sprintf is turned into strcpy by gcc behind our backs and
the C fallback version of strcpy is actually defining __builtin_strcpy

Then drop -ffreestanding from the main Makefile because it isn't
needed anymore and implies -fno-builtin, which is wrong now.
(it was only added for x86-64, so dropping it should be safe)

Noticed by Roman Zippel

Cc: Roman Zippel &lt;zippel@linux-m68k.org&gt;
Signed-off-by: Andi Kleen &lt;ak@suse.de&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@osdl.org&gt;
</content>
</entry>
<entry>
<title>Linux-2.6.12-rc2</title>
<updated>2005-04-16T22:20:36Z</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@ppc970.osdl.org</email>
</author>
<published>2005-04-16T22:20:36Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=1da177e4c3f41524e886b7f1b8a0c1fc7321cac2'/>
<id>urn:sha1:1da177e4c3f41524e886b7f1b8a0c1fc7321cac2</id>
<content type='text'>
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.

Let it rip!
</content>
</entry>
</feed>
