Re: [buildrobot] [PATCH] Fix redefinition of BITS_PER_UNIT
On 2014/1/1 02:45 PM, Mike Stump wrote: On Dec 31, 2013, at 12:26 PM, Jan-Benedict Glaw jbg...@lug-owl.de wrote: On Tue, 2013-12-31 15:24:52 +0800, Chung-Lin Tang clt...@codesourcery.com wrote: The nios2 port was just committed. Thanks to all that gave time and effort to review this. Just a heads-up: I see a lot of warnings about BITS_PER_UNIT being redefined, see eg. http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=74923 as an example. 2013-12-31 Jan-Benedict Glaw jbg...@lug-owl.de * config/nios2/nios2.h (BITS_PER_UNIT): Don't define it. diff --git a/gcc/config/nios2/nios2.h b/gcc/config/nios2/nios2.h index 8e6941b..f333be3 100644 --- a/gcc/config/nios2/nios2.h +++ b/gcc/config/nios2/nios2.h @@ -73,7 +73,6 @@ #define BITS_BIG_ENDIAN 0 #define BYTES_BIG_ENDIAN (TARGET_BIG_ENDIAN != 0) #define WORDS_BIG_ENDIAN (TARGET_BIG_ENDIAN != 0) -#define BITS_PER_UNIT 8 #define BITS_PER_WORD 32 #define UNITS_PER_WORD 4 #define POINTER_SIZE 32 Ok? Ok. Thanks for catching that.
Re: [PATCH] Final removal of mudflap
On Sat, 26 Oct 2013 14:41:01 -0600 Jeff Law l...@redhat.com wrote: Here's the final patch to remove mudflap. Per the multiple recommendations, it leaves the options as nops and warns for them. Can you write something about this for changes.html? -- Ryan Hillpsn: dirtyepic_sk gcc-porting/toolchain/wxwidgets @ gentoo.org 47C3 6D62 4864 0E49 8E9E 7F92 ED38 BD49 957A 8463 signature.asc Description: PGP signature
[Patch, bfin/c6x] Fix ICE for backends that rely on reorder_loops.
cc1 backtrace:
arraysum.c: In function 'test_entry':
arraysum.c:14:1: internal compiler error: in cfg_layout_initialize, at
cfgrtl.c:4233
}
^
0x6c096d cfg_layout_initialize(unsigned int)
../../trunk/gcc/cfgrtl.c:4233
0xeab763 reorder_loops
../../trunk/gcc/hw-doloop.c:500
0xeacd04 reorg_loops(bool, hw_doloop_hooks*)
../../trunk/gcc/hw-doloop.c:641
0xdb8d2e c6x_hwloops
../../trunk/gcc/config/c6x/c6x.c:5898
0xdbdb10 c6x_reorg
../../trunk/gcc/config/c6x/c6x.c:5939
0xa61e30 rest_of_handle_machine_reorg
../../trunk/gcc/reorg.c:3921
0xa61e5c execute
../../trunk/gcc/reorg.c:3951
Attached please find the patch for this ICE.
Since c6x backend choose doloops whose tail and head are the same
block, code generation will not be affected.
But it may bring some negetive effect on target code efficiency for
bfin backend as less hw-doloops may be generated.
In my point of view, what we need here is a better block reordering
that cares about hw-doloops.
If OK for trunk, can someone please apply it? Thanks.
Index: gcc/ChangeLog
===
--- gcc/ChangeLog(revision 206273)
+++ gcc/ChangeLog(working copy)
@@ -1,3 +1,12 @@
+2014-01-01 Felix Yang fei.yang0...@gmail.com
+
+* hw-doloop.c (set_bb_indices): Remove.
+(reorder_loops): Ditto.
+(reorg_loops): Remove do_reorder parameter.
+* hw-doloop.h (reorg_loops): Likewise.
+* config/c6x/c6x.c (c6x_hwloops): Do not rely on reorder_loops.
+* config/bfin/bfin.c (bfin_reorg_loops): Ditto.
+
2014-01-01 Jakub Jelinek ja...@redhat.com
* config/i386/sse.md (*movmode_internal): Guard
Index: gcc/hw-doloop.c
===
--- gcc/hw-doloop.c(revision 206273)
+++ gcc/hw-doloop.c(working copy)
@@ -470,85 +470,6 @@ free_loops (hwloop_info loops)
}
}
-#define BB_AUX_INDEX(BB) ((intptr_t) (BB)-aux)
-
-/* Initialize the aux fields to give ascending indices to basic blocks. */
-static void
-set_bb_indices (void)
-{
- basic_block bb;
- intptr_t index;
-
- index = 0;
- FOR_EACH_BB_FN (bb, cfun)
-bb-aux = (void *) index++;
-}
-
-/* The taken-branch edge from the loop end can actually go forward.
- If the target's hardware loop support requires that the loop end be
- after the loop start, try to reorder a loop's basic blocks when we
- find such a case.
- This is not very aggressive; it only moves at most one block. It
- does not introduce new branches into loops; it may remove them, or
- it may switch fallthru/jump edges. */
-static void
-reorder_loops (hwloop_info loops)
-{
- basic_block bb;
- hwloop_info loop;
-
- cfg_layout_initialize (0);
-
- set_bb_indices ();
-
- for (loop = loops; loop; loop = loop-next)
-{
- edge e;
- edge_iterator ei;
-
- if (loop-bad)
-continue;
-
- if (BB_AUX_INDEX (loop-head) = BB_AUX_INDEX (loop-tail))
-continue;
-
- FOR_EACH_EDGE (e, ei, loop-head-succs)
-{
- if (bitmap_bit_p (loop-block_bitmap, e-dest-index)
- BB_AUX_INDEX (e-dest) BB_AUX_INDEX (loop-tail))
-{
- basic_block start_bb = e-dest;
- basic_block start_prev_bb = start_bb-prev_bb;
-
- if (dump_file)
-fprintf (dump_file, ;; Moving block %d before block %d\n,
- loop-head-index, start_bb-index);
- loop-head-prev_bb-next_bb = loop-head-next_bb;
- loop-head-next_bb-prev_bb = loop-head-prev_bb;
-
- loop-head-prev_bb = start_prev_bb;
- loop-head-next_bb = start_bb;
- start_prev_bb-next_bb = start_bb-prev_bb = loop-head;
-
- set_bb_indices ();
- break;
-}
-}
- loops = loops-next;
-}
-
- FOR_EACH_BB_FN (bb, cfun)
-{
- if (bb-next_bb != EXIT_BLOCK_PTR_FOR_FN (cfun))
-bb-aux = bb-next_bb;
- else
-bb-aux = NULL;
-}
- cfg_layout_finalize ();
- clear_aux_for_blocks ();
- df_analyze ();
-}
-
/* Call the OPT function for LOOP and all of its sub-loops. This is
done in a depth-first search; innermost loops are visited first.
OPTIMIZE and FAIL are the functions passed to reorg_loops by the
@@ -611,15 +532,10 @@ optimize_loop (hwloop_info loop, struct hw_doloop_
instructions before the loop, to define loop bounds or set up a
special loop counter register.
- DO_REORDER should be set to true if we should try to use the
- reorder_loops function to ensure the loop end occurs after the loop
- start. This is for use by targets where the loop hardware requires
- this condition.
-
HOOKS is used to pass in target specific hooks; see
hw-doloop.h. */
void
-reorg_loops (bool do_reorder, struct hw_doloop_hooks *hooks)
+reorg_loops (struct hw_doloop_hooks *hooks)
{
hwloop_info loops = NULL;
hwloop_info loop;
@@ -632,21 +548,10 @@ void
bitmap_obstack_initialize (loop_stack);
if (dump_file)
-fprintf (dump_file, ;; Find loops, first pass\n\n);
+
Fix bootstrap with -mno-accumulate-outgoing-args
Hi,
this patch fixes ICE seen with -mno-accumulate-outgoing-args bootstrap building
go runtime.
The ICE is in dwarf2cfi.c while checking that on all paths into given basic
block stack
frames are same. It goes away either with disabling crossjumping or sched2 but
the problem
IMO really originates in combine-stack-adj.
Crossjumping combines two call seqences and breaks basic blocks in half of
argument setups.
OK, sched2 reorders:
(insn 762 761 765 50 (set (mem/c:SI (plus:SI (reg/f:SI 7 sp)
(const_int 112 [0x70])) [17 MEM[(struct *)bs + 8B]+0 S4 A64])
(const_int 8 [0x8])) ../../../../libgo/go/encoding/binary/binary.go:273
90 {*movsi_internal}
(nil))
(insn 765 762 766 50 (set (mem:HI (reg/f:SI 7 sp) [49 S2 A16])
(reg/v:HI 1 dx [orig:232 v ] [232]))
../../../../libgo/go/encoding/binary/binary.go:273 91 {*movhi_internal}
(expr_list:REG_DEAD (reg/v:HI 1 dx [orig:232 v ] [232])
(expr_list:REG_ARGS_SIZE (const_int 16 [0x10])
(nil
(insn 766 765 2326 50 (parallel [
(set (reg/f:SI 7 sp)
(plus:SI (reg/f:SI 7 sp)
(const_int -12 [0xfff4])))
(clobber (reg:CC 17 flags))
]) ../../../../libgo/go/encoding/binary/binary.go:273 265 {*addsi_1}
(expr_list:REG_UNUSED (reg:CC 17 flags)
(expr_list:REG_ARGS_SIZE (const_int 28 [0x1c])
(nil
to
(insn 766 761 762 54 (parallel [
(set (reg/f:SI 7 sp)
(plus:SI (reg/f:SI 7 sp)
(const_int -12 [0xfff4])))
(clobber (reg:CC 17 flags))
]) ../../../../libgo/go/encoding/binary/binary.go:273 265 {*addsi_1}
(expr_list:REG_UNUSED (reg:CC 17 flags)
(expr_list:REG_ARGS_SIZE (const_int 28 [0x1c])
(nil
(insn:TI 762 766 765 54 (set (mem/c:SI (plus:SI (reg/f:SI 7 sp)
(const_int 124 [0x7c])) [17 MEM[(struct *)bs + 8B]+0 S4 A64])
(const_int 8 [0x8])) ../../../../libgo/go/encoding/binary/binary.go:273
90 {*movsi_internal}
(nil))
(insn 765 762 770 54 (set (mem:HI (plus:SI (reg/f:SI 7 sp)
(const_int 12 [0xc])) [49 S2 A16])
(reg/v:HI 1 dx [orig:232 v ] [232]))
../../../../libgo/go/encoding/binary/binary.go:273 91 {*movhi_internal}
(expr_list:REG_DEAD (reg/v:HI 1 dx [orig:232 v ] [232])
(expr_list:REG_ARGS_SIZE (const_int 16 [0x10])
(nil
Here insn 765 gets adjusted for insn766 wihtout updating REG_ARGS_SIZE.
This is IMO not bug in scheduler but bug in fact that insn 775 should not have
the note on it
when it is not adjusting stack pointer. This is because originally it was push
instruction,
but combine-stack-adjustments turned it into move.
I think it should remove the ARG_SIZE note when doing so, since argument block
size should
be corrently annotated by preceeding stack adjustment insn.
Bootstrapped/regtested x86_64-linux. Did not double check it is solves the ARM
issue
reported in PR, too.
OK?
* combine-stack-adj.c (combine_stack_adjustments_for_block): Remove
ARG_SIZE note when adjustment was eliminated.
Index: combine-stack-adj.c
===
--- combine-stack-adj.c (revision 206233)
+++ combine-stack-adj.c (working copy)
@@ -567,6 +567,7 @@ combine_stack_adjustments_for_block (bas
try_apply_stack_adjustment (insn, reflist, 0,
-last_sp_adjust))
{
+ rtx note;
if (last2_sp_set)
maybe_move_args_size_note (last2_sp_set, last_sp_set, false);
else
@@ -576,6 +577,11 @@ combine_stack_adjustments_for_block (bas
reflist = NULL;
last_sp_set = NULL_RTX;
last_sp_adjust = 0;
+ /* We no longer adjust stack size. Whoever adjusted it earlier
+hopefully got the note right. */
+ note = find_reg_note (insn, REG_ARGS_SIZE, NULL_RTX);
+ if (note)
+ remove_note (insn, note);
continue;
}
}
Disable accumulate-outgoing-args for Generic and Buldozers
Hi, currently we have somewhat non-sential setting for accumulate-ougoing-args. It is disabled for Intel chips because recent chips do have stack engines making push/pop instructions cheap, it is however enabled for AMD chips and Generic. Originally accumulation was disabled since push/pop instructions was expensive on PentiumPro-Pentium4 and K6-K8 CPUS that did not have useful stack engines. This reason is now gone. There are still pros and cons of arg accumulation. I did quite extensive testing on AMD chips and found it performance neutral. On 32bit code it saves about 4% of code but with frame pointer disabled it expans unwind info quite a lot, so resulting binary is about 8% bigger. (This is also current default for -Os) I think we generally prefer code segment size reduction over EH frame, so we should flip the default (or disable it for cores if we decide otherwise). This patch disables accumulation by default. I intend to commit it once the bootstrap PR on unwind info is resolved if there is no significant oposition for doing so. I will also update release note explaining the code size effect. It would be great to get a heuristic enabling frame pointer for functions where doing so reduces code size without performance regressions. I think it is quite commonly the case. Bootstrapped/regtested x86_64-linux Honza * config/i38/x86-tune.def: Disable X86_TUNE_ACCUMULATE_OUTGOING_ARGS for generic and recent AMD chips Index: config/i386/x86-tune.def === --- config/i386/x86-tune.def(revision 206233) +++ config/i386/x86-tune.def(working copy) @@ -143,7 +143,7 @@ DEF_TUNE (X86_TUNE_REASSOC_FP_TO_PARALLE regression on mgrid due to IRA limitation leading to unecessary use of the frame pointer in 32bit mode. */ DEF_TUNE (X86_TUNE_ACCUMULATE_OUTGOING_ARGS, accumulate_outgoing_args, - m_PPRO | m_P4_NOCONA | m_BONNELL | m_SILVERMONT | m_AMD_MULTIPLE | m_GENERIC) + m_PPRO | m_P4_NOCONA | m_BONNELL | m_SILVERMONT | m_ATHLON_K8) /* X86_TUNE_PROLOGUE_USING_MOVE: Do not use push/pop in prologues that are considered on critical path. */
Re: [PATCH] Tiny predcom improvement (PR tree-optimization/59643)
On Tue, Dec 31, 2013 at 03:22:07PM -0500, Vladimir Makarov wrote:
Scimark2 is always used by Phoronix to show how bad GCC in
comparison with LLVM. It is understandable. For some reasons
phoronix is very biased to LLVM and, I'd say, a marketing machine
for LLVM.
They use very small selected benchmarks. Benchmarking is evil but I
believe more SPEC2000/SPEC2006 which use bigger real programs. With
their approach, they could use whetstone instead of Scimark but the
results would be very bad for LLVM (e.g. 64-bit code for -O3 on
Haswell):
I'm aware of all that, that said putting some minimal effort to increase
obstackles for their marketing is worth it.
It would be nice to fix also Scimark2 LU GCC-4.8 degradation to
finally stop this nonsense from Phoronix.
But strangely I don't see any LU GCC-4.8 degradation. This is
-O3 -march=native on i7-2600 (the Phoronix numbers were from i7-4960X,
but that is just SandyBridge vs. IvyBridge-E difference, so I don't
think at least for GCC (verified for the patched trunk, -O3 -march=native
and -O3 -march=ivybridge generated bitwise identical code) it is a significant
difference in what GCC generates, just the CPU is faster and has bigger caches.
Don't have i7-4960X to test it there unfortunately. The Phoronix posted numbers
show 80% improvement on LU from clang 3.3 to clang 3.4.
LU_factor has several inner loops, only the last one
for (jj=j+1; jjN; jj++)
Aii[jj] -= AiiJ * Aj[jj];
(but the only one with loop depth 3) is vectorized (with versioning for alias
due to the badly chosen data structure) by both gcc and clang,
for (k=j+1; kM; k++)
A[k][j] *= recp;
for vectorization would require gather+scatter (i.e. Skylake+) plus some
guarantee that it doesn't alias (#pragma omp simd?), but still it is
questionable if vectorization would be beneficial, and
double t = fabs(A[j][j]);
for (i=j+1; iM; i++)
{
double ab = fabs(A[i][j]);
if ( ab t)
{
jp = i;
t = ab;
}
}
is perhaps vectorizable with gather load (i.e. AVX2+) and -Ofast, haven't
tried that though.
GCC 4.7.4 20130609:
Composite Score: 1323.20
FFT Mflops: 183.61(N=1048576)
SOR Mflops: 618.12(1000 x 1000)
MonteCarlo: Mflops: 412.98
Sparse matmult Mflops: 1773.16(N=10, nz=100)
LU Mflops: 3628.12(M=1000, N=1000)
GCC 4.8.2 20131212 (Red Hat 4.8.2-7):
Composite Score: 1437.05
FFT Mflops: 213.91(N=1048576)
SOR Mflops: 1139.72(1000 x 1000)
MonteCarlo: Mflops: 526.34
Sparse matmult Mflops: 1713.81(N=10, nz=100)
LU Mflops: 3591.47(M=1000, N=1000)
GCC 4.9.0 20131230:
Composite Score: 1569.78
FFT Mflops: 254.65(N=1048576)
SOR Mflops: 1131.31(1000 x 1000)
MonteCarlo: Mflops: 563.64
Sparse matmult Mflops: 1780.87(N=10, nz=100)
LU Mflops: 4118.40(M=1000, N=1000)
GCC 4.9.0 20140101 plus the predcom patch:
Composite Score: 1692.05
FFT Mflops: 253.90(N=1048576)
SOR Mflops: 1605.16(1000 x 1000)
MonteCarlo: Mflops: 556.34
Sparse matmult Mflops: 1861.82(N=10, nz=100)
LU Mflops: 4183.01(M=1000, N=1000)
clang 3.3:
Composite Score: 1576.91
FFT Mflops: 255.41(N=1048576)
SOR Mflops: 1613.61(1000 x 1000)
MonteCarlo: Mflops: 557.79
Sparse matmult Mflops: 1914.02(N=10, nz=100)
LU Mflops: 3543.74(M=1000, N=1000)
clang 3.4 20131230:
Composite Score: 1566.95
FFT Mflops: 255.41(N=1048576)
SOR Mflops: 1617.87(1000 x 1000)
MonteCarlo: Mflops: 528.94
Sparse matmult Mflops: 1804.41(N=10, nz=100)
LU Mflops: 3628.12(M=1000, N=1000)
Jakub
[C++] PR59378: __builtin_shuffle in templates
Hello,
this patch makes build_x_vec_perm_expr more similar to the other build_x_*
functions (I don't know why I had imagined it wouldn't be necessary).
Bootstrap+testsuite on x86_64-unknown-linux-gnu.
2014-01-01 Marc Glisse marc.gli...@inria.fr
PR c++/59378
gcc/cp/
* typeck.c (build_x_vec_perm_expr): Handle non-dependent arguments
in templates.
gcc/testsuite/
* g++.dg/ext/pr59378.C: New file.
--
Marc GlisseIndex: gcc/cp/typeck.c
===
--- gcc/cp/typeck.c (revision 206274)
+++ gcc/cp/typeck.c (working copy)
@@ -4937,26 +4937,39 @@ cp_build_binary_op (location_t location,
return result;
}
/* Build a VEC_PERM_EXPR.
This is a simple wrapper for c_build_vec_perm_expr. */
tree
build_x_vec_perm_expr (location_t loc,
tree arg0, tree arg1, tree arg2,
tsubst_flags_t complain)
{
- if (processing_template_decl
- (type_dependent_expression_p (arg0)
+ tree orig_arg0 = arg0;
+ tree orig_arg1 = arg1;
+ tree orig_arg2 = arg2;
+ if (processing_template_decl)
+{
+ if (type_dependent_expression_p (arg0)
|| type_dependent_expression_p (arg1)
- || type_dependent_expression_p (arg2)))
-return build_min_nt_loc (loc, VEC_PERM_EXPR, arg0, arg1, arg2);
- return c_build_vec_perm_expr (loc, arg0, arg1, arg2, complain tf_error);
+ || type_dependent_expression_p (arg2))
+ return build_min_nt_loc (loc, VEC_PERM_EXPR, arg0, arg1, arg2);
+ arg0 = build_non_dependent_expr (arg0);
+ if (arg1)
+ arg1 = build_non_dependent_expr (arg1);
+ arg2 = build_non_dependent_expr (arg2);
+}
+ tree exp = c_build_vec_perm_expr (loc, arg0, arg1, arg2, complain
tf_error);
+ if (processing_template_decl exp != error_mark_node)
+return build_min_non_dep (VEC_PERM_EXPR, exp, orig_arg0,
+ orig_arg1, orig_arg2);
+ return exp;
}
/* Return a tree for the sum or difference (RESULTCODE says which)
of pointer PTROP and integer INTOP. */
static tree
cp_pointer_int_sum (enum tree_code resultcode, tree ptrop, tree intop,
tsubst_flags_t complain)
{
tree res_type = TREE_TYPE (ptrop);
Index: gcc/testsuite/g++.dg/ext/pr59378.C
===
--- gcc/testsuite/g++.dg/ext/pr59378.C (revision 0)
+++ gcc/testsuite/g++.dg/ext/pr59378.C (working copy)
@@ -0,0 +1,8 @@
+// { dg-do compile }
+typedef int v4si __attribute__ ((vector_size (4*sizeof(int;
+templateint C
+void traverse(v4si bounds){
+ v4si m = {0,1,2,3};
+ bounds = __builtin_shuffle(bounds, m);
+}
+template void traverse0(v4si);
Property changes on: gcc/testsuite/g++.dg/ext/pr59378.C
___
Added: svn:keywords
## -0,0 +1 ##
+Author Date Id Revision URL
\ No newline at end of property
Added: svn:eol-style
## -0,0 +1 ##
+native
\ No newline at end of property
[C++] Advertise -fext-numeric-literals in error messages
Hello,
an error message like the following:
error: unable to find numeric literal operator 'operator iF'
for using _Complex_I can be a bit hard for users to handle. This adds a
note that -std=gnu++11 and -fext-numeric-literals might help. Ideally we
would check if the suffix is indeed recognized by -fext-numeric-literals
before printing this text, but that's harder, someone else can do that
later.
No testcase because notes are pruned in the testsuite.
Bootstrap+testsuite on x86_64-unknown-linux-gnu.
2014-01-01 Marc Glisse marc.gli...@inria.fr
PR c++/59087
gcc/cp/
* parser.c (cp_parser_userdef_numeric_literal): Mention
-fext-numeric-literals in the message.
--
Marc GlisseIndex: gcc/cp/parser.c
===
--- gcc/cp/parser.c (revision 206274)
+++ gcc/cp/parser.c (working copy)
@@ -3918,20 +3918,23 @@ cp_parser_userdef_numeric_literal (cp_pa
result = finish_call_expr (decl, args, false, true, tf_none);
if (result != error_mark_node)
{
release_tree_vector (args);
return result;
}
}
release_tree_vector (args);
error (unable to find numeric literal operator %qD, name);
+ if (!cpp_get_options (parse_in)-ext_numeric_literals)
+inform (token-location, use -std=gnu++11 or -fext-numeric-literals
+ to enable more built-in suffixes);
return error_mark_node;
}
/* Parse a user-defined string constant. Returns a call to a user-defined
literal operator taking a character pointer and the length of the string
as arguments. */
static tree
cp_parser_userdef_string_literal (cp_token *token)
{
[C++] sfinae implicit-explicit construction
Hello,
this patch fixes the issue reported at
http://stackoverflow.com/q/20860535/1918193
that the error we get when implicitly constructing from an initializer
list using an explicit constructor doesn't have sfinae magic.
Bootstrap+testsuite on x86_64-unknown-linux-gnu.
2014-01-01 Marc Glisse marc.gli...@inria.fr
gcc/cp/
* call.c (convert_like_real): Check complain.
gcc/testsuite/
* g++.dg/cpp0x/initlist-explicit-sfinae.C: New file.
--
Marc GlisseIndex: gcc/cp/call.c
===
--- gcc/cp/call.c (revision 206274)
+++ gcc/cp/call.c (working copy)
@@ -5927,20 +5927,22 @@ convert_like_real (conversion *convs, tr
tree convfn = cand-fn;
unsigned i;
/* When converting from an init list we consider explicit
constructors, but actually trying to call one is an error. */
if (DECL_NONCONVERTING_P (convfn) DECL_CONSTRUCTOR_P (convfn)
/* Unless this is for direct-list-initialization. */
!(BRACE_ENCLOSED_INITIALIZER_P (expr)
CONSTRUCTOR_IS_DIRECT_INIT (expr)))
{
+ if (!(complain tf_error))
+ return error_mark_node;
error (converting to %qT from initializer list would use
explicit constructor %qD, totype, convfn);
}
/* If we're initializing from {}, it's value-initialization. */
if (BRACE_ENCLOSED_INITIALIZER_P (expr)
CONSTRUCTOR_NELTS (expr) == 0
TYPE_HAS_DEFAULT_CONSTRUCTOR (totype))
{
bool direct = CONSTRUCTOR_IS_DIRECT_INIT (expr);
Index: gcc/testsuite/g++.dg/cpp0x/initlist-explicit-sfinae.C
===
--- gcc/testsuite/g++.dg/cpp0x/initlist-explicit-sfinae.C (revision 0)
+++ gcc/testsuite/g++.dg/cpp0x/initlist-explicit-sfinae.C (working copy)
@@ -0,0 +1,47 @@
+// { dg-do compile }
+// { dg-options -std=c++11 }
+templatetypename _Tp
+_Tp declval() noexcept;
+
+templatebool b
+struct bt {
+static constexpr bool value = b;
+};
+
+template typename To_, typename... From_
+class my_is_convertible_many {
+ private:
+template typename To
+ struct indirector {
+ indirector(To);
+ };
+
+template typename To, typename... From
+ struct tag {};
+
+template typename To, typename... From
+ static auto test(tagTo, From...)
+ - decltype(indirectorTo({declvalFrom()...}), bttrue());
+static auto test(...)
+ - btfalse;
+
+ public:
+static constexpr bool value = decltype(test(tagTo_, From_...()))::value;
+};
+
+struct A {};
+struct B {};
+struct C {};
+
+struct Test {
+ Test(A, A);
+ //Test(B, B);
+ explicit Test(C, C);
+};
+
+int main() {
+ static_assert(my_is_convertible_manyTest, A, A::value,); // true, correct
+ static_assert(!my_is_convertible_manyTest, B, B::value,); // false,
correct
+ static_assert(!my_is_convertible_manyTest, C, C::value,); // error
+ return 0;
+}
Property changes on: gcc/testsuite/g++.dg/cpp0x/initlist-explicit-sfinae.C
___
Added: svn:eol-style
## -0,0 +1 ##
+native
\ No newline at end of property
Added: svn:keywords
## -0,0 +1 ##
+Author Date Id Revision URL
\ No newline at end of property
Re: pch bug fix
On Wed, Jan 01, 2014 at 08:46:31AM +0100, Jakub Jelinek wrote:
Thanks for tracking this down, this sounds like PR59436. How have you
managed to track it down? I also wonder why it doesn't seem to affect 4.8
when it also has the same change.
Based on the comments in gengtype.c, I'd expect
unsigned char *GTY ((atomic, length (sizeof (struct target_optabs
optabs;
to work (or, perhaps instead of sizeof directly call a function that is
defined in optabs.c and returns that value, perhaps optabs.h isn't included
where it should be), but unfortunately it seems to be rejected right now.
So, the question is how hard would it be to support that.
Without any gengtype.c changes, I wonder if just following change wouldn't
do it, gengtype considers only char and unsigned char pointers as strings
with the special strlen handling, all other scalar types are treated
differently it seems, and signed char aliases everything too.
Or s/signed char/void/ in the patch is perhaps even better.
--- gcc/tree-core.h.jj 2013-12-11 10:11:06.0 +0100
+++ gcc/tree-core.h 2014-01-01 19:42:15.319869786 +0100
@@ -1550,7 +1550,7 @@ struct GTY(()) tree_optimization_option
/* Target optabs for this set of optimization options. This is of
type `struct target_optabs *'. */
- unsigned char *GTY ((atomic)) optabs;
+ signed char *GTY ((atomic)) optabs;
/* The value of this_target_optabs against which the optabs above were
generated. */
--- gcc/optabs.c.jj 2013-12-10 12:43:21.0 +0100
+++ gcc/optabs.c2014-01-01 19:43:04.093620067 +0100
@@ -6245,7 +6245,7 @@ init_tree_optimization_optabs (tree optn
/* If the optabs changed, record it. */
if (memcmp (tmp_optabs, this_target_optabs, sizeof (struct target_optabs)))
-TREE_OPTIMIZATION_OPTABS (optnode) = (unsigned char *) tmp_optabs;
+TREE_OPTIMIZATION_OPTABS (optnode) = (signed char *) tmp_optabs;
else
{
TREE_OPTIMIZATION_OPTABS (optnode) = NULL;
Jakub
Re: [PATCH] Tiny predcom improvement (PR tree-optimization/59643)
On 1/1/2014, 12:50 PM, Jakub Jelinek wrote: On Tue, Dec 31, 2013 at 03:22:07PM -0500, Vladimir Makarov wrote: Scimark2 is always used by Phoronix to show how bad GCC in comparison with LLVM. It is understandable. For some reasons phoronix is very biased to LLVM and, I'd say, a marketing machine for LLVM. They use very small selected benchmarks. Benchmarking is evil but I believe more SPEC2000/SPEC2006 which use bigger real programs. With their approach, they could use whetstone instead of Scimark but the results would be very bad for LLVM (e.g. 64-bit code for -O3 on Haswell): I'm aware of all that, that said putting some minimal effort to increase obstackles for their marketing is worth it. I believe that Michael Larabel has no idea what he is measuring. I don't believe in his data too. Recently I tried to reproduce Scimark results for GCC4.8 and LLVM3.3 from his article LLVM Clang 3.4 Already Has Some Performance Changes: http://www.phoronix.com/scan.php?page=articleitem=llvm_clang34_firstnum=2 He used i7-4770K for this. I used the closest machine I found i5-4670 (with switched turbo mode off). The important difference is 0.1Ghz in frequency (3.5Ghz vs. 3.4 Ghz). I got close GCC Scimark (-large) composite score when I used -O and still on my machine the composite score was 20% higher than the article reports although the article says that -O3 -march=core-avx were used. His articles about LLVM and GCC usually contains a lot of negative emotions about GCC and positive ones about LLVM. I don't know may be he tried to communicate with GCC community and got a frustrated experience. That is only my explanation now why he is so biased towards LLVM. So far I saw several pitfalls in his testing methodology: o Micro-benchmarking. You just gave an example LU-factorization in Scimark2 where most benchmark time is spent in 2-lines loop. o Comparing LLVM and GCC on fortran benchmarks. LLVM has no fortran FE and just quietly call system GCC. So comparison LLVM and GCC on fortran benchmarks means comparison system GCC and a given GCC. o IMO, the data in articles lack credability may be because a wrong setup.
Re: [PATCH i386 5/8] [AVX-512] Extend vectorizer hooks.
gcc/
2013-12-30 Alexander Ivchenko alexander.ivche...@intel.com
Maxim Kuznetsov maxim.kuznet...@intel.com
Sergey Lega sergey.s.l...@intel.com
Anna Tikhonova anna.tikhon...@intel.com
Ilya Tocar ilya.to...@intel.com
Andrey Turetskiy andrey.turets...@intel.com
Ilya Verbin ilya.ver...@intel.com
Kirill Yukhin kirill.yuk...@intel.com
Michael Zolotukhin michael.v.zolotuk...@intel.com
* config/i386/i386.c (MAX_CLASSES): Increase number of classes.
(classify_argument): Extend for 512 bit vectors.
(construct_container): Ditto.
(function_arg_advance_32): Ditto.
(function_arg_advance_64): Ditto.
(function_arg_32): Ditto.
(function_arg_64): Ditto.
(function_value_32): Ditto.
(return_in_memory_32): Ditto.
(ix86_gimplify_va_arg): Ditto.
(standard_sse_constant_p): Ditto.
(standard_sse_constant_opcode): Ditto.
(ix86_expand_vector_convert_uns_vsivsf): Ditto.
(ix86_build_const_vector): Ditto.
(ix86_build_signbit_mask): Ditto.
(ix86_expand_sse_cmp): Extend for AVX512.
(ix86_expand_sse_movcc): Ditto.
(ix86_expand_int_vcond): Ditto.
(ix86_expand_vec_perm): Ditto.
(ix86_expand_sse_unpack): Ditto.
(ix86_constant_alignment): Ditto.
The change is actually to ix86_data_alignment, not to ix86_constant_alignment:
@@ -26219,7 +26433,8 @@ ix86_constant_alignment (tree exp, int align)
int
ix86_data_alignment (tree type, int align, bool opt)
{
- int max_align = optimize_size ? BITS_PER_WORD : MIN (256,
MAX_OFILE_ALIGNMENT);
+ int max_align = optimize_size ? BITS_PER_WORD
+ : MIN (512, MAX_OFILE_ALIGNMENT);
if (opt
AGGREGATE_TYPE_P (type)
Note that it has unexpected side-effects: previously, in 32-bit mode, 256-bit
aggregate objects would have been given 256-bit alignment; now, they will fall
back to default alignment, for example 32-bit only.
--
Eric Botcazou
[PATCH] pch bug fix (take 2, PR pch/59436)
On Wed, Jan 01, 2014 at 07:53:48PM +0100, Jakub Jelinek wrote:
Without any gengtype.c changes, I wonder if just following change wouldn't
do it, gengtype considers only char and unsigned char pointers as strings
with the special strlen handling, all other scalar types are treated
differently it seems, and signed char aliases everything too.
Or s/signed char/void/ in the patch is perhaps even better.
I've bootstrapped/regtested this on x86_64-linux and i686-linux,
and hopefully verified the problem from the PR is gone, by running over
610 successful PCH write + PCH read cycles as described in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59436#c14 , no failures
with the patch, while on a tree from yesterday without the patch I could
reproduce it 17 times, on average every 22 iterations (from 2 to 81).
Ok for trunk (and after a while for 4.8)?
2014-01-01 Mike Stump mikest...@comcast.net
Jakub Jelinek ja...@redhat.com
PR pch/59436
* tree-core.h (struct tree_optimization_option): Change optabs
type from unsigned char * to void *.
* optabs.c (init_tree_optimization_optabs): Adjust
TREE_OPTIMIZATION_OPTABS initialization.
--- gcc/tree-core.h.jj 2013-12-11 10:11:06.0 +0100
+++ gcc/tree-core.h 2014-01-01 19:42:15.319869786 +0100
@@ -1550,7 +1550,7 @@ struct GTY(()) tree_optimization_option
/* Target optabs for this set of optimization options. This is of
type `struct target_optabs *'. */
- unsigned char *GTY ((atomic)) optabs;
+ void *GTY ((atomic)) optabs;
/* The value of this_target_optabs against which the optabs above were
generated. */
--- gcc/optabs.c.jj 2013-12-10 12:43:21.0 +0100
+++ gcc/optabs.c2014-01-01 19:43:04.093620067 +0100
@@ -6245,7 +6245,7 @@ init_tree_optimization_optabs (tree optn
/* If the optabs changed, record it. */
if (memcmp (tmp_optabs, this_target_optabs, sizeof (struct target_optabs)))
-TREE_OPTIMIZATION_OPTABS (optnode) = (unsigned char *) tmp_optabs;
+TREE_OPTIMIZATION_OPTABS (optnode) = (void *) tmp_optabs;
else
{
TREE_OPTIMIZATION_OPTABS (optnode) = NULL;
Jakub
Re: [Patch, bfin/c6x] Fix ICE for backends that rely on reorder_loops.
Ping x1
Any suggestions on this?
The background is that we cannot call cfg_layout_initialize after the
bb-reorder pass
as indicated by the following code snippet:
/* Once bb reordering is complete, cfg layout mode should not be re-entered.
Entering cfg layout mode will perform optimizations on the cfg that
could affect the bb layout negatively or even require fixups. An
example of the latter is if edge forwarding performed when optimizing
the cfg layout required moving a block from the hot to the cold section
under -freorder-blocks-and-partition. This would create an illegal
partitioning unless some manual fixup was performed. */
gcc_assert (!crtl-bb_reorder_complete);
I just removed the reorder_loops functionality and will consider
implementing a similiar feature
at the end of the bb-reorder pass as a next step.
Cheers,
Felix
On Wed, Jan 1, 2014 at 9:01 PM, Felix Yang fei.yang0...@gmail.com wrote:
cc1 backtrace:
arraysum.c: In function 'test_entry':
arraysum.c:14:1: internal compiler error: in cfg_layout_initialize, at
cfgrtl.c:4233
}
^
0x6c096d cfg_layout_initialize(unsigned int)
../../trunk/gcc/cfgrtl.c:4233
0xeab763 reorder_loops
../../trunk/gcc/hw-doloop.c:500
0xeacd04 reorg_loops(bool, hw_doloop_hooks*)
../../trunk/gcc/hw-doloop.c:641
0xdb8d2e c6x_hwloops
../../trunk/gcc/config/c6x/c6x.c:5898
0xdbdb10 c6x_reorg
../../trunk/gcc/config/c6x/c6x.c:5939
0xa61e30 rest_of_handle_machine_reorg
../../trunk/gcc/reorg.c:3921
0xa61e5c execute
../../trunk/gcc/reorg.c:3951
Attached please find the patch for this ICE.
Since c6x backend choose doloops whose tail and head are the same
block, code generation will not be affected.
But it may bring some negetive effect on target code efficiency for
bfin backend as less hw-doloops may be generated.
In my point of view, what we need here is a better block reordering
that cares about hw-doloops.
If OK for trunk, can someone please apply it? Thanks.
Index: gcc/ChangeLog
===
--- gcc/ChangeLog(revision 206273)
+++ gcc/ChangeLog(working copy)
@@ -1,3 +1,12 @@
+2014-01-01 Felix Yang fei.yang0...@gmail.com
+
+* hw-doloop.c (set_bb_indices): Remove.
+(reorder_loops): Ditto.
+(reorg_loops): Remove do_reorder parameter.
+* hw-doloop.h (reorg_loops): Likewise.
+* config/c6x/c6x.c (c6x_hwloops): Do not rely on reorder_loops.
+* config/bfin/bfin.c (bfin_reorg_loops): Ditto.
+
2014-01-01 Jakub Jelinek ja...@redhat.com
* config/i386/sse.md (*movmode_internal): Guard
Index: gcc/hw-doloop.c
===
--- gcc/hw-doloop.c(revision 206273)
+++ gcc/hw-doloop.c(working copy)
@@ -470,85 +470,6 @@ free_loops (hwloop_info loops)
}
}
-#define BB_AUX_INDEX(BB) ((intptr_t) (BB)-aux)
-
-/* Initialize the aux fields to give ascending indices to basic blocks. */
-static void
-set_bb_indices (void)
-{
- basic_block bb;
- intptr_t index;
-
- index = 0;
- FOR_EACH_BB_FN (bb, cfun)
-bb-aux = (void *) index++;
-}
-
-/* The taken-branch edge from the loop end can actually go forward.
- If the target's hardware loop support requires that the loop end be
- after the loop start, try to reorder a loop's basic blocks when we
- find such a case.
- This is not very aggressive; it only moves at most one block. It
- does not introduce new branches into loops; it may remove them, or
- it may switch fallthru/jump edges. */
-static void
-reorder_loops (hwloop_info loops)
-{
- basic_block bb;
- hwloop_info loop;
-
- cfg_layout_initialize (0);
-
- set_bb_indices ();
-
- for (loop = loops; loop; loop = loop-next)
-{
- edge e;
- edge_iterator ei;
-
- if (loop-bad)
-continue;
-
- if (BB_AUX_INDEX (loop-head) = BB_AUX_INDEX (loop-tail))
-continue;
-
- FOR_EACH_EDGE (e, ei, loop-head-succs)
-{
- if (bitmap_bit_p (loop-block_bitmap, e-dest-index)
- BB_AUX_INDEX (e-dest) BB_AUX_INDEX (loop-tail))
-{
- basic_block start_bb = e-dest;
- basic_block start_prev_bb = start_bb-prev_bb;
-
- if (dump_file)
-fprintf (dump_file, ;; Moving block %d before block %d\n,
- loop-head-index, start_bb-index);
- loop-head-prev_bb-next_bb = loop-head-next_bb;
- loop-head-next_bb-prev_bb = loop-head-prev_bb;
-
- loop-head-prev_bb = start_prev_bb;
- loop-head-next_bb = start_bb;
- start_prev_bb-next_bb = start_bb-prev_bb = loop-head;
-
- set_bb_indices ();
- break;
-}
-}
- loops = loops-next;
-}
-
- FOR_EACH_BB_FN (bb, cfun)
-{
- if (bb-next_bb != EXIT_BLOCK_PTR_FOR_FN (cfun))
-bb-aux = bb-next_bb;
- else
-bb-aux = NULL;
-}
-
Re: pch bug fix
On Dec 31, 2013, at 11:46 PM, Jakub Jelinek ja...@redhat.com wrote: On Tue, Dec 31, 2013 at 10:39:58PM -0800, Mike Stump wrote: In testing for wide-int, we discovered that someone seems to have blown pch Thanks for tracking this down, this sounds like PR59436. To confirm that, one would need to either, investigate those issues, if it is the same, it is just plain hard work, or statistically work up a probability of failure, and run the test case enough to be 99.9% certain in a change of test case result and then drop my patch in, and then check. In my case, I was near 30% failure, so, I could run it 20 times, and be 99.9% certain. I didn't judge my work by the probabilistic method; rather I only used it to double check after I was certain I understood and fixed the problem. I read through the PR and could not rise above 10% confidence that it is the same problem. How have you managed to track it down? :-) You know, I'd love to teach an AI how to debug gcc, then, we could just use it to debug gcc, and it would have found the problem in 20 minutes on my crappy computer (16 core), I'd love to use my nice computer (64 cores) on a hard problem with such a program. One day, this will come to pass, but, we seem so far away still from that goal. I'll give you an overview of how it should be done, and I mostly did this, though, at times not quite in this order: First, was the determination that the issue, when pch isn't used, doesn't occur. Next, was to find the data that is wrong and the address it is at. You see if the wrong data is memory smashed or created that way purposefully. In my case, it was smashed by an unrelated data structure. Next, why, what formed that address for both pieces of data? In my case, both were ggc allocated, and valid addresses, wait, that's can't be. Yup, it is the case. The allocations are correct, and purposefully given out by ggc and are correct and both simultaneously live, wait, that can't be. Size, it turns out, the person allocation the data structure was pch importing, and it has a size in mind, that size is way to small, and the write off the end of the allocated data structure clobbers the other unrelated data structure. Now, why is the size wrong? Comes from the pch file that way. Why? During initial allocation on the pch build size, the size is correct. If pch is off, the size is correct, what? Walk writing, notice that someone calls strlen on the data in question. Wait, that's wrong, why does it do that? Ah, char * is a string. char[500], when you gty atomic it and takes it's address, it persisted out as a string, but that's wrong. Make it not use strlen. The rest of the process is then about fixing it. I'm old skool, so, I remember the days of debugging gcc when we had memory smashers, lifetime issues and other such fun. ggc was invented to get rid of a large class of errors in one wave of the magic wand, and today, those issues do seem rarer indeed. I also wonder why it doesn't seem to affect 4.8 when it also has the same change. Don't know. If no one writes to the pat_enable after pch load, then, trivially, clobbering can't happen; though, if someone ever reads pat_enable, then I can't imagine how it could work. Based on the comments in gengtype.c, I'd expect unsigned char *GTY ((atomic, length (sizeof (struct target_optabs optabs; The comments should be fixed... to work (or, perhaps instead of sizeof directly call a function that is defined in optabs.c and returns that value, perhaps optabs.h isn't included where it should be), but unfortunately it seems to be rejected right now. Yup, I thought the same, and first tried the same. I too noticed it didn't work. So, the question is how hard would it be to support that. I don't know. All I know is that if a single other person stubs his toe on this issue, it will be a complete waste of their time trying to track it down.
Re: [PATCH] pch bug fix (take 2, PR pch/59436)
On Jan 1, 2014, at 3:08 PM, Jakub Jelinek ja...@redhat.com wrote: On Wed, Jan 01, 2014 at 07:53:48PM +0100, Jakub Jelinek wrote: Without any gengtype.c changes, I wonder if just following change wouldn't do it, gengtype considers only char and unsigned char pointers as strings with the special strlen handling, all other scalar types are treated differently it seems, and signed char aliases everything too. Or s/signed char/void/ in the patch is perhaps even better. I've bootstrapped/regtested this on x86_64-linux and i686-linux, and hopefully verified the problem from the PR is gone, by running over 610 successful PCH write + PCH read cycles as described in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59436#c14 , no failures with the patch, while on a tree from yesterday without the patch I could reproduce it 17 times, on average every 22 iterations (from 2 to 81). Yup. That sounds like the same bug then. Ok for trunk (and after a while for 4.8)? I thought my fingers tried this version for some reason… certainly I like this version better than mine. I've tried this, and indeed it fixes my bug, so, I withdraw my version and endorse this one, thanks.
Re: [PATCH] pch bug fix (take 2, PR pch/59436)
On Jan 1, 2014, at 3:08 PM, Jakub Jelinek ja...@redhat.com wrote:
if (memcmp (tmp_optabs, this_target_optabs, sizeof (struct target_optabs)))
-TREE_OPTIMIZATION_OPTABS (optnode) = (unsigned char *) tmp_optabs;
+TREE_OPTIMIZATION_OPTABS (optnode) = (void *) tmp_optabs;
Oh, the cast isn't necessary.
diff --git a/gcc/optabs.c b/gcc/optabs.c
index 24e75d5..3958735 100644
--- a/gcc/optabs.c
+++ b/gcc/optabs.c
@@ -6242,7 +6242,7 @@ init_tree_optimization_optabs (tree optnode)
/* If the optabs changed, record it. */
if (memcmp (tmp_optabs, this_target_optabs, sizeof (struct target_optabs)))
-TREE_OPTIMIZATION_OPTABS (optnode) = (unsigned char *) tmp_optabs;
+TREE_OPTIMIZATION_OPTABS (optnode) = tmp_optabs;
else
{
TREE_OPTIMIZATION_OPTABS (optnode) = NULL;
is fine.
Re: wide-int, avr
On Nov 23, 2013, at 11:19 AM, Mike Stump mikest...@comcast.net wrote: Richi has asked the we break the wide-int patch so that the individual port and front end maintainers can review their parts without have to go through the entire patch.This patch covers the avr port. Ok? Ping? * config/avr/avr.c (avr_out_round): Use wide-int interfaces. (avr_fold_builtin): Likewise. diff --git a/gcc/config/avr/avr.c b/gcc/config/avr/avr.c index 8d98c81..e94e0d7 100644 --- a/gcc/config/avr/avr.c +++ b/gcc/config/avr/avr.c @@ -7550,6 +7550,8 @@ avr_out_round (rtx insn ATTRIBUTE_UNUSED, rtx *xop, int *plen) // The smallest fractional bit not cleared by the rounding is 2^(-RP). int fbit = (int) GET_MODE_FBIT (mode); double_int i_add = double_int_zero.set_bit (fbit-1 - INTVAL (xop[2])); + wide_int wi_add = wi::set_bit_in_zero (fbit-1 - INTVAL (xop[2]), +GET_MODE_PRECISION (imode)); // Lengths of PLUS and AND parts. int len_add = 0, *plen_add = plen ? len_add : NULL; int len_and = 0, *plen_and = plen ? len_and : NULL; @@ -7579,7 +7581,7 @@ avr_out_round (rtx insn ATTRIBUTE_UNUSED, rtx *xop, int *plen) // Rounding point ^^^ // Added above ^ rtx xreg = simplify_gen_subreg (imode, xop[0], mode, 0); - rtx xmask = immed_double_int_const (-i_add - i_add, imode); + rtx xmask = immed_wide_int_const (-wi_add - wi_add, imode); xpattern = gen_rtx_SET (VOIDmode, xreg, gen_rtx_AND (imode, xreg, xmask)); @@ -12230,7 +12232,7 @@ avr_fold_builtin (tree fndecl, int n_args ATTRIBUTE_UNUSED, tree *arg, break; } -tmap = double_int_to_tree (map_type, tree_to_double_int (arg[0])); +tmap = wide_int_to_tree (map_type, arg[0]); map = TREE_INT_CST_LOW (tmap); if (TREE_CODE (tval) != INTEGER_CST @@ -12335,8 +12337,7 @@ avr_fold_builtin (tree fndecl, int n_args ATTRIBUTE_UNUSED, tree *arg, /* Use map o G^-1 instead of original map to undo the effect of G. */ -tmap = double_int_to_tree (map_type, - double_int::from_uhwi (best_g.map)); +tmap = wide_int_to_tree (map_type, best_g.map); return build_call_expr (fndecl, 3, tmap, tbits, tval); } /* AVR_BUILTIN_INSERT_BITS */
Re: wide-int, build system
On Nov 23, 2013, at 11:20 AM, Mike Stump mikest...@comcast.net wrote: Richi has asked the we break the wide-int patch so that the individual port and front end maintainers can review their parts without have to go through the entire patch.This patch covers the build system (make). Ok? Ping? * Makefile.in (RTL_H, CFGLOOP_H, C_COMMON_H, TREE_FLOW_H): Add wide-int.h. (REAL_H): Add signop.h. (OBJS): Add wide-int.o and wide-int-print.o. (GTFILES): Add wide-int.h and signop.h. (wide-int.h): New rule. (TAGS): Look for .cc files too. diff --git a/gcc/Makefile.in b/gcc/Makefile.in index 34e07a0..958118d 100644 --- a/gcc/Makefile.in +++ b/gcc/Makefile.in @@ -869,7 +869,7 @@ RTL_BASE_H = coretypes.h rtl.h rtl.def $(MACHMODE_H) reg-notes.def \ insn-notes.def $(INPUT_H) $(REAL_H) statistics.h $(VEC_H) \ $(FIXED_VALUE_H) alias.h $(HASHTAB_H) FIXED_VALUE_H = fixed-value.h $(MACHMODE_H) double-int.h -RTL_H = $(RTL_BASE_H) $(FLAGS_H) genrtl.h +RTL_H = $(RTL_BASE_H) $(FLAGS_H) genrtl.h wide-int.h READ_MD_H = $(OBSTACK_H) $(HASHTAB_H) read-md.h PARAMS_H = params.h params.def BUILTINS_DEF = builtins.def sync-builtins.def omp-builtins.def \ @@ -899,7 +899,7 @@ FUNCTION_H = function.h $(HASHTAB_H) $(TM_H) hard-reg-set.h \ EXPR_H = expr.h insn-config.h $(FUNCTION_H) $(RTL_H) $(FLAGS_H) $(TREE_H) $(MACHMODE_H) $(EMIT_RTL_H) OPTABS_H = optabs.h insn-codes.h insn-opinit.h REGS_H = regs.h $(MACHMODE_H) hard-reg-set.h -CFGLOOP_H = cfgloop.h $(BASIC_BLOCK_H) double-int.h \ +CFGLOOP_H = cfgloop.h $(BASIC_BLOCK_H) double-int.h wide-int.h \ $(BITMAP_H) sbitmap.h IPA_UTILS_H = ipa-utils.h $(TREE_H) $(CGRAPH_H) IPA_REFERENCE_H = ipa-reference.h $(BITMAP_H) $(TREE_H) @@ -914,7 +914,7 @@ TIMEVAR_H = timevar.h timevar.def INSN_ATTR_H = insn-attr.h insn-attr-common.h $(INSN_ADDR_H) INSN_ADDR_H = $(srcdir)/insn-addr.h C_COMMON_H = c-family/c-common.h c-family/c-common.def $(TREE_H) \ - $(SPLAY_TREE_H) $(CPPLIB_H) $(GGC_H) $(DIAGNOSTIC_CORE_H) + $(SPLAY_TREE_H) $(CPPLIB_H) $(GGC_H) $(DIAGNOSTIC_CORE_H) wide-int.h C_PRAGMA_H = c-family/c-pragma.h $(CPPLIB_H) C_TREE_H = c/c-tree.h $(C_COMMON_H) $(DIAGNOSTIC_H) SYSTEM_H = system.h hwint.h $(srcdir)/../include/libiberty.h \ @@ -932,7 +932,7 @@ TREE_PASS_H = tree-pass.h $(TIMEVAR_H) $(DUMPFILE_H) TREE_FLOW_H = tree-flow.h tree-flow-inline.h tree-ssa-operands.h \ $(BITMAP_H) sbitmap.h $(BASIC_BLOCK_H) $(GIMPLE_H) \ $(HASHTAB_H) $(CGRAPH_H) $(IPA_REFERENCE_H) \ - tree-ssa-alias.h + tree-ssa-alias.h wide-int.h TREE_SSA_H = tree-ssa.h $(TREE_FLOW_H) PRETTY_PRINT_H = pretty-print.h $(INPUT_H) $(OBSTACK_H) TREE_PRETTY_PRINT_H = tree-pretty-print.h $(PRETTY_PRINT_H) @@ -942,7 +942,7 @@ DIAGNOSTIC_H = diagnostic.h $(DIAGNOSTIC_CORE_H) $(PRETTY_PRINT_H) C_PRETTY_PRINT_H = c-family/c-pretty-print.h $(PRETTY_PRINT_H) \ $(C_COMMON_H) $(TREE_H) TREE_INLINE_H = tree-inline.h -REAL_H = real.h $(MACHMODE_H) +REAL_H = real.h $(MACHMODE_H) signop.h LTO_STREAMER_H = lto-streamer.h $(LINKER_PLUGIN_API_H) $(TARGET_H) \ $(CGRAPH_H) $(VEC_H) $(HASH_TABLE_H) $(TREE_H) $(GIMPLE_H) \ $(GCOV_IO_H) $(DIAGNOSTIC_H) alloc-pool.h pointer-set.h @@ -1465,6 +1465,8 @@ OBJS = \ vmsdbgout.o \ vtable-verify.o \ web.o \ + wide-int.o \ + wide-int-print.o \ xcoffout.o \ $(out_object_file) \ $(EXTRA_OBJS) \ @@ -2227,7 +2229,7 @@ s-tm-texi: build/genhooks$(build_exeext) $(srcdir)/doc/tm.texi.in GTFILES = $(CPP_ID_DATA_H) $(srcdir)/input.h $(srcdir)/coretypes.h \ $(host_xm_file_list) \ $(tm_file_list) $(HASHTAB_H) $(SPLAY_TREE_H) $(srcdir)/bitmap.h \ - $(srcdir)/alias.h $(srcdir)/coverage.c $(srcdir)/rtl.h \ + $(srcdir)/wide-int.h $(srcdir)/alias.h $(srcdir)/coverage.c $(srcdir)/rtl.h \ $(srcdir)/optabs.h $(srcdir)/tree.h $(srcdir)/tree-core.h \ $(srcdir)/libfuncs.h $(SYMTAB_H) \ $(srcdir)/real.h $(srcdir)/function.h $(srcdir)/insn-addr.h $(srcdir)/hwint.h \ @@ -2238,6 +2240,7 @@ GTFILES = $(CPP_ID_DATA_H) $(srcdir)/input.h $(srcdir)/coretypes.h \ $(srcdir)/alias.c $(srcdir)/bitmap.c $(srcdir)/cselib.c $(srcdir)/cgraph.c \ $(srcdir)/ipa-prop.c $(srcdir)/ipa-cp.c $(srcdir)/ipa-utils.h \ $(srcdir)/dbxout.c \ + $(srcdir)/signop.h \ $(srcdir)/dwarf2out.h \ $(srcdir)/dwarf2asm.c \ $(srcdir)/dwarf2cfi.c \ @@ -2435,15 +2438,16 @@ CFLAGS-gengtype-parse.o += -DGENERATOR_FILE build/gengtype-parse.o: $(BCONFIG_H) gengtype-state.o build/gengtype-state.o: gengtype-state.c $(SYSTEM_H) \ - gengtype.h errors.h double-int.h version.h $(HASHTAB_H) $(OBSTACK_H) \ - $(XREGEX_H) + gengtype.h errors.h double-int.h version.h $(HASHTAB_H)\ + $(OBSTACK_H) $(XREGEX_H) gengtype-state.o: $(CONFIG_H) CFLAGS-gengtype-state.o += -DGENERATOR_FILE build/gengtype-state.o: $(BCONFIG_H) - +wide-int.h: $(GTM_H) $(TREE_H) hwint.h $(OPTIONS_H)
Re: wide-int, OpenMP
On Nov 23, 2013, at 11:22 AM, Mike Stump mikest...@comcast.net wrote:
Richi has asked the we break the wide-int patch so that the individual port
and front end maintainers can review their parts without have to go through
the entire patch.This patch covers the OpenMP code.
Ok?
Ping?
* omp-low.c
(scan_omp_1_op): Use wide-int interfaces.
diff --git a/gcc/omp-low.c b/gcc/omp-low.c
index 2995060..d26139c 100644
--- a/gcc/omp-low.c
+++ b/gcc/omp-low.c
@@ -2530,9 +2530,7 @@ scan_omp_1_op (tree *tp, int *walk_subtrees, void *data)
if (tem != TREE_TYPE (t))
{
if (TREE_CODE (t) == INTEGER_CST)
- *tp = build_int_cst_wide (tem,
- TREE_INT_CST_LOW (t),
- TREE_INT_CST_HIGH (t));
+ *tp = wide_int_to_tree (tem, t);
else
TREE_TYPE (t) = tem;
}
Re: wide-int, doc
On Nov 23, 2013, at 11:21 AM, Mike Stump mikest...@comcast.net wrote:
Richi has asked the we break the wide-int patch so that the individual port
and front end maintainers can review their parts without have to go through
the entire patch.This patch covers the documentation.
Ok?
Ping?
* doc/generic.texi
(Constant expressions): Use wide-int interfaces.
* doc/rtl.texi
(const_double): Use wide-int interfaces.
(const_wide_int, CONST_WIDE_INT, CONST_WIDE_INT_VEC): New.
(CONST_WIDE_INT_NUNITS, CONST_WIDE_INT_ELT): New.
* doc/tm.texi.in
(REAL_VALUE_TO_INT): Remove.
(REAL_VALUE_FROM_INT): Remove.
(TARGET_SUPPORTS_WIDE_INT): New.
* doc/tm.texi: Regenerate.
diff --git a/gcc/doc/generic.texi b/gcc/doc/generic.texi
index f2dd0ff..534018e 100644
--- a/gcc/doc/generic.texi
+++ b/gcc/doc/generic.texi
@@ -1022,10 +1022,15 @@ As this example indicates, the operands are
zero-indexed.
@node Constant expressions
@subsection Constant expressions
@tindex INTEGER_CST
-@findex TREE_INT_CST_HIGH
-@findex TREE_INT_CST_LOW
@findex tree_int_cst_lt
@findex tree_int_cst_equal
+@tindex tree_fits_uhwi_p
+@tindex tree_fits_shwi_p
+@tindex tree_to_uhwi
+@tindex tree_to_shwi
+@tindex TREE_INT_CST_NUNITS
+@tindex TREE_INT_CST_ELT
+@tindex TREE_INT_CST_LOW
@tindex REAL_CST
@tindex FIXED_CST
@tindex COMPLEX_CST
@@ -1044,36 +1049,18 @@ These nodes represent integer constants. Note that the
type of these
constants is obtained with @code{TREE_TYPE}; they are not always of type
@code{int}. In particular, @code{char} constants are represented with
@code{INTEGER_CST} nodes. The value of the integer constant @code{e} is
-given by
-@smallexample
-((TREE_INT_CST_HIGH (e) HOST_BITS_PER_WIDE_INT)
-+ TREE_INST_CST_LOW (e))
-@end smallexample
-@noindent
-HOST_BITS_PER_WIDE_INT is at least thirty-two on all platforms. Both
-@code{TREE_INT_CST_HIGH} and @code{TREE_INT_CST_LOW} return a
-@code{HOST_WIDE_INT}. The value of an @code{INTEGER_CST} is interpreted
-as a signed or unsigned quantity depending on the type of the constant.
-In general, the expression given above will overflow, so it should not
-be used to calculate the value of the constant.
-
-The variable @code{integer_zero_node} is an integer constant with value
-zero. Similarly, @code{integer_one_node} is an integer constant with
-value one. The @code{size_zero_node} and @code{size_one_node} variables
-are analogous, but have type @code{size_t} rather than @code{int}.
-
-The function @code{tree_int_cst_lt} is a predicate which holds if its
-first argument is less than its second. Both constants are assumed to
-have the same signedness (i.e., either both should be signed or both
-should be unsigned.) The full width of the constant is used when doing
-the comparison; the usual rules about promotions and conversions are
-ignored. Similarly, @code{tree_int_cst_equal} holds if the two
-constants are equal. The @code{tree_int_cst_sgn} function returns the
-sign of a constant. The value is @code{1}, @code{0}, or @code{-1}
-according on whether the constant is greater than, equal to, or less
-than zero. Again, the signedness of the constant's type is taken into
-account; an unsigned constant is never less than zero, no matter what
-its bit-pattern.
+represented in an array of HOST_WIDE_INT. There are enough elements
+in the array to represent the value without taking extra elements for
+redundant 0s or -1. The number of elements used to represent @code{e}
+is available via @code{TREE_INT_CST_NUNITS}. Element @code{i} can be
+extracted by using @code{TREE_INT_CST_ELT (e, i)}.
+@code{TREE_INT_CST_LOW} is a shorthand for @code{TREE_INT_CST_ELT (e, 0)}.
+
+The functions @code{tree_fits_shwi_p} and @code{tree_fits_uhwi_p}
+can be used to tell if the value is small enough to fit in a
+signed HOST_WIDE_INT or an unsigned HOST_WIDE_INT respectively.
+The value can then be extracted using @code{tree_to_shwi} and
+@code{tree_to_uhwi}.
@item REAL_CST
diff --git a/gcc/doc/rtl.texi b/gcc/doc/rtl.texi
index df2bb68..2565995 100644
--- a/gcc/doc/rtl.texi
+++ b/gcc/doc/rtl.texi
@@ -1541,17 +1541,21 @@ Similarly, there is only one object for the integer
whose value is
@findex const_double
@item (const_double:@var{m} @var{i0} @var{i1} @dots{})
-Represents either a floating-point constant of mode @var{m} or an
-integer constant too large to fit into @code{HOST_BITS_PER_WIDE_INT}
-bits but small enough to fit within twice that number of bits (GCC
-does not provide a mechanism to represent even larger constants). In
-the latter case, @var{m} will be @code{VOIDmode}. For integral values
-constants for modes with more bits than twice the number in
-@code{HOST_WIDE_INT} the implied high order bits of that constant are
-copies of the top bit of @code{CONST_DOUBLE_HIGH}. Note however that
-integral values are neither inherently signed nor inherently unsigned;
-where necessary,
Re: wide-int, avr
On Jan 1, 2014, at 5:55 PM, Mike Stump mikest...@comcast.net wrote: On Nov 23, 2013, at 11:19 AM, Mike Stump mikest...@comcast.net wrote: Richi has asked the we break the wide-int patch so that the individual port and front end maintainers can review their parts without have to go through the entire patch.This patch covers the avr port. Ok? Ping? Ignore this one. For some reason my Mail reader didn't collapse the reply into the right thread… ouch.
Re: wide-int, C++ front end
On Nov 26, 2013, at 1:34 AM, Richard Biener richard.guent...@gmail.com wrote:
On Mon, Nov 25, 2013 at 9:05 PM, Richard Sandiford
rdsandif...@googlemail.com wrote:
Jason Merrill ja...@redhat.com writes:
On 11/23/2013 02:20 PM, Mike Stump wrote:
@@ -2605,8 +2606,7 @@ cp_tree_equal (tree t1, tree t2)
switch (code1)
{
case INTEGER_CST:
- return TREE_INT_CST_LOW (t1) == TREE_INT_CST_LOW (t2)
- TREE_INT_CST_HIGH (t1) == TREE_INT_CST_HIGH (t2);
+ return wi::to_widest (t1) == wi::to_widest (t2);
Why not use wi::eq_p like you do in the C front end?
Thanks for noticing the difference. I think c_tree_equal should change
to use to_widest too.
wi::eq_p (t1, t2) asserts that t1 and t2 are the same precision and
ignores signedness; it just tests whether they are the same bitstring.
wi::to_widest (t1) == wi::to_widest (t2) compares them as logical numbers,
taking sign into account and allowing different types. I think that's
what the original TREE_INT_CST_LOW and TREE_INT_CST_HIGH tests did too.
Though in this case (comparing two INTEGER_CSTs) it would be better
to use a tree abstraction - thus tree_int_cst_equal. It saves us from
making the decision on what to map this in wide-int to multiple times.
Seems like a good idea to me:
Index: cp/tree.c
===
--- cp/tree.c (revision 206183)
+++ cp/tree.c (working copy)
@@ -2606,7 +2606,7 @@ cp_tree_equal (tree t1, tree t2)
switch (code1)
{
case INTEGER_CST:
- return wi::to_widest (t1) == wi::to_widest (t2);
+ return tree_int_cst_equal (t1, t2);
case REAL_CST:
return REAL_VALUES_EQUAL (TREE_REAL_CST (t1), TREE_REAL_CST (t2));
Jason, are the C++ patches with this change to them Ok?
Re: wide-int, fortran
On Nov 23, 2013, at 12:16 PM, Steve Kargl s...@troutmask.apl.washington.edu wrote: On Sat, Nov 23, 2013 at 11:21:21AM -0800, Mike Stump wrote: Richi has asked the we break the wide-int patch so that the individual port and front end maintainers can review their parts without have to go through the entire patch.This patch covers the fortran front end. Ok? + *logical = wi::eq_p (t, 0) ? 0 : 1; I can't find the meaning of :: in n1256.pdf. What does this do? Also, given the complete lack of a description of what this patch does and no pointer to a discussion of what this patch does, and no description of its benefit to gfortran, I vote no. I don't like the notion that one person says yes, and one says no, and then we ignore the no, and use the yes to approve a patch. Can the fortran come up with a final unified answer… Thanks. The quoted code above merely tests to see if t is equal to 0, and set *logical to 0 is it is 0 and 1 if it's not. wi::eq_p is read in English as, does equality hold in the wide-int sense of equality? mpz::eq_p would mean then, does equality hold in the mpz sense of equality? tree::eq_p would mean then, does equality hold in the tree sense of equality? If you interested in the lower layer answer, wi::eq_p() calls a function, whose name is wi::eq_p, with the given arguments, just like foo() calls foo, with the given arguments. operator +(1, 2), for example, calls a function whose name is operator +, with the two arguments 1 and 2. In C++ names, if you will, can be arbitrarily composed and grouped using types (classes) and namespaces. classes are composition of 0 or more other types (think struct in C), and namespaces are not. wi, is such a namespace and relates to a concept called wide int, inside that concept, there is a concept of equality; however, there is no data with wi, it isn't a class (a struct). In normal C, it would be spelled wi_eq_p () as C doesn't (yet) have a grouping feature. As for the patch, it is a simple bug fix to fix a few ICEs and wrong code generation bugs present in gcc. Without it, gcc ICEs and produces wrong code, with it, it doesn't. The bugs are usually in the 2*HWI and larger sizes (64 bits for 32 hosts and 128 bit for 64 bit hosts). The benefit to fortran would be support for more correct code gen and a lessoning of ICEs on valid code. Ok?
Re: wide-int, gengtype
On Nov 23, 2013, at 11:21 AM, Mike Stump mikest...@comcast.net wrote:
Richi has asked the we break the wide-int patch so that the individual port
and front end maintainers can review their parts without have to go through
the entire patch.This patch covers the gengtype code.
Ok?
Ping?
We'll need a global reviewer to step forward if the gty maintainer doesn't have
the time. If no one is at one with the code, then I'd ask the SC to solicit
such an additional person to become maintainer.
* gengtype.c: Remove include of double-int.h.
(do_typedef): Use wide-int interfaces.
(open_base_files): Add wide-int.h.
(main): Add offset_int and widest_int typedefs.
* gengtype-lex.l: Handle ^.
(CXX_KEYWORD): Add static.
* gengtype-parse.c
(require3): New.
(require_template_declaration): Handle constant template arguments
and nested templates.
* gengtype-state.c: Don't include double-int.h.
diff --git a/gcc/gengtype.c b/gcc/gengtype.c
index 86e9ca2..0c0195c 100644
--- a/gcc/gengtype.c
+++ b/gcc/gengtype.c
@@ -25,7 +25,6 @@
#include system.h
#include errors.h/* for fatal */
#include getopt.h
-#include double-int.h
#include version.h /* for version_string pkgversion_string. */
#include hashtab.h
#include xregex.h
@@ -535,7 +534,7 @@ do_typedef (const char *s, type_p t, struct fileloc *pos)
for (p = typedefs; p != NULL; p = p-next)
if (strcmp (p-name, s) == 0)
{
- if (p-type != t)
+ if (p-type != t strcmp (s, result_type) != 0)
{
error_at_line (pos, type `%s' previously defined, s);
error_at_line (p-line, previously defined here);
@@ -1766,7 +1765,7 @@ open_base_files (void)
static const char *const ifiles[] = {
config.h, system.h, coretypes.h, tm.h,
hashtab.h, splay-tree.h, obstack.h, bitmap.h, input.h,
- tree.h, rtl.h, function.h, insn-config.h, expr.h,
+ tree.h, rtl.h, wide-int.h, function.h, insn-config.h, expr.h,
hard-reg-set.h, basic-block.h, cselib.h, insn-addr.h,
optabs.h, libfuncs.h, debug.h, ggc.h, cgraph.h,
gimple.h, gimple-iterator.h, gimple-ssa.h, tree-cfg.h,
@@ -5633,6 +5632,8 @@ main (int argc, char **argv)
POS_HERE (do_scalar_typedef (REAL_VALUE_TYPE, pos));
POS_HERE (do_scalar_typedef (FIXED_VALUE_TYPE, pos));
POS_HERE (do_scalar_typedef (double_int, pos));
+ POS_HERE (do_scalar_typedef (offset_int, pos));
+ POS_HERE (do_scalar_typedef (widest_int, pos));
POS_HERE (do_scalar_typedef (uint64_t, pos));
POS_HERE (do_scalar_typedef (uint8, pos));
POS_HERE (do_scalar_typedef (uintptr_t, pos));
diff --git a/gcc/gengtype-lex.l b/gcc/gengtype-lex.l
index f46cd17..7ece2ab 100644
--- a/gcc/gengtype-lex.l
+++ b/gcc/gengtype-lex.l
@@ -57,7 +57,7 @@ ITYPE {IWORD}({WS}{IWORD})*
/* Include '::' in identifiers to capture C++ scope qualifiers. */
ID {CID}({HWS}::{HWS}{CID})*
EOID [^[:alnum:]_]
-CXX_KEYWORD inline|public:|private:|protected:|template|operator|friend
+CXX_KEYWORD inline|public:|private:|protected:|template|operator|friend|static
%x in_struct in_struct_comment in_comment
%option warn noyywrap nounput nodefault perf-report
@@ -110,6 +110,7 @@ CXX_KEYWORD
inline|public:|private:|protected:|template|operator|friend
const/{EOID} /* don't care */
{CXX_KEYWORD}/{EOID} |
~|
+^|
{
*yylval = XDUPVAR (const char, yytext, yyleng, yyleng + 1);
return IGNORABLE_CXX_KEYWORD;
diff --git a/gcc/gengtype-parse.c b/gcc/gengtype-parse.c
index 8328e3a..0a58822 100644
--- a/gcc/gengtype-parse.c
+++ b/gcc/gengtype-parse.c
@@ -197,6 +197,23 @@ require2 (int t1, int t2)
return v;
}
+/* If the next token does not have one of the codes T1, T2 or T3, report a
+ parse error; otherwise return the token's value. */
+static const char *
+require3 (int t1, int t2, int t3)
+{
+ int u = token ();
+ const char *v = advance ();
+ if (u != t1 u != t2 u != t3)
+{
+ parse_error (expected %s, %s or %s, have %s,
+ print_token (t1, 0), print_token (t2, 0),
+ print_token (t3, 0), print_token (u, v));
+ return 0;
+}
+ return v;
+}
+
/* Near-terminals. */
/* C-style string constant concatenation: STRING+
@@ -243,18 +260,45 @@ require_template_declaration (const char *tmpl_name)
str = concat (tmpl_name, , (char *) 0);
/* Read the comma-separated list of identifiers. */
- while (token () != '')
+ int depth = 1;
+ while (depth 0)
{
- const char *id = require2 (ID, ',');
+ if (token () == ENUM)
+ {
+ advance ();
+ str = concat (str, enum , (char *) 0);
+ continue;
+ }
+ if (token () == NUM)
+ {
+ str = concat (str, advance (), (char *) 0);
+
Re: wide-int, gimple
On Nov 28, 2013, at 6:20 AM, Richard Biener richard.guent...@gmail.com wrote:
On Thu, Nov 28, 2013 at 12:58 PM, Richard Sandiford
rdsandif...@googlemail.com wrote:
Jakub Jelinek ja...@redhat.com writes:
On Mon, Nov 25, 2013 at 12:24:30PM +0100, Richard Biener wrote:
On Sat, Nov 23, 2013 at 8:21 PM, Mike Stump mikest...@comcast.net wrote:
Richi has asked the we break the wide-int patch so that the
individual port and front end maintainers can review their parts
without have to go through the entire patch. This patch covers the
gimple code.
@@ -1754,7 +1754,7 @@ dump_ssaname_info (pretty_printer *buffer, tree
node, int spc)
if (!POINTER_TYPE_P (TREE_TYPE (node))
SSA_NAME_RANGE_INFO (node))
{
- double_int min, max, nonzero_bits;
+ widest_int min, max, nonzero_bits;
value_range_type range_type = get_range_info (node, min, max);
if (range_type == VR_VARYING)
this makes me suspect you are changing SSA_NAME_RANGE_INFO
to embed two max wide_ints. That's a no-no.
Well, the range_info_def struct right now contains 3 double_ints, which is
unnecessary overhead for the most of the cases where the SSA_NAME's type
has just at most HOST_BITS_PER_WIDE_INT bits and thus we could fit all 3 of
them into 3 HOST_WIDE_INTs rather than 3 double_ints. So supposedly struct
range_info_def could be a template on the type's precision rounded up to HWI
bits, or say have 3 alternatives there, use
FIXED_WIDE_INT (HOST_BITS_PER_WIDE_INT) for the smallest types,
FIXED_WIDE_INT (2 * HOST_BITS_PER_WIDE_INT) aka double_int for the larger
but still common ones, and widest_int for the rest, then the API to set/get
it could use widest_int everywhere, and just what storage we'd use would
depend on the precision of the type.
This patch adds a trailing_wide_ints N that can be used at the end of
a variable-length structure to store N wide_ints. There's also a macro
to declare get/set methods for each of the N elements.
At the moment I've only defined non-const operator[]. It'd be possible
to add a const version later if necessary.
The size of range_info_def for precisions that fit in M HWIs is then
1 + 3 * M, so 4 for the common case (down from 6 on trunk). The maximum
is 7 for current x86_64 types (up from 6 on trunk).
I wondered whether to keep the interface using widest_int, but I think
wide_int works out more naturally. The only caller that wants to extend
beyond the precision is CCP, but that's already special because the upper
bits are supposed to be set (i.e. it's not a normal sign or zero extension).
This relies on the SSA_NAME_ANTI_RANGE_P patch I just posted.
If this is OK I'll look at using the same structure elsewhere.
Looks good to me.
So, is that an Ok for the gimple patch and the follow on work? Just double
checking.
Re: wide-int, ipa
On Nov 23, 2013, at 11:22 AM, Mike Stump mikest...@comcast.net wrote:
Richi has asked the we break the wide-int patch so that the individual port
and front end maintainers can review their parts without have to go through
the entire patch.This patch covers the ipa code.
Ok?
Ping?
I promise, this patch isn't frightening. Small, easy to read and understand,
doesn't require an ipa expert.
* ipa-devirt.c
(get_polymorphic_call_info): Use wide-int interfaces.
* ipa-prop.c
(compute_complex_assign_jump_func): Use wide-int interfaces.
(get_ancestor_addr_info): Likewise.
(ipa_modify_call_arguments): Likewise.
diff --git a/gcc/ipa-devirt.c b/gcc/ipa-devirt.c
index 38cf378..41e5300 100644
--- a/gcc/ipa-devirt.c
+++ b/gcc/ipa-devirt.c
@@ -968,7 +968,7 @@ get_polymorphic_call_info (tree fndecl,
{
base_pointer = TREE_OPERAND (base, 0);
context-offset
-+= offset2 + mem_ref_offset (base).low * BITS_PER_UNIT;
+ += offset2 + mem_ref_offset (base).ulow () * BITS_PER_UNIT;
context-outer_type = NULL;
}
/* We found base object. In this case the outer_type
diff --git a/gcc/ipa-prop.c b/gcc/ipa-prop.c
index d122dd5..3953442 100644
--- a/gcc/ipa-prop.c
+++ b/gcc/ipa-prop.c
@@ -1063,7 +1063,7 @@ compute_complex_assign_jump_func (struct ipa_node_params
*info,
|| max_size == -1
|| max_size != size)
return;
- offset += mem_ref_offset (base).low * BITS_PER_UNIT;
+ offset += mem_ref_offset (base).to_short_addr () * BITS_PER_UNIT;
ssa = TREE_OPERAND (base, 0);
if (TREE_CODE (ssa) != SSA_NAME
|| !SSA_NAME_IS_DEFAULT_DEF (ssa)
@@ -1122,7 +1122,7 @@ get_ancestor_addr_info (gimple assign, tree *obj_p,
HOST_WIDE_INT *offset)
|| TREE_CODE (SSA_NAME_VAR (parm)) != PARM_DECL)
return NULL_TREE;
- *offset += mem_ref_offset (expr).low * BITS_PER_UNIT;
+ *offset += mem_ref_offset (expr).to_short_addr () * BITS_PER_UNIT;
*obj_p = obj;
return expr;
}
@@ -3661,9 +3661,8 @@ ipa_modify_call_arguments (struct cgraph_edge *cs, gimple
stmt,
if (TYPE_ALIGN (type) align)
align = TYPE_ALIGN (type);
}
- misalign += (tree_to_double_int (off)
- .sext (TYPE_PRECISION (TREE_TYPE (off))).low
- * BITS_PER_UNIT);
+ misalign += (offset_int::from (off, SIGNED)
+ * BITS_PER_UNIT).to_short_addr ();
misalign = misalign (align - 1);
if (misalign != 0)
align = (misalign -misalign);
Re: wide-int, loop
On Nov 26, 2013, at 1:14 AM, Richard Biener richard.guent...@gmail.com wrote:
@@ -2662,8 +2661,8 @@ iv_number_of_iterations (struct loop *loop, rtx
insn, rtx condition,
iv1.step = const0_rtx;
if (INTVAL (iv0.step) 0)
{
- iv0.step = simplify_gen_unary (NEG, comp_mode, iv0.step, mode);
- iv1.base = simplify_gen_unary (NEG, comp_mode, iv1.base, mode);
+ iv0.step = simplify_gen_unary (NEG, comp_mode, iv0.step,
comp_mode);
+ iv1.base = simplify_gen_unary (NEG, comp_mode, iv1.base,
comp_mode);
}
iv0.step = lowpart_subreg (mode, iv0.step, comp_mode);
separate bugfix?
most likely.i will submit separately.
@@ -1378,7 +1368,8 @@ decide_peel_simple (struct loop *loop, int flags)
/* If we have realistic estimate on number of iterations, use it. */
if (get_estimated_loop_iterations (loop, iterations))
{
- if (double_int::from_shwi (npeel).ule (iterations))
+ /* TODO: unsigned/signed confusion */
+ if (wi::leu_p (npeel, iterations))
{
if (dump_file)
{
what does this refer to? npeel is unsigned.
it was the fact that they were doing the from_shwi and then using an
unsigned test.
Ah - probably a typo. Please just remove the TODO.
Done:
Index: loop-unroll.c
===
--- loop-unroll.c (revision 206183)
+++ loop-unroll.c (working copy)
@@ -1371,7 +1371,6 @@ decide_peel_simple (struct loop *loop, i
/* If we have realistic estimate on number of iterations, use it. */
if (get_estimated_loop_iterations (loop, iterations))
{
- /* TODO: unsigned/signed confusion */
if (wi::leu_p (npeel, iterations))
{
if (dump_file)
Otherwise looks good to me.
Kenny hasn't yet integrated the first into trunk, but I'd like to ask anyway:
Ok?
Re: wide-int, sched
On Nov 23, 2013, at 11:22 AM, Mike Stump mikest...@comcast.net wrote:
Richi has asked the we break the wide-int patch so that the individual port
and front end maintainers can review their parts without have to go through
the entire patch.This patch covers the scheduler code.
Ok?
Ping?
I promise, this one is easy…
* sched-vis.c
(print_value): Handle CONST_WIDE_INT.
* sel-sched-ir.c
(lhs_and_rhs_separable_p): Update comment.
diff --git a/gcc/sched-vis.c b/gcc/sched-vis.c
index a965c4d..8fa29bf 100644
--- a/gcc/sched-vis.c
+++ b/gcc/sched-vis.c
@@ -428,6 +428,23 @@ print_value (pretty_printer *pp, const_rtx x, int verbose)
pp_scalar (pp, HOST_WIDE_INT_PRINT_HEX,
(unsigned HOST_WIDE_INT) INTVAL (x));
break;
+
+case CONST_WIDE_INT:
+ {
+ const char *sep = ;
+ int i;
+ for (i = CONST_WIDE_INT_NUNITS (x) - 1; i = 0; i--)
+ {
+ pp_string (pp, sep);
+ sep = ,;
+ sprintf (tmp, HOST_WIDE_INT_PRINT_HEX,
+(unsigned HOST_WIDE_INT) CONST_WIDE_INT_ELT (x, i));
+ pp_string (pp, tmp);
+ }
+pp_greater (pp);
+ }
+ break;
+
case CONST_DOUBLE:
if (FLOAT_MODE_P (GET_MODE (x)))
{
diff --git a/gcc/sel-sched-ir.c b/gcc/sel-sched-ir.c
index 7dfc703..0db84e6 100644
--- a/gcc/sel-sched-ir.c
+++ b/gcc/sel-sched-ir.c
@@ -1141,10 +1141,10 @@ lhs_and_rhs_separable_p (rtx lhs, rtx rhs)
if (lhs == NULL || rhs == NULL)
return false;
- /* Do not schedule CONST, CONST_INT and CONST_DOUBLE etc as rhs: no point
- to use reg, if const can be used. Moreover, scheduling const as rhs may
- lead to mode mismatch cause consts don't have modes but they could be
- merged from branches where the same const used in different modes. */
+ /* Do not schedule constants as rhs: no point to use reg, if const
+ can be used. Moreover, scheduling const as rhs may lead to mode
+ mismatch cause consts don't have modes but they could be merged
+ from branches where the same const used in different modes. */
if (CONSTANT_P (rhs))
return false;
Re: wide-int, OpenMP
On Wed, Jan 01, 2014 at 05:56:56PM -0800, Mike Stump wrote:
On Nov 23, 2013, at 11:22 AM, Mike Stump mikest...@comcast.net wrote:
Richi has asked the we break the wide-int patch so that the individual port
and front end maintainers can review their parts without have to go through
the entire patch.This patch covers the OpenMP code.
Ok?
Ping?
* omp-low.c
(scan_omp_1_op): Use wide-int interfaces.
Ok if the rest of wide int changes is approved.
--- a/gcc/omp-low.c
+++ b/gcc/omp-low.c
@@ -2530,9 +2530,7 @@ scan_omp_1_op (tree *tp, int *walk_subtrees, void *data)
if (tem != TREE_TYPE (t))
{
if (TREE_CODE (t) == INTEGER_CST)
- *tp = build_int_cst_wide (tem,
- TREE_INT_CST_LOW (t),
- TREE_INT_CST_HIGH (t));
+ *tp = wide_int_to_tree (tem, t);
else
TREE_TYPE (t) = tem;
}
Jakub
