Hi Kalvis,
> I'd like to propose the attached patch (developed against GCC 15.2.0) as a fix
> for the bug logged in PR target/112400.
Thank you for your submission.
> When cross-compiling itself for VAX, GCC terminates abruptly with an ICE when
> compiling gimple_match.cc; the root cause seems to be an incompletely removed
> computed jump instruction, which causes the assertion in cfgrtl.cc around line
> 4083, to no longer hold.
>
> I have verified that the problem is present in GCC 15.2.0 and believe that
> it's also present in trunk (based on the fact that the patterns for the
> "casesi1" and "*casesi1" instructions in 15.2.0 and trunk are the same).
I note that our documentation claims that `use' must only be used with
`reg' expressions, however I can see numerous counterexamples across other
backends and therefore have to conclude it is OK, especially if it fixes
the bug at hand, although I have no own experience with this RTX type.
Have you run your fix through full regression-testing or is it only the
reproducer from the PR and presumably the build of GCC that the fix has
been verified against? Regardless, I'll push it through verification in
my own environment and let you know of the outcome.
I'm curious as to what has caused this regression, or alternatively what
is different that causes the problem with your configuration but not mine,
as I was certainly able to build a GCC 15 snapshot just fine shortly after
GCC 14 was branched:
$ vax-netbsdelf-gcc --version
vax-netbsdelf-gcc (GCC) 15.0.0 20240525 (experimental)
[...]
> I've been able to generate a reduced input file from gimple_match.cc which
> demonstrates the problem in GCC 15.2.0 on NetBSD/amd64 cross-compiling for
> vax; I've attached that input file to the problem report. I'll need some help
> to turn that into a test in the GCC testsuite, however.
We'll sort it.
> (For completeness, I note that I do not have write access to the GCC tree.)
I can see you have already contributed commit 1a2b5eeb5d24 ("[PATCH v2]:
pch, target: update host hooks for NetBSD and OpenBSD"), which I believe
has exhausted the cumulative limit of code changes that can be considered
legally insignificant.
Therefore please decide whether you'd like to contribute this and any
future changes under a copyright assignment to FSF or the Developer's
Certificate of Origin.
Please review <https://gcc.gnu.org/contribute.html#legal> for further
details and feel free to ask if you find anything unclear.
NB answering from my work address on this occasion to make sure the reply
reaches you directly, as GMail has issues with e-mail submissions from my
personal address (cc'd). I do hope you can receive my further replies via
the mailing list and will appreciate your understanding.
Please do let me know if you have any questions or concerns at this
point.
Maciej
