This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[RFC] PR 58542: const_int vs lost modes


In this pr, we have a -1 in type __int128.  Since this value can be
represented in a HOST_WIDE_INT, we expand this to a const_int.

The expansion from tree to rtl happens in expand_builtin_atomic_store.  And as
with most of our builtins, we then pass off the rtl to another routine for
expansion.  When we fill in the blanks of the expand_operand in
expand_atomic_compare_and_swap, we've forgotten that the const_int is of
TImode.  Then convert_modes attempts to zero-extend what it assumes is a
narrower mode and we get corrupt data.

For a bit I thought that the bug was in convert_modes, but honestly any
change I make there merely moves the bug around.  The biggest problem is
that we've lost the mode.

Given that we lose the mode through any of 10 stack frames, I believe it
to be implausible to adjust all of the call frames in optabs.c.  The real
bug is that const_int doesn't carry a mode.

The most isolated patch I can come up with, especially since we ought to
fix this in 4.8 branch as well, is to only allow expansion of wide int
modes to const_int when they're positive.

Thoughts?


r~

Attachment: d58542
Description: Text document


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]