Custom Query (1030 matches)
Results (778 - 780 of 1030)
| Ticket | Resolution | Summary | Owner | Reporter |
|---|---|---|---|---|
| #855 | fixed | ARM port pc-lusering fails to recognize allocation sequence | ||
| Description |
Running the simple test case from ticket:717 results in a trip to the kernel debugger with the complaint: unexpected instruction preceding alloc trap. The unexpected instruction is the (relatively new) branch around an unconditional uuo_alloc_trap. If pc_luser_xp() notes that a thread is at the alloc_trap, it expects the immediately preceding instruction to be a comparison, and that's now an instruction earlier. |
|||
| #857 | fixed | ARM fp register tracking | ||
| Description |
The ARM fp unit generally offers at least 32 single-float registers (s0-s31) and at least 16 double-float registers (d0-d15); modern VFP implementations offer more than 16 doubles. s0 and s1 occupy the same 64 bits in a 128-bit vector register as does d0, s2 and s3 conflict with d1, etc. The compiler thinks that (for instance) s1 and d0 are disjoint and thus (at least in theory) might try to keep distinct live values in conflicting FPRs. |
|||
| #871 | fixed | ARITHMETIC-ERROR-OPERANDS, -OPERATION not set to meaningful values on x86, ARM | ||
| Description |
When a SIGFPE (or equivalent) is received, we need to try harder to determine the operation/operands to fully initialize the resulting ARITHMETIC-ERROR condition. On x86, CCL::DECODE-ARITHMETIC-ERROR doesn't try very hard. On ARM, nothing tries at all (though we don't actually get a SIGFPE.) The PPC ports disassembled the instruction that caused the exception; the other ports need to do the same thing. |
|||
