On Fri, Dec 9, 2011 at 4:56 PM, Richard Sandiford
richard.sandif...@linaro.org wrote:
Carrot Wei car...@google.com writes:
Since it also affects 4.6 branch, can this and r176270 also be ported
to gcc4.6?
Always worth asking, but in this case, I'm not sure it's appropriate.
The patch is
Carrot Wei car...@google.com writes:
Since it also affects 4.6 branch, can this and r176270 also be ported
to gcc4.6?
Always worth asking, but in this case, I'm not sure it's appropriate.
The patch is pretty invasive, and I don't think the bug is a regression.
Also, 4.6 generates really lousy
Since it also affects 4.6 branch, can this and r176270 also be ported to gcc4.6?
thanks
Carrot
On Wed, Jul 13, 2011 at 12:34 AM, Richard Sandiford
richard.sandif...@linaro.org wrote:
PR 48183 is caused by the fact that we don't really support integers
(or least integer constants) wider than
H.J. Lu hjl.to...@gmail.com writes:
This caused:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49736
Sorry for the breakage. It was due to a humiliating stupid mistake
in the hunk to update all_zeros_p:
@@ -5129,13 +5152,12 @@ mostly_zeros_p (const_tree exp)
all_zeros_p (const_tree exp)
{
On Tue, Jul 12, 2011 at 9:34 AM, Richard Sandiford
richard.sandif...@linaro.org wrote:
PR 48183 is caused by the fact that we don't really support integers
(or least integer constants) wider than 2*HOST_BITS_PER_WIDE_INT:
http://gcc.gnu.org/ml/gcc-patches/2011-03/msg01220.html
However,
PR 48183 is caused by the fact that we don't really support integers
(or least integer constants) wider than 2*HOST_BITS_PER_WIDE_INT:
http://gcc.gnu.org/ml/gcc-patches/2011-03/msg01220.html
However, such constants shouldn't be needed in normal use.
They came from an unnecessary
On 07/12/2011 12:34 PM, Richard Sandiford wrote:
- HOST_WIDE_INT num_type_elements, num_initialized_elements;
+ bool complete_p = true;
+ HOST_WIDE_INT num_elts = 0;
Let's use num_split_elts so that it's clearer that we're counting the
number of elements that have been initialized outside
