On 3/26/2022 4:41 PM, John Scott via Gcc-help wrote:
Hi,
While working on upgrading the gcc-sh-elf Debian package from gcc 11 to
gcc 12, I think I've found a regression. I'm able to reproduce it with
an upstream bare-metal build.
I've had a hard time figuring out how to bisect it. A naive run with
git bisect start
git bisect new .
git bisect old releases/gcc-11.2.0
fails with
The merge base 250f234988b6231669a720c52101d3686d645072 is new.
The property has changed between 250f234988b6231669a720c52101d3686d645072 and [7ca388565af176bd4efd4f8db1e5e9e11e98ef45].
error: bisect run failed: 'git bisect--helper --bisect-state (null)' exited with error code -3
I'm not enough of a Git or GCC wizard to get further. Does anyone have
any advice so I can make an informative bug report?
Bisection isn't really needed for a good bug report. What's most
important is to give complete sources, ideally a test which will exit
with zero status for a success and call abort for failure. Compile the
test with -save-temps and pass along the .i file so that we don't need
your system header files. Minimizing the amount of library bits your
test needs is also helpful. It's OK to use standard C library
functions, but if you send us something linking against several
libraries it's going to be harder for us to analyze what's really going
on because we probably don't have those libraries.
It's unlikely most of the developers are going to have SH hardware or
even a setup that would let them run debian on qemu. So if you've done
any debugging to pinpoint what's happening at the assembly level, that's
helpful. We do have old gdb-sim simulators. So if your test is simple
enough we may be able to debug it with that.
jeff
