[BUG] Test Failure 2.52.0, t8020.16,19

[BUG] Test Failure 2.52.0, t8020.16,19

[rsbecker]

The following two failures appeared on NonStop for the actual release. I did
not see them in -rc0 or after (doesn't mean they didn't happen after rc0).
To my eyes, this looks like a real issue not just on NonStop. It is 100%
reproducible and is not transient. The build is with OpenSSL 3.4, but that
should not matter.

expecting success of 8020.16 'cross merge boundaries in blaming':
        git checkout HEAD^0 &&
        git rm -rf . &&
        test_commit m1 &&
        git checkout HEAD^ &&
        git rm -rf . &&
        test_commit m2 &&
        git merge m1 &&
        check_last_modified <<-\EOF
        m2 m2.t
        m1 m1.t
        EOF

++ git checkout 'HEAD^0'
Note: switching to 'HEAD^0'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by switching back to a branch.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -c with the switch command. Example:

  git switch -c <new-branch-name>

Or undo this operation with:

  git switch -

Turn off this advice by setting config variable advice.detachedHead to false

HEAD is now at 08525b6 remove a
++ git rm -rf .
rm 'file'
++ test_commit m1
++ local notick=
++ local echo=echo
++ local append=
++ local author=
++ local signoff=
++ local indir=
++ local tag=light
++ test 1 '!=' 0
++ case "$1" in
++ break
++ indir=
++ local file=m1.t
++ test -n ''
++ echo m1
++ git add -- m1.t
++ test -z ''
++ test_tick
++ test -z set
++ test_tick=1112912173
++ GIT_COMMITTER_DATE='1112912173 -0700'
++ GIT_AUTHOR_DATE='1112912173 -0700'
++ export GIT_COMMITTER_DATE GIT_AUTHOR_DATE
++ git commit -m m1
[detached HEAD 53e7187] m1
 Author: A U Thor <author@example.com>
 2 files changed, 1 insertion(+), 1 deletion(-)
 delete mode 100644 file
 create mode 100644 m1.t
++ case "$tag" in
++ git tag m1
++ git checkout 'HEAD^'
Previous HEAD position was 53e7187 m1
HEAD is now at 08525b6 remove a
++ git rm -rf .
rm 'file'
++ test_commit m2
++ local notick=
++ local echo=echo
++ local append=
++ local author=
++ local signoff=
++ local indir=
++ local tag=light
++ test 1 '!=' 0
++ case "$1" in
++ break
++ indir=
++ local file=m2.t
++ test -n ''
++ echo m2
++ git add -- m2.t
++ test -z ''
++ test_tick
++ test -z set
++ test_tick=1112912233
++ GIT_COMMITTER_DATE='1112912233 -0700'
++ GIT_AUTHOR_DATE='1112912233 -0700'
++ export GIT_COMMITTER_DATE GIT_AUTHOR_DATE
++ git commit -m m2
[detached HEAD 9b81a41] m2
 Author: A U Thor <author@example.com>
 2 files changed, 1 insertion(+), 1 deletion(-)
 delete mode 100644 file
 create mode 100644 m2.t
++ case "$tag" in
++ git tag m2
++ git merge m1
Merge made by the 'ort' strategy.
 m1.t | 1 +
 1 file changed, 1 insertion(+)
 create mode 100644 m1.t
++ check_last_modified
++ local indir=
++ test 0 '!=' 0
++ cat
++ git last-modified
++ git name-rev --annotate-stdin --name-only --tags
++ tr '\t' ' '
++ test_cmp expect actual
++ test 2 -ne 2
++ eval 'diff -u' '"$@"'
+++ diff -u expect actual
--- expect      2025-11-19 15:43:34 +0000
+++ actual      2025-11-19 15:43:34 +0000
@@ -1,2 +1,2 @@
+ac29b6e974b49803f1c6ec5a705d1bf7dbfa7d2f m1.t
 m2 m2.t
-m1 m1.t
error: last command exited with $?=1
not ok 16 - cross merge boundaries in blaming



expecting success of 8020.19 'last-modified merge undoes changes':
        git checkout HEAD^0 &&
        git rm -rf . &&
        test_commit b1 file A &&
        test_commit b2 file B &&
        test_commit b3 file C &&
        test_commit b4 file D &&
        git checkout b2 &&
        test_commit b5 file2 2 &&
        git checkout b4 &&
        git merge --no-commit --no-ff b5 &&
        git checkout b2 -- file &&
        git merge --continue &&
        check_last_modified <<-\EOF
        b5 file2
        b2 file
        EOF

++ git checkout 'HEAD^0'
HEAD is now at 7b0602a Merge tag 'a4' into HEAD
++ git rm -rf .
rm 'file'
++ test_commit b1 file A
++ local notick=
++ local echo=echo
++ local append=
++ local author=
++ local signoff=
++ local indir=
++ local tag=light
++ test 3 '!=' 0
++ case "$1" in
++ break
++ indir=
++ local file=file
++ test -n ''
++ echo A
++ git add -- file
++ test -z ''
++ test_tick
++ test -z set
++ test_tick=1112912713
++ GIT_COMMITTER_DATE='1112912713 -0700'
++ GIT_AUTHOR_DATE='1112912713 -0700'
++ export GIT_COMMITTER_DATE GIT_AUTHOR_DATE
++ git commit -m b1
[detached HEAD c48d0f6] b1
 Author: A U Thor <author@example.com>
 1 file changed, 1 insertion(+), 1 deletion(-)
++ case "$tag" in
++ git tag b1
++ test_commit b2 file B
++ local notick=
++ local echo=echo
++ local append=
++ local author=
++ local signoff=
++ local indir=
++ local tag=light
++ test 3 '!=' 0
++ case "$1" in
++ break
++ indir=
++ local file=file
++ test -n ''
++ echo B
++ git add -- file
++ test -z ''
++ test_tick
++ test -z set
++ test_tick=1112912773
++ GIT_COMMITTER_DATE='1112912773 -0700'
++ GIT_AUTHOR_DATE='1112912773 -0700'
++ export GIT_COMMITTER_DATE GIT_AUTHOR_DATE
++ git commit -m b2
[detached HEAD ee27b37] b2
 Author: A U Thor <author@example.com>
 1 file changed, 1 insertion(+), 1 deletion(-)
++ case "$tag" in
++ git tag b2
++ test_commit b3 file C
++ local notick=
++ local echo=echo
++ local append=
++ local author=
++ local signoff=
++ local indir=
++ local tag=light
++ test 3 '!=' 0
++ case "$1" in
++ break
++ indir=
++ local file=file
++ test -n ''
++ echo C
++ git add -- file
++ test -z ''
++ test_tick
++ test -z set
++ test_tick=1112912833
++ GIT_COMMITTER_DATE='1112912833 -0700'
++ GIT_AUTHOR_DATE='1112912833 -0700'
++ export GIT_COMMITTER_DATE GIT_AUTHOR_DATE
++ git commit -m b3
[detached HEAD c90ce7d] b3
 Author: A U Thor <author@example.com>
 1 file changed, 1 insertion(+), 1 deletion(-)
++ case "$tag" in
++ git tag b3
++ test_commit b4 file D
++ local notick=
++ local echo=echo
++ local append=
++ local author=
++ local signoff=
++ local indir=
++ local tag=light
++ test 3 '!=' 0
++ case "$1" in
++ break
++ indir=
++ local file=file
++ test -n ''
++ echo D
++ git add -- file
++ test -z ''
++ test_tick
++ test -z set
++ test_tick=1112912893
++ GIT_COMMITTER_DATE='1112912893 -0700'
++ GIT_AUTHOR_DATE='1112912893 -0700'
++ export GIT_COMMITTER_DATE GIT_AUTHOR_DATE
++ git commit -m b4
[detached HEAD 317a439] b4
 Author: A U Thor <author@example.com>
 1 file changed, 1 insertion(+), 1 deletion(-)
++ case "$tag" in
++ git tag b4
++ git checkout b2
Previous HEAD position was 317a439 b4
HEAD is now at ee27b37 b2
++ test_commit b5 file2 2
++ local notick=
++ local echo=echo
++ local append=
++ local author=
++ local signoff=
++ local indir=
++ local tag=light
++ test 3 '!=' 0
++ case "$1" in
++ break
++ indir=
++ local file=file2
++ test -n ''
++ echo 2
++ git add -- file2
++ test -z ''
++ test_tick
++ test -z set
++ test_tick=1112912953
++ GIT_COMMITTER_DATE='1112912953 -0700'
++ GIT_AUTHOR_DATE='1112912953 -0700'
++ export GIT_COMMITTER_DATE GIT_AUTHOR_DATE
++ git commit -m b5
[detached HEAD 5526d49] b5
 Author: A U Thor <author@example.com>
 1 file changed, 1 insertion(+)
 create mode 100644 file2
++ case "$tag" in
++ git tag b5
++ git checkout b4
Previous HEAD position was 5526d49 b5
HEAD is now at 317a439 b4
++ git merge --no-commit --no-ff b5
Automatic merge went well; stopped before committing as requested
++ git checkout b2 -- file
++ git merge --continue
[detached HEAD da1857e] Merge tag 'b5' into HEAD
 Author: A U Thor <author@example.com>
++ check_last_modified
++ local indir=
++ test 0 '!=' 0
++ cat
++ git last-modified
++ git name-rev --annotate-stdin --name-only --tags
++ tr '\t' ' '
++ test_cmp expect actual
++ test 2 -ne 2
++ eval 'diff -u' '"$@"'
+++ diff -u expect actual
--- expect      2025-11-19 15:43:57 +0000
+++ actual      2025-11-19 15:43:57 +0000
@@ -1,2 +1,2 @@
-b5 file2
-b2 file
+da1857e0652b6f264c0038d684ddecddc273e506 file2
+da1857e0652b6f264c0038d684ddecddc273e506 file
error: last command exited with $?=1
not ok 19 - last-modified merge undoes changes


--
Brief whoami: NonStop&UNIX developer since approximately
UNIX(421664400)
NonStop(211288444200000000)
-- In real life, I talk too much.

Re: [BUG] Test Failure 2.52.0, t8020.16,19

[Kristoffer Haugsbakk]

On Wed, Nov 19, 2025, at 16:50, rsbecker@nexbridge.com wrote:
> The following two failures appeared on NonStop for the actual release. I did
> not see them in -rc0 or after (doesn't mean they didn't happen after rc0).
> To my eyes, this looks like a real issue not just on NonStop. It is 100%
> reproducible and is not transient. The build is with OpenSSL 3.4, but that
> should not matter.
>
> expecting success of 8020.16 'cross merge boundaries in blaming':
>         git checkout HEAD^0 &&
>         git rm -rf . &&
>         test_commit m1 &&
>         git checkout HEAD^ &&
>         git rm -rf . &&
>         test_commit m2 &&
>         git merge m1 &&
>         check_last_modified <<-\EOF
>         m2 m2.t
>         m1 m1.t
>         EOF
>[snip]

Also reported here https://lore.kernel.org/git/4dc4c8cd-c0cc-4784-8fcf-defa3a051087@mit.edu/

RE: [BUG] Test Failure 2.52.0, t8020.16,19

[rsbecker]

On November 19, 2025 11:25 AM, Kristoffer Haugsbakk wrote
>To: rsbecker <rsbecker@nexbridge.com>; git@vger.kernel.org
>Subject: Re: [BUG] Test Failure 2.52.0, t8020.16,19
>
>On Wed, Nov 19, 2025, at 16:50, rsbecker@nexbridge.com wrote:
>> The following two failures appeared on NonStop for the actual release.
>> I did not see them in -rc0 or after (doesn't mean they didn't happen after rc0).
>> To my eyes, this looks like a real issue not just on NonStop. It is
>> 100% reproducible and is not transient. The build is with OpenSSL 3.4,
>> but that should not matter.
>>
>> expecting success of 8020.16 'cross merge boundaries in blaming':
>>         git checkout HEAD^0 &&
>>         git rm -rf . &&
>>         test_commit m1 &&
>>         git checkout HEAD^ &&
>>         git rm -rf . &&
>>         test_commit m2 &&
>>         git merge m1 &&
>>         check_last_modified <<-\EOF
>>         m2 m2.t
>>         m1 m1.t
>>         EOF
>>[snip]
>
>Also reported here https://lore.kernel.org/git/4dc4c8cd-c0cc-4784-8fcf-
>defa3a051087@mit.edu/

Thanks. Like ships passing in the wind 😉 

RE: [BUG] Test Failure 2.52.0, t8020.16,19

[rsbecker]

On November 19, 2025 11:25 AM, Kristoffer Haugsbakk wrote:
>On Wed, Nov 19, 2025, at 16:50, rsbecker@nexbridge.com wrote:
>> The following two failures appeared on NonStop for the actual release. I
did
>> not see them in -rc0 or after (doesn't mean they didn't happen after
rc0).
>> To my eyes, this looks like a real issue not just on NonStop. It is 100%
>> reproducible and is not transient. The build is with OpenSSL 3.4, but
that
>> should not matter.
>>
>> expecting success of 8020.16 'cross merge boundaries in blaming':
>>         git checkout HEAD^0 &&
>>         git rm -rf . &&
>>         test_commit m1 &&
>>         git checkout HEAD^ &&
>>         git rm -rf . &&
>>         test_commit m2 &&
>>         git merge m1 &&
>>         check_last_modified <<-\EOF
>>         m2 m2.t
>>         m1 m1.t
>>         EOF
>>[snip]
>
>Also reported here https://lore.kernel.org/git/4dc4c8cd-c0cc-4784-8fcf-
>defa3a051087@mit.edu/

As a packager for NonStop, my team and I are trying to determine whether
2.52.0
can actually be shipped. The concern is, is this a defect in the test code
or underlying
git merge code, and if the latter, how big an impact. If we hold off, how
long will it
take for a fix (approximately). I do not know the merge code, so... 

Re: [BUG] Test Failure 2.52.0, t8020.16,19

[Kristoffer Haugsbakk]

On Fri, Nov 21, 2025, at 14:18, rsbecker@nexbridge.com wrote:
> On November 19, 2025 11:25 AM, Kristoffer Haugsbakk wrote:
>>On Wed, Nov 19, 2025, at 16:50, rsbecker@nexbridge.com wrote:
>>> The following two failures appeared on NonStop for the actual release. I
> did
>>> not see them in -rc0 or after (doesn't mean they didn't happen after
> rc0).
>>> To my eyes, this looks like a real issue not just on NonStop. It is 100%
>>> reproducible and is not transient. The build is with OpenSSL 3.4, but
> that
>>> should not matter.
>>>
>>> expecting success of 8020.16 'cross merge boundaries in blaming':
>>>         git checkout HEAD^0 &&
>>>         git rm -rf . &&
>>>         test_commit m1 &&
>>>         git checkout HEAD^ &&
>>>         git rm -rf . &&
>>>         test_commit m2 &&
>>>         git merge m1 &&
>>>         check_last_modified <<-\EOF
>>>         m2 m2.t
>>>         m1 m1.t
>>>         EOF
>>>[snip]
>>
>>Also reported here https://lore.kernel.org/git/4dc4c8cd-c0cc-4784-8fcf-
>>defa3a051087@mit.edu/
>
> As a packager for NonStop, my team and I are trying to determine whether
> 2.52.0
> can actually be shipped. The concern is, is this a defect in the test code
> or underlying
> git merge code, and if the latter, how big an impact. If we hold off, how
> long will it
> take for a fix (approximately). I do not know the merge code, so...

See the email from Jeff King on that thread https://lore.kernel.org/git/20251120081611.GC1283645@coredump.intra.peff.net/

By the way your email client reflows lines so aggressively that it
breaks lines in the middle of URLs.

RE: [BUG] Test Failure 2.52.0, t8020.16,19

[rsbecker]

On November 21, 2025 8:36 AM, Kristoffer Haugsbakk wrote:
>On Fri, Nov 21, 2025, at 14:18, rsbecker@nexbridge.com wrote:
>> On November 19, 2025 11:25 AM, Kristoffer Haugsbakk wrote:
>>>On Wed, Nov 19, 2025, at 16:50, rsbecker@nexbridge.com wrote:
>>>> The following two failures appeared on NonStop for the actual
>>>> release. I
>> did
>>>> not see them in -rc0 or after (doesn't mean they didn't happen after
>> rc0).
>>>> To my eyes, this looks like a real issue not just on NonStop. It is
>>>> 100% reproducible and is not transient. The build is with OpenSSL
>>>> 3.4, but
>> that
>>>> should not matter.
>>>>
>>>> expecting success of 8020.16 'cross merge boundaries in blaming':
>>>>         git checkout HEAD^0 &&
>>>>         git rm -rf . &&
>>>>         test_commit m1 &&
>>>>         git checkout HEAD^ &&
>>>>         git rm -rf . &&
>>>>         test_commit m2 &&
>>>>         git merge m1 &&
>>>>         check_last_modified <<-\EOF
>>>>         m2 m2.t
>>>>         m1 m1.t
>>>>         EOF
>>>>[snip]
>>>
>>>Also reported here
>>>https://lore.kernel.org/git/4dc4c8cd-c0cc-4784-8fcf-
>>>defa3a051087@mit.edu/
>>
>> As a packager for NonStop, my team and I are trying to determine
>> whether
>> 2.52.0
>> can actually be shipped. The concern is, is this a defect in the test
>> code or underlying git merge code, and if the latter, how big an
>> impact. If we hold off, how long will it take for a fix
>> (approximately). I do not know the merge code, so...
>
>See the email from Jeff King on that thread
>https://lore.kernel.org/git/20251120081611.GC1283645@coredump.intra.peff.n
>et/
>
>By the way your email client reflows lines so aggressively that it breaks
lines in the
>middle of URLs.

Yes, I'm using Outlook, which does not like bottom-tracked replies at all. I
have to manually do everything and it breaks rational likes. Blame you know
whom.

In any event, "make SANITIZE=address,undefined" generates bad CFLAGS, so I
cannot compile that way.

Re: [BUG] Test Failure 2.52.0, t8020.16,19

[Junio C Hamano]

<rsbecker@nexbridge.com> writes:

>>> expecting success of 8020.16 'cross merge boundaries in blaming':
>>>         git checkout HEAD^0 &&
>>>         git rm -rf . &&
>>>         test_commit m1 &&
>>>         git checkout HEAD^ &&
>>>         git rm -rf . &&
>>>         test_commit m2 &&
>>>         git merge m1 &&
>>>         check_last_modified <<-\EOF
>>>         m2 m2.t
>>>         m1 m1.t
>>>         EOF
>>>[snip]
>>
>>Also reported here https://lore.kernel.org/git/4dc4c8cd-c0cc-4784-8fcf-
>>defa3a051087@mit.edu/
>
> .... The concern is, is this a defect in the test code
> or underlying
> git merge code, and if the latter, how big an impact. If we hold off, how
> long will it
> take for a fix (approximately). I do not know the merge code, so... 

But is this really about "merge"?

The test is about how the "last-modified" command behaves given
histories of various shapes prepared with the sequence of commands
that comes before the "check_last_modified" line.

You can probably take a snapshot of the resulting repository
immediately after "git merge m1" from a test with both problematic
version and older version and compare the two repositories, and I an
reasonably certain that you wouldn't see any differences (no, I am
not saying they should be bit-for-bit identical, but the set of
objects and topology should be the same).  Bisection by others
pointing at a commit that changed how "last-modified" computes its
result should be a strong enough hint as well that the problem is
unlikely with "merge".

RE: [BUG] Test Failure 2.52.0, t8020.16,19

[rsbecker]

On November 21, 2025 8:36 AM, Kristoffer Haugsbakk wrote:
>On Fri, Nov 21, 2025, at 14:18, rsbecker@nexbridge.com wrote:
>> On November 19, 2025 11:25 AM, Kristoffer Haugsbakk wrote:
>>>On Wed, Nov 19, 2025, at 16:50, rsbecker@nexbridge.com wrote:
>>>> The following two failures appeared on NonStop for the actual
>>>> release. I
>> did
>>>> not see them in -rc0 or after (doesn't mean they didn't happen after
>> rc0).
>>>> To my eyes, this looks like a real issue not just on NonStop. It is
>>>> 100% reproducible and is not transient. The build is with OpenSSL
>>>> 3.4, but
>> that
>>>> should not matter.
>>>>
>>>> expecting success of 8020.16 'cross merge boundaries in blaming':
>>>>         git checkout HEAD^0 &&
>>>>         git rm -rf . &&
>>>>         test_commit m1 &&
>>>>         git checkout HEAD^ &&
>>>>         git rm -rf . &&
>>>>         test_commit m2 &&
>>>>         git merge m1 &&
>>>>         check_last_modified <<-\EOF
>>>>         m2 m2.t
>>>>         m1 m1.t
>>>>         EOF
>>>>[snip]
>>>
>>>Also reported here
>>>https://lore.kernel.org/git/4dc4c8cd-c0cc-4784-8fcf-
>>>defa3a051087@mit.edu/
>>
>> As a packager for NonStop, my team and I are trying to determine
>> whether
>> 2.52.0
>> can actually be shipped. The concern is, is this a defect in the test
>> code or underlying git merge code, and if the latter, how big an
>> impact. If we hold off, how long will it take for a fix
>> (approximately). I do not know the merge code, so...
>
>See the email from Jeff King on that thread
>https://lore.kernel.org/git/20251120081611.GC1283645@coredump.intra.peff.n
>et/
>
>By the way your email client reflows lines so aggressively that it breaks
lines in the
>middle of URLs.

I tried the suggestion from Jeff King, but there are no problematic casts
that I can see.
One possible issue here is the use of & with enums vs. ints, like

if (data.commit->object.flags & BOUNDARY) {

If flags is an in and BOUNDARY causes a sign extension, this might be an
issue on a
big-endian platform, particularly if 0x8000000 is used as the value or if a
sign
extension is expected.

The SANITIZE option ends up causing -f to be supplied to c99, which is gcc
specific.

RE: [BUG] Test Failure 2.52.0, t8020.16,19

[rsbecker]

On November 26, 2025 11:16 AM, I wrote:
>On November 21, 2025 8:36 AM, Kristoffer Haugsbakk wrote:
>>On Fri, Nov 21, 2025, at 14:18, rsbecker@nexbridge.com wrote:
>>> On November 19, 2025 11:25 AM, Kristoffer Haugsbakk wrote:
>>>>On Wed, Nov 19, 2025, at 16:50, rsbecker@nexbridge.com wrote:
>>>>> The following two failures appeared on NonStop for the actual
>>>>> release. I
>>> did
>>>>> not see them in -rc0 or after (doesn't mean they didn't happen
>>>>> after
>>> rc0).
>>>>> To my eyes, this looks like a real issue not just on NonStop. It is
>>>>> 100% reproducible and is not transient. The build is with OpenSSL
>>>>> 3.4, but
>>> that
>>>>> should not matter.
>>>>>
>>>>> expecting success of 8020.16 'cross merge boundaries in blaming':
>>>>>         git checkout HEAD^0 &&
>>>>>         git rm -rf . &&
>>>>>         test_commit m1 &&
>>>>>         git checkout HEAD^ &&
>>>>>         git rm -rf . &&
>>>>>         test_commit m2 &&
>>>>>         git merge m1 &&
>>>>>         check_last_modified <<-\EOF
>>>>>         m2 m2.t
>>>>>         m1 m1.t
>>>>>         EOF
>>>>>[snip]
>>>>
>>>>Also reported here
>>>>https://lore.kernel.org/git/4dc4c8cd-c0cc-4784-8fcf-
>>>>defa3a051087@mit.edu/
>>>
>>> As a packager for NonStop, my team and I are trying to determine
>>> whether
>>> 2.52.0
>>> can actually be shipped. The concern is, is this a defect in the test
>>> code or underlying git merge code, and if the latter, how big an
>>> impact. If we hold off, how long will it take for a fix
>>> (approximately). I do not know the merge code, so...
>>
>>See the email from Jeff King on that thread
>>https://lore.kernel.org/git/20251120081611.GC1283645@coredump.intra.pef
>>f.n
>>et/
>>
>>By the way your email client reflows lines so aggressively that it
>>breaks lines in the middle of URLs.
>
>I tried the suggestion from Jeff King, but there are no problematic casts
that I can
>see.
>One possible issue here is the use of & with enums vs. ints, like
>
>if (data.commit->object.flags & BOUNDARY) {
>
>If flags is an in and BOUNDARY causes a sign extension, this might be an
issue on a
>big-endian platform, particularly if 0x8000000 is used as the value or if a
sign
>extension is expected.
>
>The SANITIZE option ends up causing -f to be supplied to c99, which is gcc
specific.

Not the issue with BOUNDARY. I am considering a potential compiler issue but
need to see whether this is try or not. There have been issues in the
distant past with unsigned flag:28 (bigger than 16 bits) on 32-bit builds,
which mine must be for now. I doubt this is the issue, but I need to verify
one way or another based on what is expected for t8020.16 or 19. I can use
gdb to verify one of the casts or calculations but  I'm sorry but I cannot
follow what the code is doing well enough to know for certain. Is there a
specific line with results I can verify/dispute in builtin/last-modified.c
that will show an issue, please? A little help would be appreciated. My team
has decided that 2.52.0 is potentially problematic on NonStop ia64 and x86
because of this problem.