aboutsummaryrefslogtreecommitdiffstats
path: root/fs/exofs
diff options
context:
space:
mode:
authorRichard Henderson <rth@redhat.com>2011-03-23 17:42:49 +0000
committerDavid Howells <dhowells@redhat.com>2011-03-23 17:42:49 +0000
commit5a4b65ab506398ba5a35c37e06edddd387cc0add (patch)
tree419fb3b0468f69922bf1a0c6023468ba53c4f608 /fs/exofs
parent1a8d59e529d07f7888f9c6c86a9f59ea4ef077aa (diff)
downloadkernel_samsung_smdk4412-5a4b65ab506398ba5a35c37e06edddd387cc0add.zip
kernel_samsung_smdk4412-5a4b65ab506398ba5a35c37e06edddd387cc0add.tar.gz
kernel_samsung_smdk4412-5a4b65ab506398ba5a35c37e06edddd387cc0add.tar.bz2
MN10300: gcc 4.6 vs am33 inline assembly
GCC 4.6 explicitly represents the MDR register. It may be accessed via the "z" constraint. Perhaps more importantly, it tracks when the MDR register is clobbered and uses the RETF instruction if the incoming value is still valid. Thus it is important to (at least) clobber the MDR register in relevant inline assembly fragments, lest RETF be used incorrectly. The only instances I could find are here. There are reads of the MDR register in kernel/gdb-stub.c, but that's harmless. Although, frankly, __builtin_return_address(0) might be a better thing in those cases. Certainly MDR isn't going to contain anything else that might be useful... Signed-off-by: Richard Henderson <rth@redhat.com> Signed-off-by: David Howells <dhowells@redhat.com>
Diffstat (limited to 'fs/exofs')
0 files changed, 0 insertions, 0 deletions