[PATCH v2 0/3] x86: Fix a F00F bug warning and cleanup surrounding code

[PATCH v2 0/3] x86: Fix a F00F bug warning and cleanup surrounding code

[Sohil Mehta]

This is an iteration of the series posted earlier by Richard Weinberger.
https://lore.kernel.org/lkml/20260216104343.3625292-1-richard@nod.at/

The patches primarily fix a harmless "alternatives_patched" warning that
affects the original Pentium (Family 5) processors with SMP. In this
revision, I reworded the commit messages and added a patch to simplify
the warning logic for the F00F bug. The patches seemed worth reposting
because the scope of the change is limited and it reduces lines of code.

The series is split into three patches for easier review. Let me know if
it would be preferable to merge them. Also, I wasn't sure whether the Fixes
tag in patch 1 is necessary. I left it inplace as Richard had it in his
original series, but it can be removed to avoid backporting hassles.

Richard Weinberger (2):
  x86/cpu/intel: Don't clear X86_BUG_F00F before setting it
  x86/cpufeature: Remove clear_cpu_bug()

Sohil Mehta (1):
  x86/cpu/intel: Simplify F00F bug notice using pr_notice_once()

 arch/x86/include/asm/cpufeature.h | 1 -
 arch/x86/kernel/cpu/intel.c       | 8 +-------
 2 files changed, 1 insertion(+), 8 deletions(-)

-- 
2.43.0

[PATCH v2 1/3] x86/cpu/intel: Don't clear X86_BUG_F00F before setting it

[Sohil Mehta]

From: Richard Weinberger <richard@nod.at>

On x86 SMP systems with the F00F bug present, the following warning
occurs for each AP:

  WARNING: arch/x86/kernel/cpu/cpuid-deps.c:126 at do_clear_cpu_cap+0xb4/0x110
  Call Trace:
   clear_cpu_cap+0x8/0x10
   init_intel+0x1b/0x4b0
   identify_cpu+0x154/0x750
   identify_secondary_cpu+0x3d/0x90
   start_secondary+0x6b/0xf0
   startup_32_smp+0x151/0x160

The X86_BUG_F00F CPU feature is first cleared in intel_workarounds() and
then set for the affected models. This sequence works fine on the BSP
but on AP bringup, where alternatives have already been patched,
clearing the flag triggers the warning.

There is no technical reason for clearing the flag before setting it.
It is mainly an artifact of the introduction of X86_BUG_F00F in commit
e2604b49e8a8 ("x86, cpu: Convert F00F bug detection"). Remove the
unnecessary clearing of the flag.

Note that the fixes tag references a recent commit that introduced the
warning rather than the old commit that converted F00F bug detection to
use clear_cpu_bug().

Fixes: ee8962082a44 ("x86/alternatives: Catch late X86_FEATURE modifiers")
Signed-off-by: Richard Weinberger <richard@nod.at>
[sohil: reworded commit message]
Signed-off-by: Sohil Mehta <sohil.mehta@intel.com>
---
v2:
 - Reworded commit message to clarify the issue.
---
 arch/x86/kernel/cpu/intel.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c
index f28c0efb7c8f..e957c5a1501c 100644
--- a/arch/x86/kernel/cpu/intel.c
+++ b/arch/x86/kernel/cpu/intel.c
@@ -395,7 +395,6 @@ static void intel_workarounds(struct cpuinfo_x86 *c)
 	 * system. Announce that the fault handler will be checking for it.
 	 * The Quark is also family 5, but does not have the same bug.
 	 */
-	clear_cpu_bug(c, X86_BUG_F00F);
 	if (c->x86_vfm >= INTEL_FAM5_START && c->x86_vfm < INTEL_QUARK_X1000) {
 		static int f00f_workaround_enabled;
 
-- 
2.43.0

[PATCH v2 2/3] x86/cpu/intel: Simplify F00F bug notice using pr_notice_once()

[Sohil Mehta]

The F00F bug workaround goes through a lot of effort to print the kernel
notice exactly once. Replace it with pr_notice_once(), which precisely
does that.

Signed-off-by: Sohil Mehta <sohil.mehta@intel.com>
---
v2:
 - New patch
---
 arch/x86/kernel/cpu/intel.c | 7 +------
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c
index e957c5a1501c..84a652a7dd41 100644
--- a/arch/x86/kernel/cpu/intel.c
+++ b/arch/x86/kernel/cpu/intel.c
@@ -396,13 +396,8 @@ static void intel_workarounds(struct cpuinfo_x86 *c)
 	 * The Quark is also family 5, but does not have the same bug.
 	 */
 	if (c->x86_vfm >= INTEL_FAM5_START && c->x86_vfm < INTEL_QUARK_X1000) {
-		static int f00f_workaround_enabled;
-
 		set_cpu_bug(c, X86_BUG_F00F);
-		if (!f00f_workaround_enabled) {
-			pr_notice("Intel Pentium with F0 0F bug - workaround enabled.\n");
-			f00f_workaround_enabled = 1;
-		}
+		pr_notice_once("Intel Pentium with F0 0F bug - workaround enabled.\n");
 	}
 #endif
 
-- 
2.43.0

[PATCH v2 3/3] x86/cpufeature: Remove clear_cpu_bug()

[Sohil Mehta]

From: Richard Weinberger <richard@nod.at>

X86_BUG_F00F was the last remaining user of clear_cpu_bug(). With no
users left, remove this helper.

Signed-off-by: Richard Weinberger <richard@nod.at>
Signed-off-by: Sohil Mehta <sohil.mehta@intel.com>
---
v2:
 - Improve commit message
---
 arch/x86/include/asm/cpufeature.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/x86/include/asm/cpufeature.h b/arch/x86/include/asm/cpufeature.h
index 3ddc1d33399b..90680f978d43 100644
--- a/arch/x86/include/asm/cpufeature.h
+++ b/arch/x86/include/asm/cpufeature.h
@@ -125,7 +125,6 @@ static __always_inline bool _static_cpu_has(u16 bit)
 
 #define cpu_has_bug(c, bit)		cpu_has(c, (bit))
 #define set_cpu_bug(c, bit)		set_cpu_cap(c, (bit))
-#define clear_cpu_bug(c, bit)		clear_cpu_cap(c, (bit))
 
 #define static_cpu_has_bug(bit)		static_cpu_has((bit))
 #define boot_cpu_has_bug(bit)		cpu_has_bug(&boot_cpu_data, (bit))
-- 
2.43.0

Re: [PATCH v2 0/3] x86: Fix a F00F bug warning and cleanup surrounding code

[Richard Weinberger]

----- Ursprüngliche Mail -----
> Von: "Sohil Mehta" <sohil.mehta@intel.com>
> This is an iteration of the series posted earlier by Richard Weinberger.
> https://lore.kernel.org/lkml/20260216104343.3625292-1-richard@nod.at/
> 
> The patches primarily fix a harmless "alternatives_patched" warning that
> affects the original Pentium (Family 5) processors with SMP. In this
> revision, I reworded the commit messages and added a patch to simplify
> the warning logic for the F00F bug. The patches seemed worth reposting
> because the scope of the change is limited and it reduces lines of code.
> 
> The series is split into three patches for easier review. Let me know if
> it would be preferable to merge them. Also, I wasn't sure whether the Fixes
> tag in patch 1 is necessary. I left it inplace as Richard had it in his
> original series, but it can be removed to avoid backporting hassles.
> 
> Richard Weinberger (2):
>  x86/cpu/intel: Don't clear X86_BUG_F00F before setting it
>  x86/cpufeature: Remove clear_cpu_bug()
> 
> Sohil Mehta (1):
>  x86/cpu/intel: Simplify F00F bug notice using pr_notice_once()

Thanks for reviving these patches!
//richard

Re: [PATCH v2 2/3] x86/cpu/intel: Simplify F00F bug notice using pr_notice_once()

[Ahmed S. Darwish]

Hi Sohil,

On Thu, 14 May 2026, Sohil Mehta wrote:
>
> --- a/arch/x86/kernel/cpu/intel.c
> +++ b/arch/x86/kernel/cpu/intel.c
> @@ -396,13 +396,8 @@ static void intel_workarounds(struct cpuinfo_x86 *c)
>  	 * The Quark is also family 5, but does not have the same bug.
>  	 */
>  	if (c->x86_vfm >= INTEL_FAM5_START && c->x86_vfm < INTEL_QUARK_X1000) {
> -		static int f00f_workaround_enabled;
> -
>  		set_cpu_bug(c, X86_BUG_F00F);
> -		if (!f00f_workaround_enabled) {
> -			pr_notice("Intel Pentium with F0 0F bug - workaround enabled.\n");
> -			f00f_workaround_enabled = 1;
> -		}
> +		pr_notice_once("Intel Pentium with F0 0F bug - workaround enabled.\n");
>  	}
>

I think you can go further and just remove the whole dmesg line.

All other set_cpu_bug() call sites in the kernel do not print anything [*],
and /proc/cpuinfo already has a dedicated CPU bugs line.

Thanks,
Ahmed

[*] Except a single, also legacy, call site: X86_BUG_FDIV

Re: [PATCH v2 1/3] x86/cpu/intel: Don't clear X86_BUG_F00F before setting it

[Ahmed S. Darwish]

On Thu, 14 May 2026, Sohil Mehta wrote:
>
> From: Richard Weinberger <richard@nod.at>
>
> On x86 SMP systems with the F00F bug present, the following warning
> occurs for each AP:
>
>   WARNING: arch/x86/kernel/cpu/cpuid-deps.c:126 at do_clear_cpu_cap+0xb4/0x110
>   Call Trace:
>    clear_cpu_cap+0x8/0x10
>    init_intel+0x1b/0x4b0
>    identify_cpu+0x154/0x750
>    identify_secondary_cpu+0x3d/0x90
>    start_secondary+0x6b/0xf0
>    startup_32_smp+0x151/0x160
>
> The X86_BUG_F00F CPU feature is first cleared in intel_workarounds() and
> then set for the affected models. This sequence works fine on the BSP
> but on AP bringup, where alternatives have already been patched,
> clearing the flag triggers the warning.
>
> There is no technical reason for clearing the flag before setting it.
> It is mainly an artifact of the introduction of X86_BUG_F00F in commit
> e2604b49e8a8 ("x86, cpu: Convert F00F bug detection"). Remove the
> unnecessary clearing of the flag.
>
> Note that the fixes tag references a recent commit that introduced the
> warning rather than the old commit that converted F00F bug detection to
> use clear_cpu_bug().
>
> Fixes: ee8962082a44 ("x86/alternatives: Catch late X86_FEATURE modifiers")
> Signed-off-by: Richard Weinberger <richard@nod.at>
> [sohil: reworded commit message]
> Signed-off-by: Sohil Mehta <sohil.mehta@intel.com>
> ---

Reviewed-by: Ahmed S. Darwish <darwi@linutronix.de>

Re: [PATCH v2 3/3] x86/cpufeature: Remove clear_cpu_bug()

[Ahmed S. Darwish]

On Thu, 14 May 2026, Sohil Mehta wrote:
>
> From: Richard Weinberger <richard@nod.at>
>
> X86_BUG_F00F was the last remaining user of clear_cpu_bug(). With no
> users left, remove this helper.
>
> Signed-off-by: Richard Weinberger <richard@nod.at>
> Signed-off-by: Sohil Mehta <sohil.mehta@intel.com>
> ---

Reviewed-by: Ahmed S. Darwish <darwi@linutronix.de>

Re: [PATCH v2 2/3] x86/cpu/intel: Simplify F00F bug notice using pr_notice_once()

[Sohil Mehta]

On 5/15/2026 12:14 PM, Ahmed S. Darwish wrote:

Thank you for the reviewing the series.

>> +		pr_notice_once("Intel Pentium with F0 0F bug - workaround enabled.\n");

> 
> I think you can go further and just remove the whole dmesg line.
> 

It's a long-standing user-visible boot message. It doesn't feel worth
removing to save a single line of code. My intention with this series
was to avoid any visible change because of the rarity of these machines.

Unless there is a strong preference I would prefer to leave it in place.
Would it be beneficial for some future rework?

Re: [PATCH v2 2/3] x86/cpu/intel: Simplify F00F bug notice using pr_notice_once()

[Ahmed S. Darwish]

On Fri, 15 May 2026, Sohil Mehta wrote:
>
> On 5/15/2026 12:14 PM, Ahmed S. Darwish wrote:
> > >
> > > +		pr_notice_once("Intel Pentium with F0 0F bug - workaround enabled.\n");
> >
> > I think you can go further and just remove the whole dmesg line.
> >
>
> It's a long-standing user-visible boot message. It doesn't feel worth
> removing to save a single line of code. My intention with this series
> was to avoid any visible change because of the rarity of these machines.
>

AFAIK this F00F thing just kills the machine, so I don't know why would a
legacy user-space program scan dmesg for that "wourkaround enabled" string.

I'd vote to remove it, and restore the message only if user-space /really/
breaks, which I highly doubt.

It's not a deal breaker, so I'll leave it here.

All the best,
Ahmed

Re: [PATCH v2 2/3] x86/cpu/intel: Simplify F00F bug notice using pr_notice_once()

[Dave Hansen]

On 5/15/26 12:14, Ahmed S. Darwish wrote:
>>  	if (c->x86_vfm >= INTEL_FAM5_START && c->x86_vfm < INTEL_QUARK_X1000) {
>> -		static int f00f_workaround_enabled;
>> -
>>  		set_cpu_bug(c, X86_BUG_F00F);
>> -		if (!f00f_workaround_enabled) {
>> -			pr_notice("Intel Pentium with F0 0F bug - workaround enabled.\n");
>> -			f00f_workaround_enabled = 1;
>> -		}
>> +		pr_notice_once("Intel Pentium with F0 0F bug - workaround enabled.\n");
>>  	}
>>
> I think you can go further and just remove the whole dmesg line.
> 
> All other set_cpu_bug() call sites in the kernel do not print anything [*],
> and /proc/cpuinfo already has a dedicated CPU bugs line.

Ahmed, this is a good point. I can almost guarantee that this message
predates all the bug gunk in /proc/cpuinfo.

I think this pr_notice() is fine to remove.

Re: [PATCH v2 2/3] x86/cpu/intel: Simplify F00F bug notice using pr_notice_once()

[Sohil Mehta]

> I think this pr_notice() is fine to remove.

Sure, I'll remove the notice and also convert the #ifdef
CONFIG_X86_F00F_BUG into IS_ENABLED(CONFIG_X86_F00F_BUG).

Re: [PATCH v2 2/3] x86/cpu/intel: Simplify F00F bug notice using pr_notice_once()

[Dave Hansen]

On 5/18/26 13:29, Sohil Mehta wrote:
>> I think this pr_notice() is fine to remove.
> Sure, I'll remove the notice and also convert the #ifdef
> CONFIG_X86_F00F_BUG into IS_ENABLED(CONFIG_X86_F00F_BUG).

BTW... The basic trajectory these days is not to be so careful with
32-bit-only gunk. If it's causing us any headache -- even a few lines of
code -- it better be unambiguously crucial to functionality to stick around.

In this case, the guy still running a Pentium classic is highly unlikely
to be concerned about the kernel forgetting to add an F0 0F workaround.
There are also unlikely to be Pentiums sitting in data centers with log
monitoring tools that are desperately looking for that F0 0F hunk in dmesg.

The most likely thing is: there are a few dozen Pentiums (if that) out
there running mainline kernels. I'm not sure they even have more than a
couple of distros they can run. Nobody is going to notice this message
going away.

Re: [PATCH v2 2/3] x86/cpu/intel: Simplify F00F bug notice using pr_notice_once()

[H. Peter Anvin]

On May 18, 2026 2:17:13 PM PDT, Dave Hansen <dave.hansen@intel.com> wrote:
>On 5/18/26 13:29, Sohil Mehta wrote:
>>> I think this pr_notice() is fine to remove.
>> Sure, I'll remove the notice and also convert the #ifdef
>> CONFIG_X86_F00F_BUG into IS_ENABLED(CONFIG_X86_F00F_BUG).
>
>BTW... The basic trajectory these days is not to be so careful with
>32-bit-only gunk. If it's causing us any headache -- even a few lines of
>code -- it better be unambiguously crucial to functionality to stick around.
>
>In this case, the guy still running a Pentium classic is highly unlikely
>to be concerned about the kernel forgetting to add an F0 0F workaround.
>There are also unlikely to be Pentiums sitting in data centers with log
>monitoring tools that are desperately looking for that F0 0F hunk in dmesg.
>
>The most likely thing is: there are a few dozen Pentiums (if that) out
>there running mainline kernels. I'm not sure they even have more than a
>couple of distros they can run. Nobody is going to notice this message
>going away.

Just nuke the text. It's pointless; we have many other bug workarounds we are less noisy about.

Re: [PATCH v2 2/3] x86/cpu/intel: Simplify F00F bug notice using pr_notice_once()

[Maciej W. Rozycki]

On Mon, 18 May 2026, Dave Hansen wrote:

> The most likely thing is: there are a few dozen Pentiums (if that) out
> there running mainline kernels. I'm not sure they even have more than a
> couple of distros they can run. Nobody is going to notice this message
> going away.

 Well, I've noticed this already, but go nuke it, I'm not going to care.  
I'm glad the do_clear_cpu_cap() warning does go away though; I've never 
got to looking into it, so thanks, Sohil, for this effort.

  Maciej

Linux version 7.0.0-dirty (macro@angie) (i386-linux-gnu-gcc (GCC) 15.0.0 20241112 (experimental), GNU ld (GNU Binutils) 2.45.50.20250805) #1 SMP PREEMPT Fri May  1 22:51:23 BST 2026
KERNEL supported cpus:
  Intel GenuineIntel
x86 CPU feature dependency check failure: CPU0 has 'mmx' enabled but 'fxsr' disabled. Kernel might be fine, but no guarantees.
x86/CPU: Model not found in latest microcode list
[...]
Intel Pentium with F0 0F bug - workaround enabled.
[...]
smpboot: CPU0: Intel Pentium MMX (family: 0x5, model: 0x4, stepping: 0x3)
[...]
smp: Bringing up secondary CPUs ...
smpboot: x86: Booting SMP configuration:
.... node  #0, CPUs:      #1
Masked ExtINT on CPU#1
[Firmware Bug]: CPU   1: APIC ID mismatch. CPUID: 0x0000 APIC: 0x0001
------------[ cut here ]------------
WARNING: at do_clear_cpu_cap+0x90/0xe0, CPU#1: swapper/1/0
CPU: 1 UID: 0 PID: 0 Comm: swapper/1 Not tainted 7.0.0-dirty #1 PREEMPT
[...]

Re: [PATCH v2 2/3] x86/cpu/intel: Simplify F00F bug notice using pr_notice_once()

[Christian Ludloff]

>> The most likely thing is: there are a few dozen Pentiums (if that) out
>> there running mainline kernels. I'm not sure they even have more than a
>> couple of distros they can run. Nobody is going to notice this message
>> going away.

And not just any Pentium, but a dual Pentium system!

Mine is sitting in a box in storage. So I won't notice.  :)

> Well, I've noticed this already, but go nuke it, I'm not going to care.
> I'm glad the do_clear_cpu_cap() warning does go away though; I've never
> got to looking into it, so thanks, Sohil, for this effort.

thx +1

Fwiw, Oct 1 will mark the 30th anniversary of F00F discovery.

18:32:26 -0500 to be exact, in case it matters.

Ah yes... a Tuesday... of course...  :)

--
C.

Re: [PATCH v2 2/3] x86/cpu/intel: Simplify F00F bug notice using pr_notice_once()

[Maciej W. Rozycki]

Hi Christian,

 Long time, no hear!

> >> The most likely thing is: there are a few dozen Pentiums (if that) out
> >> there running mainline kernels. I'm not sure they even have more than a
> >> couple of distros they can run. Nobody is going to notice this message
> >> going away.
> 
> And not just any Pentium, but a dual Pentium system!

 Yep, 30+ years on and I'm still alive and kicking along with my toys!

 This actually continues getting serious use, most recently for glibc ISO 
C formatted input/output test coverage improvement and the x87 FP formats.

 And there is actually an unrelated test there that reproducibly triggers 
a crash, which I yet have to chase, and which is somewhat tricky as all 
the test cases are run indirectly via the dynamic loader, so there's no 
useful program name reported.  So I'll have to run the testsuite parts by 
hand to narrow this down.  Maybe alongside the i486 support restoration 
project, which I hope to get at this coming July.

 For the record:

------------[ cut here ]------------
Bad FPU state detected at restore_fpregs_from_fpstate+0x4b/0x50, reinitializing FPU registers.
WARNING: CPU: 1 PID: 21035 at fixup_exception+0x296/0x2b0
CPU: 1 UID: 500 PID: 21035 Comm: ld-linux.so.2 Tainted: G        W          6.13.0-dirty #2
Tainted: [W]=WARN
Hardware name: [...]
EIP: fixup_exception+0x296/0x2b0
Code: 04 89 7e 30 e9 43 fe ff ff 0f 0b 90 0f 0b ba 4c 8a 9c c0 e9 7d fe ff ff c6 05 1a d9 92 c0 01 50 68 ac e6 82 c0 e8 ca b9 00 00 <0f> 0b 5e 5f e9 90 fe ff ff 90 0f 0b ba 4c 8a 9c c0 e9 df fd ff ff
EAX: 0000005e EBX: c089b190 ECX: dfbf2e24 EDX: 00000000
ESI: d312bf0c EDI: 00000010 EBP: d312bedc ESP: d312be60
DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 EFLAGS: 00010092
CR0: 80050033 CR2: b7f46988 CR3: 130fe000 CR4: 00000050
Call Trace:
 ? show_regs.cold+0x14/0x22
 ? __warn.cold+0x3a/0x95
 ? fixup_exception+0x296/0x2b0
 ? report_bug+0x10e/0x140
 ? fixup_exception+0x297/0x2b0
 ? exc_overflow+0x40/0x40
 ? handle_bug+0x3e/0x70
 ? exc_invalid_op+0x24/0x60
 ? handle_exception+0x14d/0x14d
 ? exc_overflow+0x40/0x40
 ? fixup_exception+0x296/0x2b0
 ? exc_overflow+0x40/0x40
 ? fixup_exception+0x296/0x2b0
 ? restore_fpregs_from_fpstate+0x4b/0x50
 ? exc_page_fault+0x123/0x430
 ? doublefault_shim+0x120/0x120
 ? handle_exception+0x14d/0x14d
 ? clear_user+0x2b/0x40
 math_error+0x45/0x110
 ? exc_debug+0x40/0x40
 exc_coprocessor_error+0x1a/0x30
 handle_exception+0x14d/0x14d
EIP: restore_fpregs_from_fpstate+0x4b/0x50
Code: 8b 0d 08 52 89 c0 21 fa 21 c8 8d 7b 40 0f ae 2f 5b 5f 5d c3 8d 76 00 eb 0e cc cc cc 0f ae 4b 40 5b 5f 5d c3 8d 76 00 dd 63 40 <5b> 5f 5d c3 90 55 89 e5 57 56 53 64 8b 1d 80 30 9b c0 64 8b 3d 88
EAX: 00000cff EBX: d47cbb40 ECX: 00000000 EDX: 00000000
ESI: d47cbb00 EDI: 00000001 EBP: d312bf70 ESP: d312bf68
DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 EFLAGS: 00010046
 ? exc_debug+0x40/0x40
 ? exc_debug+0x40/0x40
 ? restore_fpregs_from_fpstate+0x48/0x50
 switch_fpu_return+0x3f/0x70
 syscall_exit_to_user_mode+0x10e/0x150
 do_int80_syscall_32+0x44/0x90
 entry_INT80_32+0x10d/0x10d
EIP: 0xb7d1061e
Code: 00 89 44 24 18 8d 6c 24 24 55 e8 bd 5e f7 ff 65 a1 08 00 00 00 8d 78 68 b8 78 00 00 00 bb 11 00 20 01 31 c9 31 d2 31 f6 cd 80 <89> c6 83 c4 10 3d 00 f0 ff ff 77 3e 85 c0 74 16 83 ec 0c 55 e8 f9
EAX: 0000522c EBX: 01200011 ECX: 00000000 EDX: 00000000
ESI: 00000000 EDI: b7f46a68 EBP: bfc10908 ESP: bfc108e0
DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 007b EFLAGS: 00000246
---[ end trace 0000000000000000 ]---
traps: PANIC: double fault, error_code: 0x0
Oops: double fault: 0000 [#1] SMP
CPU: 1 UID: 500 PID: 21035 Comm: ld-linux.so.2 Tainted: G        W          6.13.0-dirty #2
Tainted: [W]=WARN
Hardware name: [...]
EIP: search_extable+0x16/0x30
Code: 00 e8 7e 54 d4 ff 8b 5d fc 58 5a 89 ec 5d c3 2e 8d 74 26 00 55 89 e5 53 53 8d 5d f8 89 4d f8 68 c0 ab 6e c0 89 d1 89 c2 89 d8 <6a> 0c e8 73 d3 d4 ff 8b 5d fc 89 ec 5d c3 cc cc cc cc cc cc cc cc
EAX: d3000004 EBX: d3000004 ECX: 000002d5 EDX: c089a4d0
ESI: d30000c4 EDI: 00000010 EBP: d300000c ESP: d3000000
DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068 EFLAGS: 00010086
CR0: 80050033 CR2: d2fffffc CR3: 009be000 CR4: 00000050
Call Trace:
 <#DF>
 ? show_regs.cold+0x14/0x22
 ? __die+0x18/0x4b
 ? die+0x21/0x40
 ? exc_double_fault+0x55/0x60
 ? doublefault_shim+0x115/0x120
 ? search_extable+0x16/0x30
 ? asm_exc_double_fault+0xa/0x10
 </#DF>
---[ end trace 0000000000000000 ]---
EIP: search_extable+0x16/0x30
Code: 00 e8 7e 54 d4 ff 8b 5d fc 58 5a 89 ec 5d c3 2e 8d 74 26 00 55 89 e5 53 53 8d 5d f8 89 4d f8 68 c0 ab 6e c0 89 d1 89 c2 89 d8 <6a> 0c e8 73 d3 d4 ff 8b 5d fc 89 ec 5d c3 cc cc cc cc cc cc cc cc
EAX: d3000004 EBX: d3000004 ECX: 000002d5 EDX: c089a4d0
ESI: d30000c4 EDI: 00000010 EBP: d300000c ESP: d3000000
DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068 EFLAGS: 00010086
CR0: 80050033 CR2: d2fffffc CR3: 009be000 CR4: 00000050
Kernel panic - not syncing: Fatal exception in interrupt
Kernel Offset: disabled

(now that I've looked at it again, I can see it's 6.13.0 as it's been a 
while, so maybe it's gone now in 7.x, hmm... will have to check.)

  Maciej

Re: [PATCH v2 2/3] x86/cpu/intel: Simplify F00F bug notice using pr_notice_once()

[Maciej W. Rozycki]

On Fri, 22 May 2026, Maciej W. Rozycki wrote:

> (now that I've looked at it again, I can see it's 6.13.0 as it's been a 
> while, so maybe it's gone now in 7.x, hmm... will have to check.)

 Yep, still there:

------------[ cut here ]------------
Bad FPU state detected at restore_fpregs_from_fpstate+0x48/0x50, reinitializing FPU registers.
WARNING: at fixup_exception+0x2a1/0x2c0, CPU#1: ld-linux.so.2/9621
CPU: 1 UID: 500 PID: 9621 Comm: ld-linux.so.2 Tainted: G        W           7.0.0-dirty #1 PREEMPT 
Tainted: [W]=WARN
Hardware name: [...]
EIP: fixup_exception+0x2a1/0x2c0
Code: 40 fe ff ff 0f 0b 8d 76 00 0f 0b ba 0c 99 a4 c0 e9 76 fe ff ff 8b 7e 30 c6 05 bf 82 9a c0 01 57 68 38 1b 8a c0 e8 1f be 00 00 <0f> 0b 58 5a e9 7b fe ff ff 8d b6 00 00 00 00 0f 0b ba 0c 99 a4 c0
EAX: 0000005e EBX: c0915690 ECX: dfbf2c84 EDX: 00000000
ESI: c2759f10 EDI: c014d9d8 EBP: c2759edc ESP: c2759e60
DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 EFLAGS: 00010086
CR0: 80050033 CR2: b7c0e7a8 CR3: 08998000 CR4: 00000050
Call Trace:
 ? restore_fpregs_from_fpstate+0x48/0x50
 ? handle_mm_fault+0x537/0xd40
 ? exc_debug+0x40/0x40
 math_error+0x46/0x110
 exc_coprocessor_error+0x1a/0x30
 handle_exception+0x14d/0x14d
EIP: restore_fpregs_from_fpstate+0x48/0x50
Code: 90 c0 21 c8 8b 0d 2c f2 90 c0 21 ca 0f ae 6b 40 5b 5d c3 8d b4 26 00 00 00 00 eb 0e cc cc cc 0f ae 4b 40 5b 5d c3 8d 74 26 00 <dd> 63 40 5b 5d c3 66 90 55 ba ff 1c 08 00 89 e5 31 c9 b8 80 e1 90
EAX: 00081cff EBX: c3f60e40 ECX: 00000000 EDX: 00000000
ESI: c3f60e00 EDI: 00000001 EBP: c2759f70 ESP: c2759f6c
DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 EFLAGS: 00010046
 ? exc_debug+0x40/0x40
 ? exc_debug+0x40/0x40
 ? restore_fpregs_from_fpstate+0x48/0x50
 switch_fpu_return+0x3f/0x70
 ret_from_fork+0x1a9/0x200
 ret_from_fork_asm+0x12/0x20
 entry_INT80_32+0x10d/0x10d
EIP: 0xb7cd633e
Code: Unable to access opcode bytes at 0xb7cd6314.
EAX: 00000000 EBX: 01200011 ECX: 00000000 EDX: 00000000
ESI: 00000000 EDI: b7c0e7a8 EBP: bfa651e8 ESP: bfa651c0
DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 007b EFLAGS: 00000246
---[ end trace 0000000000000000 ]---
BUG: kernel NULL pointer dereference, address: 00000012
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
*pde = 00000000 
Oops: Oops: 0000 [#1] SMP
CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Tainted: G        W           7.0.0-dirty #1 PREEMPT 
BUG: unable to handle page fault for address: c08ecfae
#PF: supervisor read access in kernel mode
#PF: e

The test system rebooted at this point and I was lucky enough to have a 
peek at the console then and cross-check it with the test harness output, 
so I've narrowed the reproducer down now to `math/test-fenv'.  OK, that 
does seem correlated and also triggers with the test run by hand.

 The last output from the test is:

Test: after fesetenv (FE_NOMASK_ENV) processes will abort
      when feraiseexcept (FE_DIVBYZERO) is called.
  Pass: Process received SIGFPE.
Test: after fesetenv (FE_DFL_ENV) processes will not abort
      when feraiseexcept (FE_DIVBYZERO) is called.

so it's `feraiseexcept' for division by zero that ultimately triggers the 
issue in the newly-cloned child as the FP context is installed.

 I've added a debug call to double-check the hypothesis and retrieve the 
values of CW and SW and it confirmed an active zero divide exception, but 
also made the crash go away, with ex_handler_fprestore() then invoked over 
a dozen of times through the execution of the program to completion, so 
it's a heisenbug after all.

 I'll see if I can chase it down later.  I suspect ex_handler_fprestore() 
shouldn't have triggered in the first place too, as it's not ptrace(2) or 
the like that have set up the FP context like this.

 NB I've linked this reply back to the original thread.

  Maciej

Re: [PATCH v2 2/3] x86/cpu/intel: Simplify F00F bug notice using pr_notice_once()

[Dave Hansen]

On 5/22/26 13:27, Maciej W. Rozycki wrote:
>  This actually continues getting serious use, most recently for glibc ISO 
> C formatted input/output test coverage improvement and the x87 FP formats.

I'm as nostalgic as anyone and I've enjoyed keeping some relics around
for fun.

But keeping something powered on and running test suites doesn't count
as "serious use". It actually needs to get used for something outside of
pure testing.

Re: [PATCH v2 2/3] x86/cpu/intel: Simplify F00F bug notice using pr_notice_once()

[Maciej W. Rozycki]

On Tue, 26 May 2026, Dave Hansen wrote:

> >  This actually continues getting serious use, most recently for glibc ISO 
> > C formatted input/output test coverage improvement and the x87 FP formats.
> 
> I'm as nostalgic as anyone and I've enjoyed keeping some relics around
> for fun.
> 
> But keeping something powered on and running test suites doesn't count
> as "serious use". It actually needs to get used for something outside of
> pure testing.

 As a toolchain developer this is serious use for me, I get paid for it.

  Maciej

Re: [PATCH v2 2/3] x86/cpu/intel: Simplify F00F bug notice using pr_notice_once()

[David Laight]

On Tue, 26 May 2026 07:14:01 -0700
Dave Hansen <dave.hansen@intel.com> wrote:

> On 5/22/26 13:27, Maciej W. Rozycki wrote:
> >  This actually continues getting serious use, most recently for glibc ISO 
> > C formatted input/output test coverage improvement and the x87 FP formats.  
> 
> I'm as nostalgic as anyone and I've enjoyed keeping some relics around
> for fun.
> 
> But keeping something powered on and running test suites doesn't count
> as "serious use". It actually needs to get used for something outside of
> pure testing.

Keeping the house warm?

-- David

Re: [PATCH v2 2/3] x86/cpu/intel: Simplify F00F bug notice using pr_notice_once()

[Christian Ludloff]

On Tue, May 26, 2026 at 8:20 AM David Laight
<david.laight.linux@gmail.com> wrote:
> > On 5/22/26 13:27, Maciej W. Rozycki wrote:
> > > This actually continues getting serious use, most recently for glibc ISO
> > > C formatted input/output test coverage improvement and the x87 FP formats.

x87 testing... on a Pentium?

> Keeping the house warm?

Opinions on that are divided.

--
C.

Re: [PATCH v2 2/3] x86/cpu/intel: Simplify F00F bug notice using pr_notice_once()

[Maciej W. Rozycki]

On Tue, 26 May 2026, Christian Ludloff wrote:

> > > > This actually continues getting serious use, most recently for glibc ISO
> > > > C formatted input/output test coverage improvement and the x87 FP formats.
> 
> x87 testing... on a Pentium?

 Yes, 32-bit x86 remains a supported target with the GNU C library, down 
to i486 I believe, that includes dedicated platform code such as for the 
80-bit extended format, so this was a good portability exercise, given 
that the scope of the tests were floating-point formatted input/output 
specifiers, not previously sufficiently covered.

  Maciej

Re: [PATCH v2 2/3] x86/cpu/intel: Simplify F00F bug notice using pr_notice_once()

[H. Peter Anvin]

On May 26, 2026 12:15:19 PM PDT, "Maciej W. Rozycki" <macro@orcam.me.uk> wrote:
>On Tue, 26 May 2026, Christian Ludloff wrote:
>
>> > > > This actually continues getting serious use, most recently for glibc ISO
>> > > > C formatted input/output test coverage improvement and the x87 FP formats.
>> 
>> x87 testing... on a Pentium?
>
> Yes, 32-bit x86 remains a supported target with the GNU C library, down 
>to i486 I believe, that includes dedicated platform code such as for the 
>80-bit extended format, so this was a good portability exercise, given 
>that the scope of the tests were floating-point formatted input/output 
>specifiers, not previously sufficiently covered.
>
>  Maciej

However, x87 should be testable on any x86 silicon.

Re: [PATCH v2 2/3] x86/cpu/intel: Simplify F00F bug notice using pr_notice_once()

[Richard Weinberger]

----- Ursprüngliche Mail -----
> Von: "Maciej W. Rozycki" <macro@orcam.me.uk>
> An: "Christian Ludloff" <ludloff@gmail.com>
> CC: "richard" <richard@nod.at>, "Dave Hansen" <dave.hansen@intel.com>, "Sohil Mehta" <sohil.mehta@intel.com>, "Ahmed S.
> Darwish" <darwi@linutronix.de>, "bp" <bp@alien8.de>, "x86" <x86@kernel.org>, "Thomas Gleixner" <tglx@kernel.org>,
> "mingo" <mingo@redhat.com>, "hpa" <hpa@zytor.com>, "Josh Poimboeuf" <jpoimboe@kernel.org>, "andrew cooper3"
> <andrew.cooper3@citrix.com>, "Tony Luck" <tony.luck@intel.com>, "linux-kernel" <linux-kernel@vger.kernel.org>
> Gesendet: Montag, 25. Mai 2026 12:41:00
> Betreff: Re: [PATCH v2 2/3] x86/cpu/intel: Simplify F00F bug notice using pr_notice_once()

> On Fri, 22 May 2026, Maciej W. Rozycki wrote:
> 
>> (now that I've looked at it again, I can see it's 6.13.0 as it's been a
>> while, so maybe it's gone now in 7.x, hmm... will have to check.)
> 
> Yep, still there:
> 
> ------------[ cut here ]------------
> Bad FPU state detected at restore_fpregs_from_fpstate+0x48/0x50, reinitializing
> FPU registers.
> WARNING: at fixup_exception+0x2a1/0x2c0, CPU#1: ld-linux.so.2/9621
> CPU: 1 UID: 500 PID: 9621 Comm: ld-linux.so.2 Tainted: G        W
> 7.0.0-dirty #1 PREEMPT
> Tainted: [W]=WARN
> Hardware name: [...]

Do you see this also in qemu?
I can give your test a try on my dual Pentium system.

Thanks,
//richard

Re: [PATCH v2 2/3] x86/cpu/intel: Simplify F00F bug notice using pr_notice_once()

[Maciej W. Rozycki]

On Tue, 26 May 2026, Richard Weinberger wrote:

> >> (now that I've looked at it again, I can see it's 6.13.0 as it's been a
> >> while, so maybe it's gone now in 7.x, hmm... will have to check.)
> > 
> > Yep, still there:
> > 
> > ------------[ cut here ]------------
> > Bad FPU state detected at restore_fpregs_from_fpstate+0x48/0x50, reinitializing
> > FPU registers.
> > WARNING: at fixup_exception+0x2a1/0x2c0, CPU#1: ld-linux.so.2/9621
> > CPU: 1 UID: 500 PID: 9621 Comm: ld-linux.so.2 Tainted: G        W
> > 7.0.0-dirty #1 PREEMPT
> > Tainted: [W]=WARN
> > Hardware name: [...]
> 
> Do you see this also in qemu?

 No idea, I have no QEMU setup readily available for this target.  It does 
not appear to be related to things such as the cache subsystem, which QEMU 
does not strive to emulate, so I'd expect this issue to trigger though.

> I can give your test a try on my dual Pentium system.

 Actually here is about the simplest reduced reproducer.  Link with -lm.

#define _GNU_SOURCE

#include <fenv.h>
#include <stdlib.h>
#include <unistd.h>

#include <sys/wait.h>

int main(void)
{
	int status;
	int pid;

	if (!(pid = fork())) {
		fesetenv(FE_NOMASK_ENV);
		feraiseexcept(FE_DIVBYZERO);
		exit(0);
	}
	waitpid (pid, &status, 0);
	if (!(pid = fork())) {
		fesetenv(FE_DFL_ENV);
		feraiseexcept(FE_DIVBYZERO);
		exit(0);
	}
	waitpid (pid, &status, 0);
	return 0;
}

 The primary cause is the leak of the CW and SW from the first child to 
the second.  It likely doesn't trigger the chain of events with CPUs that 
support FXRSTOR, because that instruction rightfully doesn't raise numeric 
exceptions, but I suspect the leak may still be there, just less likely to 
get noticed.  A carefully crafted user code might still get wrong results.

 Then for FRSTOR chips I don't think ex_handler_fprestore() ought to call 
fpu_reset_from_exception_fixup() at all -- instead it should just raise 
SIGFPE with the FP context as it is and let the signal action handle it, 
as it seems to me that it can always trigger if a task is pre-empted from 
its FP context while an unmasked numeric exception is pending, and then 
the context attempted to be reloaded, which will clearly break the app.

 The third issue is the actual crash that follows, which appears random, 
suggesting kernel data corruption.  Actually I've just retried the test 
case above to be sure, as I've modified the kernel since, and the box just 
rebooted after the dump from ex_handler_fprestore(), no further output 
produced to the console.  It might be worth tracking down even if both 
issues above have been fixed, most probably covering this issue.

 Thanks for your interest as I may not have the cycles to chase it further 
in the coming days.

  Maciej

Re: [PATCH v2 2/3] x86/cpu/intel: Simplify F00F bug notice using pr_notice_once()

[Maciej W. Rozycki]

On Tue, 26 May 2026, H. Peter Anvin wrote:

> > Yes, 32-bit x86 remains a supported target with the GNU C library, down 
> >to i486 I believe, that includes dedicated platform code such as for the 
> >80-bit extended format, so this was a good portability exercise, given 
> >that the scope of the tests were floating-point formatted input/output 
> >specifiers, not previously sufficiently covered.
> 
> However, x87 should be testable on any x86 silicon.

 We have model-dependent quirks, clearly.  Actually even this system is 
not pure x87 anymore as it has the MMX extension, and with the recent 
removal of i486 support it's getting harder and harder to get at the right 
environment.  As we spoke IIRC last year, I'll try to maintain support for 
the i486 with emulation off-tree.  The hard part might be RDTSC.

 And I've seen cases of code relying on newer hardware features by chance, 
which then eventually broke when tried on original hardware.  I've seen 
and fixed QEMU bugs too where ISA subsetting wasn't correct and software 
that worked on QEMU broke on real hw.

 Then haven't more recent x86 architecture revisions switched away from 
the venerable x87 FPU and its data formats for FP computations?  A genuine 
question as I have not been following progress here.  What I know though 
is the x87 stack architecture is antiquated, and hard to pipeline and emit 
optimised code for.  And also mixing computations of various precisions is 
problematic.

  Maciej

Re: [PATCH v2 2/3] x86/cpu/intel: Simplify F00F bug notice using pr_notice_once()

[H. Peter Anvin]

On May 26, 2026 5:29:25 PM PDT, "Maciej W. Rozycki" <macro@orcam.me.uk> wrote:
>On Tue, 26 May 2026, H. Peter Anvin wrote:
>
>> > Yes, 32-bit x86 remains a supported target with the GNU C library, down 
>> >to i486 I believe, that includes dedicated platform code such as for the 
>> >80-bit extended format, so this was a good portability exercise, given 
>> >that the scope of the tests were floating-point formatted input/output 
>> >specifiers, not previously sufficiently covered.
>> 
>> However, x87 should be testable on any x86 silicon.
>
> We have model-dependent quirks, clearly.  Actually even this system is 
>not pure x87 anymore as it has the MMX extension, and with the recent 
>removal of i486 support it's getting harder and harder to get at the right 
>environment.  As we spoke IIRC last year, I'll try to maintain support for 
>the i486 with emulation off-tree.  The hard part might be RDTSC.
>
> And I've seen cases of code relying on newer hardware features by chance, 
>which then eventually broke when tried on original hardware.  I've seen 
>and fixed QEMU bugs too where ISA subsetting wasn't correct and software 
>that worked on QEMU broke on real hw.
>
> Then haven't more recent x86 architecture revisions switched away from 
>the venerable x87 FPU and its data formats for FP computations?  A genuine 
>question as I have not been following progress here.  What I know though 
>is the x87 stack architecture is antiquated, and hard to pipeline and emit 
>optimised code for.  And also mixing computations of various precisions is 
>problematic.
>
>  Maciej

SSE/AVX is preferred, but x87 is still supported. It is certainly less performant though.

Re: [PATCH v2 2/3] x86/cpu/intel: Simplify F00F bug notice using pr_notice_once()

[David Laight]

On Tue, 26 May 2026 13:49:08 -0700
"H. Peter Anvin" <hpa@zytor.com> wrote:

> On May 26, 2026 12:15:19 PM PDT, "Maciej W. Rozycki" <macro@orcam.me.uk> wrote:
> >On Tue, 26 May 2026, Christian Ludloff wrote:
> >  
> >> > > > This actually continues getting serious use, most recently for glibc ISO
> >> > > > C formatted input/output test coverage improvement and the x87 FP formats.  
> >> 
> >> x87 testing... on a Pentium?  
> >
> > Yes, 32-bit x86 remains a supported target with the GNU C library, down 
> >to i486 I believe, that includes dedicated platform code such as for the 
> >80-bit extended format, so this was a good portability exercise, given 
> >that the scope of the tests were floating-point formatted input/output 
> >specifiers, not previously sufficiently covered.
> >
> >  Maciej  
> 
> However, x87 should be testable on any x86 silicon.

And gets used for 'long double' on x86-64.

If full precision is enabled there are a whole lot of horrid corner cases.
Mostly due to correctly generating the FP signals when the 80bit return
value from a function is written to a 64bit 'double'.

-- David

Re: [PATCH v2 2/3] x86/cpu/intel: Simplify F00F bug notice using pr_notice_once()

[Maciej W. Rozycki]

On Wed, 27 May 2026, David Laight wrote:

> > However, x87 should be testable on any x86 silicon.
> 
> And gets used for 'long double' on x86-64.
> 
> If full precision is enabled there are a whole lot of horrid corner cases.
> Mostly due to correctly generating the FP signals when the 80bit return
> value from a function is written to a 64bit 'double'.

 No IEEE quad for `long double' still, not even on 64-bit hw?  Weird.

  Maciej

Re: [PATCH v2 2/3] x86/cpu/intel: Simplify F00F bug notice using pr_notice_once()

[H. Peter Anvin]

On May 27, 2026 2:23:35 AM PDT, "Maciej W. Rozycki" <macro@orcam.me.uk> wrote:
>On Wed, 27 May 2026, David Laight wrote:
>
>> > However, x87 should be testable on any x86 silicon.
>> 
>> And gets used for 'long double' on x86-64.
>> 
>> If full precision is enabled there are a whole lot of horrid corner cases.
>> Mostly due to correctly generating the FP signals when the 80bit return
>> value from a function is written to a 64bit 'double'.
>
> No IEEE quad for `long double' still, not even on 64-bit hw?  Weird.
>
>  Maciej

The ABI was designed in 2003 or so...

Re: [PATCH v2 2/3] x86/cpu/intel: Simplify F00F bug notice using pr_notice_once()

[Maciej W. Rozycki]

On Wed, 27 May 2026, H. Peter Anvin wrote:

> >> If full precision is enabled there are a whole lot of horrid corner cases.
> >> Mostly due to correctly generating the FP signals when the 80bit return
> >> value from a function is written to a 64bit 'double'.
> >
> > No IEEE quad for `long double' still, not even on 64-bit hw?  Weird.
> 
> The ABI was designed in 2003 or so...

 Hmm, usually it's hardware that gets features first with software to 
follow.  For instance by now the POWER port has gained three `long double' 
formats in their psABI, all of which can coexist in a single system (I got 
that covered in the course of the glibc test improvement effort too).

  Maciej

Re: [PATCH v2 2/3] x86/cpu/intel: Simplify F00F bug notice using pr_notice_once()

[H. Peter Anvin]

On May 27, 2026 9:14:10 AM PDT, "Maciej W. Rozycki" <macro@orcam.me.uk> wrote:
>On Wed, 27 May 2026, H. Peter Anvin wrote:
>
>> >> If full precision is enabled there are a whole lot of horrid corner cases.
>> >> Mostly due to correctly generating the FP signals when the 80bit return
>> >> value from a function is written to a 64bit 'double'.
>> >
>> > No IEEE quad for `long double' still, not even on 64-bit hw?  Weird.
>> 
>> The ABI was designed in 2003 or so...
>
> Hmm, usually it's hardware that gets features first with software to 
>follow.  For instance by now the POWER port has gained three `long double' 
>formats in their psABI, all of which can coexist in a single system (I got 
>that covered in the course of the glibc test improvement effort too).
>
>  Maciej

The x87 psABI does have a __float128 type IIRC.

Re: [PATCH v2 2/3] x86/cpu/intel: Simplify F00F bug notice using pr_notice_once()

[David Laight]

On Mon, 01 Jun 2026 07:43:32 -0700
"H. Peter Anvin" <hpa@zytor.com> wrote:

> On May 27, 2026 9:14:10 AM PDT, "Maciej W. Rozycki" <macro@orcam.me.uk> wrote:
> >On Wed, 27 May 2026, H. Peter Anvin wrote:
> >  
> >> >> If full precision is enabled there are a whole lot of horrid corner cases.
> >> >> Mostly due to correctly generating the FP signals when the 80bit return
> >> >> value from a function is written to a 64bit 'double'.  
> >> >
> >> > No IEEE quad for `long double' still, not even on 64-bit hw?  Weird.  
> >> 
> >> The ABI was designed in 2003 or so...  
> >
> > Hmm, usually it's hardware that gets features first with software to 
> >follow.  For instance by now the POWER port has gained three `long double' 
> >formats in their psABI, all of which can coexist in a single system (I got 
> >that covered in the course of the glibc test improvement effort too).
> >
> >  Maciej  
> 
> The x87 psABI does have a __float128 type IIRC.
> 

Isn't that the 16bit exponent, 64bit mantissa of the x87 fpu?
It has to aligned so there are 48bits unused.

-- David