packages: gcc/gcc-branch.diff - rel 5; upstream fixes
arekm
arekm at pld-linux.org
Sun Jun 28 18:28:37 CEST 2009
Author: arekm Date: Sun Jun 28 16:28:37 2009 GMT
Module: packages Tag: HEAD
---- Log message:
- rel 5; upstream fixes
---- Files affected:
packages/gcc:
gcc-branch.diff (1.12 -> 1.13)
---- Diffs:
================================================================
Index: packages/gcc/gcc-branch.diff
diff -u packages/gcc/gcc-branch.diff:1.12 packages/gcc/gcc-branch.diff:1.13
--- packages/gcc/gcc-branch.diff:1.12 Mon Apr 27 09:43:34 2009
+++ packages/gcc/gcc-branch.diff Sun Jun 28 18:28:26 2009
@@ -1,7 +1,7 @@
Index: configure
===================================================================
---- configure (.../tags/gcc_4_4_0_release) (wersja 146826)
-+++ configure (.../branches/gcc-4_4-branch) (wersja 146826)
+--- configure (.../tags/gcc_4_4_0_release) (wersja 149030)
++++ configure (.../branches/gcc-4_4-branch) (wersja 149030)
@@ -272,7 +272,7 @@
PACKAGE_BUGREPORT=
@@ -37,8 +37,8 @@
s, at clooglibs@,$clooglibs,;t t
Index: Makefile.in
===================================================================
---- Makefile.in (.../tags/gcc_4_4_0_release) (wersja 146826)
-+++ Makefile.in (.../branches/gcc-4_4-branch) (wersja 146826)
+--- Makefile.in (.../tags/gcc_4_4_0_release) (wersja 149030)
++++ Makefile.in (.../branches/gcc-4_4-branch) (wersja 149030)
@@ -17068,7 +17068,7 @@
libsrcdir="$$s/mpfr"; \
$(SHELL) $${libsrcdir}/configure \
@@ -120,10 +120,44 @@
@endif mpfr-bootstrap
+Index: libgomp/team.c
+===================================================================
+--- libgomp/team.c (.../tags/gcc_4_4_0_release) (wersja 149030)
++++ libgomp/team.c (.../branches/gcc-4_4-branch) (wersja 149030)
+@@ -125,6 +125,7 @@
+ while (local_fn);
+ }
+
++ gomp_sem_destroy (&thr->release);
+ return NULL;
+ }
+
+@@ -201,6 +202,7 @@
+ struct gomp_thread_pool *pool
+ = (struct gomp_thread_pool *) thread_pool;
+ gomp_barrier_wait_last (&pool->threads_dock);
++ gomp_sem_destroy (&gomp_thread ()->release);
+ pthread_exit (NULL);
+ }
+
+Index: libgomp/ChangeLog
+===================================================================
+--- libgomp/ChangeLog (.../tags/gcc_4_4_0_release) (wersja 149030)
++++ libgomp/ChangeLog (.../branches/gcc-4_4-branch) (wersja 149030)
+@@ -1,3 +1,9 @@
++2009-05-20 Jakub Jelinek <jakub at redhat.com>
++
++ PR libgomp/40174
++ * team.c (gomp_thread_start): Destroy thr->release semaphore.
++ (gomp_free_pool_helper): Likewise.
++
+ 2009-04-21 Release Manager
+
+ * GCC 4.4.0 released.
Index: gcc/fwprop.c
===================================================================
---- gcc/fwprop.c (.../tags/gcc_4_4_0_release) (wersja 146826)
-+++ gcc/fwprop.c (.../branches/gcc-4_4-branch) (wersja 146826)
+--- gcc/fwprop.c (.../tags/gcc_4_4_0_release) (wersja 149030)
++++ gcc/fwprop.c (.../branches/gcc-4_4-branch) (wersja 149030)
@@ -1,5 +1,5 @@
/* RTL-based forward propagation pass for GNU compiler.
- Copyright (C) 2005, 2006, 2007, 2008 Free Software Foundation, Inc.
@@ -250,10 +284,291 @@
/* Else try simplifying. */
if (DF_REF_TYPE (use) == DF_REF_REG_MEM_STORE)
+Index: gcc/doc/extend.texi
+===================================================================
+--- gcc/doc/extend.texi (.../tags/gcc_4_4_0_release) (wersja 149030)
++++ gcc/doc/extend.texi (.../branches/gcc-4_4-branch) (wersja 149030)
+@@ -8304,6 +8304,7 @@
+ @item unsigned int __builtin_ia32_crc32si (unsigned int, unsigned int)
+ Generates the @code{crc32l} machine instruction.
+ @item unsigned long long __builtin_ia32_crc32di (unsigned long long, unsigned long long)
++Generates the @code{crc32q} machine instruction.
+ @end table
+
+ The following built-in functions are changed to generate new SSE4.2
+Index: gcc/doc/passes.texi
+===================================================================
+--- gcc/doc/passes.texi (.../tags/gcc_4_4_0_release) (wersja 149030)
++++ gcc/doc/passes.texi (.../branches/gcc-4_4-branch) (wersja 149030)
+@@ -21,7 +21,7 @@
+ * Parsing pass:: The language front end turns text into bits.
+ * Gimplification pass:: The bits are turned into something we can optimize.
+ * Pass manager:: Sequencing the optimization passes.
+-* Tree-SSA passes:: Optimizations on a high-level representation.
++* Tree SSA passes:: Optimizations on a high-level representation.
+ * RTL passes:: Optimizations on a low-level representation.
+ @end menu
+
+@@ -94,8 +94,8 @@
+ should be passed to @code{cgraph_finalize_function}.
+
+ TODO: I know rest_of_compilation currently has all sorts of
+-rtl-generation semantics. I plan to move all code generation
+-bits (both tree and rtl) to compile_function. Should we hide
++RTL generation semantics. I plan to move all code generation
++bits (both Tree and RTL) to compile_function. Should we hide
+ cgraph from the front ends and move back to rest_of_compilation
+ as the official interface? Possibly we should rename all three
+ interfaces such that the names match in some meaningful way and
+@@ -172,12 +172,12 @@
+
+ TODO: describe the global variables set up by the pass manager,
+ and a brief description of how a new pass should use it.
+-I need to look at what info rtl passes use first at enddots{}
++I need to look at what info RTL passes use first at enddots{}
+
+- at node Tree-SSA passes
+- at section Tree-SSA passes
++ at node Tree SSA passes
++ at section Tree SSA passes
+
+-The following briefly describes the tree optimization passes that are
++The following briefly describes the Tree optimization passes that are
+ run after gimplification and what source files they are located in.
+
+ @itemize @bullet
+@@ -401,7 +401,7 @@
+ The optimizations performed by this pass are:
+
+ Loop invariant motion. This pass moves only invariants that
+-would be hard to handle on rtl level (function calls, operations that expand to
++would be hard to handle on RTL level (function calls, operations that expand to
+ nontrivial sequences of insns). With @option{-funswitch-loops} it also moves
+ operands of conditions that are invariant out of the loop, so that we can use
+ just trivial invariantness analysis in loop unswitching. The pass also includes
+@@ -422,8 +422,8 @@
+ out of the loops. To achieve this, a duplicate of the loop is created for
+ each possible outcome of conditional jump(s). The pass is implemented in
+ @file{tree-ssa-loop-unswitch.c}. This pass should eventually replace the
+-rtl-level loop unswitching in @file{loop-unswitch.c}, but currently
+-the rtl-level pass is not completely redundant yet due to deficiencies
++RTL level loop unswitching in @file{loop-unswitch.c}, but currently
++the RTL level pass is not completely redundant yet due to deficiencies
+ in tree level alias analysis.
+
+ The optimizations also use various utility functions contained in
+@@ -651,8 +651,8 @@
+ @node RTL passes
+ @section RTL passes
+
+-The following briefly describes the rtl generation and optimization
+-passes that are run after tree optimization.
++The following briefly describes the RTL generation and optimization
++passes that are run after the Tree optimization passes.
+
+ @itemize @bullet
+ @item RTL generation
+@@ -679,15 +679,15 @@
+ and @code{gencodes}, tell this pass which standard names are available
+ for use and which patterns correspond to them.
+
+- at item Generate exception handling landing pads
++ at item Generation of exception landing pads
+
+ This pass generates the glue that handles communication between the
+ exception handling library routines and the exception handlers within
+ the function. Entry points in the function that are invoked by the
+ exception handling library are called @dfn{landing pads}. The code
+-for this pass is located within @file{except.c}.
++for this pass is located in @file{except.c}.
+
+- at item Cleanup control flow graph
++ at item Control flow graph cleanup
+
+ This pass removes unreachable code, simplifies jumps to next, jumps to
+ jump, jumps across jumps, etc. The pass is run multiple times.
+@@ -702,16 +702,16 @@
+ variables that come from a single definition, and
+ seeing if the result can be simplified. It performs copy propagation
+ and addressing mode selection. The pass is run twice, with values
+-being propagated into loops only on the second run. It is located in
+- at file{fwprop.c}.
++being propagated into loops only on the second run. The code is
++located in @file{fwprop.c}.
+
+ @item Common subexpression elimination
+
+ This pass removes redundant computation within basic blocks, and
+ optimizes addressing modes based on cost. The pass is run twice.
+-The source is located in @file{cse.c}.
++The code for this pass is located in @file{cse.c}.
+
+- at item Global common subexpression elimination.
++ at item Global common subexpression elimination
+
+ This pass performs two
+ different types of GCSE depending on whether you are optimizing for
+@@ -755,46 +755,37 @@
+ assignments with arithmetic, boolean value producing comparison
+ instructions, and conditional move instructions. In the very last
+ invocation after reload, it will generate predicated instructions
+-when supported by the target. The pass is located in @file{ifcvt.c}.
++when supported by the target. The code is located in @file{ifcvt.c}.
+
+ @item Web construction
+
+ This pass splits independent uses of each pseudo-register. This can
+ improve effect of the other transformation, such as CSE or register
+-allocation. Its source files are @file{web.c}.
++allocation. The code for this pass is located in @file{web.c}.
+
+- at item Life analysis
+-
+-This pass computes which pseudo-registers are live at each point in
+-the program, and makes the first instruction that uses a value point
+-at the instruction that computed the value. It then deletes
+-computations whose results are never used, and combines memory
+-references with add or subtract instructions to make autoincrement or
+-autodecrement addressing. The pass is located in @file{flow.c}.
+-
+ @item Instruction combination
+
+ This pass attempts to combine groups of two or three instructions that
+ are related by data flow into single instructions. It combines the
+ RTL expressions for the instructions by substitution, simplifies the
+ result using algebra, and then attempts to match the result against
+-the machine description. The pass is located in @file{combine.c}.
++the machine description. The code is located in @file{combine.c}.
+
+ @item Register movement
+
+ This pass looks for cases where matching constraints would force an
+ instruction to need a reload, and this reload would be a
+ register-to-register move. It then attempts to change the registers
+-used by the instruction to avoid the move instruction.
+-The pass is located in @file{regmove.c}.
++used by the instruction to avoid the move instruction. The code is
++located in @file{regmove.c}.
+
+- at item Optimize mode switching
++ at item Mode switching optimization
+
+ This pass looks for instructions that require the processor to be in a
+ specific ``mode'' and minimizes the number of mode changes required to
+ satisfy all users. What these modes are, and what they apply to are
+-completely target-specific.
+-The source is located in @file{mode-switching.c}.
++completely target-specific. The code for this pass is located in
++ at file{mode-switching.c}.
+
+ @cindex modulo scheduling
+ @cindex sms, swing, software pipelining
+@@ -802,8 +793,8 @@
+
+ This pass looks at innermost loops and reorders their instructions
+ by overlapping different iterations. Modulo scheduling is performed
+-immediately before instruction scheduling.
+-The pass is located in (@file{modulo-sched.c}).
++immediately before instruction scheduling. The code for this pass is
++located in @file{modulo-sched.c}.
+
+ @item Instruction scheduling
+
+@@ -813,7 +804,7 @@
+ It re-orders instructions within a basic block to try to separate the
+ definition and use of items that otherwise would cause pipeline
+ stalls. This pass is performed twice, before and after register
+-allocation. The pass is located in @file{haifa-sched.c},
++allocation. The code for this pass is located in @file{haifa-sched.c},
+ @file{sched-deps.c}, @file{sched-ebb.c}, @file{sched-rgn.c} and
+ @file{sched-vis.c}.
+
+@@ -884,13 +875,13 @@
+ position in code and generates notes describing the variable locations
+ to RTL code. The location lists are then generated according to these
+ notes to debug information if the debugging information format supports
+-location lists.
++location lists. The code is located in @file{var-tracking.c}.
+
+ @item Delayed branch scheduling
+
+ This optional pass attempts to find instructions that can go into the
+-delay slots of other instructions, usually jumps and calls. The
+-source file name is @file{reorg.c}.
++delay slots of other instructions, usually jumps and calls. The code
++for this pass is located in @file{reorg.c}.
+
+ @item Branch shortening
+
+@@ -899,13 +890,14 @@
+ In this pass, the compiler figures out what how far each instruction
+ will be from each other instruction, and therefore whether the usual
+ instructions, or the longer sequences, must be used for each branch.
++The code for this pass is located in @file{final.c}.
+
+ @item Register-to-stack conversion
+
+ Conversion from usage of some hard registers to usage of a register
+ stack may be done at this point. Currently, this is supported only
+-for the floating-point registers of the Intel 80387 coprocessor. The
+-source file name is @file{reg-stack.c}.
++for the floating-point registers of the Intel 80387 coprocessor. The
++code for this pass is located in @file{reg-stack.c}.
+
+ @item Final
+
+Index: gcc/doc/gccint.texi
+===================================================================
+--- gcc/doc/gccint.texi (.../tags/gcc_4_4_0_release) (wersja 149030)
++++ gcc/doc/gccint.texi (.../branches/gcc-4_4-branch) (wersja 149030)
+@@ -109,10 +109,10 @@
+ * Options:: Option specification files.
+ * Passes:: Order of passes, what they do, and what each file is for.
+ * Trees:: The source representation used by the C and C++ front ends.
+-* RTL:: The intermediate representation that most passes work on.
+ * GENERIC:: Language-independent representation generated by Front Ends
+ * GIMPLE:: Tuple representation used by Tree SSA optimizers
+ * Tree SSA:: Analysis and optimization of GIMPLE
++* RTL:: Machine-dependent low-level intermediate representation.
+ * Control Flow:: Maintaining and manipulating the control flow graph.
+ * Loop Analysis and Representation:: Analysis and representation of loops
+ * Machine Desc:: How to write machine description instruction patterns.
+Index: gcc/doc/md.texi
+===================================================================
+--- gcc/doc/md.texi (.../tags/gcc_4_4_0_release) (wersja 149030)
++++ gcc/doc/md.texi (.../branches/gcc-4_4-branch) (wersja 149030)
+@@ -5111,8 +5111,6 @@
+ Operand 0 is the memory on which the atomic operation is performed.
+ Operand 1 is the second operand to the binary operator.
+
+-The ``nand'' operation is @code{~op0 & op1}.
+-
+ This pattern must issue any memory barrier instructions such that all
+ memory operations before the atomic operation occur before the atomic
+ operation and all memory operations after the atomic operation occur
+Index: gcc/doc/rtl.texi
+===================================================================
+--- gcc/doc/rtl.texi (.../tags/gcc_4_4_0_release) (wersja 149030)
++++ gcc/doc/rtl.texi (.../branches/gcc-4_4-branch) (wersja 149030)
+@@ -10,10 +10,10 @@
+ @cindex representation of RTL
+ @cindex Register Transfer Language (RTL)
+
+-Most of the work of the compiler is done on an intermediate representation
+-called register transfer language. In this language, the instructions to be
+-output are described, pretty much one by one, in an algebraic form that
+-describes what the instruction does.
++The last part of the compiler work is done on a low-level intermediate
++representation called Register Transfer Language. In this language, the
++instructions to be output are described, pretty much one by one, in an
++algebraic form that describes what the instruction does.
+
+ RTL is inspired by Lisp lists. It has both an internal form, made up of
+ structures that point at other structures, and a textual form that is used
Index: gcc/ira-conflicts.c
===================================================================
---- gcc/ira-conflicts.c (.../tags/gcc_4_4_0_release) (wersja 146826)
-+++ gcc/ira-conflicts.c (.../branches/gcc-4_4-branch) (wersja 146826)
+--- gcc/ira-conflicts.c (.../tags/gcc_4_4_0_release) (wersja 149030)
++++ gcc/ira-conflicts.c (.../branches/gcc-4_4-branch) (wersja 149030)
@@ -411,9 +411,9 @@
/* Can not be tied. It is not in the cover class. */
return false;
@@ -266,17 +581,403 @@
for (;;)
{
ira_allocate_and_set_costs
+@@ -806,7 +806,7 @@
+ if ((! flag_caller_saves && ALLOCNO_CALLS_CROSSED_NUM (a) != 0)
+ /* For debugging purposes don't put user defined variables in
+ callee-clobbered registers. */
+- || (optimize <= 1
++ || (optimize == 0
+ && (attrs = REG_ATTRS (regno_reg_rtx [ALLOCNO_REGNO (a)])) != NULL
+ && (decl = attrs->decl) != NULL
+ && VAR_OR_FUNCTION_DECL_P (decl)
+Index: gcc/tree-ssa-loop-niter.c
+===================================================================
+--- gcc/tree-ssa-loop-niter.c (.../tags/gcc_4_4_0_release) (wersja 149030)
++++ gcc/tree-ssa-loop-niter.c (.../branches/gcc-4_4-branch) (wersja 149030)
+@@ -534,7 +534,7 @@
+ }
+
+ /* Derives the upper bound BND on the number of executions of loop with exit
+- condition S * i <> C, assuming that the loop is not infinite. If
++ condition S * i <> C, assuming that this exit is taken. If
+ NO_OVERFLOW is true, then the control variable of the loop does not
+ overflow. If NO_OVERFLOW is true or BNDS.below >= 0, then BNDS.up
+ contains the upper bound on the value of C. */
+@@ -574,7 +574,7 @@
+
+ /* Determines number of iterations of loop whose ending condition
+ is IV <> FINAL. TYPE is the type of the iv. The number of
+- iterations is stored to NITER. NEVER_INFINITE is true if
++ iterations is stored to NITER. EXIT_MUST_BE_TAKEN is true if
+ we know that the exit must be taken eventually, i.e., that the IV
+ ever reaches the value FINAL (we derived this earlier, and possibly set
+ NITER->assumptions to make sure this is the case). BNDS contains the
+@@ -582,7 +582,7 @@
+
+ static bool
+ number_of_iterations_ne (tree type, affine_iv *iv, tree final,
+- struct tree_niter_desc *niter, bool never_infinite,
++ struct tree_niter_desc *niter, bool exit_must_be_taken,
+ bounds *bnds)
+ {
+ tree niter_type = unsigned_type_for (type);
+@@ -639,9 +639,9 @@
+ build_int_cst (niter_type, 1), bits);
+ s = fold_binary_to_constant (RSHIFT_EXPR, niter_type, s, bits);
+
+- if (!never_infinite)
++ if (!exit_must_be_taken)
+ {
+- /* If we cannot assume that the loop is not infinite, record the
++ /* If we cannot assume that the exit is taken eventually, record the
+ assumptions for divisibility of c. */
+ assumption = fold_build2 (FLOOR_MOD_EXPR, niter_type, c, d);
+ assumption = fold_build2 (EQ_EXPR, boolean_type_node,
+@@ -664,20 +664,21 @@
+ of the final value does not overflow are recorded in NITER. If we
+ find the final value, we adjust DELTA and return TRUE. Otherwise
+ we return false. BNDS bounds the value of IV1->base - IV0->base,
+- and will be updated by the same amount as DELTA. */
++ and will be updated by the same amount as DELTA. EXIT_MUST_BE_TAKEN is
++ true if we know that the exit must be taken eventually. */
+
+ static bool
+ number_of_iterations_lt_to_ne (tree type, affine_iv *iv0, affine_iv *iv1,
+ struct tree_niter_desc *niter,
+ tree *delta, tree step,
+- bounds *bnds)
++ bool exit_must_be_taken, bounds *bnds)
+ {
+ tree niter_type = TREE_TYPE (step);
+ tree mod = fold_build2 (FLOOR_MOD_EXPR, niter_type, *delta, step);
+ tree tmod;
+ mpz_t mmod;
+ tree assumption = boolean_true_node, bound, noloop;
+- bool ret = false;
++ bool ret = false, fv_comp_no_overflow;
+ tree type1 = type;
+ if (POINTER_TYPE_P (type))
+ type1 = sizetype;
+@@ -692,17 +693,31 @@
+ mpz_set_double_int (mmod, tree_to_double_int (mod), true);
+ mpz_neg (mmod, mmod);
+
++ /* If the induction variable does not overflow and the exit is taken,
++ then the computation of the final value does not overflow. This is
++ also obviously the case if the new final value is equal to the
++ current one. Finally, we postulate this for pointer type variables,
++ as the code cannot rely on the object to that the pointer points being
++ placed at the end of the address space (and more pragmatically,
++ TYPE_{MIN,MAX}_VALUE is not defined for pointers). */
++ if (integer_zerop (mod) || POINTER_TYPE_P (type))
++ fv_comp_no_overflow = true;
++ else if (!exit_must_be_taken)
++ fv_comp_no_overflow = false;
++ else
++ fv_comp_no_overflow =
++ (iv0->no_overflow && integer_nonzerop (iv0->step))
++ || (iv1->no_overflow && integer_nonzerop (iv1->step));
++
+ if (integer_nonzerop (iv0->step))
+ {
+ /* The final value of the iv is iv1->base + MOD, assuming that this
+ computation does not overflow, and that
+ iv0->base <= iv1->base + MOD. */
+- if (!iv0->no_overflow && !integer_zerop (mod))
++ if (!fv_comp_no_overflow)
+ {
+ bound = fold_build2 (MINUS_EXPR, type1,
+ TYPE_MAX_VALUE (type1), tmod);
+- if (POINTER_TYPE_P (type))
+- bound = fold_convert (type, bound);
+ assumption = fold_build2 (LE_EXPR, boolean_type_node,
+ iv1->base, bound);
+ if (integer_zerop (assumption))
+@@ -726,12 +741,10 @@
+ /* The final value of the iv is iv0->base - MOD, assuming that this
+ computation does not overflow, and that
+ iv0->base - MOD <= iv1->base. */
+- if (!iv1->no_overflow && !integer_zerop (mod))
++ if (!fv_comp_no_overflow)
+ {
+ bound = fold_build2 (PLUS_EXPR, type1,
+ TYPE_MIN_VALUE (type1), tmod);
+- if (POINTER_TYPE_P (type))
+- bound = fold_convert (type, bound);
+ assumption = fold_build2 (GE_EXPR, boolean_type_node,
+ iv0->base, bound);
+ if (integer_zerop (assumption))
+@@ -969,13 +982,13 @@
+ /* Determines number of iterations of loop whose ending condition
+ is IV0 < IV1. TYPE is the type of the iv. The number of
+ iterations is stored to NITER. BNDS bounds the difference
+- IV1->base - IV0->base. */
++ IV1->base - IV0->base. EXIT_MUST_BE_TAKEN is true if we know
++ that the exit must be taken eventually. */
+
+ static bool
+ number_of_iterations_lt (tree type, affine_iv *iv0, affine_iv *iv1,
+ struct tree_niter_desc *niter,
+- bool never_infinite ATTRIBUTE_UNUSED,
+- bounds *bnds)
++ bool exit_must_be_taken, bounds *bnds)
+ {
+ tree niter_type = unsigned_type_for (type);
+ tree delta, step, s;
+@@ -1034,7 +1047,7 @@
+ transform the condition to != comparison. In particular, this will be
+ the case if DELTA is constant. */
+ if (number_of_iterations_lt_to_ne (type, iv0, iv1, niter, &delta, step,
+- bnds))
++ exit_must_be_taken, bnds))
+ {
+ affine_iv zps;
+
+@@ -1076,14 +1089,14 @@
+
+ /* Determines number of iterations of loop whose ending condition
+ is IV0 <= IV1. TYPE is the type of the iv. The number of
+- iterations is stored to NITER. NEVER_INFINITE is true if
++ iterations is stored to NITER. EXIT_MUST_BE_TAKEN is true if
+ we know that this condition must eventually become false (we derived this
+ earlier, and possibly set NITER->assumptions to make sure this
+ is the case). BNDS bounds the difference IV1->base - IV0->base. */
+
+ static bool
+ number_of_iterations_le (tree type, affine_iv *iv0, affine_iv *iv1,
+- struct tree_niter_desc *niter, bool never_infinite,
++ struct tree_niter_desc *niter, bool exit_must_be_taken,
+ bounds *bnds)
+ {
+ tree assumption;
+@@ -1094,9 +1107,13 @@
+ /* Say that IV0 is the control variable. Then IV0 <= IV1 iff
+ IV0 < IV1 + 1, assuming that IV1 is not equal to the greatest
+ value of the type. This we must know anyway, since if it is
+- equal to this value, the loop rolls forever. */
++ equal to this value, the loop rolls forever. We do not check
++ this condition for pointer type ivs, as the code cannot rely on
++ the object to that the pointer points being placed at the end of
++ the address space (and more pragmatically, TYPE_{MIN,MAX}_VALUE is
++ not defined for pointers). */
+
+- if (!never_infinite)
++ if (!exit_must_be_taken && !POINTER_TYPE_P (type))
+ {
+ if (integer_nonzerop (iv0->step))
+ assumption = fold_build2 (NE_EXPR, boolean_type_node,
+@@ -1131,7 +1148,8 @@
+
+ bounds_add (bnds, double_int_one, type1);
+
+- return number_of_iterations_lt (type, iv0, iv1, niter, never_infinite, bnds);
++ return number_of_iterations_lt (type, iv0, iv1, niter, exit_must_be_taken,
++ bnds);
+ }
+
+ /* Dumps description of affine induction variable IV to FILE. */
+@@ -1177,7 +1195,7 @@
+ affine_iv *iv1, struct tree_niter_desc *niter,
+ bool only_exit)
+ {
+- bool never_infinite, ret;
++ bool exit_must_be_taken = false, ret;
+ bounds bnds;
+
+ /* The meaning of these assumptions is this:
+@@ -1202,42 +1220,27 @@
+ code = swap_tree_comparison (code);
+ }
+
+- if (!only_exit)
+- {
+- /* If this is not the only possible exit from the loop, the information
+- that the induction variables cannot overflow as derived from
+- signedness analysis cannot be relied upon. We use them e.g. in the
+- following way: given loop for (i = 0; i <= n; i++), if i is
+- signed, it cannot overflow, thus this loop is equivalent to
+- for (i = 0; i < n + 1; i++); however, if n == MAX, but the loop
+- is exited in some other way before i overflows, this transformation
+- is incorrect (the new loop exits immediately). */
+- iv0->no_overflow = false;
+- iv1->no_overflow = false;
+- }
+-
+ if (POINTER_TYPE_P (type))
+ {
+ /* Comparison of pointers is undefined unless both iv0 and iv1 point
+ to the same object. If they do, the control variable cannot wrap
<<Diff was trimmed, longer than 597 lines>>
---- CVS-web:
http://cvs.pld-linux.org/cgi-bin/cvsweb.cgi/packages/gcc/gcc-branch.diff?r1=1.12&r2=1.13&f=u
More information about the pld-cvs-commit
mailing list