On Wed, 28 Aug 2013, Kenneth Zadeck wrote:
Note that the bits above the precision are not defined and the
algorithms used here are careful not to depend on their value. In
particular, values that come in from rtx constants may have random
bits.
Which is a red herring. It should be fixed. I cannot even believe
that sentence given the uses of CONST_DOUBLE_LOW/CONST_DOUBLE_HIGH
or INTVAL/UINTVAL. I don't see accesses masking out 'undefined' bits
anywhere.
I can agree with you that this could be fixed. But it is not necessary to
fix it. The rtl level and most of the tree level has existed for a long time
by doing math within the precision.
you do not see the masking at the rtl level because the masking is not
necessary. if you never look beyond the precision you just do not care.
There is the issue with divide and mod and quite frankly the code on the trunk
scares me to death. my code at the rtl level makes sure that everything is
clean since i can see if it is a udiv or a div that is enough info to clean
the value up.
I have a feeling I'm rehashing a past debate, sorry, but rtx constants
can't
have random bits. The upper bits must be a sign extension of the value.
There's exactly one valid rtx for each (value, mode) pair. If you saw
something different then that sounds like a bug. The rules should already
be fairly well enforced though, since something like (const_int 128) --
or (const_int 256) -- will not match a QImode operand.
See. We're saved ;)
this is richard's theory. There is a block of code at wide-int.cc:175 that
is ifdefed out that checks to see if the rtl consts are canonical. if you
bring it in, building the libraries fails very quickly. The million dollar
question is this the only bug or is this the first bug of a 1000 bugs. Your
comment about not seeing any masking cuts both ways. There is very little
code on the way in if you create ints with GEN_INT that makes sure someone has
done the right thing on that side. So my guess is that there are a lot of
failures and a large number of them will be in the ports.
Well, clearly RTL code _expects_ constants to be properly extended. I
can reproduce the bug and I simply guess that's a matter of mismatching
modes here (or performing an implicit truncation without properly
extending the constant).
at /space/rguenther/src/svn/wide-int/gcc/combine.c:10086
10086 GEN_INT
(count));
(gdb) l
10081
10082 mask_rtx = GEN_INT (nonzero_bits (varop, GET_MODE
(varop)));
10083
10084 mask_rtx
10085 = simplify_const_binary_operation (code,
result_mode, mask_rtx,
10086 GEN_INT
(count));
uses of GEN_INT are frowned upon ... for exactly that reason - the
mask_rtx is not a proper RTL constant for SImode.