Re: Help finding Coverity defects for generated Hexagon code

[Anton Johansson]

On 5/23/23 12:29, Paolo Bonzini wrote:
> On Tue, May 23, 2023 at 11:18 AM Peter Maydell <peter.maydell@linaro.org> wrote:
> > On Mon, 22 May 2023 at 21:24, Anton Johansson <anjo@rev.ng> wrote:
> > > Hi,
> > >
> > > coverity recently reported some defects in code generated by idef-parser
> > > (email attached). These defects are expected and we plan to emit a
> > > /* coverity[event_tag] */ comment to disable the specific event triggered.
> > We don't mark coverity false positives with comments in the
> > source. For the free online scanner, we just mark them as
> > false positives in the GUI (with an explanation of why they're
> > false positives).
> They aren't visible in the GUI because the whole "hexagon generated
> files" component is marked as not-analyzed; which apparently means it
> _is_ analyzed and visible in the emails but not in the GUI.

Ah right...

> The event tag for this error should be "dead_error_condition". In
> theory, the hexagon generated files could be a good exception to the
> rules that we don't mark false positives in the source, but finding
> the right line to add the tag can be messy.
If we decide to mark these in source, my plan was to simply emit

    if (qemu_tmp_2 >= 64) {
        /* coverity[dead_error_condition] */
        tcg_gen_movi_i64(tmp_5, 0);
    } else {
        tcg_gen_shli_i64(tmp_5, tmp_4, qemu_tmp_2);
    }

for all of these safety checks around shifts/extracts where the defect could
trigger. Maybe this is overreaching as we would also mark similar 
branches in
other instructions that are alive, but if we knew they were dead at 
translation
time we could simply not emit them to begin with.

--
Anton Johansson,
rev.ng Labs Srl.