On Nov 23, 2013, at 5:19 PM, Joern Rennecke <joern.renne...@embecosm.com> wrote:
> wide-int.h says widest_int is always signed, yet the iterations count
> in the doloop interface is now unsigned. So, which is right, the code
> or the documentation?
The interface for TARGET_CAN_USE_DOLOOP_P's iteration parameter is documented
to be const widest_int&. The documentation suggests that only non-negative
values are actually used. I don't view this as much different from an int
parameter that is documented as being 0 or 1. You are free to think of it as
signed, because int is signed, or unsigned, as the values 0 and 1 are both
non-negative. The type of formal parameter is signed.
Does that help?
> I see that dfp.c and vax.c directly include wide-int.h,
> but aarch64.c and arc.c don't. Is that safe?
Certainly it is reasonable to include this, and by doing this, one doesn't have
to worry if another header changes to not include it.
Ok for the patch directly below?
Index: gcc/ChangeLog.wide-int
===================================================================
--- gcc/ChangeLog.wide-int (revision 205365)
+++ gcc/ChangeLog.wide-int (working copy)
@@ -43,7 +43,7 @@
* config/aarch64/aarch64.c
(aapcs_vfp_sub_candidate): Use wide-int interfaces.
(aarch64_float_const_representable_p): Likewise.
- * config/arc/arc.c
+ * config/arc/arc.c: Include wide-int.h.
(arc_can_use_doloop_p): Use wide-int interfaces.
* config/arm/arm.c
(aapcs_vfp_sub_candidate): Use wide-int interfaces.
Index: gcc/config/arc/arc.c
===================================================================
--- gcc/config/arc/arc.c (revision 205364)
+++ gcc/config/arc/arc.c (working copy)
@@ -66,6 +66,7 @@ along with GCC; see the file COPYING3.
#include "tree-pass.h"
#include "context.h"
#include "pass_manager.h"
+#include "wide-int.h"
/* Which cpu we're compiling for (A5, ARC600, ARC601, ARC700). */
static const char *arc_cpu_string = "";
