f6/7 idiv r/m8 -- Unexpected results where #DE should have been raised

[mras0]

There are 9 tests where I would expect a divsion error to be signalled, but instead it behaves as if bit 14 of the numerator was flipped, but only in cases where the "new" quotient ends up being 80h.

These tests are (and only those, all other IDIV tests behave as I'd expect):

8813025dcf45588bd5141eb4d7081c67d6cf3ec3 f6.7.MOO.gz 469
c6d731127bec724d40594edc28a6ad8fdf14acbc f6.7.MOO.gz 516
c1392c8316c2d0532d80fb1fcb78832533093e4e f6.7.MOO.gz 850
b674afe8d525fdf51217456b4a3f0b9102350cc4 f6.7.MOO.gz 1265
13e7537c7cd00f676d17da613b4289afb93b338d f6.7.MOO.gz 1754
a4a926d8bbca1f281b0a479fd8c79fe3231bad34 fd.7.MOO.gz 2348
c30147a2fb7f67459cb7a1a4c888b670edd838f5 67f6.7.MOO.gz 375
8bddec44e46b709759d5d1550cd9fa16ab8e89fc 67f6.7.MOO.gz 460
a06745936bac371e6afb861b5bc87be4b2dd676e 67f6.7.MOO.gz 516

Taking f6.7 test 516 as an example (abbreviated):

    "name": "idiv cl",
    "bytes": [246, 249, 244],
    "initial": {
      "regs": {
        "eax": 2708577393,
        "ecx": 732038471,
      },
    "final": {
      "regs": {
        "eax": 2708599168,
      },
    },

I.e. AX = 9c71h = -25487 and CL = 47h = 71. 16-bit quotient = -359 => Should raise #DE.
Instead the result is AH = f1h = -15, AL = 80h = -128, as if the numerator was -128*71-15 = -9103 = dc71h = 9c71h^4000h

This pseudo-code makes the tests pass (surely the logic is not like this, but I don't have a good theory for what trigger this behavior):

if SRC = 0:
  #DE
q16 := AX / SRC
if q16 > 7fh:
  #DE
if q16 < 80h: 
  q16 := (AX ^ 4000h) / SRC
  if q16 <> 80h:
    #DE
  AH := (AX ^ 4000h) mod SRC
else:
  AH := AX mod SRC
AL := q16 & ffh

The other cases are:

648Ch / B7h  25740 / -73
8947h / 6Dh  -30393 / 109
4800h / F0h  18432 / -16
ACE8h / 26h  -21272 / 38
7DBDh / 85h  32189 / -123
741Eh / 98h  29726 / -104
6180h / BDh  24960 / -67
9C71h / 47h  -25487 / 71

EDIT: fd.7 2348 was missing
EDIT2: Now tried the 286 single step tests, and they show the same behavior.

[tremalrik]

IDIV failing to generate the #DE exception in some overflow cases is a known CPU erratum of some Intel 386 and 486 processors - see e.g. 272874-001 Intel 386DX specification update specification change 002 on page 14, or Grzegorz Mazur's old 386/486 bug page at https://web.archive.org/web/19970403004354/http://grafi.ii.pw.edu.pl/gbm/x86/3486bugs.html .