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

[<rsbecker@nexbridge.com>]

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.