FPC conformance

Free Pascal's own test suite, run against the pxx Pascal frontend. wontfix = probes FPC internals or an intentional divergence (never counts against us); gap = a real unimplemented feature; untriaged = skip-listed, not yet classified; auto-gated = needs suite infra or other targets we don't model here. What each language targets lives under Compliance.

pass
427
fail
1
skip
gap 38 · wontfix 23 · untriaged 0
auto-gated
50
pass rate (excl. wontfix/auto)
89.5%

By category

Categorypassfailskipauto
tarray 11 7 2
tarrconstr 6 2
tcase 50 4
tclass 16 8 6
tdefault 12 2 1
tenum 6 1
terecs 28 1 2 1
texception 2 2 6
tforin 24 4
tgenconstraint 40
tgeneric 91 9 7
tgenfunc 9 6 5
tint64 3 1
tinterface 0 2 4
tmoperator 3 8
tobject 3 3 4
toperator 90 2 4
tover 1 3
tprocvar 0 3
tprop 2 2
trange 4 2
tsealed 5 1
tset 10 1 2
tstatic 5
tstring 6 4 1

All tests (550)

statusnamecategorytagreason
auto tarray4.pp tarray knownrunerror
auto tarray9.pp tarray opt
auto tcase45.pp tcase unit-source
auto tcase46.pp tcase unit-source
auto tcase47.pp tcase unit-source
auto tcase48.pp tcase unit-source
auto tclass1.pp tclass version
auto tclass2.pp tclass version
auto tclass4.pp tclass opt
auto tclass6.pp tclass version
auto tclass7.pp tclass version
auto tclass8.pp tclass version
auto tdefault15.pp tdefault target=darwin
auto terecs_u1.pp terecs unit-source
auto texception4.pp texception opt
auto texception5.pp texception version
auto texception6.pp texception version
auto texception7.pp texception version
auto texception8.pp texception version
auto texception9.pp texception version
auto tgeneric103.pp tgeneric unit-source
auto tgeneric104.pp tgeneric recompile
auto tgeneric105.pp tgeneric unit-source
auto tgeneric74.pp tgeneric recompile
auto tgeneric75.pp tgeneric recompile
auto tgeneric76.pp tgeneric unit-source
auto tgeneric77.pp tgeneric unit-source
auto tgenfunc14.pp tgenfunc unit-source
auto tgenfunc15.pp tgenfunc unit-source
auto tgenfunc16.pp tgenfunc unit-source
auto tgenfunc17.pp tgenfunc unit-source
auto tgenfunc18.pp tgenfunc unit-source
auto tint644.pp tint64 opt
auto tinterface1.pp tinterface version
auto tinterface2.pp tinterface version
auto tinterface3.pp tinterface version
auto tinterface5.pp tinterface version
auto tobject10.pp tobject opt
auto tobject3.pp tobject opt
auto tobject8.pp tobject opt
auto tobject9.pp tobject opt
auto toperator2.pp toperator unit-source
auto toperator3.pp toperator unit-source
auto toperator4.pp toperator unit-source
auto toperator5.pp toperator version
auto trange1.pp trange version
auto trangeob.pp trange opt
auto tset5.pp tset opt
auto tset6.pp tset opt
auto tstring6.pp tstring version
fail terecs4.pp terecs UNKNOWN-TAG:accepted-invalid %FAIL test compiled
pass tarray1.pp tarray
pass tarray10.pp tarray
pass tarray11.pp tarray
pass tarray12.pp tarray
pass tarray16.pp tarray
pass tarray17.pp tarray
pass tarray19.pp tarray
pass tarray20.pp tarray
pass tarray3.pp tarray
pass tarray5.pp tarray
pass tarray8.pp tarray
pass tarrconstr1.pp tarrconstr
pass tarrconstr3.pp tarrconstr
pass tarrconstr4.pp tarrconstr
pass tarrconstr6.pp tarrconstr
pass tarrconstr7.pp tarrconstr
pass tarrconstr8.pp tarrconstr
pass tcase0.pp tcase
pass tcase1.pp tcase
pass tcase10.pp tcase
pass tcase11.pp tcase
pass tcase12.pp tcase
pass tcase13.pp tcase
pass tcase14.pp tcase
pass tcase15.pp tcase
pass tcase16.pp tcase
pass tcase17.pp tcase
pass tcase18.pp tcase
pass tcase19.pp tcase
pass tcase2.pp tcase
pass tcase20.pp tcase
pass tcase21.pp tcase
pass tcase22.pp tcase
pass tcase23.pp tcase
pass tcase24.pp tcase
pass tcase25.pp tcase
pass tcase26.pp tcase
pass tcase27.pp tcase
pass tcase28.pp tcase
pass tcase29.pp tcase
pass tcase3.pp tcase
pass tcase30.pp tcase
pass tcase31.pp tcase
pass tcase32.pp tcase
pass tcase33.pp tcase
pass tcase34.pp tcase
pass tcase35.pp tcase
pass tcase36.pp tcase
pass tcase37.pp tcase
pass tcase38.pp tcase
pass tcase39.pp tcase
pass tcase4.pp tcase
pass tcase40.pp tcase
pass tcase41.pp tcase
pass tcase42.pp tcase
pass tcase43.pp tcase
pass tcase44.pp tcase
pass tcase45_2.pp tcase
pass tcase46_2.pp tcase
pass tcase47_2.pp tcase
pass tcase48_2.pp tcase
pass tcase5.pp tcase
pass tcase50.pp tcase
pass tcase6.pp tcase
pass tcase7.pp tcase
pass tcase8.pp tcase
pass tcase9.pp tcase
pass tclass10.pp tclass
pass tclass10a.pp tclass
pass tclass10b.pp tclass
pass tclass10c.pp tclass
pass tclass11a.pp tclass
pass tclass12c.pp tclass
pass tclass12d.pp tclass
pass tclass13a.pp tclass
pass tclass13b.pp tclass
pass tclass13d.pp tclass
pass tclass14a.pp tclass
pass tclass14b.pp tclass
pass tclass17.pp tclass
pass tclass3.pp tclass
pass tclass9.pp tclass
pass tclassinfo1.pp tclass
pass tdefault10.pp tdefault
pass tdefault11.pp tdefault
pass tdefault12.pp tdefault
pass tdefault13.pp tdefault
pass tdefault14.pp tdefault
pass tdefault2.pp tdefault
pass tdefault3.pp tdefault
pass tdefault4.pp tdefault
pass tdefault6.pp tdefault
pass tdefault7.pp tdefault
pass tdefault8.pp tdefault
pass tdefault9.pp tdefault
pass tenum1.pp tenum
pass tenum2.pp tenum
pass tenum3.pp tenum
pass tenum4.pp tenum
pass tenum5.pp tenum
pass tenum6.pp tenum
pass terecs10.pp terecs
pass terecs11.pp terecs
pass terecs12.pp terecs
pass terecs12a.pp terecs
pass terecs12b.pp terecs
pass terecs12c.pp terecs
pass terecs12d.pp terecs
pass terecs13.pp terecs
pass terecs13a.pp terecs
pass terecs13b.pp terecs
pass terecs13c.pp terecs
pass terecs13d.pp terecs
pass terecs14.pp terecs
pass terecs15.pp terecs
pass terecs16.pp terecs
pass terecs17.pp terecs
pass terecs17a.pp terecs
pass terecs18.pp terecs
pass terecs18a.pp terecs
pass terecs19.pp terecs
pass terecs2.pp terecs
pass terecs21.pp terecs
pass terecs3.pp terecs
pass terecs5.pp terecs
pass terecs6.pp terecs
pass terecs7.pp terecs
pass terecs8.pp terecs
pass terecs9.pp terecs
pass texception1.pp texception
pass texception2.pp texception
pass tforin1.pp tforin
pass tforin10.pp tforin
pass tforin11.pp tforin
pass tforin12.pp tforin
pass tforin13.pp tforin
pass tforin14.pp tforin
pass tforin16.pp tforin
pass tforin17.pp tforin
pass tforin18.pp tforin
pass tforin19.pp tforin
pass tforin2.pp tforin
pass tforin20.pp tforin
pass tforin21.pp tforin
pass tforin22.pp tforin
pass tforin23.pp tforin
pass tforin24.pp tforin
pass tforin25.pp tforin
pass tforin26.pp tforin
pass tforin27.pp tforin
pass tforin28.pp tforin
pass tforin4.pp tforin
pass tforin5.pp tforin
pass tforin8.pp tforin
pass tforin9.pp tforin
pass tgenconstraint1.pp tgenconstraint
pass tgenconstraint10.pp tgenconstraint
pass tgenconstraint11.pp tgenconstraint
pass tgenconstraint12.pp tgenconstraint
pass tgenconstraint13.pp tgenconstraint
pass tgenconstraint14.pp tgenconstraint
pass tgenconstraint15.pp tgenconstraint
pass tgenconstraint16.pp tgenconstraint
pass tgenconstraint17.pp tgenconstraint
pass tgenconstraint18.pp tgenconstraint
pass tgenconstraint19.pp tgenconstraint
pass tgenconstraint2.pp tgenconstraint
pass tgenconstraint20.pp tgenconstraint
pass tgenconstraint21.pp tgenconstraint
pass tgenconstraint22.pp tgenconstraint
pass tgenconstraint23.pp tgenconstraint
pass tgenconstraint24.pp tgenconstraint
pass tgenconstraint25.pp tgenconstraint
pass tgenconstraint26.pp tgenconstraint
pass tgenconstraint27.pp tgenconstraint
pass tgenconstraint28.pp tgenconstraint
pass tgenconstraint29.pp tgenconstraint
pass tgenconstraint3.pp tgenconstraint
pass tgenconstraint30.pp tgenconstraint
pass tgenconstraint31.pp tgenconstraint
pass tgenconstraint32.pp tgenconstraint
pass tgenconstraint33.pp tgenconstraint
pass tgenconstraint34.pp tgenconstraint
pass tgenconstraint35.pp tgenconstraint
pass tgenconstraint36.pp tgenconstraint
pass tgenconstraint37.pp tgenconstraint
pass tgenconstraint38.pp tgenconstraint
pass tgenconstraint39.pp tgenconstraint
pass tgenconstraint4.pp tgenconstraint
pass tgenconstraint40.pp tgenconstraint
pass tgenconstraint5.pp tgenconstraint
pass tgenconstraint6.pp tgenconstraint
pass tgenconstraint7.pp tgenconstraint
pass tgenconstraint8.pp tgenconstraint
pass tgenconstraint9.pp tgenconstraint
pass tgeneric1.pp tgeneric
pass tgeneric10.pp tgeneric
pass tgeneric100.pp tgeneric
pass tgeneric101.pp tgeneric
pass tgeneric102.pp tgeneric
pass tgeneric106.pp tgeneric
pass tgeneric107.pp tgeneric
pass tgeneric11.pp tgeneric
pass tgeneric12.pp tgeneric
pass tgeneric13.pp tgeneric
pass tgeneric15.pp tgeneric
pass tgeneric16.pp tgeneric
pass tgeneric17.pp tgeneric
pass tgeneric18.pp tgeneric
pass tgeneric19.pp tgeneric
pass tgeneric2.pp tgeneric
pass tgeneric22.pp tgeneric
pass tgeneric24.pp tgeneric
pass tgeneric25.pp tgeneric
pass tgeneric27.pp tgeneric
pass tgeneric28.pp tgeneric
pass tgeneric29.pp tgeneric
pass tgeneric3.pp tgeneric
pass tgeneric31.pp tgeneric
pass tgeneric32.pp tgeneric
pass tgeneric33.pp tgeneric
pass tgeneric34.pp tgeneric
pass tgeneric35.pp tgeneric
pass tgeneric36.pp tgeneric
pass tgeneric37.pp tgeneric
pass tgeneric38.pp tgeneric
pass tgeneric39.pp tgeneric
pass tgeneric40.pp tgeneric
pass tgeneric41.pp tgeneric
pass tgeneric42.pp tgeneric
pass tgeneric43.pp tgeneric
pass tgeneric44.pp tgeneric
pass tgeneric45.pp tgeneric
pass tgeneric46.pp tgeneric
pass tgeneric47.pp tgeneric
pass tgeneric48.pp tgeneric
pass tgeneric49.pp tgeneric
pass tgeneric5.pp tgeneric
pass tgeneric50.pp tgeneric
pass tgeneric51.pp tgeneric
pass tgeneric52.pp tgeneric
pass tgeneric53.pp tgeneric
pass tgeneric54.pp tgeneric
pass tgeneric55.pp tgeneric
pass tgeneric56.pp tgeneric
pass tgeneric57.pp tgeneric
pass tgeneric58.pp tgeneric
pass tgeneric59.pp tgeneric
pass tgeneric6.pp tgeneric
pass tgeneric60.pp tgeneric
pass tgeneric61.pp tgeneric
pass tgeneric62.pp tgeneric
pass tgeneric63.pp tgeneric
pass tgeneric64.pp tgeneric
pass tgeneric65.pp tgeneric
pass tgeneric66.pp tgeneric
pass tgeneric67.pp tgeneric
pass tgeneric68.pp tgeneric
pass tgeneric69.pp tgeneric
pass tgeneric7.pp tgeneric
pass tgeneric70.pp tgeneric
pass tgeneric71.pp tgeneric
pass tgeneric72.pp tgeneric
pass tgeneric73.pp tgeneric
pass tgeneric78.pp tgeneric
pass tgeneric79.pp tgeneric
pass tgeneric8.pp tgeneric
pass tgeneric80.pp tgeneric
pass tgeneric81.pp tgeneric
pass tgeneric82.pp tgeneric
pass tgeneric83.pp tgeneric
pass tgeneric84.pp tgeneric
pass tgeneric85.pp tgeneric
pass tgeneric86.pp tgeneric
pass tgeneric87.pp tgeneric
pass tgeneric88.pp tgeneric
pass tgeneric89.pp tgeneric
pass tgeneric9.pp tgeneric
pass tgeneric90.pp tgeneric
pass tgeneric91.pp tgeneric
pass tgeneric92.pp tgeneric
pass tgeneric93.pp tgeneric
pass tgeneric94.pp tgeneric
pass tgeneric95.pp tgeneric
pass tgeneric96.pp tgeneric
pass tgeneric98.pp tgeneric
pass tgenfunc1.pp tgenfunc
pass tgenfunc11.pp tgenfunc
pass tgenfunc12.pp tgenfunc
pass tgenfunc19.pp tgenfunc
pass tgenfunc2.pp tgenfunc
pass tgenfunc3.pp tgenfunc
pass tgenfunc4.pp tgenfunc
pass tgenfunc8.pp tgenfunc
pass tgenfunc9.pp tgenfunc
pass tint641.pp tint64
pass tint642.pp tint64
pass tint643.pp tint64
pass tmoperator1.pp tmoperator
pass tmoperator11.pp tmoperator
pass tmoperator6.pp tmoperator
pass tobject4.pp tobject
pass tobject5.pp tobject
pass tobject6.pp tobject
pass toperator1.pp toperator
pass toperator10.pp toperator
pass toperator11.pp toperator
pass toperator12.pp toperator
pass toperator13.pp toperator
pass toperator14.pp toperator
pass toperator15.pp toperator
pass toperator16.pp toperator
pass toperator17.pp toperator
pass toperator18.pp toperator
pass toperator19.pp toperator
pass toperator20.pp toperator
pass toperator21.pp toperator
pass toperator22.pp toperator
pass toperator23.pp toperator
pass toperator24.pp toperator
pass toperator25.pp toperator
pass toperator26.pp toperator
pass toperator27.pp toperator
pass toperator28.pp toperator
pass toperator29.pp toperator
pass toperator30.pp toperator
pass toperator31.pp toperator
pass toperator32.pp toperator
pass toperator33.pp toperator
pass toperator34.pp toperator
pass toperator35.pp toperator
pass toperator36.pp toperator
pass toperator37.pp toperator
pass toperator38.pp toperator
pass toperator39.pp toperator
pass toperator40.pp toperator
pass toperator41.pp toperator
pass toperator42.pp toperator
pass toperator43.pp toperator
pass toperator44.pp toperator
pass toperator45.pp toperator
pass toperator46.pp toperator
pass toperator47.pp toperator
pass toperator48.pp toperator
pass toperator49.pp toperator
pass toperator50.pp toperator
pass toperator51.pp toperator
pass toperator52.pp toperator
pass toperator53.pp toperator
pass toperator54.pp toperator
pass toperator55.pp toperator
pass toperator56.pp toperator
pass toperator57.pp toperator
pass toperator58.pp toperator
pass toperator59.pp toperator
pass toperator60.pp toperator
pass toperator61.pp toperator
pass toperator62.pp toperator
pass toperator63.pp toperator
pass toperator64.pp toperator
pass toperator65.pp toperator
pass toperator66.pp toperator
pass toperator67.pp toperator
pass toperator68.pp toperator
pass toperator69.pp toperator
pass toperator7.pp toperator
pass toperator70.pp toperator
pass toperator71.pp toperator
pass toperator72.pp toperator
pass toperator73.pp toperator
pass toperator74.pp toperator
pass toperator75.pp toperator
pass toperator76.pp toperator
pass toperator77.pp toperator
pass toperator79.pp toperator
pass toperator8.pp toperator
pass toperator80.pp toperator
pass toperator81.pp toperator
pass toperator82.pp toperator
pass toperator83.pp toperator
pass toperator84.pp toperator
pass toperator85.pp toperator
pass toperator86.pp toperator
pass toperator87.pp toperator
pass toperator88.pp toperator
pass toperator89.pp toperator
pass toperator9.pp toperator
pass toperator90.pp toperator
pass toperator91.pp toperator
pass toperator92.pp toperator
pass toperator93.pp toperator
pass toperator94.pp toperator
pass toperator95.pp toperator
pass toperatorerror.pp toperator
pass tover2.pp tover
pass tprop.pp tprop
pass tprop2.pp tprop
pass trange2.pp trange
pass trange3.pp trange
pass trange4.pp trange
pass trange5.pp trange
pass tsealed1.pp tsealed
pass tsealed2.pp tsealed
pass tsealed3.pp tsealed
pass tsealed4.pp tsealed
pass tsealed5.pp tsealed
pass tset1.pp tset
pass tset2.pp tset
pass tset2a.pp tset
pass tset2b.pp tset
pass tset2c.pp tset
pass tset2d.pp tset
pass tset3.pp tset
pass tset4.pp tset
pass tset5a.pp tset
pass tset7.pp tset
pass tstatic1.pp tstatic
pass tstatic2.pp tstatic
pass tstatic3.pp tstatic
pass tstatic4.pp tstatic
pass tstatic5.pp tstatic
pass tstring1.pp tstring
pass tstring2.pp tstring
pass tstring5.pp tstring
pass tstring7.pp tstring
pass tstring8.pp tstring
pass tstring9.pp tstring
skip tarray13.pp tarray gap MEASURED 2026-09-09 at compiler 7d1893a9a54e -- DynArraySize IS SUPPLIED NOW (moved into compiler/builtin/builtin.pas, task-b-nineteen-sysutils-names-that-fpc-keeps-in-system), and the file advances from line 23 to LINE 67: `undefined variable (DynArrayIndex)`. DynArrayIndex and DynArraySetLength are what is left, and they are a different animal from DynArraySize -- that one reads the managed-block header word Length() already reads, while these two need dynamic-array RTTI to know the ELEMENT SIZE from an untyped Pointer. EVERYTHING PAST LINE 67 IS UNVERIFIED.
skip tarray14.pp tarray gap MEASURED at compiler caa8808fda7c -- concatenation with an element list on ONE side now works in every spelling (`a + [x]`, `[x] + a`, `a += [x]`, `Concat(a, [x])`, either order; see test_a_dynamic_array_concatenates_with_an_element_list, and its twin tarray17 is burned). What is left is line 70: `Concat([1, 2, 3], [6, 8, 10])` with BOTH operands element lists, where nothing in the expression names the element type -- fpc takes it from the assignment destination and the expression parser has no channel carrying that. WAS A SILENT WRONG ANSWER AND IS NOW A REFUSAL: it compiled clean and answered len=4310464 against fpc's 6 (verified pre-existing against the stashed compiler), and reported the damage at line 100, `end.`. The refusal names the line and what would be needed. Burning this needs a destination-type channel into expression parsing, which is a design change and not a gate widening.
skip tarray15.pp tarray gap MEASURED at compiler 1619c9df16f4 — LINE 36, `v6: array of array[0..2] of LongInt = ((1, 2, 3), (4, 5, 6))`: a DECLARATION initialiser for a dynamic array of FIXED ROWS. fpc accepts it (and REFUSES the statement spelling of the same literal, which pxx now refuses too, matching). We refuse it deliberately rather than emit the silent garbage the retag produced: a row is bytes inside the outer block, not a handle, so the open-array ctor lowering has nothing to build. Needs a pending-init that emits a STATEMENT (SetLength + per-element stores) rather than one assignment. The TYPE now parses and its row bounds are right — see test_a_dynamic_array_of_fixed_rows_has_row_bounds. Its Delphi twin tarray16 is burned. EVERYTHING PAST LINE 36 IS UNVERIFIED.
skip tarray18.pp tarray gap `class operator := (a: array of LongInt): TTest1` -- an OPEN ARRAY as an operator's operand type, line 46, `operator overloading: array is not a supported operand type` (OperandTypeKindRec resolves records, classes, string/ansistring and BuiltinTypeNameTk and nothing else). WALL MOVED 2026-09-06 at d674faa3ea21, from line 37: the previous reason was `specialize` in RESULT-TYPE position, which was really TArray not being ambient -- fixed by compiler/builtin/sysgenerics.pas, and the result-type spelling was never the problem. Everything past 46 is UNVERIFIED
skip tarray2.pp tarray wontfix array of const / TVarRec — diffed line by line vs fpc 3.2.2 at compiler e313d353df5f. Every tag and value matches except two rows, neither a defect: one prints @Testit's ADDRESS, and the two Extended rows follow from this RTL modelling Extended as Double (CLAUDE.md records that as the architecture). The four that WERE defects are fixed — VPChar printed its pointer, VObject.ClassName was empty, a class reference tagged vtPointer(5) not vtClass(8), QWord(x) tagged vtInt64(16) not vtQWord(17). The old reason named none of them because it described the FILE, not the line the output diverges on. Detail: working/feature-pascal-corpus-fpc-testsuite.md
skip tarray6.pp tarray gap REASON CORRECTED 2026-09-06 at compiler d697a8a680fd -- BOTH HALVES OF THE OLD REASON WERE STALE OR WRONG. It COMPILES: local var-section initializers work, and the whole ansi half is byte-identical to fpc measured in isolation (`S = pc`, `S = ca`, `S := pc`, `S := ca` on AnsiString/PChar/array-of-Char all correct). Nor is it a refusal any more: it runs, EXITS 0, and prints 8 of 22 lines -- a SILENT WRONG ANSWER, so do not read this skip as a parse gap. The live wall is one thing and it is filed: bug-p-a-string-literal-bound-to-a-pwidechar-is-emitted-narrow. `pw: PWideChar = 'abcd'` gets a narrow literal, so `Length(pw)` answers 4261104 against fpc's 4 and every later comparison against pw/wa is false. AND {$define PXX_WIDE_PAYLOAD} DOES NOT FIX IT (measured both sides), so this row is NOT gated on chore-a-decide-whether-widestring-can-come-out-from-behind-pxx-wide-payload the way tover1/tstring10/tstring11 are -- retiring that gate would leave tarray6 exactly here. Reason corrected by frankS; the row stays frankD's.
skip tarray7.pp tarray gap MEASURED at compiler a20c9f373ce4 -- the open-array slice `a[lo..hi]` IS IMPLEMENTED and nine of this file's eleven checks pass (static array incl. a negative low bound, typed-pointer heap block, dynamic array, and the `var` write-back direction; see test_an_open_array_slice_passes_a_sub_range). The last two -- `uppercase(f[1..10])` on a shortstring and on an ansistring -- are REFUSED BY NAME and blocked on bug-a-the-address-of-a-string-element-is-the-literals-address: `@s[i]` on a string assigned a LITERAL answers the literal's address, so the slice's copy-out wrote into the shared literal and changed every other variable holding it. WARNING FOR WHOEVER RETRIES THIS ROW: with the string base enabled it EXITS 0, because it slices f[1..10] -- the WHOLE string -- so the write went to the literal and was read back from the literal, self-consistently. A hand-written f[2..5] is what separated them. Do not burn this on its exit code.
skip tarrconstr2.pp tarrconstr wontfix dialect-pass -- `TAB.create(1 + 2, 'c')` for `TAB = array of byte`. fpc says `Incompatible types: got "Char" expected "Byte"`; pxx stores 99. NOT a hole opened by the constructor: an array constructor stores each element through the NORMAL element-assign path, and `b := 'c'` for a Byte is a defined conversion in this dialect -- AssignKindsIncompatible (symtab.inc) leaves char-to-number alone ON PURPOSE and its own header says so: merely-unidiomatic pairs fpc also rejects belong behind --strict-assign, not in the default check. A constructor stricter than the assignment it lowers to would be the inconsistency. Burn this row the day --strict-assign exists. MEASURED 2026-09-06 at compiler aa3669390683: the identical `D := [1 + 2, 'c']` behaves the same and has no corpus row at all, so this file has a %FAIL row for one spelling of the divergence and nothing for the other. Until today this row PASSED FOR THE WRONG REASON -- pxx rejected it with `undefined variable (TAB)`, having no dynamic-array constructor at all; fixing that (tarrconstr1) is what exposed it, the same shape as the 24 rows the mandatory-header fix exposed in 2026-07-11's re-audit.
skip tarrconstr5.pp tarrconstr gap `array of TSet` where TSet is a SET type, line 47, `unknown type: TSet` -- a set as an open-array element. WALL MOVED 2026-09-06 at d674faa3ea21, from line 14: the previous reason was `inline specialize TArray<specialize TArray<String>> in type decl`, which was TArray not being ambient; the nested inline specialization itself parses. Everything past 47 is UNVERIFIED
skip tclass11b.pp tclass accepts-invalid access control unenforced by project policy — strict private NESTED TYPE reached from a descendant; see bug-pascal-member-visibility-unenforced. (Until 2026-08-25 this test "passed" for the wrong reason — pxx refused it at `TSomeClass.Test;`, a virtual class method as a statement, which was itself a bug: bug-p-a-virtual-class-method-cannot-be-called-as-a-statement.)
skip tclass12a.pp tclass gap Extended-precision Str formatting — value identical, pxx prints double-width 3.1400000000000001E+000 vs FPC's 20-digit extended (no 80-bit Extended print path)
skip tclass12b.pp tclass accepts-invalid access control unenforced by project policy — see bug-pascal-member-visibility-unenforced
skip tclass13.pp tclass wontfix TAG RESTS ON A PREMISE THAT IS PARTLY FALSE. Re-measured 2026-09-06 at 67d173f13: `uses typinfo` resolves and `GetEnumName(TypeInfo(TCol), Ord(cGreen))` prints `cGreen`, byte-identical to fpc 3.2.2 -- so "needs FPC typinfo/RTTI (TypeInfo/GetEnumName)" is not what stops it. It stops at line 56 on `TypeInfo(TRootClass.TNode.TEnum)`: a QUALIFIED NESTED TYPE NAME in an expression, `expected ')' before '.'`, which is the same nested-type gap tclass13a and tclass13c both carry as gap:. Whether RTTI for a NESTED enum then works is UNVERIFIED -- nothing has been behind that wall. Tag left alone rather than flipped on an unverified premise.
skip tclass13c.pp tclass gap accepts-invalid — TRootClass.Integer nested-type member; needs per-class nested-type registry — PARKED (user call 2026-07-11, near-zero value; note in bug-pascal-missing-diagnostics-fail-tests)
skip tclass15.pp tclass gap nested class type + Classes TCustomMemoryStream/SetPointer
skip tclass16.pp tclass gap REASON CORRECTED 2026-09-06 at compiler 0d77c1e48ea4 -- THREE blockers, not the two this row named. (1) plain `threadvar` is refused AT ANY SCOPE, so `class threadvar` is the rung above a rung that does not exist: feature-p-threadvar-is-not-supported-at-any-scope. (2) `class threadvar` inside a class body -- the wall here, line 14, `expected ':' before 'Test'`. (3) the RTLEvent family (PRTLEvent, RTLEventCreate, RTLeventSetEvent, RTLeventWaitFor, RTLEventDestroy) is absent from lib/rtl: feature-b-the-rtlevent-family-is-absent-from-the-threading-rtl. NOT the general threading RTL, which is present and tested -- BeginThread, WaitForThreadTerminate, TThreadID, EndThread and a native TThread all exist (lib/rtl/palthreadobj.pas, lib/rtl/cthreads.pas, test/lib_fpc_thread_surface.pas). A first probe reported the whole threading RTL missing and that was the PROBE omitting its uses clause, not the RTL. Burning this row needs all three; no single ticket does it. Paired with terecs20.pp, same construct in a record.
skip tclass5.pp tclass gap class constructor `fail` + range-check error 210 semantics
skip tdefault1.pp tdefault wontfix needs FPC `variants` unit as shipped (Default() over Variant types)
skip tdefault5.pp tdefault gap Default() on record/object containing TextFile field (delphi mode)
skip tenumerators1.pp tenum gap NARROWED 2026-09-09 at compiler 177239049b43 -- three of its five sections now RUN and the residual is one missing CLASS FAMILY, not the enumerator mechanism it was filed as. TList/TFPList/TStrings/TComponent enumerators are declared in lib/rtl/classes.pas with FPC's own type names and the hand-driven MoveNext/Current protocol this file uses (fixture test/lib_classes_enumerators, 25 rows, byte-identical to fpc 3.2.2 under BOTH the HEAD and the PINNED compiler). THE WALL IS NOW LINE 71: TCollection / TCollectionItem / TCollectionEnumerator do not exist in this RTL at all -- `TCollection.Create(TCollectionItem)` fails with `a statement cannot start with .`, which is the parser hitting an unknown type and not a for-in problem. TRACK B, lib/rtl/classes.pas. Once TCollection exists this row should pass with no further work; re-measure rather than assume, because that is a prediction and not a measurement.
skip terecs1.pp terecs gap accepts-invalid -- RECORD member visibility is not enforced. Measured 2026-09-06: a cross-unit read of a `private` field of a RECORD compiles under every flag, and fpc 3.2.2 rejects it with `identifier idents no member`. CLASSES ARE NOT THE SAME SHAPE and the first version of this line said they were: `--strict-visibility` (EnforceMemberVis, pasparser_class.inc:58) rejects a private and a strict private CLASS field and is SILENT on records -- so the honest claim is that the lax default is a stated dialect choice, the opt-in parity flag covers classes only, and the conformance runner does not pass it in any case (bug-p-strict-visibility-is-silent-on-records). NOT A REGRESSION: the pinned compiler accepts all of it too. The row was green for an UNRELATED reason and the mask lifted at d349b85ef -- a parameterless `class constructor` in terecs_u1 used to be refused with `a record constructor must have at least one parameter without a default value`, so pxx never reached the private access and the %fail row passed on the wrong error. Us accepting what fpc rejects is not a defect, so this is a missing diagnostic and a reminder, not open work
skip terecs20.pp terecs gap REASON CORRECTED 2026-09-06 at compiler 0d77c1e48ea4 -- the RECORD twin of tclass16.pp and the same three blockers in the same order, wall at line 15, `expected ':' before 'Test'`. See tclass16.pp's row for the measurement; the two differ only in `TTest = record` vs `TTest = class`, so do not re-measure them separately. feature-p-threadvar-is-not-supported-at-any-scope + feature-b-the-rtlevent-family-is-absent-from-the-threading-rtl.
skip texception10.pp texception gap THE STATEMENT HALF IS FIXED (2026-09-07, compiler c3b9c27982f0) -- `TMyObject.Create(nil);` with no destination is legal FPC (it constructs and drops the reference, which leaks, and the leak is the programmer's business, not a parse error); BuildMetaclassNew hands back AN_METACLASS_NEW, which is not one of ASTNodeIsCall's five kinds, so the statement parser fell to Expect(':=') and reported `expected ':=' before ';'`. The row now COMPILES. WHAT IS LEFT is the other half and it is DECIDED TERRITORY, not a gap anyone should take: the ctor dereferences nil on purpose and fpc catches the fault as a catchable `Exception` with Message='Access violation', which is item 3 of decide-segv-runtime-error-default (rainy-day, prio 10) -- `a catchable EAccessViolation from signal context ... its own sitting`. MEASURED 2026-09-07: pxx prints the first `Creating the first time` and then SIGSEGVs (exit 139) where fpc prints all five lines and exits 0. Burn this row the day that decision lands, not before.
skip texception3.pp texception wontfix allocator introspection, NOT exception handling. Re-measured 2026-09-06 with the real corpus: the row compiles, runs, and passes ALL 119 exception sub-tests. Its only failure is the final `if DoMem(mem)<>0 then do_error(99999)`, which asserts that GetFPCHeapStatus.CurrHeapUsed returns to its prior value across the whole run. CONTROL, measured: a program with NO exceptions at all -- 100 IntToStr/concat iterations -- reports Lost=208 under pxx and Lost=64 under FPC, so `DoMem<>0` is not a leak detector in either compiler; it is an allocator high-water reading, and pxx bump-allocates from one arena. The pxx allocation CENSUS (-dPXX_ALLOC_CENSUS) shows no runaway on the reduced raise/handle loop (allocs=1871 frees=1868 live=3). The old reason ("RTL ExitCode variable missing; try/finally with exit/break/continue") is stale in both clauses. Residual question, owned: bug-b-currheapused-does-not-return-to-its-prior-value-after-a-freed-block.
skip tforin15.pp tforin gap THE WALL MOVED 2026-09-07 at compiler 029799e446d5, and the old reason DESCRIBED THE STATE AFTER THE FIRST HALF RATHER THAN THE ONE IT WAS IN. It said the two `operator enumerator` declarations 'cannot be told apart'; they never got that far -- `OperandTypeKindRec` refused `Twice` outright with `Twice is not a supported operand type`, so the second declaration did not parse and the row was a REFUSAL, not a collision. That refusal was not about distinctness at all: a PLAIN `type TInt = Integer` was refused identically, and fpc 3.2.2 accepts `operator enumerator(a: TInt): T` and prints 7. Fixed, plus the use-site half (a container that is an EXPRESSION never reached the operator table); fixture test/test_for_in_operator_enumerator_on_an_alias_and_an_expression.pas, five rows, all matching fpc. WHAT IS LEFT is now exactly what the old reason described: this file compiles and RUNS, printing 1 where fpc prints 2, because `Twice` and `Integer` register under one key (tyInteger, REC_NONE) and the first row declared wins. MADE LOUD RATHER THAN LEFT SILENT -- the compiler now warns `operator is already overloaded for these operand types` at the second declaration, so the wrong answer announces itself; a silent wrong answer would have been worse than the refusal it replaced. Burning this row needs alias IDENTITY in the operator table AND at the use site (`Twice(1)` is a cast with no symbol, and only AN_IDENT arguments carry SymAliasIdx today) -- the channel bug-p-a-distinct-type-declaration-is-parsed-but-is-not-distinct built for overloads, extended to operators. Do not half-plumb it; that ticket settled that a channel which guesses is worse than one that abstains
skip tforin3.pp tforin wontfix a nil GetEnumerator. fpc emits a nil guard and treats the for-in as an empty loop (this test exists to assert that); pxx reports `Runtime error 216 (nil reference)` and stops. MEASURED that ours is the deliberate emitted nil-check and not a fault: with --no-nil-check the same program SEGFAULTS, so the 216 is feature-a-emitted-nil-checks turning a fault into a located report, which is the check working. CHOSEN, not tolerated: a GetEnumerator returning nil is a mistake in the source -- an empty collection returns an enumerator whose MoveNext is False, not nil -- and the goal doc says an input only produced by a mistake makes FPC's answer not a specification, and to prefer the answer that leaves the mistake visible. Note the alternative is not benign: this test's own MoveNext returns True unconditionally, so "call it anyway" is an infinite loop, and fpc only escapes because it skips the loop entirely. REOPEN on real source that returns nil from GetEnumerator MEANING empty; an fpc test asserting fpc is not that
skip tforin6.pp tforin decided `operator enumerator` for a class returning an `object`-type enumerator. Gated FIRST on decide-old-style-object-types (option A, 28c19f214): the row declares `TMyListEnumerator = object` and stops at the object-type diagnostic before reaching any of that. Re-tagged from gap: 2026-09-06 -- it was advertising chaseable work, and nobody can make progress on it while the decision stands. WHAT IS BEHIND THE DECISION IS UNVERIFIED, exactly as the tobject*/tprocvar1/tsealed6 rows say of themselves: if the decision flips this row is live and must be RE-MEASURED, not assumed still blocked.
skip tforin7.pp tforin decided `enumerator MoveNext` / `enumerator Current` method+property directives. Gated FIRST on decide-old-style-object-types (option A, 28c19f214): the row declares `TMyListEnumerator = object` and stops at the object-type diagnostic before reaching any of that. Re-tagged from gap: 2026-09-06 -- it was advertising chaseable work, and nobody can make progress on it while the decision stands. WHAT IS BEHIND THE DECISION IS UNVERIFIED, exactly as the tobject*/tprocvar1/tsealed6 rows say of themselves: if the decision flips this row is live and must be RE-MEASURED, not assumed still blocked.
skip tgeneric14.pp tgeneric wontfix dialect-pass — test header says %fail is an FPC IMPLEMENTATION limitation ("assembler symbols not global"), not a language rule — PXX passing is correct
skip tgeneric20.pp tgeneric wontfix dialect-pass — generic method impl without <T> marker — PXX's generics surface deliberately accepts the stripped form (3d71edcf); not a bug
skip tgeneric21.pp tgeneric gap accepts-invalid — a generic nested inside a generic. SEMANTICS NOW VERIFIED (the previous reason said unverified): pxx accepts the DECLARATION and refuses every USE -- `specialize TO1.TInner<Integer>` gives `expected '<' before '.'` -- so we do not support nested generics, we only fail to reject them. NOT a dialect-pass for that reason. The mistake is still visible, just at the use site instead of the declaration, so this is a differing diagnostic rather than a wrong value; rank it accordingly
skip tgeneric23.pp tgeneric wontfix requires FPC `fgl` unit as shipped (TFPGList)
skip tgeneric26.pp tgeneric wontfix dialect-pass — a type parameter in a VARIANT part. fpc forbids it; pxx supports it and MEASURED correct, which is what separates this from the other accepts-invalid rows: `specialize TRecArr<Integer>` compiles, `a[0].F := 7` then reads `a[0].Z` as 7, i.e. the variant cases alias as a variant must. Verified for internal consistency only -- fpc rejects the source, so there is no oracle to diff against, and that limit is the reason this says what was checked rather than 'works'. Accepting what FPC rejects is not a defect (the goal doc), and here the accepted construct does the right thing rather than merely parsing
skip tgeneric30.pp tgeneric wontfix dialect-pass — mode-delphi generic method impl without <T> — PXX's Delphi-generics rewriter deliberately accepts the bare name (3d71edcf); not a bug
skip tgeneric4.pp tgeneric wontfix dialect-pass -- pxx compiles this %FAIL row and RUNS IT CORRECTLY. MEASURED 2026-09-06: prints `Unit`, exit 0, which is what the row's OWN assertion demands (`if slist.data<>'Unit' then halt(1)`); on pin v404 it printed `Program` and halted 1, the silent wrong answer bug-p-a-generic-template-body-resolves-its-symbols-at-the-specialization-site fixed. The `{ %fail }` records an FPC LIMITATION its own comment states -- "should found the LocalFill in ugeneric4, but for the moment that is not allowed since the assembler symbol is not global" -- not a rule the language wants; accepting what FPC rejects is not a defect (CLAUDE.md). REGRESSION ASSERTION: test_gen_declunit26 (test/test_generic_body_binds_in_its_declaring_unit.pas), whose row 1 fails if the program's copy ever wins again.
skip tgeneric97.pp tgeneric wontfix expects FPC's internal specialized ClassName 'ttest<system.longint>'
skip tgeneric99.pp tgeneric gap REASON SHARPENED 2026-09-07 at compiler cd30ba1c7d5d -- THE WALL MOVED FROM ugeneric99.pp:11 TO :25 AND THE OLD REASON NAMED ONLY THE FORMS FURTHER DOWN. Line 11 was `TTestT = specialize TTest<T>` inside `generic TTest<T>` -- a nested type naming its OWN template, which is not qualified-specialize syntax at all and is now fixed (bug-p-a-nested-type-that-specializes-its-own-template-is-renamed-to-the-outer-specialization, fixture test_selfnesttype26). The wall is now line 25, `t: specialize TTest<LongInt>.TTestClass` -- a nested type reached THROUGH an inline specialization, reported as `unknown type: TTestClass`. AFTER THAT the old reason is correct and is what remains: `ugeneric99.specialize TTest<LongInt>` and `TTestClass.specialize TTest<LongInt>`, i.e. a unit or a type qualifier BEFORE the `specialize` keyword. %NORUN, so this row needs only to COMPILE -- do not look for an output oracle. Three separate jobs behind one row; burn it only when the qualified forms parse, and re-measure the wall line first because it has now moved twice.
skip tgenfunc10.pp tgenfunc gap REASON WENT STALE, CORRECTED 2026-09-07 at compiler 46709f4e7648 -- and it was TRUE WHEN WRITTEN, which the first version of this correction got wrong. The old reason read "inline `specialize` expression inside generic function body". It was written 2026-07-12 (55658626a, the triage of 205 untagged skips), when SpecializeInlineGenericFuncUses did not exist at all and the neighbouring rows read "generic (standalone) functions + inline specialize call expression" and "generic class functions not supported" -- so the inline specialize USE genuinely was this row's first wall. It stopped being the wall when that machinery landed, and nothing re-checks a reason when its blocker is removed. Read literally against today's file the phrase is false (the file is { %NORUN }, the generic's body is the single field access `Result := aArg.Test`, and both `specialize Test<TTest>(t)` calls sit in ORDINARY procedures) -- but false-now and false-when-written are different failures and only the second would be carelessness. Reading it turned up a real bug that had nothing to do with the recorded reason -- the specializer rewrote every token spelled like the template name, so the FIELD `Test` became `Test_TTestGlobal`; fixed, fixture test/test_specialization_does_not_rename_after_a_dot.pas. WHAT IS LEFT is the second blocker, now the only one: `unknown type: TTest`. The two TTest types are ROUTINE-LOCAL and a routine-local type is not visible as a specialization argument. This file is the corpus row for bug-p-a-specializations-concrete-argument-is-keyed-by-its-spelling-so-two-scopes-types-collide and is well chosen for it: the two locals are deliberately DIFFERENT (one LongInt, one String), so a spelling-keyed cache collides even once visibility is fixed. Both halves must land before this burns. -- AND THE FIRST HALF IS A PASS-ORDER PROBLEM, measured 2026-09-08 at dffc987ce33e: the routine-local type is not out of scope at the splice point, it does not EXIST there. ParseSubroutine skips a routine body outright while PreScanPass is set, so a local `type` section is parsed in pass 2, strictly after FlushPendingFuncSpecializations empties the queue at the end of the declaration section. One routine and one local type reproduce it, so the two-scopes collision this row is chosen for cannot be reached yet; the same program with TTest declared at unit level compiles and runs. The fix direction (instantiate during pass 2 inside the using routine, where nested routines already keep two same-named siblings distinct and the keying collision dissolves) is costed in the ticket
skip tgenfunc13.pp tgenfunc wontfix dialect-pass -- the METHOD twin of tgenfunc14, and NEW TODAY: pin v404 REJECTED this row (the generic-method header did not parse at all), 1364d9542 makes it parse, so pxx now accepts a %FAIL row it used to refuse by accident rather than by rule. MEASURED 2026-09-06 that the rule is the same one tgenfunc14 records: constraints on generic METHODS are parsed and DROPPED -- a CONTRADICTORY pair (declared `<T: class>`, implemented `<T: record>`, specialized with `Integer`, which is neither) compiles and runs. So the repeat FPC forbids produces no wrong answer and refuses no legal code. RE-MEASURE IF CONSTRAINT CHECKING IS EVER ADDED: the repeated and contradictory forms stop being equivalent the moment either side is enforced, and this row becomes a real FAIL again.
skip tgenfunc23.pp tgenfunc gap REASON SHARPENED 2026-09-06 -- the sibling half is REAL and is the one tgenfunc8 did NOT cover. `Test<T>(const aArg: T)` and `Test<T>(const aArg: array of T)` are siblings at one type arity AND at one VALUE-parameter count (both take exactly one), so the pair (name, parameter count) that separates tgenfunc8's overloads cannot separate these: only `Test_LongInt(LongInt)` is emitted and the array call reports `no overload of Test_LongInt matches these arguments / argument types: (set)`. Telling them apart needs the specialized PARAMETER TYPES, i.e. a comparison after substitution, which the guard makes before anything is emitted. SECOND WALL IN THE SAME LINE, and the diagnostic names it: `[1, 2, 3]` is read as a SET, not as an open-array argument -- so even with both bodies present this row needs the open-array literal too. Two mechanisms, not one; do not read the tgenfunc8 fix as most of the way here.
skip tgenfunc5.pp tgenfunc wontfix parses and runs since the generic-method work; the ROW calls an instance method on a never-Created object and pxx raises nil-reference 216 where fpc runs it. Pre-existing and unrelated to generics (an ordinary non-generic method on a nil receiver does the same on pin v403). Adding one `t := TTest.Create` makes it exit 0.
skip tgenfunc6.pp tgenfunc wontfix same as tgenfunc5 — the Delphi surface of it. Parses now; the row never Creates its receiver and pxx refuses a nil one. With a Create it exits 0.
skip tgenfunc7.pp tgenfunc wontfix parses and runs since the cross-unit generic-method work (1364d9542) -- MEASURED: the row never Creates its receiver, and pxx refuses a nil one. Adding one `t := TTest.Create` makes it exit 0; an ORDINARY non-generic method on a nil receiver gives the same Runtime error 216 on this same build, so it is pre-existing and unrelated to generics. Same shape and same evidence as tgenfunc5/tgenfunc6. REGRESSION ASSERTION: test_gen_xmeth26 (test/test_generic_method_across_a_uses_clause.pas) covers the generic half this row was skipped for.
skip tinterface4.pp tinterface wontfix TAG IS SUSPECT AND THE REASON WAS WRONG. Re-measured 2026-09-06 at 67d173f13: the row stops at `cannot override: no virtual method found in parent chain: AfterConstruction`, because pxx's TObject declares neither AfterConstruction nor BeforeDestruction -- grep of lib/rtl and compiler/ finds the names nowhere. Both are ordinary virtual members of TObject in FPC and in Delphi, so that is a plain gap, not an FPC internal. The variants unit and the IInterface/NewInstance refcount internals this reason used to name may still be needed AFTER it, but the row never reaches them and nobody has measured what is behind the wall. Left wontfix rather than re-tagged because the tag was not established either way here.
skip tinterface6.pp tinterface gap REASON SHARPENED 2026-09-06 at compiler cda68a91bec5 -- THREE CHANGES ACROSS TWO LANES, not one gap. (1) `const g: TGUID = ICom` is REFUSED (`expected '(' before 'ICom'`); (2) `var g: TGUID = ICom` COMPILES AND STORES THE GUID'S ADDRESS instead of its 16 bytes -- a silent wrong value, filed as bug-p-an-interface-name-in-a-var-initialiser-stores-the-guids-address-not-the-guid; (3) IsEqualGUID is absent from lib/rtl/sysutils.pas (zero hits), which is Track B. The interface-name-as-value machinery itself is NOT the gap and already works: `h := ICom` as a statement gives the correct bytes (114 171 182 4 = 04B6AB72 LE, matching fpc), because AN_GUIDCONST exists and the GUID is recorded at declaration. The CORBA half additionally needs a shortstring destination to take the raw UID text (`const s: shortstring = ICorba` is refused too). So this row cannot be burned by one arm, and the var-init silent-wrong-value half is worth fixing on its own merits regardless of this row.
skip tmoperator10.pp tmoperator wontfix probes TypInfo GetTypeData ElType/ElType2 RTTI layout of dyn array
skip tmoperator2.pp tmoperator gap [[feature-a-record-rtti-descriptors-for-initializearray-and-finalizearray]] -- `undefined variable (InitializeArray)`, line 100, measured 2026-09-06 at 88a0b3d93835. `InitializeArray(P, TypeInfo(TFoo), N)` is the RTTI-DRIVEN form of a management operator: handed a pointer and a descriptor, not an lvalue, so the syntactic ticket cannot absorb it. Neither name exists anywhere in compiler/ or lib/rtl. NOT management operators, which are IMPLEMENTED for a local. One of three rows on one cause (tmoperator2/3/9). Everything past that line is UNVERIFIED
skip tmoperator3.pp tmoperator gap [[feature-a-record-rtti-descriptors-for-initializearray-and-finalizearray]] -- `undefined variable (InitializeArray)`, line 82, measured 2026-09-06 at 88a0b3d93835. `InitializeArray(P, TypeInfo(TFoo), N)` is the RTTI-DRIVEN form of a management operator: handed a pointer and a descriptor, not an lvalue, so the syntactic ticket cannot absorb it. Neither name exists anywhere in compiler/ or lib/rtl. NOT management operators, which are IMPLEMENTED for a local. One of three rows on one cause (tmoperator2/3/9). Everything past that line is UNVERIFIED
skip tmoperator4.pp tmoperator gap THE NESTED-FIELD ARM of [[feature-pascal-management-operators-nested-and-array]] -- `a field of a record with a management operator is not managed yet`, line 81, measured 2026-09-06 at 88a0b3d93835. Its previous reason said "management operators across multiple record types", which is not what it stops on and named no ticket. Everything past line 81 is UNVERIFIED
skip tmoperator5.pp tmoperator decided management operator invocation ORDER across a hierarchy -- and the previous reason named only that, which is not what the row stops on. Gated FIRST on decide-old-style-object-types (option A, 28c19f214): the row declares `TA = object` and stops at the object-type diagnostic before reaching any of that. Re-tagged from gap: 2026-09-06 -- it was advertising chaseable work, and nobody can make progress on it while the decision stands. WHAT IS BEHIND THE DECISION IS UNVERIFIED, exactly as the tobject*/tprocvar1/tsealed6 rows say of themselves: if the decision flips this row is live and must be RE-MEASURED, not assumed still blocked. Management operators themselves are IMPLEMENTED (measured 2026-09-06, Initialize/Finalize fire for a local), so the ordering claim was untested speculation about code the compiler never reached.
skip tmoperator7.pp tmoperator gap THE ARRAY ARM of [[feature-pascal-management-operators-nested-and-array]] -- `an array of a record with a management operator is not supported yet`, line 101, measured 2026-09-06 at 88a0b3d93835. IT ONLY REACHES LINE 101 SINCE TODAY: it stopped at line 29 on `undefined variable (InitializeCount)`, a `class var` named unqualified from inside `class operator TFoo.Initialize`, because a class operator body was parsed as a bare global function with no record scope. That was NAME RESOLUTION, not management operators, and this row read it as "the management-operator cluster" because that is what the file is about. Fixed; the 72-line advance is what re-measuring bought
skip tmoperator8.pp tmoperator gap [[feature-pascal-management-operators-copy-and-addref]] -- `operator Copy/AddRef is recognised but not dispatched yet`, line 63, measured 2026-09-06 at 88a0b3d93835. The Initialize/Finalize half of the previous reason is WRONG: those two work and have since slice 3 (both fire for a local, in order). The only live tmoperator row on this ticket. Everything past line 63 is UNVERIFIED
skip tmoperator9.pp tmoperator gap [[feature-a-record-rtti-descriptors-for-initializearray-and-finalizearray]] -- `undefined variable (InitializeArray)`, line 48, measured 2026-09-06 at 88a0b3d93835. `InitializeArray(P, TypeInfo(TFoo), N)` is the RTTI-DRIVEN form of a management operator: handed a pointer and a descriptor, not an lvalue, so the syntactic ticket cannot absorb it. Neither name exists anywhere in compiler/ or lib/rtl. NOT management operators, which are IMPLEMENTED for a local. One of three rows on one cause (tmoperator2/3/9). Everything past that line is UNVERIFIED
skip tobject1.pp tobject decided old-style TP `object` types are not implemented (decide-old-style-object-types, option A, 28c19f214). NOT a gap to chase -- the decision's revisit trigger is a real program needing it, not a conformance row. NO LONGER DOUBLE-BLOCKED, measured 2026-09-06: erroru.pp compiles and runs byte-identical to fpc, so the ONLY thing holding this row is the `object` decision -- if that flips, this row is live and must be re-measured rather than assumed still blocked.
skip tobject2.pp tobject decided old-style TP `object` types are not implemented (decide-old-style-object-types, option A, 28c19f214). NOT a gap to chase -- the decision's revisit trigger is a real program needing it, not a conformance row. Named by that ticket as one of its three acceptance tests, with virtual methods and constructor/destructor.
skip tobject7.pp tobject decided old-style TP `object` types are not implemented (decide-old-style-object-types, option A, 28c19f214). NOT a gap to chase -- the decision's revisit trigger is a real program needing it, not a conformance row. Private nested type, typed const and static class property on top of the base feature.
skip toperator6.pp toperator gap COMPILES AND RUNS, and exits 2 -- a silent wrong answer, not a refusal, so do not read this row's skip as a parse gap. `value := high(int64)+100` must select the QWord `operator :=` overload and selects the Int64 one. MEASURED 2026-09-06: the VALUE is right on both compilers (9223372036854775907) and only the TYPE is wrong -- pxx keeps the fold tyInt64 where fpc promotes it to QWord, so `if (high(int64)+100) > 0` also takes the negative arm. Root cause banked on bug-p-a-constant-expression-that-overflows-int64-stays-signed; the LITERAL half of it is already fixed (10e670503) and does not reach a fold
skip toperator78.pp toperator gap FPC refuses a binary operator overload only when the operation is ALREADY DEFINED for those operand types; pxx approximates that as "at least one operand is a record or class", and the gap is 91 of 209 measured same-type cells. The `**` half of this row now compiles (it gained a token, a precedence level, and an exemption from the aggregate rule); the wall is `operator >< (left, right: LongInt)` at line 9, which fpc accepts because `><` is predefined for SETS only -- NOT the `operator + (LongInt, AnsiString)` at line 14 that the diagnostic NAMES, because the refusal is raised after ParseSubroutine and reports the token past the previous declaration's body. Measured table and both halves of the fix in bug-p-the-operator-predefined-check-is-an-aggregate-approximation; tools/operator_predefined_matrix_probe.py regenerates it. %NORUN, so only the DECLARATIONS have to be accepted -- but a scalar-keyed overload is inert at the use site today, so the declaration half alone would burn this row by accepting operators that never fire
skip tover1.pp tover gap `widestring` is an ALIAS of `ansistring` unless {$define PXX_WIDE_PAYLOAD}, so its two string overloads are one type declared twice. PASSES under that define (measured 2026-09-05) — the overload key itself now carries the element WIDTH. Retiring the gate is chore-a-decide-whether-widestring-can-come-out-from-behind-pxx-wide-payload
skip tover3.pp tover wontfix dialect-pass — overload ambiguity — PXX deterministically ranks (picks longint for cardinal arg) by design; FPC-parity ambiguity errors belong to --strict-overload
skip tover4.pp tover gap 80-bit extended/cextended float type and overload resolution across single/double/extended
skip tprocvar1.pp tprocvar decided old-style TP `object` types are not implemented (decide-old-style-object-types, option A, 28c19f214). NOT a gap to chase -- the decision's revisit trigger is a real program needing it, not a conformance row. Named by that ticket as an acceptance test (same gap as tobject2.pp / tsealed6.pp). Its procvar content passes now — the previous reason named three gaps (method pointers, @Class.Method, typed-const procvars) and a fourth found chasing it (anonymous procedural types); all are fixed, and unskipping shows `object constructor init` is what is left.
skip tprocvar2.pp tprocvar gap typed const procvar initialized with bare proc name (TP mode), procvar via move()
skip tprocvar3.pp tprocvar decided delphi-mode procvar-of-object, @-less proc assignment, codepointer methods. Gated FIRST on decide-old-style-object-types (option A, 28c19f214): the row declares `to1 = object` and stops at the object-type diagnostic before reaching any of that. Re-tagged from gap: 2026-09-06 -- it was advertising chaseable work, and nobody can make progress on it while the decision stands. WHAT IS BEHIND THE DECISION IS UNVERIFIED, exactly as the tobject*/tprocvar1/tsealed6 rows say of themselves: if the decision flips this row is live and must be RE-MEASURED, not assumed still blocked.
skip tprop1.pp tprop gap global `property` section in a program (FPC-mode global properties)
skip tpropdef.pp tprop wontfix depends on FPC Classes/TComponent published-property RTTI streaming (stored/nodefault)
skip tsealed6.pp tsealed decided old-style TP `object` types are not implemented (decide-old-style-object-types, option A, 28c19f214). NOT a gap to chase -- the decision's revisit trigger is a real program needing it, not a conformance row. Named by that ticket as an acceptance test; wants `object abstract` / `object sealed` on top of the base feature.
skip tsetsize.pp tset wontfix asserts FPC's exact set-size/packing layout (SizeOf(set of subrange))
skip tstring10.pp tstring gap punicodechar/pwidechar value casts + unicodestring/widestring conversions (Flush/Output landed)
skip tstring11.pp tstring gap an open `array of WideChar` / `array of AnsiChar` argument binding a UnicodeString/RawByteString parameter. The overload KEY is no longer the blocker — under {$define PXX_WIDE_PAYLOAD} the two Test1 candidates are distinct and the refusal moves to the open-array conversion at line 42; without it they are one type (same alias gate as tover1)
skip tstring3.pp tstring gap THE CHAR HALF IS FIXED (2026-09-06, compiler 3fa98ccccf88) -- a one-character named const is a string initialiser now, so `FDivChars = (c1,c2)` and `FDIVStringS = (s1,s2)` compile; fixture test/test_a_one_character_named_constant_is_a_string_initialiser.pas. WHAT IS LEFT, line 15: a RESOURCESTRING as a typed-const array element (`= (RsFDivFlawed, RsFDivOK)`). Not the same gap and not a lookup miss: a resourcestring is deliberately NOT a constant here -- ParseConstSection routes it to DeclareInitialisedStringVar, i.e. real storage, which is what makes `@S` legal and is what FPC's runtime-replaceable resourcestring is. Its initial span IS recoverable (a PendingInit of Kind=1), but nothing marks the resulting sym AS a resourcestring -- isResStr is a parse-time parameter with no persistent flag -- so a rule keyed on "is a string var with a literal initialiser" would also admit `var s: string = 'x'; const A: shortstring = s;`, which fpc refuses. Needs a sym flag, i.e. a defs.inc slot (message frankH before taking one).
skip tstring4.pp tstring wontfix reads ansistring refcount/length header words -- FPC internal string layout, which we do not claim. Re-measured 2026-09-06 at faa41e4b920f: it compiles (with the suite on the unit path) and runs. CORRECTION to the earlier note here, which said it "diverges only on GetFPCHeapStatus numbers" -- it does not. It also diverges on the Len header words (that IS this wontfix) AND on Str of Comp/Extended/Single. The Extended and Single rows are the decided Extended=Double architecture; the Comp row is a REAL defect hiding behind this skip and is now filed as bug-a-a-float-assigned-to-an-integer-lvalue-moves-the-bits-instead-of-converting. wontfix stands; the reason did not.