On 2/28/24 09:29, Richard Henderson wrote:
On 2/28/24 02:20, Paolo Bonzini wrote:
On Wed, Feb 28, 2024 at 12:19 PM Philippe Mathieu-Daudé
wrote:
On 28/2/24 12:06, Paolo Bonzini wrote:
The variables uext_opc and sext_opc are used without initialization if
TCG_TARGET_extract_i{32,64}_valid ret
On 2/28/24 02:20, Paolo Bonzini wrote:
On Wed, Feb 28, 2024 at 12:19 PM Philippe Mathieu-Daudé
wrote:
On 28/2/24 12:06, Paolo Bonzini wrote:
The variables uext_opc and sext_opc are used without initialization if
TCG_TARGET_extract_i{32,64}_valid returns false. The result, depending
on the co
On Wed, Feb 28, 2024 at 12:19 PM Philippe Mathieu-Daudé
wrote:
>
> On 28/2/24 12:06, Paolo Bonzini wrote:
> > The variables uext_opc and sext_opc are used without initialization if
> > TCG_TARGET_extract_i{32,64}_valid returns false. The result, depending
> > on the compiler, might be the generat
On 28/2/24 12:06, Paolo Bonzini wrote:
The variables uext_opc and sext_opc are used without initialization if
TCG_TARGET_extract_i{32,64}_valid returns false. The result, depending
on the compiler, might be the generation of extract and sextract opcodes
Shouldn't compilers bark?
with invalid
The variables uext_opc and sext_opc are used without initialization if
TCG_TARGET_extract_i{32,64}_valid returns false. The result, depending
on the compiler, might be the generation of extract and sextract opcodes
with invalid offset and count, or just random data in the TCG opcode
stream.
Fixes
