PowerPC prologue and epilogue 6

2012-04-21 Thread Alan Modra
This patch adds out-of-line vector saves and restores.  To do this I
made some infrastructure changes to various functions like
rs6000_emit_savres_rtx that currently take boolean parameters (savep,
gpr, and lr).  Rather than add yet another boolean to specify vector
regs, I chose to lump them all together in a bitmask.  This made the
patch a little larger but overall is a better interface, I think.

I also revert a change I made in
http://gcc.gnu.org/ml/gcc-patches/2012-04/msg01014.html to always use
r11 as a frame reg whenever abiv4 emits out-of-line saves.  Code
quality in functions with small frames is better without that
particular change.  This however meant some changes are required later
when setting up pointer regs for gpr and fpr out-of-line saves.

What else is here?  Improved register selection when saving vrsave in
the prologue and when restoring cr in the epilogue, allowing better
scheduling.  A fix to rs6000_output_function_prologue to output the
correct .extern for ELF, then deciding we don't need such things
anyway.  And various other little code cleanups.  Bootstrapped and
regression tested powerpc-linux.

gcc/
* config/rs6000/rs6000 (SAVE_INLINE_VRS, REST_INLINE_VRS,
V_SAVE_INLINE, SAVRES_LR, SAVRES_SAVE, SAVRES_REG,
SAVRES_GPR, SAVRES_FPR, SAVRES_VR): Define.
(no_global_regs_above): Delete.
(no_global_regs): New function.
(rs6000_savres_strategy): Handle vector regs.  Use proper lr_save_p
value for load multiple test.
(savres_routine_syms): Increase size.
(rs6000_savres_routine_name, rs6000_savres_routine_sym,
ptr_regno_for_savres, rs6000_emit_savres_rtx): Pass in int selector
rather than a number of boolean flags.  Update all callers.
(rs6000_savres_routine_name): Generate vector save/restore names.
(rs6000_savres_routine_sym): Handle vector regs.  Delete forward decl.
(ptr_regno_for_savres, rs6000_emit_savres_rtx): Likewise.
(rs6000_emit_prologue): Delete saving_FPRs_inline, saving_GPRs_inline
and using_store_multiple.  Expand uses.  Don't always use r11 as
frame reg when needed for out-of-line saves.  Set up initial offset
for out-of-line vector saves when buying stack frame.  Handle pointer
reg setup for out-of-line fp save.  Emit call to out-of-line vector
save function.  Choose r11 or r12 for vrsave reg when available for
better scheduling.
(rs6000_output_function_prologue): Don't emit .extern for ELF.
(rs6000_emit_epilogue): Choose a better frame reg when restoring
from back-chain to suit out-of-line vector restore functions.  Emit
call to out-of-line vector restore function.  Adjust register used
for cr restore.  Tweak pointer register setup for gpr restore.
* config/rs6000/rs6000.h (FIRST_SAVED_GP_REGNO): Take into account
FIXED_R13.
* config/rs6000/sysv4.h (FP_SAVE_INLINE, GP_SAVE_INLINE): Simplify.
(V_SAVE_INLINE): Define.
* config/rs6000/altivec.md (save_vregs_*, restore_vregs_*): New insns.
libgcc/
* config/rs6000/crtsavevr.S: New file.
* config/rs6000/crtrestvr.S: New file.
* config/rs6000/t-savresfgpr: Build the above.
* config/rs6000/t-netbsd: Likewise.

diff -urpN gcc-alan5/gcc/config/rs6000/rs6000.c 
gcc-alan6/gcc/config/rs6000/rs6000.c
--- gcc-alan5/gcc/config/rs6000/rs6000.c2012-04-19 20:55:02.214727782 
+0930
+++ gcc-alan6/gcc/config/rs6000/rs6000.c2012-04-21 15:47:44.193462791 
+0930
@@ -937,7 +937,6 @@ static bool legitimate_small_data_p (enu
 static bool legitimate_lo_sum_address_p (enum machine_mode, rtx, int);
 static struct machine_function * rs6000_init_machine_status (void);
 static bool rs6000_assemble_integer (rtx, unsigned int, int);
-static bool no_global_regs_above (int, bool);
 #if defined (HAVE_GAS_HIDDEN)  !TARGET_MACHO
 static void rs6000_assemble_visibility (tree, int);
 #endif
@@ -950,7 +949,6 @@ static tree rs6000_handle_struct_attribu
 static void rs6000_eliminate_indexed_memrefs (rtx operands[2]);
 static const char *rs6000_mangle_type (const_tree);
 static void rs6000_set_default_type_attributes (tree);
-static rtx rs6000_savres_routine_sym (rs6000_stack_t *, bool, bool, bool);
 static bool rs6000_reg_live_or_pic_offset_p (int);
 static tree rs6000_builtin_vectorized_libmass (tree, tree, tree);
 static tree rs6000_builtin_vectorized_function (tree, tree, tree);
@@ -17405,6 +17403,21 @@ is_altivec_return_reg (rtx reg, void *xy
 }
 
 
+/* Look for user-defined global regs in the range FIRST to LAST-1.
+   We should not restore these, and so cannot use lmw or out-of-line
+   restore functions if there are any.  We also can't save them
+   (well, emit frame notes for them), because frame unwinding during
+   exception handling will restore saved registers.  */
+
+static bool
+global_regs_p (unsigned first, unsigned last)
+{
+  while (first  last)
+if 

Re: [libcpp] maybe canonicalize system paths in line-map

2012-04-21 Thread Manuel López-Ibáñez
Ping: http://gcc.gnu.org/ml/gcc-patches/2012-04/msg00903.html

On 15 April 2012 20:44, Manuel López-Ibáñez lopeziba...@gmail.com wrote:
 This patch tries to store the shortest form of a path to a system
 file, either the original given or the canonical form returned by
 realpath. User files are left untouched. This converts this:

 t.cc: In function 'void f()':
 t.cc:2:23: error: no matching function for call to 'sort(int)'
 t.cc:2:23: note: candidates are:
 In file included from
 /home/redi/gcc/4.x/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../include/c++/4.8.0/algorithm:63:0,
                 from t.cc:1:
 /home/redi/gcc/4.x/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../include/c++/4.8.0/bits/stl_algo.h:5420:5:
 note: templateclass _RAIter void std::sort(_RAIter, _RAIter)
 /home/redi/gcc/4.x/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../include/c++/4.8.0/bits/stl_algo.h:5420:5:
 note:   template argument deduction/substitution failed:
 t.cc:2:23: note:   candidate expects 2 arguments, 1 provided
 In file included from
 /home/redi/gcc/4.x/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../include/c++/4.8.0/algorithm:63:0,
                 from t.cc:1:
 /home/redi/gcc/4.x/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../include/c++/4.8.0/bits/stl_algo.h:5456:5:
 note: templateclass _RAIter, class _Compare void std::sort(_RAIter, _RAIter,
 _Compare)
 /home/redi/gcc/4.x/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../include/c++/4.8.0/bits/stl_algo.h:5456:5:
 note:   template argument deduction/substitution failed:
 t.cc:2:23: note:   candidate expects 3 arguments, 1 provided

 into this:

 canonicalize-paths.C: In function ‘void f()’:
 canonicalize-paths.C:2:23: error: no matching function for call to ‘sort(int)’
 canonicalize-paths.C:2:23: note: candidates are:
 In file included from
 /home/manuel/test2/186353M/install/include/c++/4.8.0/algorithm:63:0,
                 from canonicalize-paths.C:1:
 /home/manuel/test2/186353M/install/include/c++/4.8.0/bits/stl_algo.h:5420:5:
 note: templateclass _RAIter void std::sort(_RAIter, _RAIter)
 /home/manuel/test2/186353M/install/include/c++/4.8.0/bits/stl_algo.h:5420:5:
 note:   template argument deduction/substitution failed:
 canonicalize-paths.C:2:23: note:   candidate expects 2 arguments, 1 provided
 In file included from
 /home/manuel/test2/186353M/install/include/c++/4.8.0/algorithm:63:0,
                 from canonicalize-paths.C:1:
 /home/manuel/test2/186353M/install/include/c++/4.8.0/bits/stl_algo.h:5456:5:
 note: templateclass _RAIter, class _Compare void std::sort(_RAIter,
 _RAIter, _Compare)
 /home/manuel/test2/186353M/install/include/c++/4.8.0/bits/stl_algo.h:5456:5:
 note:   template argument deduction/substitution failed:
 canonicalize-paths.C:2:23: note:   candidate expects 3 arguments, 1 provided

 Bootstrapped and regtested on x86-64-unknown-linux-gnu.

 OK for trunk?

 2012-04-15  Manuel López-Ibáñez  m...@gcc.gnu.org

        PR 52974
 libcpp/
        * line-map.c (maybe_shorter_path): New.
        (linemap_add): Use it.


[C] improve missing initializers diagnostics

2012-04-21 Thread Manuel López-Ibáñez
This patch improves missing initializers diagnostics. From:

pr36446.c:13:3: warning: missing initializer [-Wmissing-field-initializers]
   .h = {1},
   ^
pr36446.c:13:3: warning: (near initialization for ‘m0.h.b’)
[-Wmissing-field-initializers]
   .h = {1},
   ^

to:

pr36446.c:13:3: warning: missing initializer for field ‘b’ of ‘struct
h’ [-Wmissing-field-initializers]
   .h = {1},
   ^
pr36446.c:3:7: note: ‘b’ declared here
   int b;
   ^

Bootstrapped/regression tested.

OK?


2012-04-19  Manuel López-Ibáñez  m...@gcc.gnu.org

* c-typeck.c (pop_init_level): Improve diagnostics.
testsuite/
* gcc.dg/m-un-2.c: Update.
* gcc.dg/20011021-1.c: Update.


missing-initializers.diff
Description: Binary data


Re: [libcpp] maybe canonicalize system paths in line-map

2012-04-21 Thread Jonathan Wakely
I think this patch is a *huge* improvement for C++ diagnostics that
refer to standard library files, I really hope it will be approved in
some form.


On 21 April 2012 12:58, Manuel López-Ibáñez lopeziba...@gmail.com wrote:
 Ping: http://gcc.gnu.org/ml/gcc-patches/2012-04/msg00903.html

 On 15 April 2012 20:44, Manuel López-Ibáñez lopeziba...@gmail.com wrote:
 This patch tries to store the shortest form of a path to a system
 file, either the original given or the canonical form returned by
 realpath. User files are left untouched. This converts this:

 t.cc: In function 'void f()':
 t.cc:2:23: error: no matching function for call to 'sort(int)'
 t.cc:2:23: note: candidates are:
 In file included from
 /home/redi/gcc/4.x/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../include/c++/4.8.0/algorithm:63:0,
                 from t.cc:1:
 /home/redi/gcc/4.x/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../include/c++/4.8.0/bits/stl_algo.h:5420:5:
 note: templateclass _RAIter void std::sort(_RAIter, _RAIter)
 /home/redi/gcc/4.x/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../include/c++/4.8.0/bits/stl_algo.h:5420:5:
 note:   template argument deduction/substitution failed:
 t.cc:2:23: note:   candidate expects 2 arguments, 1 provided
 In file included from
 /home/redi/gcc/4.x/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../include/c++/4.8.0/algorithm:63:0,
                 from t.cc:1:
 /home/redi/gcc/4.x/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../include/c++/4.8.0/bits/stl_algo.h:5456:5:
 note: templateclass _RAIter, class _Compare void std::sort(_RAIter, 
 _RAIter,
 _Compare)
 /home/redi/gcc/4.x/lib/gcc/x86_64-unknown-linux-gnu/4.8.0/../../../../include/c++/4.8.0/bits/stl_algo.h:5456:5:
 note:   template argument deduction/substitution failed:
 t.cc:2:23: note:   candidate expects 3 arguments, 1 provided

 into this:

 canonicalize-paths.C: In function ‘void f()’:
 canonicalize-paths.C:2:23: error: no matching function for call to 
 ‘sort(int)’
 canonicalize-paths.C:2:23: note: candidates are:
 In file included from
 /home/manuel/test2/186353M/install/include/c++/4.8.0/algorithm:63:0,
                 from canonicalize-paths.C:1:
 /home/manuel/test2/186353M/install/include/c++/4.8.0/bits/stl_algo.h:5420:5:
 note: templateclass _RAIter void std::sort(_RAIter, _RAIter)
 /home/manuel/test2/186353M/install/include/c++/4.8.0/bits/stl_algo.h:5420:5:
 note:   template argument deduction/substitution failed:
 canonicalize-paths.C:2:23: note:   candidate expects 2 arguments, 1 provided
 In file included from
 /home/manuel/test2/186353M/install/include/c++/4.8.0/algorithm:63:0,
                 from canonicalize-paths.C:1:
 /home/manuel/test2/186353M/install/include/c++/4.8.0/bits/stl_algo.h:5456:5:
 note: templateclass _RAIter, class _Compare void std::sort(_RAIter,
 _RAIter, _Compare)
 /home/manuel/test2/186353M/install/include/c++/4.8.0/bits/stl_algo.h:5456:5:
 note:   template argument deduction/substitution failed:
 canonicalize-paths.C:2:23: note:   candidate expects 3 arguments, 1 provided

 Bootstrapped and regtested on x86-64-unknown-linux-gnu.

 OK for trunk?

 2012-04-15  Manuel López-Ibáñez  m...@gcc.gnu.org

        PR 52974
 libcpp/
        * line-map.c (maybe_shorter_path): New.
        (linemap_add): Use it.


Re: [RFA, C++] Symbol table 12/many: Remove cxx_analyze_expr hook

2012-04-21 Thread Jason Merrill

OK.

Jason


Re: [C/ObjC/C++/ObjC++] cleanup diagnostics initialization

2012-04-21 Thread Manuel López-Ibáñez
I created PR 53061 to track this. I prefer to focus on other things,
so feel free to take the patch there and do whatever you need to get
it approved.

Cheers,

Manuel.


Re: [libcpp] maybe canonicalize system paths in line-map

2012-04-21 Thread Jason Merrill
It seems like we'll do this for every line in the header, which could 
lead to a lot of leaked memory.  Instead, we should canonicalize when 
setting ORDINARY_MAP_FILE_NAME.


Jason


Re: [RFA, C++] Symbol table 12/many: Remove cxx_analyze_expr hook

2012-04-21 Thread Jan Hubicka
Jason,
thank you.  My goal is to get rid of places where C++ FE is forcing symbols to 
be output unconditoinally.
I think the remaining cases are those where mark_decl_referenced is called.

My understnading is that those are
 1) COMDAT symbols that must be output because they are keyed, but for weird
ABI reasons they have COMDAT linkage even if normal public linkage would
suit better.

This is code in maybe_make_one_only and the following call of mark_needed:
  if (!CLASSTYPE_KEY_METHOD (class_type)
  || DECL_DECLARED_INLINE_P (CLASSTYPE_KEY_METHOD (class_type))
  || targetm.cxx.class_data_always_comdat ())
{ 
  /* The ABI requires COMDAT linkage.  Normally, we
 only emit COMDAT things when they are needed;
 make sure that we realize that this entity is
 indeed needed.  */
  comdat_p = true;
  mark_needed (decl);
 2) symbols marked as needed by the repository (rest of mark_needed calls).

I would like to make those cases less restrictive. 

When doing LTO, we can still privatize and/or optimize out those symbols.  This 
is
the case where the symbols have hidden linkage and linker plugin tells us that 
there
are no external uses.

I am not sure about symbols exported form the DSO when linker plugin does not 
mark them
as used, I think they need to stay.

Consequentely I would like to add a new flag, comdat_keyed_by_abi, that force
comdat to stay unless the above exception holds (and verify that only comdats
are getting this flag).  Does this make sense?

It is couple thousdand symbols building Mozilla, being able to optimize them
may make things to smoother + this flag is a lot more descriptive than the
fallback mechanizm disabling any sort of optimization on the symbol.
(mark_decl_referenced has same the effect as used attribute, that is IPA code
assumes it has no chance to track its behaviour at all).

Honza


Re: [libcpp] maybe canonicalize system paths in line-map

2012-04-21 Thread Manuel López-Ibáñez
On 21 April 2012 14:56, Jason Merrill ja...@redhat.com wrote:
 It seems like we'll do this for every line in the header, which could lead
 to a lot of leaked memory.  Instead, we should canonicalize when setting
 ORDINARY_MAP_FILE_NAME.

Hum, my understanding of the code is that this is exactly what I
implemented. That is, at most we leak every time
ORDINARY_MAP_FILE_NAME is set to a system header file (if the realpath
is shorter than the original path). This is a bit inefficient because
this happens two times per #include (when entering and when leaving).
But I honestly don't know how to avoid this.

If any one has suggestions on a better implementation, I am happy to
hear about it.

Cheers,

Manuel.


[RFC] improve caret diagnostics for overload failures

2012-04-21 Thread Manuel López-Ibáñez
As noticed by Jason in PR 2485. The current output with caret
diagnostics is a bit verbose in some cases:

wa2.C: In function ‘int main()’:
wa2.C:6:6: error: no matching function for call to ‘f(int)’
   f(1);
  ^
wa2.C:6:6: note: candidates are:
   f(1);
  ^
wa2.C:1:6: note: void f()
 void f();
  ^
wa2.C:1:6: note:   candidate expects 0 arguments, 1 provided
 void f();
  ^
wa2.C:2:6: note: void f(int, int)
 void f(int,int);
  ^
wa2.C:2:6: note:   candidate expects 2 arguments, 1 provided
 void f(int,int);
  ^

Following the discussion there, this patch changes the output to:

caret-overload.C:102:6: error: no matching function for call to ‘f(int)’
   f(1);
  ^
note: candidates are:
caret-overload.C:1:6: note: void f()
  note:   candidate expects 0 arguments, 1 provided
 void f();
  ^
caret-overload.C:10:6: note: void f(int, int)
   note:   candidate expects 2 arguments, 1 provided
 void f(int,int);
  ^

(Gmail messes up the alignment, see the output in the PR as it is
actually meant to be)

I have two questions. First, is the implementation approach ok?

Second, changing the output like this, requires updating tons of
testcases. I could update the testcases to match the notes without
prefix by simply matching the 0 line. But perhaps it is better to add
a new { dg-notes-2 note1 note2 } which passes a regexp such as
[^\n]*note1[^\n]*\n[^\n]*note2[^\n]* to process-message. What do you think?

Cheers,

Manuel.


caret-overload.diff
Description: Binary data


[C/C++] Do not pretty-print expressions with caret diagnostics for wrong function call

2012-04-21 Thread Manuel López-Ibáñez
This patch avoids pretty-printing expressions when the caret is
enabled for the error given when calling as a function something that
is not a function.

This fixes (when caret is enabled) the bugs described in PR35441 and
also shown here http://clang.llvm.org/diagnostics.html (No Pretty
Printing of Expressions in Diagnostics).

Bootstrapped/regression tested.

OK?

2012-04-21  Manuel López-Ibáñez  m...@gcc.gnu.org

PR 35441
* c-typeck.c (inform_declaration): New.
(build_function_call_vec):  Do not pretty-print
expressions when caret is enabled.
(convert_arguments): Use inform_declaration.
* cp/typeck.c (cp_build_function_call_vec): Do not pretty-print
expressions when caret is enabled.
* testsuite/c-c++-common/pr35441.C: New.


fix-pr35441-2.diff
Description: Binary data


Re: [RFC] improve caret diagnostics for overload failures

2012-04-21 Thread Gabriel Dos Reis
Do no use 'char' as the type of a flag.  Prefer 'unsigned int'.

On Sat, Apr 21, 2012 at 8:57 AM, Manuel López-Ibáñez
lopeziba...@gmail.com wrote:
 As noticed by Jason in PR 2485. The current output with caret
 diagnostics is a bit verbose in some cases:

 wa2.C: In function ‘int main()’:
 wa2.C:6:6: error: no matching function for call to ‘f(int)’
   f(1);
      ^
 wa2.C:6:6: note: candidates are:
   f(1);
      ^
 wa2.C:1:6: note: void f()
  void f();
      ^
 wa2.C:1:6: note:   candidate expects 0 arguments, 1 provided
  void f();
      ^
 wa2.C:2:6: note: void f(int, int)
  void f(int,int);
      ^
 wa2.C:2:6: note:   candidate expects 2 arguments, 1 provided
  void f(int,int);
      ^

 Following the discussion there, this patch changes the output to:

 caret-overload.C:102:6: error: no matching function for call to ‘f(int)’
   f(1);
      ^
                        note: candidates are:
 caret-overload.C:1:6: note: void f()
                      note:   candidate expects 0 arguments, 1 provided
  void f();
      ^
 caret-overload.C:10:6: note: void f(int, int)
                       note:   candidate expects 2 arguments, 1 provided
  void f(int,int);
      ^

 (Gmail messes up the alignment, see the output in the PR as it is
 actually meant to be)

 I have two questions. First, is the implementation approach ok?

 Second, changing the output like this, requires updating tons of
 testcases. I could update the testcases to match the notes without
 prefix by simply matching the 0 line. But perhaps it is better to add
 a new { dg-notes-2 note1 note2 } which passes a regexp such as
 [^\n]*note1[^\n]*\n[^\n]*note2[^\n]* to process-message. What do you think?

 Cheers,

 Manuel.


Re: [RFC] improve caret diagnostics for overload failures

2012-04-21 Thread Manuel López-Ibáñez
On 21 April 2012 16:22, Gabriel Dos Reis g...@integrable-solutions.net wrote:
 Do no use 'char' as the type of a flag.  Prefer 'unsigned int'.


Thanks, good catch! Should I worry about memory here and use something shorter?

Cheers,

Manuel.


Re: [C/C++] Do not pretty-print expressions with caret diagnostics for wrong function call

2012-04-21 Thread Manuel López-Ibáñez
Hi Gabriel,

I hope you meant to send this OK also to gcc-patches.

Cheers,

Manuel.

On 21 April 2012 16:25, Gabriel Dos Reis g...@integrable-solutions.net wrote:
 OK.

 On Sat, Apr 21, 2012 at 9:06 AM, Manuel López-Ibáñez
 lopeziba...@gmail.com wrote:
 This patch avoids pretty-printing expressions when the caret is
 enabled for the error given when calling as a function something that
 is not a function.

 This fixes (when caret is enabled) the bugs described in PR35441 and
 also shown here http://clang.llvm.org/diagnostics.html (No Pretty
 Printing of Expressions in Diagnostics).

 Bootstrapped/regression tested.

 OK?

 2012-04-21  Manuel López-Ibáñez  m...@gcc.gnu.org

        PR 35441
        * c-typeck.c (inform_declaration): New.
        (build_function_call_vec):  Do not pretty-print
        expressions when caret is enabled.
        (convert_arguments): Use inform_declaration.
        * cp/typeck.c (cp_build_function_call_vec): Do not pretty-print
        expressions when caret is enabled.
        * testsuite/c-c++-common/pr35441.C: New.


Re: [C/C++] Do not pretty-print expressions with caret diagnostics for wrong function call

2012-04-21 Thread Gabriel Dos Reis
On Sat, Apr 21, 2012 at 9:41 AM, Manuel López-Ibáñez
lopeziba...@gmail.com wrote:
 Hi Gabriel,

 I hope you meant to send this OK also to gcc-patches.

Indeed.


 Cheers,

 Manuel.

 On 21 April 2012 16:25, Gabriel Dos Reis g...@integrable-solutions.net 
 wrote:
 OK.

 On Sat, Apr 21, 2012 at 9:06 AM, Manuel López-Ibáñez
 lopeziba...@gmail.com wrote:
 This patch avoids pretty-printing expressions when the caret is
 enabled for the error given when calling as a function something that
 is not a function.

 This fixes (when caret is enabled) the bugs described in PR35441 and
 also shown here http://clang.llvm.org/diagnostics.html (No Pretty
 Printing of Expressions in Diagnostics).

 Bootstrapped/regression tested.

 OK?

 2012-04-21  Manuel López-Ibáñez  m...@gcc.gnu.org

        PR 35441
        * c-typeck.c (inform_declaration): New.
        (build_function_call_vec):  Do not pretty-print
        expressions when caret is enabled.
        (convert_arguments): Use inform_declaration.
        * cp/typeck.c (cp_build_function_call_vec): Do not pretty-print
        expressions when caret is enabled.
        * testsuite/c-c++-common/pr35441.C: New.


Re: [RFC] improve caret diagnostics for overload failures

2012-04-21 Thread Jakub Jelinek
On Sat, Apr 21, 2012 at 04:26:32PM +0200, Manuel López-Ibáñez wrote:
 On 21 April 2012 16:22, Gabriel Dos Reis g...@integrable-solutions.net 
 wrote:
  Do no use 'char' as the type of a flag.  Prefer 'unsigned int'.
 
 
 Thanks, good catch! Should I worry about memory here and use something 
 shorter?

If it is a bool flag, you certainly should use bool type, which is shorter.

Jakub


Re: [RFC] improve caret diagnostics for overload failures

2012-04-21 Thread Gabriel Dos Reis
On Sat, Apr 21, 2012 at 9:42 AM, Jakub Jelinek ja...@redhat.com wrote:
 On Sat, Apr 21, 2012 at 04:26:32PM +0200, Manuel López-Ibáñez wrote:
 On 21 April 2012 16:22, Gabriel Dos Reis g...@integrable-solutions.net 
 wrote:
  Do no use 'char' as the type of a flag.  Prefer 'unsigned int'.
 

 Thanks, good catch! Should I worry about memory here and use something 
 shorter?

 If it is a bool flag, you certainly should use bool type, which is shorter.

It is a bit flag -- see the patch in his original message and 'enum
diagnostic_info_flags'.


[PATCH] genattrtab: avoid NULL-deref on error

2012-04-21 Thread Jim Meyering
I see that no one responded when I posted this in February.
Ok to commit, now?

2012-02-24  Jim Meyering  meyer...@redhat.com

* genattrtab.c (gen_attr): Avoid NULL-deref after diagnosing
absence of an define_enum call.


diff --git a/gcc/genattrtab.c b/gcc/genattrtab.c
index 4a4c2a2..bfbe3e8 100644
--- a/gcc/genattrtab.c
+++ b/gcc/genattrtab.c
@@ -1,6 +1,6 @@
 /* Generate code from machine description to compute values of attributes.
Copyright (C) 1991, 1993, 1994, 1995, 1996, 1997, 1998, 1999, 2000,
-   2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010
+   2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2012
Free Software Foundation, Inc.
Contributed by Richard Kenner (ken...@vlsi1.ultra.nyu.edu)

@@ -2993,8 +2993,9 @@ gen_attr (rtx exp, int lineno)
   if (!et || !et-md_p)
error_with_line (lineno, No define_enum called `%s' defined,
 attr-name);
-  for (ev = et-values; ev; ev = ev-next)
-   add_attr_value (attr, ev-name);
+  if (et)
+   for (ev = et-values; ev; ev = ev-next)
+ add_attr_value (attr, ev-name);
 }
   else if (*XSTR (exp, 1) == '\0')
 attr-is_numeric = 1;
--
1.7.10.228.g81f95


Re: [PATCH] Fix PR53011

2012-04-21 Thread H.J. Lu
On Tue, Apr 17, 2012 at 6:38 AM, Richard Guenther rguent...@suse.de wrote:

 This fixes PR53011 - EH cleanup needs to cater for loops now
 (or avoid some transforms).

 Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.

 Richard.

This caused:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53062


-- 
H.J.


Re: [C/C++] Do not pretty-print expressions with caret diagnostics for wrong function call

2012-04-21 Thread Jakub Jelinek
On Sat, Apr 21, 2012 at 04:06:17PM +0200, Manuel López-Ibáñez wrote:
 This patch avoids pretty-printing expressions when the caret is
 enabled for the error given when calling as a function something that
 is not a function.
 
 This fixes (when caret is enabled) the bugs described in PR35441 and
 also shown here http://clang.llvm.org/diagnostics.html (No Pretty
 Printing of Expressions in Diagnostics).
 
 Bootstrapped/regression tested.
 
 OK?
 
 2012-04-21  Manuel López-Ibáñez  m...@gcc.gnu.org
 
   PR 35441

This should be PR c/35441

   * c-typeck.c (inform_declaration): New.
   (build_function_call_vec):  Do not pretty-print
   expressions when caret is enabled.
   (convert_arguments): Use inform_declaration.
   * cp/typeck.c (cp_build_function_call_vec): Do not pretty-print
   expressions when caret is enabled.
   * testsuite/c-c++-common/pr35441.C: New.

+ if (!flag_diagnostics_show_caret) 
   
+   error_at (input_location,   
   
+ %qE cannot be used as a function, original);
   
+ else if (DECL_P (original))   
   
+   error_at (input_location,   
   
+ %qD cannot be used as a function, original);
   
+ else  
   
+   error_at (input_location,   
   
+ expression cannot be used as a function);   
   

Before we start to add many similar tests, I wonder if we shouldn't
test not just that caret diagnostics is on, but that it will be actually
printed for the specific locus.  The source could come up from
stdin, or the file no longer available, etc.  So, shouldn't
this be guarded instead on some predicate that takes locus_t as an
argument (input_location in this case), say can_emit_caret_diagnostics_p,
which would return false right away for !flag_diagnostics_show_caret,
otherwise would try to grab the source line (and cache it) and return true
only if it succeeded?  Then error_at after it if returned true would just
use the cached line, so it wouldn't read things twice.

There have been requests to (at least optionally) limit caret diagnostics
to certain number of carets and then stop emitting them if there are too
many, because with caret the output is most often 3 times as long, such
predicate could take that into account too if it is added.

Jakub


Re: [PATCH] Fix PR53011

2012-04-21 Thread H.J. Lu
On Sat, Apr 21, 2012 at 10:19 AM, H.J. Lu hjl.to...@gmail.com wrote:
 On Tue, Apr 17, 2012 at 6:38 AM, Richard Guenther rguent...@suse.de wrote:

 This fixes PR53011 - EH cleanup needs to cater for loops now
 (or avoid some transforms).

 Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.

 Richard.

 This caused:

 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53062


Sorry. Wrong revision.

-- 
H.J.


Re: rfa: vectorize strided loads [2/2] [PR 18437]

2012-04-21 Thread H.J. Lu
On Tue, Apr 10, 2012 at 6:46 AM, Michael Matz m...@suse.de wrote:
 Hi,


 Michael.

        PR tree-optimization/18437

        * tree-vectorizer.h (_stmt_vec_info.stride_load_p): New member.
        (STMT_VINFO_STRIDE_LOAD_P): New accessor.
        (vect_check_strided_load): Declare.
        * tree-vect-data-refs.c (vect_check_strided_load): New function.
        (vect_analyze_data_refs): Use it to accept strided loads.
        * tree-vect-stmts.c (vectorizable_load): Ditto and handle them.


This caused:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53062

H.J.


Re: rfa: vectorize strided loads [2/2] [PR 18437]

2012-04-21 Thread H.J. Lu
On Sat, Apr 21, 2012 at 11:11 AM, H.J. Lu hjl.to...@gmail.com wrote:
 On Tue, Apr 10, 2012 at 6:46 AM, Michael Matz m...@suse.de wrote:
 Hi,


 Michael.

        PR tree-optimization/18437

        * tree-vectorizer.h (_stmt_vec_info.stride_load_p): New member.
        (STMT_VINFO_STRIDE_LOAD_P): New accessor.
        (vect_check_strided_load): Declare.
        * tree-vect-data-refs.c (vect_check_strided_load): New function.
        (vect_analyze_data_refs): Use it to accept strided loads.
        * tree-vect-stmts.c (vectorizable_load): Ditto and handle them.


 This caused:

 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53062


It also caused:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53048

-- 
H.J.


libgo patch committed: More syscall package improvements

2012-04-21 Thread Ian Lance Taylor
This patch to libgo brings the syscall package closer to the one
provided on GNU/Linux systems by the master Go library.  This is mostly
additional constants, but also corrects the Tgkill and Mount functions.
This an incremental step; there is more work to do.  Bootstrapped and
ran Go testsuite on x86_64-unknown-linux-gnu.  Committed to mainline and
4.7 branch.

Ian

diff -r a776919b56e7 libgo/configure.ac
--- a/libgo/configure.ac	Fri Apr 20 14:20:14 2012 -0700
+++ b/libgo/configure.ac	Sat Apr 21 11:47:01 2012 -0700
@@ -453,9 +453,9 @@
   ;;
 esac
 
-AC_CHECK_HEADERS(sys/mman.h syscall.h sys/epoll.h sys/ptrace.h sys/syscall.h sys/user.h sys/utsname.h sys/select.h sys/socket.h net/if.h net/if_arp.h sys/prctl.h sys/mount.h sys/vfs.h sys/statfs.h sys/timex.h sys/sysinfo.h utime.h linux/ether.h linux/reboot.h)
+AC_CHECK_HEADERS(sys/file.h sys/mman.h syscall.h sys/epoll.h sys/inotify.h sys/ptrace.h sys/syscall.h sys/user.h sys/utsname.h sys/select.h sys/socket.h net/if.h net/if_arp.h net/route.h netpacket/packet.h sys/prctl.h sys/mount.h sys/vfs.h sys/statfs.h sys/timex.h sys/sysinfo.h utime.h linux/ether.h linux/reboot.h netinet/in_syst.h netinet/ip.h netinet/ip_mroute.h netinet/if_ether.h)
 
-AC_CHECK_HEADERS([linux/filter.h linux/netlink.h linux/rtnetlink.h], [], [],
+AC_CHECK_HEADERS([linux/filter.h linux/if_addr.h linux/if_ether.h linux/if_tun.h linux/netlink.h linux/rtnetlink.h], [], [],
 [#ifdef HAVE_SYS_SOCKET_H
 #include sys/socket.h
 #endif
diff -r a776919b56e7 libgo/go/syscall/libcall_linux.go
--- a/libgo/go/syscall/libcall_linux.go	Fri Apr 20 14:20:14 2012 -0700
+++ b/libgo/go/syscall/libcall_linux.go	Sat Apr 21 11:47:01 2012 -0700
@@ -335,7 +335,7 @@
 //sys	Tee(rfd int, wfd int, len int, flags int) (n int64, err error)
 //tee(rfd int, wfd int, len Size_t, flags uint) Ssize_t
 
-func Tgkill(tgid, tid, sig Signal) error {
+func Tgkill(tgid, tid int, sig Signal) error {
 	r1, _, errno := Syscall(SYS_TGKILL, uintptr(tgid), uintptr(tid), uintptr(sig))
 	if r1  0 {
 		return errno
diff -r a776919b56e7 libgo/go/syscall/libcall_posix.go
--- a/libgo/go/syscall/libcall_posix.go	Fri Apr 20 14:20:14 2012 -0700
+++ b/libgo/go/syscall/libcall_posix.go	Sat Apr 21 11:47:01 2012 -0700
@@ -268,7 +268,7 @@
 //sys	Mknod(path string, mode uint32, dev int) (err error)
 //mknod(path *byte, mode Mode_t, dev _dev_t) int
 
-//sys	Mount(source string, target string, fstype string, flags int, data string) (err error)
+//sys	Mount(source string, target string, fstype string, flags uintptr, data string) (err error)
 //mount(source *byte, target *byte, fstype *byte, flags _C_long, data *byte) int
 
 //sys	Nanosleep(time *Timespec, leftover *Timespec) (err error)
diff -r a776919b56e7 libgo/mksysinfo.sh
--- a/libgo/mksysinfo.sh	Fri Apr 20 14:20:14 2012 -0700
+++ b/libgo/mksysinfo.sh	Sat Apr 21 11:47:01 2012 -0700
@@ -40,6 +40,18 @@
 #include sys/ttold.h
 #endif
 #include netinet/tcp.h
+#if defined(HAVE_NETINET_IN_SYSTM_H)
+#include netinet/in_systm.h
+#endif
+#if defined(HAVE_NETINET_IP_H)
+#include netinet/ip.h
+#endif
+#if defined(HAVE_NETINET_IP_MROUTE_H)
+#include netinet/ip_mroute.h
+#endif
+#if defined(HAVE_NETINET_IF_ETHER_H)
+#include netinet/if_ether.h
+#endif
 #include signal.h
 #include sys/ioctl.h
 #include termios.h
@@ -52,6 +64,9 @@
 #if defined(HAVE_SYS_EPOLL_H)
 #include sys/epoll.h
 #endif
+#if defined(HAVE_SYS_FILE_H)
+#include sys/file.h
+#endif
 #if defined(HAVE_SYS_MMAN_H)
 #include sys/mman.h
 #endif
@@ -85,6 +100,15 @@
 #if defined(HAVE_LINUX_FILTER_H)
 #include linux/filter.h
 #endif
+#if defined(HAVE_LINUX_IF_ADDR_H)
+#include linux/if_addr.h
+#endif
+#if defined(HAVE_LINUX_IF_ETHER_H)
+#include linux/if_ether.h
+#endif
+#if defined(HAVE_LINUX_IF_TUN_H)
+#include linux/if_tun.h
+#endif
 #if defined(HAVE_LINUX_NETLINK_H)
 #include linux/netlink.h
 #endif
@@ -97,6 +121,12 @@
 #if defined(HAVE_NET_IF_ARP_H)
 #include net/if_arp.h
 #endif
+#if defined(HAVE_NET_ROUTE_H)
+#include net/route.h
+#endif
+#if defined (HAVE_NETPACKET_PACKET_H)
+#include netpacket/packet.h
+#endif
 #if defined(HAVE_SYS_MOUNT_H)
 #include sys/mount.h
 #endif
@@ -124,6 +154,9 @@
 #if defined(HAVE_LINUX_REBOOT_H)
 #include linux/reboot.h
 #endif
+#if defined(HAVE_SYS_INOTIFY_H)
+#include sys/inotify.h
+#endif
 
 /* Constants that may only be defined as expressions on some systems,
expressions too complex for -fdump-go-spec to handle.  These are
@@ -199,6 +232,8 @@
   sed -e 's/^\(const \)_\(MAP_[^= ]*\)\(.*\)$/\1\2 = _\2/'  ${OUT}
 grep '^const _MADV_' gen-sysinfo.go | \
   sed -e 's/^\(const \)_\(MADV_[^= ]*\)\(.*\)$/\1\2 = _\2/'  ${OUT}
+grep '^const _MCL_' gen-sysinfo.go | \
+  sed -e 's/^\(const \)_\(MCL_[^= ]*\)\(.*\)$/\1\2 = _\2/'  ${OUT}
 
 # Process status constants.
 grep '^const _W' gen-sysinfo.go |
@@ -700,7 +735,7 @@
   -e 's/rtm_src_len/Src_len/' \
   -e 's/rtm_tos/Tos/' \
   -e 's/rtm_table/Table/' \
-  -e 's/rtm_protocol/Procotol/' \
+  -e 's/rtm_protocol/Protocol/' \
   -e 's/rtm_scope/Scope/' 

[committed] Restore fold checking

2012-04-21 Thread Richard Sandiford
Noticed after making yes,rtl,df,fold my default --enable-checking option
(the rtl and df bits being long overdue).  Bootstrapped  regression-tested
on x86_64-linux-gnu and installed as obvious.

Richard


gcc/
* fold-const.c (fold_checksum_tree): Fix VECTOR_CST case.

Index: gcc/fold-const.c
===
--- gcc/fold-const.c2012-04-21 18:50:37.0 +0100
+++ gcc/fold-const.c2012-04-21 18:50:37.559865589 +0100
@@ -14391,7 +14391,8 @@ fold_checksum_tree (const_tree expr, str
  fold_checksum_tree (TREE_IMAGPART (expr), ctx, ht);
  break;
case VECTOR_CST:
- fold_checksum_tree (TREE_VECTOR_CST_ELTS (expr), ctx, ht);
+ for (i = 0; i  (int) VECTOR_CST_NELTS (expr); ++i)
+   fold_checksum_tree (VECTOR_CST_ELT (expr, i), ctx, ht);
  break;
default:
  break;


[committed] Clean up ADDRESS handling in alias.c, take 2

2012-04-21 Thread Richard Sandiford
To compound my woe on this one: it turns out that there's also a use
of ADDRESS in store-motion.c.  Obviously a very poor grep session
on my part.

dse.c and store-motion.c are checking for the same thing, and they are
also the only two external users of find_base_term.  It seemed better
to define a higher-level function for them to use instead.

I moved the UNIQUE_BASE_* constants from alias.h to alias.c to
emphasise that ADDRESS really should be local to alias.c.

Also, after all that fuss about using HOST_WIDE_INT as the ADDRESS
argument, I realised that the counter we use has always been a plain int.
We might as well use i instead, which will save room on 32-bit hosts.

Bootstrapped  regression-tested on x86_64-linux-gnu.  The w-i
change seemed obvious, and the rest is rtl optimisation stuff, so:
applied to clear the PR.

Richard


gcc/
PR bootstrap/53021
* rtl.def (ADDRESS): Use i rather than w.
* rtl.h (find_base_term): Delete.
(may_be_sp_based_p): Declare.
* rtl.c (rtx_code_size): Remove ADDRESS special case.
* alias.h (UNIQUE_BASE_VALUE_SP, UNIQUE_BASE_VALUE_ARGP)
(UNIQUE_BASE_VALUE_FP, UNIQUE_BASE_VALUE_HFP): Move to...
* alias.c: ...here.
(find_base_term): Make static.
(may_be_sp_based_p): New function.
* dse.c (record_store): Use it.
* store-motion.c (store_killed_in_insn): Likewise.

Index: gcc/rtl.def
===
--- gcc/rtl.def 2012-04-21 13:46:34.035549209 +0100
+++ gcc/rtl.def 2012-04-21 18:50:46.271865336 +0100
@@ -110,7 +110,7 @@ DEF_RTL_EXPR(INSN_LIST, insn_list, ue
 DEF_RTL_EXPR(SEQUENCE, sequence, E, RTX_EXTRA)
 
 /* Represents a non-global base address.  This is only used in alias.c.  */
-DEF_RTL_EXPR(ADDRESS, address, w, RTX_EXTRA)
+DEF_RTL_EXPR(ADDRESS, address, i, RTX_EXTRA)
 
 /* --
Expression types used for things in the instruction chain.
Index: gcc/rtl.h
===
--- gcc/rtl.h   2012-04-21 13:46:34.064549203 +0100
+++ gcc/rtl.h   2012-04-21 18:50:47.765865292 +0100
@@ -2597,7 +2597,7 @@ extern void init_alias_analysis (void);
 extern void end_alias_analysis (void);
 extern void vt_equate_reg_base_value (const_rtx, const_rtx);
 extern bool memory_modified_in_insn_p (const_rtx, const_rtx);
-extern rtx find_base_term (rtx);
+extern bool may_be_sp_based_p (rtx);
 extern rtx gen_hard_reg_clobber (enum machine_mode, unsigned int);
 extern rtx get_reg_known_value (unsigned int);
 extern bool get_reg_known_equiv_p (unsigned int);
Index: gcc/rtl.c
===
--- gcc/rtl.c   2012-04-21 13:46:34.063549202 +0100
+++ gcc/rtl.c   2012-04-21 18:50:46.130865340 +0100
@@ -111,7 +111,7 @@ #define DEF_RTL_EXPR(ENUM, NAME, FORMAT,
 const unsigned char rtx_code_size[NUM_RTX_CODE] = {
 #define DEF_RTL_EXPR(ENUM, NAME, FORMAT, CLASS)
\
   (((ENUM) == CONST_INT || (ENUM) == CONST_DOUBLE  \
-|| (ENUM) == CONST_FIXED || (ENUM) == ADDRESS) \
+|| (ENUM) == CONST_FIXED)  \
? RTX_HDR_SIZE + (sizeof FORMAT - 1) * sizeof (HOST_WIDE_INT)   \
: RTX_HDR_SIZE + (sizeof FORMAT - 1) * sizeof (rtunion)),
 
Index: gcc/alias.h
===
--- gcc/alias.h 2012-04-21 13:46:34.044549199 +0100
+++ gcc/alias.h 2012-04-21 18:50:46.945865316 +0100
@@ -51,11 +51,4 @@ extern int nonoverlapping_memrefs_p (con
memory barriers, including an address of SCRATCH.  */
 #define ALIAS_SET_MEMORY_BARRIER   ((alias_set_type) -1)
 
-/* Values of XWINT (address, 0) of Pmode ADDRESS rtxes for special
-   registers.  */
-#define UNIQUE_BASE_VALUE_SP   -1
-#define UNIQUE_BASE_VALUE_ARGP -2
-#define UNIQUE_BASE_VALUE_FP   -3
-#define UNIQUE_BASE_VALUE_HFP  -4
-
 #endif /* GCC_ALIAS_H */
Index: gcc/alias.c
===
--- gcc/alias.c 2012-04-21 13:46:34.064549203 +0100
+++ gcc/alias.c 2012-04-21 19:05:05.222840362 +0100
@@ -228,6 +228,13 @@ static GTY(()) rtx arg_base_value;
array.  */
 static GTY((deletable)) VEC(rtx,gc) *old_reg_base_value;
 
+/* Values of XINT (address, 0) of Pmode ADDRESS rtxes for special
+   registers.  */
+#define UNIQUE_BASE_VALUE_SP   -1
+#define UNIQUE_BASE_VALUE_ARGP -2
+#define UNIQUE_BASE_VALUE_FP   -3
+#define UNIQUE_BASE_VALUE_HFP  -4
+
 #define static_reg_base_value \
   (this_target_rtl-x_static_reg_base_value)
 
@@ -1584,7 +1591,7 @@ rtx_equal_for_memref_p (const_rtx x, con
   return 1;
 }
 
-rtx
+static rtx
 find_base_term (rtx x)
 {
   cselib_val *val;
@@ -1740,6 +1747,16 @@ find_base_term (rtx x)
 }
 }
 
+/* Return true if accesses to address X may alias accesses based
+   on the stack pointer.  */
+
+bool

Re: [PATCH] Fix parts of PR52975

2012-04-21 Thread H.J. Lu
On Mon, Apr 16, 2012 at 2:22 AM, Richard Guenther rguent...@suse.de wrote:

 When looking at the code we produce from if-conversion and vectorization
 I noticed several things.  For one, we are not handling TARGET_MEM_REF
 in operand_equal_p which means that DOM does not clean up loads/stores
 of that form (to the extent DOM can do that anyway).  Also we never
 simplify the conditions in VEC_COND_EXPRs because the combining in
 forwprop does not handle them.  And we do not combine the inverted
 COND_EXPRs if-conversion can create - but it's easy to do that in
 forwprop.

 The following addresses this two issues.

 Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.

 Richard.

 2012-04-16  Richard Guenther  rguent...@suse.de

        PR tree-optimization/52975
        * tree-ssa-forwprop.c (combine_cond_exprs): New function.
        (ssa_forward_propagate_and_combine): Call it for COND_EXPRs
        and VEC_COND_EXPRs.  Also combine into VEC_COND_EXPRs condition.
        * fold-const.c (operand_equal_p): Handle TARGET_MEM_REF.


This caused:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53032


-- 
H.J.


Re: [PATCH][1/2] Fix PR44688, set and preserve the maximum iterations of vectorizer prologue loops

2012-04-21 Thread H.J. Lu
On Wed, Apr 18, 2012 at 4:30 AM, Richard Guenther rguent...@suse.de wrote:

 Finally.

 Boostrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.

 Richard.

 2012-04-18  Richard Guenther  rguent...@suse.de

        PR tree-optimization/44688
        * cfgloop.h (record_niter_bound): Declare.
        * tree-ssa-loop-niter.c (record_niter_bound): Export.
        Update the estimation with the upper bound here...
        (estimate_numbers_of_iterations_loop): ... instead of here.
        Do not forcefully reset a recorded upper bound.
        * tree-vect-loop-manip.c (vect_do_peeling_for_alignment):
        Record the maximum number of loop iterations of the
        prologue loop.


This caused:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53047

-- 
H.J.


Re: [PATCH] Fix PR53031

2012-04-21 Thread H.J. Lu
On Thu, Apr 19, 2012 at 5:47 AM, Richard Guenther rguent...@suse.de wrote:

 This fixes PR53031 and reverts back to using the number of latch
 iterations in VRP when computing ranges for induction variables.
 Now after ira_allocno_object_iter_cond is fixed this no longer
 breaks bootstrap.

 Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.

 Richard.

 2012-04-19  Richard Guenther  rguent...@suse.de

        PR tree-optimization/53031
        * tree-vrp.c (adjust_range_with_scev): Revert back to
        using max_loop_iterations.

This caused:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53047


-- 
H.J.


Re: [C/C++] Do not pretty-print expressions with caret diagnostics for wrong function call

2012-04-21 Thread Manuel López-Ibáñez
On 21 April 2012 18:49, Jakub Jelinek ja...@redhat.com wrote:

 Before we start to add many similar tests, I wonder if we shouldn't
 test not just that caret diagnostics is on, but that it will be actually
 printed for the specific locus.  The source could come up from
 stdin, or the file no longer available, etc.  So, shouldn't
 this be guarded instead on some predicate that takes locus_t as an
 argument (input_location in this case), say can_emit_caret_diagnostics_p,
 which would return false right away for !flag_diagnostics_show_caret,
 otherwise would try to grab the source line (and cache it) and return true
 only if it succeeded?  Then error_at after it if returned true would just
 use the cached line, so it wouldn't read things twice.

Well, my preference would be to have the same message with and without
caret diagnostics, instead of still pretty-printing expressions when
the caret is disabled. Because none of my patches do actually fix the
pretty-printing of expressions: when the caret is disabled the
diagnostics are still broken.

Clang has perfect source locations and an AST closer the original
source code and they don't ever try to pretty-print expressions. On
the other hand, GCC does not even try to track the source location of
every token and its AST does not attempt to match the original source
code, and yet GCC still pretends to rebuild the original source code
when pretty-printing. And, hence, GCC often fails in embarrassing
ways.

Thus, pretty-printing expressions when the caret is disabled is the
wrong thing to do in my opinion. However, since Gabriel disagrees and
it is easy to just test for flag_diagnostics_show_caret and keep the
old code if disabled, I am doing just that in the patches that remove
pretty-printing expressions. And there is still a huge work ahead to
remove all the pretty-printing when the caret is enabled. So I
personally don't want to spend a significant effort trying to guess
when the caret was not printed in order to fall-back to something that
is broken.

People that think that pretty-printing expressions is a good idea
should work on it, if they care enough. But perhaps they should start
first by fixing the bugs in the pretty-printer, starting with the
examples in http://gcc.gnu.org/PR49152

 There have been requests to (at least optionally) limit caret diagnostics
 to certain number of carets and then stop emitting them if there are too
 many, because with caret the output is most often 3 times as long, such
 predicate could take that into account too if it is added.

That sounds very difficult to get right and a hack to avoid addressing
the real problem, which is that GCC prints a lot of useless
diagnostics, with either irrelevant or duplicated locations. Until
now, it was easy to ignore them because somewhere in the output there
was the correct diagnostic or the correct location, but with the caret
it is now too obvious that the information is either redundant or just
wrong. So the solution is to fix the diagnostics, not to hide the
caret so it is not so obvious that the diagnostics are broken. And
this is what I am doing. See
http://gcc.gnu.org/ml/gcc-patches/2012-04/msg01283.html, any help on
getting that patch working is welcome.

Cheers,

Manuel.


Re: [C/C++] Do not pretty-print expressions with caret diagnostics for wrong function call

2012-04-21 Thread Gabriel Dos Reis
I don't think the proper fix is to copy Clang.
Clang isn't the gold standard and we shouldn't
act as if it was.

When caret is not enable, the diagnostic should mention
clearly the elements in the input expressions that are problematic
without getting obtuse or elliptic -- two extremes easy to fall into.

-- Gaby