signed/unsigned overload resolution error seems unjustified

Consider this input program:

void f(unsigned int){}
void f(int){}

float4 PSMain() : SV_TARGET
{
    f(1);
    return (float4)0;
}

There is a complaint that says:

<source>:6:5: error: call to 'f' is ambiguous
    f(1);
    ^
<source>:1:6: note: candidate function
void f(unsigned int){}
     ^
<source>:2:6: note: candidate function
void f(int){}
     ^

(godbolt permalink https://godbolt.org/z/K5rWWj4c3)

whereas the slight variation to this program:

void f(unsigned int){}
void f(int){}

float4 PSMain() : SV_TARGET
{
    f(1u);  // arg type unsigned
    return (float4)0;
}

The build now passes with no complaint.

To evaluate if that behavior is reasonable, I check against the C++ equivalent in gcc12 (godbolt default)
and get a pass build in both situation.
with an assembly that lists either call f(int) or call f(unsigned int) depending on literal suffix at call site.
(https://godbolt.org/z/h4s4bx566)
I therefore infer, that the DXC behavior is not reasonable.

Which suggests to me possibly a shortcoming somewhere around the management of the unsigned type qualifier, since I recall reporting another bug on that before.

Start by reproducing the two overload-resolution cases in the issue's HLSL programs, comparing the unsuffixed literal with the unsigned-suffixed literal and the linked GCC behavior. Trace the compiler's handling of integer literal types and overload resolution; done means the unsuffixed call resolves consistently to the int overload without the reported ambiguity, while the suffixed call continues to resolve to the unsigned overload.