Kyrill Tkachov kyrylo.tkac...@arm.com writes:
The attached patch allowed the build to proceed for me, but in stage 2 I
encountered an ICE:
$TOP/gcc/dwarf2out.c: In function 'long unsigned int
_ZL11size_of_dieP10die_struct.isra.209(vecdw_attr_struct, va_gc**, long
unsigned int)':
Kyrill Tkachov kyrylo.tkac...@arm.com writes:
With that patch bootstrap now still fails at dwarf2out.c with the same
message. I'm attaching a gzipped dwarf2out.ii
Thanks. This is a nice proof of why clz_zero and ctz_zero were as bogus
as claimed. It meant that the behaviour of floor_log2
ok to commit.
kenny
On 04/28/2014 11:42 AM, Richard Sandiford wrote:
Kyrill Tkachov kyrylo.tkac...@arm.com writes:
With that patch bootstrap now still fails at dwarf2out.c with the same
message. I'm attaching a gzipped dwarf2out.ii
Thanks. This is a nice proof of why clz_zero and ctz_zero
On Tue, Apr 22, 2014 at 6:04 PM, Mike Stump mikest...@comcast.net wrote:
On Apr 22, 2014, at 8:33 AM, Richard Sandiford rdsandif...@googlemail.com
wrote:
Kyrill Tkachov kyrylo.tkac...@arm.com writes:
Ping.
http://gcc.gnu.org/ml/gcc-patches/2014-04/msg00769.html
Any ideas? I recall chatter
On 04/23/2014 05:47 AM, Richard Biener wrote:
On Tue, Apr 22, 2014 at 6:04 PM, Mike Stump mikest...@comcast.net wrote:
On Apr 22, 2014, at 8:33 AM, Richard Sandiford rdsandif...@googlemail.com
wrote:
Kyrill Tkachov kyrylo.tkac...@arm.com writes:
Ping.
On Wed, Apr 23, 2014 at 4:29 PM, Kenneth Zadeck
zad...@naturalbridge.com wrote:
On 04/23/2014 05:47 AM, Richard Biener wrote:
On Tue, Apr 22, 2014 at 6:04 PM, Mike Stump mikest...@comcast.net wrote:
On Apr 22, 2014, at 8:33 AM, Richard Sandiford
rdsandif...@googlemail.com wrote:
Kyrill
On Wed, Apr 23, 2014 at 04:36:23PM +0200, Richard Biener wrote:
I should point out that there is a community that wants to go in the
opposite direction here. They are the people with real 32 bit hosts who
want to go back to a world where they are allowed to make hwi a 32 bit
value.
On 04/23/2014 10:36 AM, Richard Biener wrote:
On Wed, Apr 23, 2014 at 4:29 PM, Kenneth Zadeck
zad...@naturalbridge.com wrote:
On 04/23/2014 05:47 AM, Richard Biener wrote:
On Tue, Apr 22, 2014 at 6:04 PM, Mike Stump mikest...@comcast.net wrote:
On Apr 22, 2014, at 8:33 AM, Richard Sandiford
in particular),
I tried bootstrapping the wide-int branch on arm-none-linux-gnueabihf and
encountered some syntax errors while building wide-int.h and wide-int.cc in
expressions that tried to cast to HOST_WIDE_INT. This patch fixes those errors.
Also, in c-ada-spec.c I think we intended to use
Kyrill Tkachov kyrylo.tkac...@arm.com writes:
Ping.
http://gcc.gnu.org/ml/gcc-patches/2014-04/msg00769.html
Any ideas? I recall chatter on IRC that we want to merge wide-int into trunk
soon. Bootstrap failure on arm would prevent that...
Sorry for the late reply. I hadn't forgotten, but I
On Apr 15, 2014, at 4:03 AM, Kyrill Tkachov kyrylo.tkac...@arm.com wrote:
I tried bootstrapping the wide-int branch on arm-none-linux-gnueabihf and
encountered some syntax errors while building wide-int.h and wide-int.cc in
expressions that tried to cast to HOST_WIDE_INT.
Thanks, nice catch
On Apr 22, 2014, at 8:33 AM, Richard Sandiford rdsandif...@googlemail.com
wrote:
Kyrill Tkachov kyrylo.tkac...@arm.com writes:
Ping.
http://gcc.gnu.org/ml/gcc-patches/2014-04/msg00769.html
Any ideas? I recall chatter on IRC that we want to merge wide-int into trunk
soon. Bootstrap failure
Hi all (and wide-int maintainers in particular),
I tried bootstrapping the wide-int branch on arm-none-linux-gnueabihf and
encountered some syntax errors while building wide-int.h and wide-int.cc in
expressions that tried to cast to HOST_WIDE_INT. This patch fixes those errors.
Also, in c-ada
Ping. I should have said that bootstrapping with rtl checking enabled
is broken as things stand.
Thanks,
Richard
Richard Sandiford rdsandif...@googlemail.com writes:
Mike Stump mikest...@comcast.net writes:
@@ -643,12 +653,14 @@ equality. */
__FUNCTION__);
On Sep 5, 2013, at 2:00 PM, Richard Sandiford rdsandif...@googlemail.com
wrote:
Ping. I should have said that bootstrapping with rtl checking enabled
is broken as things stand.
Yes, this is fine.
Richard Sandiford rdsandif...@googlemail.com writes:
Mike Stump mikest...@comcast.net writes:
Mike Stump mikest...@comcast.net writes:
@@ -643,12 +653,14 @@ equality. */
__FUNCTION__); \
_rtx-u.hwint[_n]; }))
-#define XHWIVEC_ELT(HWIVEC, I) __extension__ \
-(*({ __typeof (HWIVEC) const _hwivec =
On Fri, Aug 30, 2013 at 12:02 AM, Kenneth Zadeck
zad...@naturalbridge.com wrote:
Fixed
FAIL: gcc.dg/fixed-point/int-warning.c (test for warnings, line 12)
on
mips64-unknown-linux-gnu
But now this implementation matches how I thought the wide-int encoding
works but not how it does
On Thu, 29 Aug 2013, Mike Stump wrote:
On Aug 29, 2013, at 12:36 AM, Richard Biener rguent...@suse.de wrote:
On Wed, 28 Aug 2013, Mike Stump wrote:
On Aug 28, 2013, at 3:22 AM, Richard Biener rguent...@suse.de wrote:
Btw, rtl.h still wastes space with
struct GTY((variable_size))
On Wed, 28 Aug 2013, Mike Stump wrote:
On Aug 28, 2013, at 3:22 AM, Richard Biener rguent...@suse.de wrote:
Btw, rtl.h still wastes space with
struct GTY((variable_size)) hwivec_def {
int num_elem; /* number of elements */
HOST_WIDE_INT elem[1];
};
struct
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
On 08/29/2013 04:42 AM, Richard Biener wrote:
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
On 08/28/2013 05:08 AM, Richard Biener wrote:
On Sun, 25 Aug 2013, Mike Stump wrote:
On Aug 25, 2013, at 12:26 AM, Richard Sandiford rdsandif...@googlemail.com
wrote:
(2) Adding a new namespace, wi, for the operators. So far this
just contains the previously-static comparison functions
On Aug 29, 2013, at 12:36 AM, Richard Biener rguent...@suse.de wrote:
On Wed, 28 Aug 2013, Mike Stump wrote:
On Aug 28, 2013, at 3:22 AM, Richard Biener rguent...@suse.de wrote:
Btw, rtl.h still wastes space with
struct GTY((variable_size)) hwivec_def {
int num_elem; /* number of
Fixed
FAIL: gcc.dg/fixed-point/int-warning.c (test for warnings, line 12)
on
mips64-unknown-linux-gnu
Index: gcc/tree.c
===
--- gcc/tree.c (revision 202088)
+++ gcc/tree.c (working copy)
@@ -8531,11 +8531,11 @@ bool
On Tue, 27 Aug 2013, Kenneth Zadeck wrote:
removed all knowledge of SHIFT_COUNT_TRUNCATED from wide-int
both Richard Biener and Richard Sandiford had commented negatively about
this.
fixed bug with wide-int::fits_uhwi_p.
inline bool
wide_int_ro::fits_uhwi_p () const
{
- return (len
On Tue, 27 Aug 2013, Richard Sandiford wrote:
Kenneth Zadeck zad...@naturalbridge.com writes:
fixed fits_uhwi_p.
tested on x86-64.
kenny
Index: gcc/wide-int.h
===
--- gcc/wide-int.h (revision 201985)
+++
On Fri, 23 Aug 2013, Richard Sandiford wrote:
Hi Kenny,
This is the first time I've looked at the implementation of wide-int.h
(rather than just looking at the rtl changes, which as you know I like
in general), so FWIW here are some comments on wide-int.h. I expect
a lot of them overlap
On Sun, 25 Aug 2013, Mike Stump wrote:
On Aug 25, 2013, at 12:26 AM, Richard Sandiford rdsandif...@googlemail.com
wrote:
(2) Adding a new namespace, wi, for the operators. So far this
just contains the previously-static comparison functions
and whatever else was needed to avoid
Richard Biener rguent...@suse.de writes:
* As above, constants coming from rtl are already in the right form,
so if you create a wide_int from an rtx and only query it, no explicit
extension is needed.
* Things like logical operations and right shifts naturally preserve
the
On Wed, 28 Aug 2013, Richard Sandiford wrote:
Richard Biener rguent...@suse.de writes:
* As above, constants coming from rtl are already in the right form,
so if you create a wide_int from an rtx and only query it, no explicit
extension is needed.
* Things like logical operations
Richard Biener rguent...@suse.de writes:
So the precision variable is good for the rtl level in several ways:
- As you say, it avoids adding the explicit truncations that (in practice)
every rtl operation would need
- It's more efficient in that case, since we don't calculate high values
On Wed, 28 Aug 2013, Richard Sandiford wrote:
Richard Biener rguent...@suse.de writes:
So the precision variable is good for the rtl level in several ways:
- As you say, it avoids adding the explicit truncations that (in practice)
every rtl operation would need
- It's more
On 08/28/2013 03:45 AM, Richard Biener wrote:
On Tue, 27 Aug 2013, Kenneth Zadeck wrote:
removed all knowledge of SHIFT_COUNT_TRUNCATED from wide-int
both Richard Biener and Richard Sandiford had commented negatively about
this.
fixed bug with wide-int::fits_uhwi_p.
inline bool
On 08/28/2013 03:50 AM, Richard Biener wrote:
On Tue, 27 Aug 2013, Richard Sandiford wrote:
Kenneth Zadeck zad...@naturalbridge.com writes:
fixed fits_uhwi_p.
tested on x86-64.
kenny
Index: gcc/wide-int.h
===
---
Richard Biener rguent...@suse.de writes:
On Wed, 28 Aug 2013, Richard Sandiford wrote:
Richard Biener rguent...@suse.de writes:
So the precision variable is good for the rtl level in several ways:
- As you say, it avoids adding the explicit truncations that (in practice)
every rtl
On Wed, 28 Aug 2013, Kenneth Zadeck wrote:
On 08/28/2013 03:45 AM, Richard Biener wrote:
On Tue, 27 Aug 2013, Kenneth Zadeck wrote:
removed all knowledge of SHIFT_COUNT_TRUNCATED from wide-int
both Richard Biener and Richard Sandiford had commented negatively about
this.
On Wed, 28 Aug 2013, Richard Sandiford wrote:
Richard Biener rguent...@suse.de writes:
On Wed, 28 Aug 2013, Richard Sandiford wrote:
Richard Biener rguent...@suse.de writes:
So the precision variable is good for the rtl level in several ways:
- As you say, it avoids adding the
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
On Aug 28, 2013, at 3:22 AM, Richard Biener rguent...@suse.de wrote:
Btw, rtl.h still wastes space with
struct GTY((variable_size)) hwivec_def {
int num_elem; /* number of elements */
HOST_WIDE_INT elem[1];
};
struct GTY((chain_next (RTX_NEXT (%h)),
chain_prev
On Aug 28, 2013, at 5:48 AM, Richard Biener rguent...@suse.de wrote:
Only if the precision is HOST_BITS_PER_WIDE_INT. If the precision
is HOST_BITS_PER_WIDE_INT then both are { -1U }.
That wasn't my understanding on how things work.
You are thinking about prec==0 numbers. These are useful
On 08/28/2013 12:45 PM, Mike Stump wrote:
On Aug 28, 2013, at 5:48 AM, Richard Biener rguent...@suse.de wrote:
Only if the precision is HOST_BITS_PER_WIDE_INT. If the precision
is HOST_BITS_PER_WIDE_INT then both are { -1U }.
That wasn't my understanding on how things work.
You are thinking
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
On Aug 28, 2013, at 1:41 PM, Kenneth Zadeck zad...@naturalbridge.com wrote:
On 08/28/2013 12:45 PM, Mike Stump wrote:
tree t;
wide_int w = t;
wide_int_to_tree needs an additional type, so, the spelling is not as short
out of necessity.
i made wide_int_to_tree a function that lives in
removed all knowledge of SHIFT_COUNT_TRUNCATED from wide-int
both Richard Biener and Richard Sandiford had commented negatively about
this.
fixed bug with wide-int::fits_uhwi_p.
kenny
Index: gcc/fold-const.c
===
---
Kenneth Zadeck zad...@naturalbridge.com writes:
fixed fits_uhwi_p.
tested on x86-64.
kenny
Index: gcc/wide-int.h
===
--- gcc/wide-int.h(revision 201985)
+++ gcc/wide-int.h(working copy)
@@ -1650,7 +1650,7 @@
you are about an hour behind in reading your email. I had just
committed a patch that is very close to this.
On 08/27/2013 02:31 PM, Richard Sandiford wrote:
Kenneth Zadeck zad...@naturalbridge.com writes:
fixed fits_uhwi_p.
tested on x86-64.
kenny
Index: gcc/wide-int.h
Removed the redundant implementations of several comparison function by
just forwarding the oo version to the static version. Added static
versions of cmp, cmpu and cmps.
kenny
Index: gcc/wide-int.h
===
--- gcc/wide-int.h
fixed fits_uhwi_p.
tested on x86-64.
kenny
Index: gcc/wide-int.h
===
--- gcc/wide-int.h (revision 201985)
+++ gcc/wide-int.h (working copy)
@@ -1650,7 +1650,7 @@ wide_int_ro::fits_shwi_p () const
inline bool
Kenneth Zadeck zad...@naturalbridge.com writes:
On 08/24/2013 08:05 AM, Richard Sandiford wrote:
Richard Sandiford rdsandif...@googlemail.com writes:
I wonder how easy it would be to restrict this use of zero precision
(i.e. flexible precision) to those where primitive types like int are
used
On 08/25/2013 02:42 AM, Richard Sandiford wrote:
Kenneth Zadeck zad...@naturalbridge.com writes:
On 08/24/2013 08:05 AM, Richard Sandiford wrote:
Richard Sandiford rdsandif...@googlemail.com writes:
I wonder how easy it would be to restrict this use of zero precision
(i.e. flexible precision)
On Aug 23, 2013, at 8:02 AM, Richard Sandiford rdsandif...@googlemail.com
wrote:
We really need to get rid of the #include tm.h in wide-int.h.
MAX_BITSIZE_MODE_ANY_INT should be the only partially-target-dependent
thing in there. If that comes from tm.h then perhaps we should put it
into a
Mike Stump mikest...@comcast.net writes:
On Aug 23, 2013, at 8:02 AM, Richard Sandiford
rdsandif...@googlemail.com wrote:
We really need to get rid of the #include tm.h in wide-int.h.
MAX_BITSIZE_MODE_ANY_INT should be the only partially-target-dependent
thing in there. If that comes from
cleaned up code to get around tree-vrp issue. added some code that
richard is going to play with to see how hard it would be to clean up
rtl constants.
kenny
Index: gcc/wide-int.cc
===
--- gcc/wide-int.cc (revision 201968)
+++
On Aug 25, 2013, at 11:29 AM, Richard Sandiford rdsandif...@googlemail.com
wrote:
Mike Stump mikest...@comcast.net writes:
On Aug 23, 2013, at 8:02 AM, Richard Sandiford
rdsandif...@googlemail.com wrote:
We really need to get rid of the #include tm.h in wide-int.h.
MAX_BITSIZE_MODE_ANY_INT
On Sun, 25 Aug 2013, Mike Stump wrote:
On Aug 23, 2013, at 8:02 AM, Richard Sandiford rdsandif...@googlemail.com
wrote:
We really need to get rid of the #include tm.h in wide-int.h.
MAX_BITSIZE_MODE_ANY_INT should be the only partially-target-dependent
thing in there. If that comes from
On Aug 25, 2013, at 11:29 AM, Richard Sandiford rdsandif...@googlemail.com
wrote:
Looks like wide-int is just using BITS_PER_UNIT to get the number of
bits in char. That's a host thing, so it should be CHAR_BIT instead.
Oh, Kenny did point out one sin:
diff --git a/gcc/wide-int.cc
On Aug 25, 2013, at 1:11 PM, Joseph S. Myers jos...@codesourcery.com wrote:
On Sun, 25 Aug 2013, Mike Stump wrote:
On Aug 23, 2013, at 8:02 AM, Richard Sandiford rdsandif...@googlemail.com
wrote:
We really need to get rid of the #include tm.h in wide-int.h.
MAX_BITSIZE_MODE_ANY_INT should be
On Aug 25, 2013, at 12:26 AM, Richard Sandiford rdsandif...@googlemail.com
wrote:
(2) Adding a new namespace, wi, for the operators. So far this
just contains the previously-static comparison functions
and whatever else was needed to avoid cross-dependencies
between wi and
On 08/25/2013 06:55 PM, Mike Stump wrote:
On Aug 25, 2013, at 12:26 AM, Richard Sandiford rdsandif...@googlemail.com
wrote:
(2) Adding a new namespace, wi, for the operators. So far this
just contains the previously-static comparison functions
and whatever else was needed to avoid
Mike Stump mikest...@comcast.net writes:
On Aug 23, 2013, at 8:02 AM, Richard Sandiford
rdsandif...@googlemail.com wrote:
* When a constant that has an integer type is converted to a
wide-int it comes in with precision 0. For these constants the
top bit does accurately reflect the
Kenneth Zadeck zad...@naturalbridge.com writes:
* Code that does widening conversions. The canonical way that
this is performed is to sign or zero extend the input value to
the max width based on the sign of the type of the source and
then to truncate that value to
Richard Sandiford rdsandif...@googlemail.com writes:
I wonder how easy it would be to restrict this use of zero precision
(i.e. flexible precision) to those where primitive types like int are
used as template arguments to operators, and require a precision when
constructing a wide_int. I
On 08/24/2013 08:05 AM, Richard Sandiford wrote:
Richard Sandiford rdsandif...@googlemail.com writes:
I wonder how easy it would be to restrict this use of zero precision
(i.e. flexible precision) to those where primitive types like int are
used as template arguments to operators, and require a
On 08/13/2013 10:57 PM, Kenneth Zadeck wrote:
1) The 4 files that hold the wide-int code itself. You have seen a
lot of this code before except for the infinite precision
templates. Also the classes are more C++ than C in their flavor.
In particular, the integration with trees is
On 08/24/2013 02:16 PM, Florian Weimer wrote:
On 08/13/2013 10:57 PM, Kenneth Zadeck wrote:
1) The 4 files that hold the wide-int code itself. You have seen a
lot of this code before except for the infinite precision
templates. Also the classes are more C++ than C in their flavor.
fixed with the enclosed patch.
On 08/23/2013 11:02 AM, Richard Sandiford wrote:
/* Return true if THIS is negative based on the interpretation of SGN.
For UNSIGNED, this is always false. This is correct even if
precision is 0. */
inline bool
wide_int::neg_p (signop sgn) const
It
The patch goes for (1) but (2) seems better to me, for a few reasons:
* As above, constants coming from rtl are already in the right form,
so if you create a wide_int from an rtx and only query it, no explicit
extension is needed.
* Things like logical operations and right shifts
Hi Kenny,
This is the first time I've looked at the implementation of wide-int.h
(rather than just looking at the rtl changes, which as you know I like
in general), so FWIW here are some comments on wide-int.h. I expect
a lot of them overlap with Richard B.'s comments.
I also expect many of
On 08/23/2013 11:02 AM, Richard Sandiford wrote:
Hi Kenny,
This is the first time I've looked at the implementation of wide-int.h
(rather than just looking at the rtl changes, which as you know I like
in general), so FWIW here are some comments on wide-int.h. I expect
a lot of them overlap
On Aug 23, 2013, at 8:02 AM, Richard Sandiford rdsandif...@googlemail.com
wrote:
/* Negate THIS. */
inline wide_int_ro
wide_int_ro::operator - () const
{
wide_int_ro r;
r = wide_int_ro (0) - *this;
return r;
}
/* Negate THIS. */
inline wide_int_ro
wide_int_ro::neg () const
{
On Aug 23, 2013, at 8:02 AM, Richard Sandiford rdsandif...@googlemail.com
wrote:
#define addr_max_bitsize (64)
#define addr_max_precision \
These should either be lower-case C++ constants or upper-case macros.
Fixed:
diff --git a/gcc/wide-int.h b/gcc/wide-int.h
index 9ccdf7c..b40962c
On Aug 23, 2013, at 8:02 AM, Richard Sandiford rdsandif...@googlemail.com
wrote:
* When a constant that has an integer type is converted to a
wide-int it comes in with precision 0. For these constants the
top bit does accurately reflect the sign of that constant; this
is an
Thanks for doing this. I haven't had chance to look at the branch yet
(hope to soon), but the results on mips64-linux-gnu look pretty good:
http://gcc.gnu.org/ml/gcc-testresults/2013-08/msg02033.html
The only failures that stand out as being possibly wide-int-related are:
FAIL:
cleaned up version of convert_modes that handles all constants in a
uniform manner.
This is clean on x86-64. Will test on other platforms tomorrow.
kenny
Index: gcc/expr.c
===
--- gcc/expr.c(revision 201884)
+++ gcc/expr.c
Index: gcc/optabs.c
===
--- gcc/optabs.c(revision 201884)
+++ gcc/optabs.c(working copy)
@@ -867,7 +867,8 @@ expand_subword_shift (enum machine_mode
outof_input, const1_rtx, 0, unsignedp, methods);
Richi and everyone else who may be interested,
Congrats on your first child. They are a lot of fun, but are very
high maintenence.
Today we put up the wide-int branch for all to see and play with. See
svn+ssh://gcc.gnu.org/svn/gcc/branches/wide-int
At this point, we have completed testing
76 matches
Mail list logo
