"BLORP-clear" named as "BLORP-copy"

[Amol Surati]

Hello,

Running with a debug build of intel_hasvk, along with a few debug variables,
a weird naming problem (attributed to zero-initialization) was observed.

The end of this email has the BLORP-clear fragment shader that happened to
be named BLORP-copy.

The details about this cause of the problem is at [1]

Does Mesa know about this problem and/or its workaround/fix?

Thank you,
Amol

[1] https://gcc.gnu.org/pipermail/gcc-help/2024-May/143461.html

--------------------------------------------
shader: MESA_SHADER_FRAGMENT
source_blake3: {0x00000000, 0x00000000, 0x00000000, 0x00000000,
0x00000000, 0x00000000, 0x00000000, 0x00000000}
name: BLORP-copy
internal: true
stage: 4
next_stage: 0
inputs_read: 32
outputs_written: 2
subgroup_size: 0
origin_upper_left: true
inputs: 0
outputs: 0
uniforms: 0
decl_var shader_in INTERP_MODE_FLAT none vec4 clear_color
(VARYING_SLOT_VAR0.xyzw, 32, 0)
decl_var shader_out INTERP_MODE_NONE none vec4 gl_FragColor
(FRAG_RESULT_COLOR.xyzw, 4, 0)
decl_function main (0 params)

impl main {
    con block b0:  // preds:
    32    %5 = load_const (0x00000000)
    32x4  %4 = @load_input (%5 (0x0)) (base=32, range=1, component=0,
dest_type=float32, io location=VARYING_SLOT_VAR0 slots=1)  //
clear_color
    32    %6 = load_const (0x00000000)
               @store_output (%4, %6 (0x0)) (base=4, range=1,
wrmask=xyzw, component=0, src_type=float32, io
location=FRAG_RESULT_COLOR slots=1, xfb(), xfb2())  // gl_FragColor
               // succs: b1
    block b1:
}
--------------------------------------------