| Summary: | ppc: callgrind triggers VEX assertion failure | ||
|---|---|---|---|
| Product: | [Developer tools] valgrind | Reporter: | Bart Van Assche <bart.vanassche+kde> |
| Component: | vex | Assignee: | Josef Weidendorfer <josef.weidendorfer> |
| Status: | CONFIRMED --- | ||
| Severity: | normal | CC: | cel, jseward, will_schmidt |
| Priority: | NOR | ||
| Version First Reported In: | 3.6 SVN | ||
| Target Milestone: | wanted3.6.0 | ||
| Platform: | unspecified | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
|
Description
Bart Van Assche
2010-07-03 09:46:27 UTC
> 1Uto64(t83)
> vex: the `impossible' happened:
> iselIntExpr_R(ppc): cannot reduce tree
This must be the guard widening stuff for the branch predictor.
The code is copied from cachegrind, but it seems cachegrind has
no test running the branch prediction simulation, so this problem
was not discovered in the past.
However, I am neither familiar with VEX, nor do I have a PPC
machine...
Set to want3.6.0. I don't have time to fix it in the next few days. Bart, you might be able to kludge around it by adding Iop_1Uto64 to the case in guest_ppc_isel.c which currently handles Iop_1Uto32 and Iop_1Uto8, but I don't think that's a proper fix. (A proper fix would involve making sure PPCInstr_Set works properly in 64-bit mode). Or, you could handle Iop_1Uto64 exactly the same as Iop_1Uto32 but then emit two instructions to shift the result register left by 32 and then (unsignedly) right by 32. This would generate pretty bad code but it would work. (In reply to comment #2) > but then emit two instructions to shift the result register left by > 32 and then (unsignedly) right by 32. .. and you can figure out how to do that by looking at the instructions created by host_ppc_isel.c for Iop_Shl64 and Iop_Shr64. Currently this does not seem to fail on a Power 10 system, Fedora release 38, valgrind 3.22 |