[PATCH, alpha]: Fix PR/47230 [4.6/4.7 Regression] gcc fails to bootstrap on alpha in stage2 with "relocation truncated to fit: GPREL16 against ..."

2011-05-02 Thread Uros Bizjak
Hello!

It looks that GP relative relocations do not fit anymore into GPREL16
reloc, so bootstrap on alpha hosts fail in stage2 with  "relocation
truncated to fit: GPREL16 against ...". I found no other solution but
to pass --no-relax to linker in order to finish the bootstrap.

2011-05-02  Uros Bizjak  

PR target/47230
* configure.ac (alpha*-*-linux*): Use mh-alpha-linux.
* configure: Regenerate.

config/ChangeLog:

2011-05-02  Uros Bizjak  

PR target/47230
* mh-alpha-linux: New file.

Patch was bootstrapped and regression tested with "GNU ld (GNU
Binutils) 2.21" on alphaev68-pc-linux-gnu [1].

OK for 4.6. and 4.7 ?

[1] http://gcc.gnu.org/ml/gcc-testresults/2011-05/msg00089.html

Uros.
Index: configure.ac
===
--- configure.ac(revision 173233)
+++ configure.ac(working copy)
@@ -1100,6 +1100,9 @@
   *-interix*)
 host_makefile_frag="config/mh-interix"
 ;;
+  alpha*-*-linux*)
+host_makefile_frag="config/mh-alpha-linux"
+;;
   hppa*-hp-hpux10*)
 host_makefile_frag="config/mh-pa-hpux10"
 ;;
Index: configure
===
--- configure   (revision 173233)
+++ configure   (working copy)
@@ -3672,6 +3672,9 @@
   *-interix*)
 host_makefile_frag="config/mh-interix"
 ;;
+  alpha*-*-linux*)
+host_makefile_frag="config/mh-alpha-linux"
+;;
   hppa*-hp-hpux10*)
 host_makefile_frag="config/mh-pa-hpux10"
 ;;
Index: config/mh-alpha-linux
===
--- config/mh-alpha-linux   (revision 0)
+++ config/mh-alpha-linux   (revision 0)
@@ -0,0 +1,3 @@
+# Prevent GPREL16 relocation truncation
+LDFLAGS += -Wl,--no-relax
+BOOT_LDFLAGS += -Wl,--no-relax


Re: [RFC PATCH, go]: Port to ALPHA arch - sysinfo.go fixup

2011-05-02 Thread Uros Bizjak
On Fri, Apr 22, 2011 at 1:39 AM, Ian Lance Taylor  wrote:
> Rainer Orth  writes:
>
>> Here's the error I run into:
>>
>> /vol/gcc/src/hg/trunk/irix/libgo/go/os/file.go:432:12: error: incompatible 
>> types in assignment (implicit assignment of 'syscall.Timeval' hidden field 
>> '_f0')
>> /vol/gcc/src/hg/trunk/irix/libgo/go/os/file.go:433:12: error: incompatible 
>> types in assignment (implicit assignment of 'syscall.Timeval' hidden field 
>> '_f0')
>> /vol/gcc/src/hg/trunk/irix/libgo/go/os/file.go:434:37: error: argument 2 has 
>> incompatible type (implicit assignment of 'syscall.Timeval' hidden field 
>> '_f0')
>> make[8]: *** [os/os.lo] Error 1
>>
>>> What does the line for timeval look like in gen-sysinfo.go?
>>
>> I get
>>
>> type Timeval struct { _f0 int32; Sec Timeval_sec_t; Usec Timeval_usec_t; }
>
> Thanks.  I fixed this problem with this patch.  Bootstrapped and ran Go
> testsuite on x86_64-unknown-linux-gnu.  Committed to mainline.
>
> Ian
>
>
> 2011-04-21  Ian Lance Taylor  
>
>        * godump.c (go_format_type): Use exported Go name for anonymous
>        field name.

This still doesn't fix the build for alpha due to extra struct.  From
sysinfo.go:

type Timespec struct { Sec Timespec_sec_t; Nsec Timespec_nsec_t; }
type Stat_t struct { Dev uint64; Ino uint64; Rdev uint64; Size int64;
Blocks uint64; Mode uint32; Uid uint32; Gid uint32; Blksize uint32;
Nlink uint32; __pad0 int32; Go0 struct { Atime Timespec; }; Go1 struct
{ Mtime Timespec; }; Go2 struct { Ctime Timespec; }; __unused
[2+1]int64; }

Following patch enables the build to proceed:

Index: go/os/stat.go
===
--- go/os/stat.go   (revision 173234)
+++ go/os/stat.go   (working copy)
@@ -23,9 +23,9 @@
fi.Size = int64(stat.Size)
fi.Blksize = int64(stat.Blksize)
fi.Blocks = int64(stat.Blocks)
-   fi.Atime_ns = int64(stat.Atime.Sec)*1e9 + int64(stat.Atime.Nsec)
-   fi.Mtime_ns = int64(stat.Mtime.Sec)*1e9 + int64(stat.Mtime.Nsec)
-   fi.Ctime_ns = int64(stat.Ctime.Sec)*1e9 + int64(stat.Atime.Nsec)
+   fi.Atime_ns = int64(stat.Go0.Atime.Sec)*1e9 + int64(stat.Go0.Atime.Nsec)
+   fi.Mtime_ns = int64(stat.Go1.Mtime.Sec)*1e9 + int64(stat.Go1.Mtime.Nsec)
+   fi.Ctime_ns = int64(stat.Go2.Ctime.Sec)*1e9 + int64(stat.Go2.Ctime.Nsec)
for i := len(name)-1; i >= 0; i-- {
if name[i] == '/' {
name = name[i+1:]

(BTW: Original calculation of Ctime_ns has a cut'n'paste error,
stat.Ctime.Nsec should be used instead of stat.Atime.Nsec).

Is there a solution for this problem?

Uros.


Re: [patch, spu] Fix sched_emit_insn after scheduler changes

2011-05-02 Thread Bernd Schmidt
On 04/27/2011 03:22 PM, Ulrich Weigand wrote:
>   * haifa-sched.c (sched_emit_insn): Emit insn before first
>   non-scheduled insn.  Inform back-end about new insn.  Add
>   new insn to scheduled_insns list.

Seems like this function is only used from spu.c. OK.


Bernd



Re: [wwwdocs] Buildstat update for 4.6

2011-05-02 Thread Gerald Pfeifer
On Sun, 1 May 2011, Tom G. Christensen wrote:
> Latest results for 4.6.x

Thanks, online too, now.

Gerald


Re: [google] Multiple source LIPO test cases and bug fixes (issue4441084)

2011-05-02 Thread Rainer Orth
David,

> 2011-05-01  David Li  
>
>   * testsuite/lib/profopt.exp (proc): Multiple source file support.
 ^

This is wrong, the proc is called profopt-execute.

>   * testsuite/gcc.dg/tree-prof/lipo/lipo.exp (load_lib):
^
>   Multiple source file support.

Wrong again: not inside any proc.  Just omit.

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University


Re: [google] Patch to support calling multi-versioned functions via new GCC builtin. (issue4440078)

2011-05-02 Thread Richard Guenther
On Fri, Apr 29, 2011 at 6:23 PM, Xinliang David Li  wrote:
> Here is the background for this feature:
>
> 1) People relies on function multi-version to explore hw features and
> squeeze performance, but there is no standard ways of doing so, either
> a) using indirect function calls with function pointers set at program
> initialization; b) using manual dispatch at each callsite; b) using
> features like IFUNC.  The dispatch mechanism needs to be promoted to
> the language level and becomes the first class citizen;

You are not doing that, you are inventing a new (crude) GCC extension.

> 2) Most importantly, the above non standard approaches block
> interprocedural optimizations such as inlining. With the introduction
> of buitlin_dispatch and the clear semantics, compiler can do more
> aggressive optimization.

I don't think so, but the previous mail lacked detail on why the new
scheme would be better.

> Multi-way dispatch will be good, but most of the use cases we have
> seen is 2-way -- a fast path + a default path.
>
> Who are the targeted consumer of the feature?
>
> 1) For developers who like to MV function manually;
> 2) For user directed function cloning
>
>   e.g,
>    int foo (...) __attribute__((clone ("sse")):
>
> 3) Automatic function cloning determined by compiler.
>
>
>>
>> I am not sure that combining the function choice and its invocation
>> to a single builtin is good.  First, you use variadic arguments for
>> the actual function arguments which will cause vararg promotions
>> to apply and thus it will be impossible to dispatch to functions
>> taking single precision float values (and dependent on ABI details
>> many more similar issues).  Second, you restrict yourself to
>> only two versions of a function - that looks quite limited and this
>> restriction is not easy to lift with your proposed interface.
>
> See above. Multi-way dispatch can be added similarly.

Not with the specified syntax.  So you'd end up with _two_
language extensions.  That's bad (and unacceptable, IMHO).

>
>>
>> That's a nice idea, but why not simply process all functions with
>> a const attribute and no arguments this way?  IMHO
>>
>> int testsse (void) __attribute__((const));
>>
>> is as good and avoids the new attribute completely.  The pass would
>> also benefit other uses of this idiom (giving a way to have global
>> dynamic initializers in C).  The functions may not be strictly 'const'
>> in a way the compiler autodetects this attribute but it presents
>> exactly the promises to the compiler that allow this optimization.
>>
>> Thus, please split this piece out into a separate patch and use
>> the const attribute.
>
>
> Sounds good.
>
>>
>>>  What happens with cloning, -fclone-hot-version-paths ?
>>>  -
>>
>> Now, here you lost me somewhat, because I didn't look into the
>> patch details and I am missing an example on how the lowered
>> IL looks before that cloning.  So for now I suppose this
>> -fclone-hot-version-paths
>> is to expose direct calls to the IL.  If you would lower __builtin_dispatch
>> to a style like
>>
>>  int sel = selector ();
>>  switch (sel)
>>     {
>>     case 0:
>>       fn = popcnt;
>>      break;
>>     case 1:
>>       fn = popcnt_sse4;
>>       break;
>>     }
>>   res = (*fn) (25);
>>
>> then rather than a new pass specialized for __builtin_dispatch existing
>> optimization passes that are able to do tracing like VRP and DOM
>> via jump-threading or the tracer pass should be able to do this
>> optimization for you.  If they do not use FDO in a good way it is better
>> to improve them for this case instead of writing a new pass.
>
> What you describe may not work
>
> 1) the function selection may happen in a different function;

Well, sure.  I propose to have the above as lowered form.  If people
deliberately obfuscate code it's their fault.  Your scheme simply
makes that obfuscation impossible (or less likely possible).  So
1) is not a valid argument.

> 2) Compiler will need to hoist the selection into the program
> initializer to avoid overhead

?  Isn't that the point of the "const" function call optimization which
I said was a good thing anyway?  So, after that it would be

 int sel = some_global_static;
 ...

> As an example of why dispatch hoisting and call chain cloning is needed:
>
> void foo();
> void bar();
>
> void doit_v1();
> void doit_v2();
> bool check_v () __attribute__((const));
>
> int test();
>
>
> void bar()
> {
>    
>    for (.)
>     {
>         foo();
>         
>     }
> }
>
> void foo()
> {
>   ...
>   for (...)
>   {
>      __builtin_dispatch(check_v, doit_v1, doit_v2,...);
>     ...
>   }
> }
>
>
> int test ()
> {
>    ..
>   bar ();
> }
>
>
> The feature testing and dispatch is embedded in a 2-deep loop nest
> crossing function boundaries. The call paths test --> bar --> foo
> needs to be cloned. This is done by hoisting dispatch up the call
> chain -- it ends up :
>
>
> void bar_v1()

Re: [google] Patch to support calling multi-versioned functions via new GCC builtin. (issue4440078)

2011-05-02 Thread Richard Guenther
On Fri, Apr 29, 2011 at 7:50 PM, Sriraman Tallam  wrote:
>
> On Fri, Apr 29, 2011 at 1:56 AM, Richard Guenther
>  wrote:
>>
>> On Fri, Apr 29, 2011 at 4:52 AM, Sriraman Tallam 
>> wrote:
>> > I want this patch to be considered for google/main now. This is intended
>> > to be submitted to trunk for review soon.
>> > This patch has been tested with crosstool bootstrap using buildit and by
>> > running all tests.
>> >
>> >
>> > Patch Description :
>> > ==
>> >
>> > Frequently executed functions in programs are some times compiled
>> > into different versions to take advantage of some specific
>> > advanced features present in some of the types of platforms on
>> > which the program is executed. For instance, SSE4 versus no-SSE4.
>> > Existing techniques to do multi-versioning, for example using
>> > indirect calls, block compiler optimizations, mainly inlining.
>>
>> The general idea of supporting versioning is good, thanks for working on
>> it.
>> Comments below.
>>
>> > This patch adds a new GCC pass to support multi-versioned calls
>> > through a new builtin, __builtin_dispatch.  The __builtin_dispatch
>> > call is converted into a simple if-then construct to call the
>> > appropriate version at run-time. There are no indirect calls so
>> > inlining is not affected.
>>
>> I am not sure that combining the function choice and its invocation
>> to a single builtin is good.  First, you use variadic arguments for
>> the actual function arguments which will cause vararg promotions
>> to apply and thus it will be impossible to dispatch to functions
>> taking single precision float values (and dependent on ABI details
>> many more similar issues).  Second, you restrict yourself to
>> only two versions of a function - that looks quite limited and this
>> restriction is not easy to lift with your proposed interface.
>>
>> Thus, I would have kept regular (but indirect) calls in the source
>> program and only exposed the dispatch via a builtin, like ...
>>
>> > This patch also supports a function unswitching optimization via
>> > cloning of functions, only along hot paths, that call multi-versioned
>> > functions so that the hot multi-versioned paths can be independently
>> > optimized for performance. The cloning optimization is switched on
>> > via a flag, -fclone-hot-version-paths.
>> >
>> > Only two versions are supported in this patch. Example use :
>> >
>> >  int popcnt_sse4(unsigned int x) __attribute__((__target__("popcnt")));
>> >  int popcnt_sse4(unsigned int x)
>> >  {
>> >    int count = __builtin_popcount(x);
>> >    return count;
>> >  }
>> >
>> >  int popcnt(unsigned int x) __attribute__((__target__("no-popcnt")));
>> >  int popcnt(unsigned int x)
>> >  {
>> >    int count = __builtin_popcount(x);
>> >    return count;
>> >  }
>> >
>> >  int testsse() __attribute__((version_selector));
>> >  int main ()
>> >  {
>> >    ...
>> >    /* The multi-versioned call. */
>> >    ret = __builtin_dispatch (testsse,  (void*)popcnt_sse4,
>> > (void*)popcnt, 25);
>> >    ...
>> >  }
>>
>> int main()
>> {
>>  int (*ppcnt)(unsigned int) = __builtin_dispatch (testsse,
>> popcnt_sse4, popcnt);
>>  ret = (*ppcnt) (25);
>> }
>>
>> which would allow the testsse function to return the argument number of
>> the function to select.
>>
>> [snip]
>>
>> >  When to use the "version_selector" attribute ?
>> >  ---
>> >
>> >  Functions are marked with attribute "version_selector" only if
>> >  they are run-time constants.  Example of such functions would
>> >  be those that test if a specific feature is available on a
>> >  particular architecture.  Such functions must return a positive
>> >  integer. For two-way functions, those that test if a feature
>> >  is present or not must return 1 or 0 respectively.
>> >
>> >  This patch will make constructors that call these function once
>> >  and assign the outcome to a global variable. From then on, only
>> >  the value of the global will be used to decide which version to
>> >  execute.
>>
>> That's a nice idea, but why not simply process all functions with
>> a const attribute and no arguments this way?  IMHO
>>
>> int testsse (void) __attribute__((const));
>>
>> is as good and avoids the new attribute completely.  The pass would
>> also benefit other uses of this idiom (giving a way to have global
>> dynamic initializers in C).  The functions may not be strictly 'const'
>> in a way the compiler autodetects this attribute but it presents
>> exactly the promises to the compiler that allow this optimization.
>
>
> Since, const functions cannot, not according to the definition atleast ,
>  read files or memory, I was thinking along the lines of making it a  "pure"
> function (For example, The version_selector function could be reading
> "/proc/cpuinfo" and looking for certain features).

Well, const functions "can" read files or memory, just its result may not
vary when that memory or files change (or rather the compiler assumes

Ping #1: [Patch,AVR]: Solve PR42210

2011-05-02 Thread Georg-Johann Lay
Georg-Johann Lay schrieb:
> Richard Henderson schrieb:
> 
>> Why are you adding "optimize" to all these insns?  None of them will
>> be matched unless combine is run, which implies optimization.
> 
> Here is a patch without optimize in the insn conditions.
> 
> The optimize condition is still present in the insv expander because I
> do not know what the policy about that is in the avr backend.
> 
> Johann
> 
>> r~
>>
> 
>   PR target/42210
> 
>   * config/avr/predicates.md (const1_operand, const_0_to_7_operand):
>   New predicates.
>   
>   * config/avr/avr.md ("insv"): New insn expander.
>   ("*movbitqi.1-6.a", "*movbitqi.1-6.b", "*movbitqi.0", "*insv.io",
>   "*insv.not.io", "*insv.reg"): New insns.
> 



Re: [PATCH] Fix switch conversion (PR tree-optimization/48809)

2011-05-02 Thread Richard Guenther
On Fri, Apr 29, 2011 at 6:43 PM, Jakub Jelinek  wrote:
> Hi!
>
> The following patch fixes a bug in tree-switch-conversion.c with
> signed index_expr's.  build_arrays would compute index_expr - range_min
> in index_expr's type and use that as index into CSWTCH.N array,
> which is wrong, because in this case index_expr 98 - (-62) computed
> in signed char type results in signed overflow and we end up
> loading from CSWTCH.2[-96].  Apparently for the bounds checking
> we perform the same index_expr - range_min computation, but in
> corresponding unsigned type.  This patch computes it just once in
> unsigned type, so that overflow isn't undefined.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for
> trunk/4.6/4.5/4.4?
>
> 2011-04-29  Jakub Jelinek  
>
>        PR tree-optimization/48809
>        * tree-switch-conversion.c (build_arrays): Compute tidx in unsigned
>        type.
>        (gen_inbound_check): Don't compute index_expr - range_min in utype
>        again, instead reuse SSA_NAME initialized in build_arrays.
>        Remove two useless gsi_for_stmt calls.
>
>        * gcc.c-torture/execute/pr48809.c: New test.
>
> --- gcc/tree-switch-conversion.c.jj     2010-12-02 11:51:32.0 +0100
> +++ gcc/tree-switch-conversion.c        2011-04-29 15:23:57.0 +0200
> @@ -1,6 +1,6 @@
>  /* Switch Conversion converts variable initializations based on switch
>    statements to initializations from a static array.
> -   Copyright (C) 2006, 2008, 2009, 2010 Free Software Foundation, Inc.
> +   Copyright (C) 2006, 2008, 2009, 2010, 2011 Free Software Foundation, Inc.
>    Contributed by Martin Jambor 
>
>  This file is part of GCC.
> @@ -656,7 +656,7 @@ static void
>  build_arrays (gimple swtch)
>  {
>   tree arr_index_type;
> -  tree tidx, sub, tmp;
> +  tree tidx, sub, tmp, utype;
>   gimple stmt;
>   gimple_stmt_iterator gsi;
>   int i;
> @@ -664,14 +664,20 @@ build_arrays (gimple swtch)
>
>   gsi = gsi_for_stmt (swtch);
>
> +  /* Make sure we do not generate arithmetics in a subrange.  */
> +  utype = TREE_TYPE (info.index_expr);
> +  if (TREE_TYPE (utype))
> +    utype = lang_hooks.types.type_for_mode (TYPE_MODE (TREE_TYPE (utype)), 
> 1);
> +  else
> +    utype = lang_hooks.types.type_for_mode (TYPE_MODE (utype), 1);
> +

type_for_mode?  Ick.  What's TREE_TYPE of that char type anyway?

Why not always

  utype = build_nonstandard_integer_type (TYPE_PRECISION (TREE_TYPE
(info.index_expr)), 1);

?

Richard.

>   arr_index_type = build_index_type (info.range_size);
> -  tmp = create_tmp_var (TREE_TYPE (info.index_expr), "csti");
> +  tmp = create_tmp_var (utype, "csui");
>   add_referenced_var (tmp);
>   tidx = make_ssa_name (tmp, NULL);
> -  sub = fold_build2_loc (loc, MINUS_EXPR,
> -                    TREE_TYPE (info.index_expr), info.index_expr,
> -                    fold_convert_loc (loc, TREE_TYPE (info.index_expr),
> -                                      info.range_min));
> +  sub = fold_build2_loc (loc, MINUS_EXPR, utype,
> +                        fold_convert_loc (loc, utype, info.index_expr),
> +                        fold_convert_loc (loc, utype, info.range_min));
>   sub = force_gimple_operand_gsi (&gsi, sub,
>                                  false, NULL, true, GSI_SAME_STMT);
>   stmt = gimple_build_assign (tidx, sub);
> @@ -780,12 +786,7 @@ gen_inbound_check (gimple swtch)
>   tree label_decl2 = create_artificial_label (UNKNOWN_LOCATION);
>   tree label_decl3 = create_artificial_label (UNKNOWN_LOCATION);
>   gimple label1, label2, label3;
> -
> -  tree utype;
> -  tree tmp_u_1, tmp_u_2, tmp_u_var;
> -  tree cast;
> -  gimple cast_assign, minus_assign;
> -  tree ulb, minus;
> +  tree utype, tidx;
>   tree bound;
>
>   gimple cond_stmt;
> @@ -799,49 +800,24 @@ gen_inbound_check (gimple swtch)
>   gcc_assert (info.default_values);
>   bb0 = gimple_bb (swtch);
>
> -  /* Make sure we do not generate arithmetics in a subrange.  */
> -  if (TREE_TYPE (TREE_TYPE (info.index_expr)))
> -    utype = lang_hooks.types.type_for_mode
> -      (TYPE_MODE (TREE_TYPE (TREE_TYPE (info.index_expr))), 1);
> -  else
> -    utype = lang_hooks.types.type_for_mode
> -      (TYPE_MODE (TREE_TYPE (info.index_expr)), 1);
> +  tidx = gimple_assign_lhs (info.arr_ref_first);
> +  utype = TREE_TYPE (tidx);
>
>   /* (end of) block 0 */
>   gsi = gsi_for_stmt (info.arr_ref_first);
> -  tmp_u_var = create_tmp_var (utype, "csui");
> -  add_referenced_var (tmp_u_var);
> -  tmp_u_1 = make_ssa_name (tmp_u_var, NULL);
> -
> -  cast = fold_convert_loc (loc, utype, info.index_expr);
> -  cast_assign = gimple_build_assign (tmp_u_1, cast);
> -  SSA_NAME_DEF_STMT (tmp_u_1) = cast_assign;
> -  gsi_insert_before (&gsi, cast_assign, GSI_SAME_STMT);
> -  update_stmt (cast_assign);
> -
> -  ulb = fold_convert_loc (loc, utype, info.range_min);
> -  minus = fold_build2_loc (loc, MINUS_EXPR, utype, tmp_u_1, ulb);
> -  minus = force_gimple_operand_gsi (&gsi, minus, false, NULL, true,
> -                                   

Re: [RFT][patch] Fix PR testsuite/48498

2011-05-02 Thread Richard Guenther
On Sun, May 1, 2011 at 9:31 AM, Ira Rosen  wrote:
>
>
> gcc-patches-ow...@gcc.gnu.org wrote on 20/04/2011 02:24:55 PM:
>
>>
>> Hi,
>>
>> In gcc.dg/vect/slp-3.c and gcc.dg/vect/no-vfa-pr29145.c vectorization is
>> expected to fail on targets vect_no_align. But no realignment is
> necessary
>> here except for having the array bases aligned. This patch removes xfail
>> for vect_no_align (and increases a loop bound in slp-3.c to prevent
>> complete unrolling).  It is supposed to fix the XPASSes on SPARC, I also
>> checked it with a cross-compiler on ia64-linux-gnu, and tested on
>> x86_64-suse-linux.
>>
>> vect_no_align is true for
>>
>>         if { [istarget mipsisa64*-*-*]
>>              || [istarget sparc*-*-*]
>>              || [istarget ia64-*-*]
>>              || [check_effective_target_arm_vect_no_misalign]
>>              || ([istarget mips*-*-*]
>>                  && [check_effective_target_mips_loongson]) } {
>>             set et_vect_no_align_saved 1
>>         }
>>
>> so I'd appreciate testing on these targets.
>
> Was tested by Rainer on SPARC.
>
> OK to apply?

Ok.

Thanks,
Richard.

> Thanks,
> Ira
>
>>
>> Thanks,
>> Ira
>>
>> testsuite/ChangeLog
>>
>>    PR testsuite/48498
>>      * gcc.dg/vect/slp-3.c: Increase loop bound. Don't expect to fail
>>    on vect_no_align targets.
>>    * gcc.dg/vect/no-vfa-pr29145.c: Don't expect to fail on
>>    vect_no_align targets.
>>
>> Index: testsuite/gcc.dg/vect/slp-3.c
>> ===
>> --- testsuite/gcc.dg/vect/slp-3.c       (revision 172765)
>> +++ testsuite/gcc.dg/vect/slp-3.c       (working copy)
>> @@ -4,9 +4,9 @@
>>  #include 
>>  #include "tree-vect.h"
>>
>> -#define N 8
>> +#define N 12
>>
>> -unsigned short in[N*8] =
>> {0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,
>> 25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,
>> 47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63};
>> +unsigned short in[N*8] =
>> {0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,
>> 25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,
>> 47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,0,1,2,3,4,5,6,7,
>> 8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31};
>>
>>  int
>>  main1 ()
>> @@ -142,7 +142,7 @@
>>    return 0;
>>  }
>>
>> -/* { dg-final { scan-tree-dump-times "vectorized 3 loops" 1
> "vect" { xfail
>> vect_no_align } } } */
>> -/* { dg-final { scan-tree-dump-times "vectorizing stmts using SLP" 3
>> "vect" { xfail vect_no_align } } } */
>> +/* { dg-final { scan-tree-dump-times "vectorized 3 loops" 1 "vect" } }
> */
>> +/* { dg-final { scan-tree-dump-times "vectorizing stmts using SLP" 3
>> "vect" } } */
>>  /* { dg-final { cleanup-tree-dump "vect" } } */
>>
>> Index: testsuite/gcc.dg/vect/no-vfa-pr29145.c
>> ===
>> --- testsuite/gcc.dg/vect/no-vfa-pr29145.c      (revision 172765)
>> +++ testsuite/gcc.dg/vect/no-vfa-pr29145.c      (working copy)
>> @@ -48,6 +48,6 @@
>>    return 0;
>>  }
>>
>> -/* { dg-final { scan-tree-dump-times "vectorized 0 loops" 2
>> "vect"  { xfail vect_no_align } } } */
>> -/* { dg-final { scan-tree-dump-times "vectorized 1 loops" 1
>> "vect"  { xfail vect_no_align } } } */
>> +/* { dg-final { scan-tree-dump-times "vectorized 0 loops" 2 "vect" } }
> */
>> +/* { dg-final { scan-tree-dump-times "vectorized 1 loops" 1 "vect" } }
> */
>>  /* { dg-final { cleanup-tree-dump "vect" } } */
>>
>
>


Re: [patch] gcse.c ls_expr: remove 'loads field

2011-05-02 Thread Richard Guenther
On Sun, May 1, 2011 at 12:52 PM, Steven Bosscher  wrote:
> Hi,
>
> I noticed that this field is write-only. The last use was for store
> motion, which overloaded this 'loads' field with ANTIC_STORE_LIST. I
> went back as far as gcc 3.3.6 but couldn't figure out what the field
> is supposed to do for load motion. So this patch simply removes the
> field.
>
> Makes Nathan's EXPR_LIST/INSN_LIST a bit easier, too :-)
>
> Bootstrapped&tested on x86_64-unknown-linux-gnu. OK for trunk?

Ok.

Thanks,
Richard.

> Ciao!
> Steven
>
>
>
>        * gcse.c (struct ls_expr): Remove 'loads' member.
>        (ldst_entry): Don't initialize it.
>        (free_ldst_entry): Don't free it.
>        (print_ldst_list): Don't dump it.
>        (compute_ld_motion_mems): Don't allocate it.
>
> Index: gcse.c
> ===
> --- gcse.c      (revision 173214)
> +++ gcse.c      (working copy)
> @@ -360,7 +360,6 @@ struct ls_expr
>   struct expr * expr;          /* Gcse expression reference for LM.  */
>   rtx pattern;                 /* Pattern of this mem.  */
>   rtx pattern_regs;            /* List of registers mentioned by the mem.  */
> -  rtx loads;                   /* INSN list of loads seen.  */
>   rtx stores;                  /* INSN list of stores seen.  */
>   struct ls_expr * next;       /* Next in the list.  */
>   int invalid;                 /* Invalid for some reason.  */
> @@ -3300,7 +3299,6 @@ ldst_entry (rtx x)
>   ptr->expr         = NULL;
>   ptr->pattern      = x;
>   ptr->pattern_regs = NULL_RTX;
> -  ptr->loads        = NULL_RTX;
>   ptr->stores       = NULL_RTX;
>   ptr->reaching_reg = NULL_RTX;
>   ptr->invalid      = 0;
> @@ -3317,7 +3315,6 @@ ldst_entry (rtx x)
>  static void
>  free_ldst_entry (struct ls_expr * ptr)
>  {
> -  free_INSN_LIST_list (& ptr->loads);
>   free_INSN_LIST_list (& ptr->stores);
>
>   free (ptr);
> @@ -3359,13 +3356,6 @@ print_ldst_list (FILE * file)
>
>       print_rtl (file, ptr->pattern);
>
> -      fprintf (file, "\n        Loads : ");
> -
> -      if (ptr->loads)
> -       print_rtl (file, ptr->loads);
> -      else
> -       fprintf (file, "(nil)");
> -
>       fprintf (file, "\n       Stores : ");
>
>       if (ptr->stores)
> @@ -3517,9 +3507,7 @@ compute_ld_motion_mems (void)
>                  if (MEM_P (src) && simple_mem (src))
>                    {
>                      ptr = ldst_entry (src);
> -                     if (REG_P (dest))
> -                       ptr->loads = alloc_INSN_LIST (insn, ptr->loads);
> -                     else
> +                     if (! REG_P (dest))
>                        ptr->invalid = 1;
>                    }
>                  else
>


[C++ Patch] PR 47969

2011-05-02 Thread Paolo Carlini

Hi,

we have this simple issue where we ICE because we don't check the return 
value of build_expr_type_conversion for NULL_TREE, at variance with all 
its other uses elsewhere.


The fix seems also simple, we have already logic for emitting an error 
message (or just returning error_mark_node depending on complain) in 
case of non-integral size of the array, only, a bit later. Thus my fix, 
adding a goto. If we don't like that, we could do the below, which just 
duplicated the logic. All in all, barring completely different 
solutions, which I don't see at the moment, the goto seems to me a tad 
better.


Tested x86_64-linux.

Ok for mainline?

Paolo.

/

Index: cp/decl.c
===
--- cp/decl.c(revision 173242)
+++ cp/decl.c(working copy)
@@ -7609,6 +7609,17 @@ compute_array_index_type (tree name, tree size, ts
&& CLASSTYPE_LITERAL_P (type))
 {
   size = build_expr_type_conversion (WANT_INT, size, true);
+  if (!size)
+{
+  if (!(complain & tf_error))
+return error_mark_node;
+  if (name)
+error ("size of array %qD has non-integral type %qT",
+   name, type);
+  else
+error ("size of array has non-integral type %qT", type);
+  size = integer_one_node;
+}
   if (size == error_mark_node)
 return error_mark_node;
   type = TREE_TYPE (size);

/cp
2011-05-02  Paolo Carlini  

PR c++/47969
* decl.c (compute_array_index_type): Check build_expr_type_conversion
return value for NULL_TREE.

/testsuite
2011-05-02  Paolo Carlini  

PR c++/47969
* g++.dg/cpp0x/constexpr-47969.C: New.

Index: testsuite/g++.dg/cpp0x/constexpr-47969.C
===
--- testsuite/g++.dg/cpp0x/constexpr-47969.C(revision 0)
+++ testsuite/g++.dg/cpp0x/constexpr-47969.C(revision 0)
@@ -0,0 +1,11 @@
+// PR c++/47969
+// { dg-options -std=c++0x }
+
+struct A
+{
+  // constexpr operator int () { return 1; }
+};
+
+constexpr A a = A();
+
+int ar[a]; // { dg-error "has non-integral type" }
Index: cp/decl.c
===
--- cp/decl.c   (revision 173242)
+++ cp/decl.c   (working copy)
@@ -7609,6 +7609,8 @@ compute_array_index_type (tree name, tree size, ts
  && CLASSTYPE_LITERAL_P (type))
{
  size = build_expr_type_conversion (WANT_INT, size, true);
+ if (!size)
+   goto error;
  if (size == error_mark_node)
return error_mark_node;
  type = TREE_TYPE (size);
@@ -7625,6 +7627,7 @@ compute_array_index_type (tree name, tree size, ts
   if (error_operand_p (size))
return error_mark_node;
 
+error:
   /* The array bound must be an integer type.  */
   if (!INTEGRAL_OR_UNSCOPED_ENUMERATION_TYPE_P (type))
{


Re: [PATCH] Fix PR c/35445: ICE with conflicting declarations

2011-05-02 Thread Joseph S. Myers
On Mon, 2 May 2011, Simon Martin wrote:

> 2011-05-01  Simon Martin  
> 
> PR c/35445
> * c-decl.c (finish_decl): Only create a composite if the types are
> compatible.
> 
> 2011-05-01  Simon Martin  
> 
> PR c/35445
> * gcc.dg/pr35445.c: New test.

OK.

-- 
Joseph S. Myers
jos...@codesourcery.com


Re: [doc] Adjust reference to ACATS in sourcebuild.texi

2011-05-02 Thread Gerald Pfeifer
On Tue, 26 Apr 2011, Rainer Orth wrote:
>>  * doc/sourcebuild.texi (Ada Tests): Adjust reference to ACATS
>>  testsuite and make it version agnostic.
> I doubt this is a good idea: while you can find out what version of
> ACATS is included in GCC, the information is somewhat hard to find
> (gcc/testsuite/ada/acats/support/acats25.lst) and what update has been
> used cannot be easily determined at all.  I'd keep the version
> reference.  Arnaud?

I'll be happy to add the concrete version number if Arnaud prefers.

Gerald


[PATCH] Keep individual tree code stats

2011-05-02 Thread Richard Guenther

This patch makes us count individual tree codes instead of globbing
them only.

Bootstrapped on x86_64-unknown-linux-gnu, installed.

Richard.

2011-05-02  Richard Guenther  

* tree.c (tree_code_counts): New global array.
(record_node_allocation_statistics): Count individual tree codes.
(dump_tree_statistics): Dump individual code stats.

Index: gcc/tree.c
===
*** gcc/tree.c.orig 2011-04-29 12:59:38.0 +0200
--- gcc/tree.c  2011-05-02 12:36:41.0 +0200
*** extern int _obstack_allocated_p (struct
*** 124,129 
--- 124,130 
  #ifdef GATHER_STATISTICS
  /* Statistics-gathering stuff.  */
  
+ static int tree_code_counts[MAX_TREE_CODES];
  int tree_node_counts[(int) all_kinds];
  int tree_node_sizes[(int) all_kinds];
  
*** record_node_allocation_statistics (enum
*** 809,814 
--- 810,816 
gcc_unreachable ();
  }
  
+   tree_code_counts[(int) code]++;
tree_node_counts[(int) kind]++;
tree_node_sizes[(int) kind] += length;
  #endif
*** type_hash_canon (unsigned int hashcode,
*** 6196,6201 
--- 6198,6204 
if (t1 != 0)
  {
  #ifdef GATHER_STATISTICS
+   tree_code_counts[(int) TREE_CODE (type)]--;
tree_node_counts[(int) t_kind]--;
tree_node_sizes[(int) t_kind] -= sizeof (struct tree_type);
  #endif
*** dump_tree_statistics (void)
*** 8505,8510 
--- 8508,8518 
fprintf (stderr, "---\n");
fprintf (stderr, "%-20s %7d %10d\n", "Total", total_nodes, total_bytes);
fprintf (stderr, "---\n");
+   fprintf (stderr, "Code   Nodes\n");
+   fprintf (stderr, "\n");
+   for (i = 0; i < (int) MAX_TREE_CODES; i++)
+ fprintf (stderr, "%-20s %7d\n", tree_code_name[i], tree_code_counts[i]);
+   fprintf (stderr, "\n");
ssanames_print_statistics ();
phinodes_print_statistics ();
  #else


Turn LTO byte i/o functions inline

2011-05-02 Thread Jan Hubicka
Hi,
lto_input_1_unsigned and lto_output_1_stream are the most frequently called 
functions
during the WPA stage.  Obviously these are simple accesors that should be 
inline.
Note that even with LTO bootstrap these won't get inlined unless we declare them
inline or use -O3 or FDO.

Bootstrapped/regtested x86_64-linux, OK?

Honza

* lto-section-in.c (lto_input_1_unsigned): Move to lto-streamer.h
(lto_section_overrun): New.
* lto-section-out.c (append_block): Rename to ...
(lto_append_block): ... this one; export.
(lto_output_1_stream): Move lto lto-streamer.h
(lto_output_data_stream): Update.
* lto-streamer.h (lto_section_overrun, lto_append_block): Declare.
(lto_output_1_stream, lto_input_1_unsigned): Turn into inline
functions.

Index: lto-section-in.c
===
*** lto-section-in.c(revision 173234)
--- lto-section-in.c(working copy)
*** const char *lto_section_name[LTO_N_SECTI
*** 62,77 
"inline"
  };
  
- unsigned char
- lto_input_1_unsigned (struct lto_input_block *ib)
- {
-   if (ib->p >= ib->len)
- internal_error ("bytecode stream: trying to read %d bytes "
-   "after the end of the input buffer", ib->p - ib->len);
- 
-   return (ib->data[ib->p++]);
- }
- 
  
  /* Read an ULEB128 Number of IB.  */
  
--- 62,67 
*** lto_get_function_in_decl_state (struct l
*** 486,488 
--- 476,488 
slot = htab_find_slot (file_data->function_decl_states, &temp, NO_INSERT);
return slot? ((struct lto_in_decl_state*) *slot) : NULL;
  }
+ 
+ 
+ /* Report read pass end of the section.  */
+ 
+ void
+ lto_section_overrun (struct lto_input_block *ib)
+ {
+   internal_error ("bytecode stream: trying to read %d bytes "
+ "after the end of the input buffer", ib->p - ib->len);
+ }
Index: lto-section-out.c
===
*** lto-section-out.c   (revision 173234)
--- lto-section-out.c   (working copy)
*** lto_write_stream (struct lto_output_stre
*** 194,201 
  
  /* Adds a new block to output stream OBS.  */
  
! static void
! append_block (struct lto_output_stream *obs)
  {
struct lto_char_ptr_base *new_block;
  
--- 194,201 
  
  /* Adds a new block to output stream OBS.  */
  
! void
! lto_append_block (struct lto_output_stream *obs)
  {
struct lto_char_ptr_base *new_block;
  
*** append_block (struct lto_output_stream *
*** 234,256 
  }
  
  
- /* Write a character to the output block.  */
- 
- void
- lto_output_1_stream (struct lto_output_stream *obs, char c)
- {
-   /* No space left.  */
-   if (obs->left_in_block == 0)
- append_block (obs);
- 
-   /* Write the actual character.  */
-   *obs->current_pointer = c;
-   obs->current_pointer++;
-   obs->total_size++;
-   obs->left_in_block--;
- }
- 
- 
  /* Write raw DATA of length LEN to the output block OB.  */
  
  void
--- 234,239 
*** lto_output_data_stream (struct lto_outpu
*** 263,269 
  
/* No space left.  */
if (obs->left_in_block == 0)
!   append_block (obs);
  
/* Determine how many bytes to copy in this loop.  */
if (len <= obs->left_in_block)
--- 246,252 
  
/* No space left.  */
if (obs->left_in_block == 0)
!   lto_append_block (obs);
  
/* Determine how many bytes to copy in this loop.  */
if (len <= obs->left_in_block)
Index: lto-streamer.h
===
*** lto-streamer.h  (revision 173234)
--- lto-streamer.h  (working copy)
*** extern const char *lto_get_section_data 
*** 758,764 
  extern void lto_free_section_data (struct lto_file_decl_data *,
   enum lto_section_type,
   const char *, const char *, size_t);
- extern unsigned char lto_input_1_unsigned (struct lto_input_block *);
  extern unsigned HOST_WIDE_INT lto_input_uleb128 (struct lto_input_block *);
  extern unsigned HOST_WIDEST_INT lto_input_widest_uint_uleb128 (
struct lto_input_block *);
--- 758,763 
*** extern hashval_t lto_hash_in_decl_state 
*** 774,779 
--- 773,779 
  extern int lto_eq_in_decl_state (const void *, const void *);
  extern struct lto_in_decl_state *lto_get_function_in_decl_state (
  struct lto_file_decl_data *, tree);
+ extern void lto_section_overrun (struct lto_input_block *) ATTRIBUTE_NORETURN;
  
  /* In lto-section-out.c  */
  extern hashval_t lto_hash_decl_slot_node (const void *);
*** extern int lto_eq_type_slot_node (const 
*** 783,789 
  extern void lto_begin_section (const char *, bool);
  extern void lto_end_section (void);
  extern void lto_write_stream (struct lto_output_stream *);
- extern void

Re: [doc] Adjust reference to ACATS in sourcebuild.texi

2011-05-02 Thread Arnaud Charlet
> >>* doc/sourcebuild.texi (Ada Tests): Adjust reference to ACATS
> >>testsuite and make it version agnostic.
> > I doubt this is a good idea: while you can find out what version of
> > ACATS is included in GCC, the information is somewhat hard to find
> > (gcc/testsuite/ada/acats/support/acats25.lst) and what update has
> > been
> > used cannot be easily determined at all.  I'd keep the version
> > reference.  Arnaud?
> 
> I'll be happy to add the concrete version number if Arnaud prefers.

I'd even go further and clarify that the tests represent "a modified subset of
executable tests from the ACATS 2.5 testsuite", to make it clear that these
have no "official" status and do not correspond to the original tests
exactly.

Arno


Re: [doc] Adjust reference to ACATS in sourcebuild.texi

2011-05-02 Thread Rainer Orth
Arnaud Charlet  writes:

>> I'll be happy to add the concrete version number if Arnaud prefers.
>
> I'd even go further and clarify that the tests represent "a modified subset of
> executable tests from the ACATS 2.5 testsuite", to make it clear that these
> have no "official" status and do not correspond to the original tests
> exactly.

It would be good (though probably not in sourcebuild.texi) to describe
the modifications.  I noticed some when trying to identify the exact
version of upstream ACATS 2.5 that is included, and this info would help
for a move to 3.0 in the future.

Thanks.
Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University


Re: [doc] Adjust reference to ACATS in sourcebuild.texi

2011-05-02 Thread Arnaud Charlet
> It would be good (though probably not in sourcebuild.texi) to describe
> the modifications.  I noticed some when trying to identify the exact
> version of upstream ACATS 2.5 that is included, and this info would help
> for a move to 3.0 in the future.

You can use svn log and svn diff for that.


Re: Turn LTO byte i/o functions inline

2011-05-02 Thread Richard Guenther
On Mon, 2 May 2011, Jan Hubicka wrote:

> Hi,
> lto_input_1_unsigned and lto_output_1_stream are the most frequently called 
> functions
> during the WPA stage.  Obviously these are simple accesors that should be 
> inline.
> Note that even with LTO bootstrap these won't get inlined unless we declare 
> them
> inline or use -O3 or FDO.
> 
> Bootstrapped/regtested x86_64-linux, OK?

Ok.

Thanks,
Richard.

> Honza
> 
>   * lto-section-in.c (lto_input_1_unsigned): Move to lto-streamer.h
>   (lto_section_overrun): New.
>   * lto-section-out.c (append_block): Rename to ...
>   (lto_append_block): ... this one; export.
>   (lto_output_1_stream): Move lto lto-streamer.h
>   (lto_output_data_stream): Update.
>   * lto-streamer.h (lto_section_overrun, lto_append_block): Declare.
>   (lto_output_1_stream, lto_input_1_unsigned): Turn into inline
>   functions.
> 
> Index: lto-section-in.c
> ===
> *** lto-section-in.c  (revision 173234)
> --- lto-section-in.c  (working copy)
> *** const char *lto_section_name[LTO_N_SECTI
> *** 62,77 
> "inline"
>   };
>   
> - unsigned char
> - lto_input_1_unsigned (struct lto_input_block *ib)
> - {
> -   if (ib->p >= ib->len)
> - internal_error ("bytecode stream: trying to read %d bytes "
> - "after the end of the input buffer", ib->p - ib->len);
> - 
> -   return (ib->data[ib->p++]);
> - }
> - 
>   
>   /* Read an ULEB128 Number of IB.  */
>   
> --- 62,67 
> *** lto_get_function_in_decl_state (struct l
> *** 486,488 
> --- 476,488 
> slot = htab_find_slot (file_data->function_decl_states, &temp, NO_INSERT);
> return slot? ((struct lto_in_decl_state*) *slot) : NULL;
>   }
> + 
> + 
> + /* Report read pass end of the section.  */
> + 
> + void
> + lto_section_overrun (struct lto_input_block *ib)
> + {
> +   internal_error ("bytecode stream: trying to read %d bytes "
> +   "after the end of the input buffer", ib->p - ib->len);
> + }
> Index: lto-section-out.c
> ===
> *** lto-section-out.c (revision 173234)
> --- lto-section-out.c (working copy)
> *** lto_write_stream (struct lto_output_stre
> *** 194,201 
>   
>   /* Adds a new block to output stream OBS.  */
>   
> ! static void
> ! append_block (struct lto_output_stream *obs)
>   {
> struct lto_char_ptr_base *new_block;
>   
> --- 194,201 
>   
>   /* Adds a new block to output stream OBS.  */
>   
> ! void
> ! lto_append_block (struct lto_output_stream *obs)
>   {
> struct lto_char_ptr_base *new_block;
>   
> *** append_block (struct lto_output_stream *
> *** 234,256 
>   }
>   
>   
> - /* Write a character to the output block.  */
> - 
> - void
> - lto_output_1_stream (struct lto_output_stream *obs, char c)
> - {
> -   /* No space left.  */
> -   if (obs->left_in_block == 0)
> - append_block (obs);
> - 
> -   /* Write the actual character.  */
> -   *obs->current_pointer = c;
> -   obs->current_pointer++;
> -   obs->total_size++;
> -   obs->left_in_block--;
> - }
> - 
> - 
>   /* Write raw DATA of length LEN to the output block OB.  */
>   
>   void
> --- 234,239 
> *** lto_output_data_stream (struct lto_outpu
> *** 263,269 
>   
> /* No space left.  */
> if (obs->left_in_block == 0)
> ! append_block (obs);
>   
> /* Determine how many bytes to copy in this loop.  */
> if (len <= obs->left_in_block)
> --- 246,252 
>   
> /* No space left.  */
> if (obs->left_in_block == 0)
> ! lto_append_block (obs);
>   
> /* Determine how many bytes to copy in this loop.  */
> if (len <= obs->left_in_block)
> Index: lto-streamer.h
> ===
> *** lto-streamer.h(revision 173234)
> --- lto-streamer.h(working copy)
> *** extern const char *lto_get_section_data 
> *** 758,764 
>   extern void lto_free_section_data (struct lto_file_decl_data *,
>  enum lto_section_type,
>  const char *, const char *, size_t);
> - extern unsigned char lto_input_1_unsigned (struct lto_input_block *);
>   extern unsigned HOST_WIDE_INT lto_input_uleb128 (struct lto_input_block *);
>   extern unsigned HOST_WIDEST_INT lto_input_widest_uint_uleb128 (
>   struct lto_input_block *);
> --- 758,763 
> *** extern hashval_t lto_hash_in_decl_state 
> *** 774,779 
> --- 773,779 
>   extern int lto_eq_in_decl_state (const void *, const void *);
>   extern struct lto_in_decl_state *lto_get_function_in_decl_state (
> struct lto_file_decl_data *, tree);
> + extern void lto_section_overrun (struct lto_input_block *) 
> ATTRIBUTE_NORETURN;
>   
>   /* In 

Re: [C++ Patch] PR 47969

2011-05-02 Thread Jason Merrill

The goto variant is OK.

Jason


Re: [doc] Adjust reference to ACATS in sourcebuild.texi

2011-05-02 Thread Rainer Orth
Arnaud Charlet  writes:

>> It would be good (though probably not in sourcebuild.texi) to describe
>> the modifications.  I noticed some when trying to identify the exact
>> version of upstream ACATS 2.5 that is included, and this info would help
>> for a move to 3.0 in the future.
>
> You can use svn log and svn diff for that.

Only for the `what', but often they don't explain the `why'.

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University


Trivial patch to fix build with --enable-build-with-cxx

2011-05-02 Thread Dmitry Gorbachev
../../gcc-4.7/gcc/tree-inline.c: In function 'tree_node*
maybe_inline_call_in_expr(tree)':
../../gcc-4.7/gcc/tree-inline.c:5229:40: error: converting 'false' to
pointer type 'void (*)(tree)' [-Werror=conversion-null]

2011-05-02  Dmitry Gorbachev  

* tree-inline.c (maybe_inline_call_in_expr): Replace false by NULL.

--- gcc/tree-inline.c
+++ gcc/tree-inline.c
@@ -5226,7 +5226,7 @@
   id.transform_call_graph_edges = CB_CGE_DUPLICATE;
   id.transform_new_cfg = false;
   id.transform_return_to_modify = true;
-  id.transform_lang_insert_block = false;
+  id.transform_lang_insert_block = NULL;

   /* Make sure not to unshare trees behind the front-end's back
 since front-end specific mechanisms may rely on sharing.  */


Re: Trivial patch to fix build with --enable-build-with-cxx

2011-05-02 Thread Diego Novillo
On Mon, May 2, 2011 at 08:52, Dmitry Gorbachev  wrote:
> ../../gcc-4.7/gcc/tree-inline.c: In function 'tree_node*
> maybe_inline_call_in_expr(tree)':
> ../../gcc-4.7/gcc/tree-inline.c:5229:40: error: converting 'false' to
> pointer type 'void (*)(tree)' [-Werror=conversion-null]
>
> 2011-05-02  Dmitry Gorbachev  
>
>        * tree-inline.c (maybe_inline_call_in_expr): Replace false by NULL.

OK.


Diego.


Re: building binutils from same directory as gcc (was: Re: xgcc does not find gcc-4.6.0-go/./binutils/ar (because it is gcc-4.6.0-go/./binutils/binutils/ar))

2011-05-02 Thread Steffen Dettmer
On Sat, Apr 30, 2011 at 12:38 PM, Jonathan Wakely  wrote:
>> I tried to express this in this form:
>> --- gcc-4.6.0.dist/gcc/doc/install.texi 2011-03-21 13:13:26.0 +0100
>> +++ gcc-4.6.0/gcc/doc/install.texi      2011-04-28 15:59:53.0 +0200
>> +via SVN, it is reliable. Unpacking into the same directory means
>> +that the contents of the (versionized) directories of binutils
>
> versionized?

Thank you, "versioned" seems to be the word I was looking for.

>> What should I do now, mail to gcc-patches?
>
> Yes, patches should always be sent there for discussion and review.

ok, so I Cc:.



* http://gcc.gnu.org/contribute.html:
> Legal Prerequisites

None ("Small changes can be accepted without a copyright
disclaimer or a copyright assignment on file")

> A description of the problem/bug and how your patch addresses it.

Users of release tarballs could get confused how to build
binutils and gcc and accidently attempt an undesired "combined
build". The patch adds some explaining words.

> Testcases

None. I don't know whether to add a doc test and how to do so.

> ChangeLog

2011-05-02 Steffen Dettmer 

* doc/install.texi (Downloading the Source): Recommended
not to build binutils in combined mode when using release
tarballs.

(to be replaced this by a correct one if an improvement based on
the proposal in form of my patch is considered for a commit)

> Bootstrapping and testing

This change was not tested at all.

> The patch itself

--- gcc-4.6.0.dist/gcc/doc/install.texi 2011-03-21 13:13:26.0 +0100
+++ gcc-4.6.0/gcc/doc/install.texi  2011-05-02 14:39:01.0 +0200
@@ -553,7 +553,17 @@
 If you also intend to build binutils (either to upgrade an existing
 installation or for use in place of the corresponding tools of your
 OS), unpack the binutils distribution either in the same directory or
-a separate one.  In the latter case, add symbolic links to any
+a separate one. Using the same directory is not recommended for
+building release tarballs of gcc, but if you obtained the sources
+via SVN, it is reliable. Unpacking into the same directory means
+that the contents of the (versioned) directories of binutils
+and gcc are in one and the same directory (with subdirectories
+like @file{gcc}, @file{binutils} and @file{gas}). Contents of the
+directories common to and shared by gcc and binutils
+(@file{include}, @file{libiberty} and @file{intl}) must be
+compatible, making combined builds using standard releases hard
+to get right.  In case you are using separate directories, which
+is recommended, add symbolic links to any
 components of the binutils you intend to build alongside the compiler
 (@file{bfd}, @file{binutils}, @file{gas}, @file{gprof}, @file{ld},
 @file{opcodes}, @dots{}) to the directory containing the GCC sources.


gcc-4_6_0_gcc_doc_install.texi.diff
Description: Binary data


[PATCH] Fix PR48822

2011-05-02 Thread Richard Guenther

This fixes PR48822, an issue we ran into the past as well.  The problem
is that due to various reasons (mostly simplification of expressions)
we might be tempted to go up the lattice (from VARYING to some constant)
during value-numbering.  This is of course a recipie to oscillation
as can be seen in the testcase (we do fold 0 % a to zero but won't
touch 0 % 0).

Thus, simply never do that.

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

Richard.

2011-05-02  Richard Guenther  

PR tree-optimization/48822
* tree-ssa-sccvn.c (set_ssa_val_to): Never go up the lattice.
(process_scc): Indicate which iteration we start.

* gcc.dg/torture/pr48822.c: New testcase.

Index: gcc/tree-ssa-sccvn.c
===
*** gcc/tree-ssa-sccvn.c(revision 173243)
--- gcc/tree-ssa-sccvn.c(working copy)
*** print_scc (FILE *out, VEC (tree, heap) *
*** 2241,2252 
  static inline bool
  set_ssa_val_to (tree from, tree to)
  {
!   tree currval;
  
!   if (from != to
!   && TREE_CODE (to) == SSA_NAME
!   && SSA_NAME_OCCURS_IN_ABNORMAL_PHI (to))
! to = from;
  
/* The only thing we allow as value numbers are VN_TOP, ssa_names
   and invariants.  So assert that here.  */
--- 2241,2266 
  static inline bool
  set_ssa_val_to (tree from, tree to)
  {
!   tree currval = SSA_VAL (from);
  
!   if (from != to)
! {
!   if (currval == from)
!   {
! if (dump_file && (dump_flags & TDF_DETAILS))
!   {
! fprintf (dump_file, "Not changing value number of ");
! print_generic_expr (dump_file, from, 0);
! fprintf (dump_file, " from VARYING to ");
! print_generic_expr (dump_file, to, 0);
! fprintf (dump_file, "\n");
!   }
! return false;
!   }
!   else if (TREE_CODE (to) == SSA_NAME
!  && SSA_NAME_OCCURS_IN_ABNORMAL_PHI (to))
!   to = from;
! }
  
/* The only thing we allow as value numbers are VN_TOP, ssa_names
   and invariants.  So assert that here.  */
*** set_ssa_val_to (tree from, tree to)
*** 2263,2270 
print_generic_expr (dump_file, to, 0);
  }
  
-   currval = SSA_VAL (from);
- 
if (currval != to  && !operand_equal_p (currval, to, OEP_PURE_SAME))
  {
VN_INFO (from)->valnum = to;
--- 2277,2282 
*** process_scc (VEC (tree, heap) *scc)
*** 3280,3285 
--- 3292,3299 
  {
changed = false;
iterations++;
+   if (dump_file && (dump_flags & TDF_DETAILS))
+   fprintf (dump_file, "Starting iteration %d\n", iterations);
/* As we are value-numbering optimistically we have to
 clear the expression tables and the simplified expressions
 in each iteration until we converge.  */
Index: gcc/testsuite/gcc.dg/torture/pr48822.c
===
*** gcc/testsuite/gcc.dg/torture/pr48822.c  (revision 0)
--- gcc/testsuite/gcc.dg/torture/pr48822.c  (revision 0)
***
*** 0 
--- 1,20 
+ /* { dg-do compile } */
+ 
+ void foo (int *, int *);
+ int bar ()
+ {
+   int a = 0;
+   int b = 0;
+   if (b != 0)
+ {
+   int ax = a;
+   int bx = b;
+   while (bx != 0)
+   {
+ int tem = ax % bx;
+ ax = bx;
+ bx = tem;
+   }
+ }
+   foo (&a, &b);
+ }


Re: [patch libiberty include gcc]: PR debug/28047 DWARF output_file_names should really understand DOS pathnames

2011-05-02 Thread Nicola Pero
Can I ask for some clarifications on this patch (applied on 2011-02-28) ?

This patch changed the equality function in a hashtable that holds file names, 
making for example
"/" and "\" identical entries on MS-DOS, but it didn't change the hash 
function, meaning
"/" and "\" are now identical hashtable entries on MS-DOS, but with a 
*different* hash.

How can that work ?

Lookups for "/" will look in the slot for that hash, which is not the slot for 
"\", because "\"
has a different hash.  So, unless there is collision, "/" will never even be 
compared to "\",
and the patch (which changed the comparison function, but not the hash 
function) would have almost
always no effect as it is.

What am I missing ?

I don't have an MS-DOS machine to test on; I was just reading the code and 
wondering, so I may well
be missing something important. ;-)

How was the patch tested ?  Is there a testcase ?

Thanks



Re: [google/main][RFA] change i386 pc_thunk prefix to be "__x86"

2011-05-02 Thread Diego Novillo
On Sat, Apr 30, 2011 at 17:14, Chris Demetriou  wrote:

> 2011-04-30  Chris Demetriou  
>
>        * config/i386/i386.c (get_pc_thunk_name): Make 32-bit
>        thunk prefix be __x86.get_pc_thunk.

OK.


Diego.


Re: Trivial patch to fix build with --enable-build-with-cxx

2011-05-02 Thread Eric Botcazou
> 2011-05-02  Dmitry Gorbachev  
>
>   * tree-inline.c (maybe_inline_call_in_expr): Replace false by NULL.

Thanks for spotting this.  I'd apply it to all relevant branches (4.5/4.6).

-- 
Eric Botcazou


Re: [patch, spu] Fix sched_emit_insn after scheduler changes

2011-05-02 Thread Ulrich Weigand
Bernd Schmidt wrote:
> On 04/27/2011 03:22 PM, Ulrich Weigand wrote:
> > * haifa-sched.c (sched_emit_insn): Emit insn before first
> > non-scheduled insn.  Inform back-end about new insn.  Add
> > new insn to scheduled_insns list.
> 
> Seems like this function is only used from spu.c. OK.

Thanks for the review; I've checked this in now.

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  ulrich.weig...@de.ibm.com


[testsuite] Don't XFAIL g++.dg/tree-ssa/pr43411.C

2011-05-02 Thread Rainer Orth
Given that g++.dg/tree-ssa/pr43411.C seems to XPASS everywhere, it seems
time to remove the xfail.

Tested on i386-pc-solaris2.11 with the appropriate runtest invocation,
ok for mainline?

Rainer


2011-04-30  Rainer Orth  

* g++.dg/tree-ssa/pr43411.C: Remove xfail.

diff --git a/gcc/testsuite/g++.dg/tree-ssa/pr43411.C 
b/gcc/testsuite/g++.dg/tree-ssa/pr43411.C
--- a/gcc/testsuite/g++.dg/tree-ssa/pr43411.C
+++ b/gcc/testsuite/g++.dg/tree-ssa/pr43411.C
@@ -25,5 +25,5 @@ void testInlinePsub() {
 sink1 = v(p);
 }
 
-// { dg-final { scan-tree-dump-not "OBJ_TYPE_REF" "optimized" { xfail *-*-* } 
} }
+// { dg-final { scan-tree-dump-not "OBJ_TYPE_REF" "optimized" } }
 // { dg-final { cleanup-tree-dump "optimized" } }

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University


Turn streamer cache to pointer_map

2011-05-02 Thread Jan Hubicka
Hi,
according to oprofile, libiberty hashing takes about 30% of streaming in time
and according to callgrind, the most busy cache is node_map cache in the
streamer.

This patch turns it into pointer-map that also saves about 400MB of memory
and is bit prettier.  I get about 8-10% speedup on Mozilla streaming.
There are other uses of tree_int map, I could probably convert them, too.

Bootstrapped/regtested x86_64-linux, OK?

Honza

* lto-streamer.c (lto_streamer_cache_insert_1,
lto_streamer_cache_lookup, lto_streamer_cache_create,
lto_streamer_cache_delete): Use pointer map instead of hashtable.
* lto-streamer.h (lto_streamer_cache_d): Turn node_map into pointer_map.
Index: lto-streamer.c
===
*** lto-streamer.c  (revision 173251)
--- lto-streamer.c  (working copy)
*** lto_streamer_cache_insert_1 (struct lto_
*** 348,373 
 bool insert_at_next_slot_p)
  {
void **slot;
-   struct tree_int_map d_entry, *entry;
unsigned ix;
bool existed_p;
  
gcc_assert (t);
  
!   d_entry.base.from = t;
!   slot = htab_find_slot (cache->node_map, &d_entry, INSERT);
!   if (*slot == NULL)
  {
/* Determine the next slot to use in the cache.  */
if (insert_at_next_slot_p)
ix = VEC_length (tree, cache->nodes);
else
ix = *ix_p;
! 
!   entry = (struct tree_int_map *)pool_alloc (cache->node_map_entries);
!   entry->base.from = t;
!   entry->to = ix;
!   *slot = entry;
  
lto_streamer_cache_add_to_node_array (cache, ix, t);
  
--- 348,367 
 bool insert_at_next_slot_p)
  {
void **slot;
unsigned ix;
bool existed_p;
  
gcc_assert (t);
  
!   slot = pointer_map_insert (cache->node_map, t);
!   if (!*slot)
  {
/* Determine the next slot to use in the cache.  */
if (insert_at_next_slot_p)
ix = VEC_length (tree, cache->nodes);
else
ix = *ix_p;
!*slot = (void *)(size_t) (ix);
  
lto_streamer_cache_add_to_node_array (cache, ix, t);
  
*** lto_streamer_cache_insert_1 (struct lto_
*** 376,383 
  }
else
  {
!   entry = (struct tree_int_map *) *slot;
!   ix = entry->to;
  
if (!insert_at_next_slot_p && ix != *ix_p)
{
--- 370,376 
  }
else
  {
!   ix = (size_t) *slot;
  
if (!insert_at_next_slot_p && ix != *ix_p)
{
*** lto_streamer_cache_lookup (struct lto_st
*** 442,455 
   unsigned *ix_p)
  {
void **slot;
-   struct tree_int_map d_slot;
bool retval;
unsigned ix;
  
gcc_assert (t);
  
!   d_slot.base.from = t;
!   slot = htab_find_slot (cache->node_map, &d_slot, NO_INSERT);
if (slot == NULL)
  {
retval = false;
--- 435,446 
   unsigned *ix_p)
  {
void **slot;
bool retval;
unsigned ix;
  
gcc_assert (t);
  
!   slot = pointer_map_contains  (cache->node_map, t);
if (slot == NULL)
  {
retval = false;
*** lto_streamer_cache_lookup (struct lto_st
*** 458,464 
else
  {
retval = true;
!   ix = ((struct tree_int_map *) *slot)->to;
  }
  
if (ix_p)
--- 449,455 
else
  {
retval = true;
!   ix = (size_t) *slot;
  }
  
if (ix_p)
*** lto_streamer_cache_create (void)
*** 608,618 
  
cache = XCNEW (struct lto_streamer_cache_d);
  
!   cache->node_map = htab_create (101, tree_int_map_hash, tree_int_map_eq, 
NULL);
! 
!   cache->node_map_entries = create_alloc_pool ("node map",
!  sizeof (struct tree_int_map),
!  100);
  
/* Load all the well-known tree nodes that are always created by
   the compiler on startup.  This prevents writing them out
--- 599,605 
  
cache = XCNEW (struct lto_streamer_cache_d);
  
!   cache->node_map = pointer_map_create ();
  
/* Load all the well-known tree nodes that are always created by
   the compiler on startup.  This prevents writing them out
*** lto_streamer_cache_delete (struct lto_st
*** 636,643 
if (c == NULL)
  return;
  
!   htab_delete (c->node_map);
!   free_alloc_pool (c->node_map_entries);
VEC_free (tree, heap, c->nodes);
free (c);
  }
--- 623,629 
if (c == NULL)
  return;
  
!   pointer_map_destroy (c->node_map);
VEC_free (tree, heap, c->nodes);
free (c);
  }
Index: lto-streamer.h
===
*** lto-streamer.h  (revision 173251)
--- lto-streamer.h  (working copy)
*** typedef void (lto_free_section_data_f) (
*** 346,355 
  struct lto_streamer_cache_d
  {
/* The mapping between tree nodes and slots into the nodes array.  */
!   htab_t

[testsuite] Compile gfortran.dg/fmt_g0_6.f08 with -ffloat-store

2011-05-02 Thread Rainer Orth
gfortran.dg/fmt_g0_6.f08 execution seems to fail on all 32-bit x86
targets at -O1 and above.  Running it under gdb, I find

Program received signal SIGABRT, Aborted.
[Switching to Thread 1 (LWP 1)]
0xfed0ff85 in _lwp_kill () from /lib/libc.so.1
(gdb) where
#0  0xfed0ff85 in _lwp_kill () from /lib/libc.so.1
#1  0xfed08f49 in thr_kill () from /lib/libc.so.1
#2  0xfecb8f3d in raise () from /lib/libc.so.1
#3  0xfec9114d in abort () from /lib/libc.so.1
#4  0xfef43b2c in _gfortran_abort () at 
/vol/gcc/src/hg/trunk/local/libgfortran/intrinsics/abort.c:34
#5  0x08051821 in check_f_fmt (val=0.995, roundmode=..., w=15, d=2, e=0, 
_roundmode=1) at 
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gfortran.dg/fmt_g0_6.f08:76
#6  main (val=Could not find the frame base for "main".
) at /vol/gcc/src/hg/trunk/local/gcc/testsuite/gfortran.dg/fmt_g0_6.f08:26
#7  0x0805185b in check_all (val=0.995, w=15, d=2, e=0) at 
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gfortran.dg/fmt_g0_6.f08:21
#8  main (val=0.995, w=15, d=2, e=Could not find the frame base for "main".
) at /vol/gcc/src/hg/trunk/local/gcc/testsuite/gfortran.dg/fmt_g0_6.f08:15
#9  0x08051923 in test_g0fr (argc=1, argv=0x8047a70 
"/vol/gcc/obj/regression/trunk/11-gcc/build/gcc/testsuite/gfortran/fmt_g0_6.exe")
 at /vol/gcc/src/hg/trunk/local/gcc/testsuite/gfortran.dg/fmt_g0_6.f08:11
#10 main (argc=1, argv=0x8047a70 
"/vol/gcc/obj/regression/trunk/11-gcc/build/gcc/testsuite/gfortran/fmt_g0_6.exe")
 at /vol/gcc/src/hg/trunk/local/gcc/testsuite/gfortran.dg/fmt_g0_6.f08:13
#11 0x08050f03 in _start ()

if (s_g /= s_f) call abort

(gdb) p s_g
$1 = ''1.0'', ' ' 
(gdb) p s_f
$2 = ''   0.99'', ' ' 

The failure vanishes with -ffloat-store, so I propose the following
patch, tested on i386-pc-solaris2.11 with the appropriate runtest
invocation.

Ok for mainline?

Rainer


2011-04-30  Rainer Orth  

* gfortran.dg/fmt_g0_6.f08: Use dg-options "-ffloat-store".
Fix typo.

diff --git a/gcc/testsuite/gfortran.dg/fmt_g0_6.f08 
b/gcc/testsuite/gfortran.dg/fmt_g0_6.f08
--- a/gcc/testsuite/gfortran.dg/fmt_g0_6.f08
+++ b/gcc/testsuite/gfortran.dg/fmt_g0_6.f08
@@ -1,4 +1,5 @@
 ! { dg-do run }
-! PE48602 Invalid F conversion of G descriptor for values close to powers of 10
+! { dg-options "-ffloat-store" }
+ ! PR48602 Invalid F conversion of G descriptor for values close to powers of 
10
 ! Test case provided by Thomas Henlich
 program test_g0fr

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University


Re: Trivial patch to fix build with --enable-build-with-cxx

2011-05-02 Thread Dmitry Gorbachev
Uh, there is another one:

../../gcc-4.7/gcc/cp/parser.c: In function 'tree_node*
cp_parser_init_declarator(cp_parser*, cp_decl_specifier_seq*,
VEC_deferred_access_check_gc*, bool, bool, int, bool*, tree_node**)':
../../gcc-4.7/gcc/cp/parser.c:14612:19: error: converting 'false' to
pointer type 'tree' [-Werror=conversion-null]

2011-05-02  Dmitry Gorbachev  

* parser.c (cp_parser_init_declarator): Replace false by NULL.

--- gcc/cp/parser.c
+++ gcc/cp/parser.c
@@ -14609,7 +14609,7 @@
   if (pushed_scope)
{
  pop_scope (pushed_scope);
- pushed_scope = false;
+ pushed_scope = NULL;
}
   decl = grokfield (declarator, decl_specifiers,
initializer, !is_non_constant_init,


Re: [patch] make default linker --hash-style configurable option

2011-05-02 Thread Paul Pluzhnikov
Ping? Ping? Ping? Ping?

This is getting ridiculous. Would someone please accept the patch,
tell me what to fix in it to make it acceptable, or explain why it is
a bad idea?

Thanks!

On Mon, Apr 25, 2011 at 9:08 AM, Paul Pluzhnikov  wrote:
> Ping? Ping? Ping?
>
> On Mon, Apr 18, 2011 at 9:45 AM, Paul Pluzhnikov  
> wrote:
>> Ping? Ping?
>>
>> On Mon, Apr 11, 2011 at 11:00 AM, Paul Pluzhnikov
>>  wrote:
>>> Ping?
>
> --
> Paul Pluzhnikov
>



-- 
Paul Pluzhnikov


[build] More --enable-threads cleanup

2011-05-02 Thread Rainer Orth
In my last --enable-threads cleanup patch

[build, doc] Cleanup --enable-threads support
http://gcc.gnu.org/ml/gcc-patches/2011-04/msg00735.html

I missed another opportunity, handled by this patch.

Bootstrapped on i386-pc-solaris2.11 (not that it's relevant).  Ok for
mainline?

Rainer


2011-04-30  Rainer Orth  

gcc:
* configure.ac (enable_threads): Remove irix; add lynx, tpf; sort list.
* configure: Regenerate.

diff --git a/gcc/configure.ac b/gcc/configure.ac
--- a/gcc/configure.ac
+++ b/gcc/configure.ac
@@ -1331,8 +1331,8 @@ case ${enable_threads} in
 # default
 target_thread_file='single'
 ;;
-  aix | dce | gnat | irix | posix | posix95 | rtems | \
-  single | vxworks | win32 | mipssde)
+  aix | dce | gnat | lynx | mipssde | nks | posix | posix95 | rtems | \
+  single | tpf | vxworks | win32)
 target_thread_file=${enable_threads}
 ;;
   *)

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University


[Patch,AVR]: Fix PR27663

2011-05-02 Thread Georg-Johann Lay
This is a fix for an optimization flaw when a long value is composed
from byte values.

For -fsplit-wide-types (which is still default for avr) the code is
worse than with -fno-split-wide-types. The code for the test case is
better in either situations, i.e. compared to code without the patch,
but it is still not optimal.

Fixing this by some combine patterns is the only thing the BE can do.
I did not write more complex patterns because things get too complex
with little performance gain.

Tested without regressions.

Johann

2011-05-02  Georg-Johann Lay  

PR target/27663
* config/avr/predicates.md (const_8_16_24_operand): New predicate.
* config/avr/avr.md ("*iorqi.byte0",
"*iorqi.byte1-3"): New define_insn_and_split patterns.
Index: config/avr/predicates.md
===
--- config/avr/predicates.md	(Revision 172902)
+++ config/avr/predicates.md	(Arbeitskopie)
@@ -138,3 +138,10 @@ (define_predicate "call_insn_operand"
 (define_predicate "pseudo_register_operand"
   (and (match_code "reg")
(match_test "!HARD_REGISTER_P (op)")))
+
+;; Return true if OP is a constant integer that is either
+;; 8 or 16 or 24.
+(define_predicate "const_8_16_24_operand"
+  (and (match_code "const_int")
+   (match_test "8 == INTVAL(op) || 16 == INTVAL(op) || 24 == INTVAL(op)")))
+
Index: config/avr/avr.md
===
--- config/avr/avr.md	(Revision 172902)
+++ config/avr/avr.md	(Arbeitskopie)
@@ -3388,3 +3388,42 @@ (define_insn "fmulsu"
 	clr __zero_reg__"
   [(set_attr "length" "3")
(set_attr "cc" "clobber")])
+
+
+;; Some combine patterns that try to fix bad code when a value is composed
+;; from byte parts like in PR27663.
+;; The patterns give some release but the code still is not optimal,
+;; in particular when subreg lowering (-fsplit-wide-types) is turned on.
+;; That switch obfuscates things here and in many other places.
+
+(define_insn_and_split "*iorqi.byte0"
+  [(set (match_operand:HISI 0 "register_operand" "=r")
+(ior:HISI
+ (zero_extend:HISI (match_operand:QI 1 "register_operand" "r"))
+ (match_operand:HISI 2 "register_operand" "0")))]
+  ""
+  "#"
+  "reload_completed"
+  [(set (match_dup 3)
+(ior:QI (match_dup 3)
+(match_dup 1)))]
+  {
+operands[3] = simplify_gen_subreg (QImode, operands[0], mode, 0);
+  })
+
+(define_insn_and_split "*iorqi.byte1-3"
+  [(set (match_operand:HISI 0 "register_operand"  "=r")
+(ior:HISI
+ (ashift:HISI (zero_extend:HISI (match_operand:QI 1 "register_operand" "r"))
+  (match_operand:QI 2 "const_8_16_24_operand"  "n"))
+ (match_operand:HISI 3 "register_operand"  "0")))]
+  "INTVAL(operands[2]) < GET_MODE_BITSIZE (mode)"
+  "#"
+  "&& reload_completed"
+  [(set (match_dup 4)
+(ior:QI (match_dup 4)
+(match_dup 1)))]
+  {
+int byteno = INTVAL(operands[2]) / BITS_PER_UNIT;
+operands[4] = simplify_gen_subreg (QImode, operands[0], mode, byteno);
+  })


Re: [testsuite] Don't XFAIL g++.dg/tree-ssa/pr43411.C

2011-05-02 Thread Richard Guenther
On Mon, May 2, 2011 at 4:13 PM, Rainer Orth  
wrote:
> Given that g++.dg/tree-ssa/pr43411.C seems to XPASS everywhere, it seems
> time to remove the xfail.
>
> Tested on i386-pc-solaris2.11 with the appropriate runtest invocation,
> ok for mainline?

I think the testcase wants to test for devirtualization and inlined virtual
calls.  That still doesn't happen.  So the patterns need to be adjusted
to look for sth else than OBJ_TYPE_REF instead.

Richard.

>        Rainer
>
>
> 2011-04-30  Rainer Orth  
>
>        * g++.dg/tree-ssa/pr43411.C: Remove xfail.
>
> diff --git a/gcc/testsuite/g++.dg/tree-ssa/pr43411.C 
> b/gcc/testsuite/g++.dg/tree-ssa/pr43411.C
> --- a/gcc/testsuite/g++.dg/tree-ssa/pr43411.C
> +++ b/gcc/testsuite/g++.dg/tree-ssa/pr43411.C
> @@ -25,5 +25,5 @@ void testInlinePsub() {
>     sink1 = v(p);
>  }
>
> -// { dg-final { scan-tree-dump-not "OBJ_TYPE_REF" "optimized" { xfail *-*-* 
> } } }
> +// { dg-final { scan-tree-dump-not "OBJ_TYPE_REF" "optimized" } }
>  // { dg-final { cleanup-tree-dump "optimized" } }
>
> --
> -
> Rainer Orth, Center for Biotechnology, Bielefeld University
>


[google] Remove unqualified lookups which break clang (issue4439085)

2011-05-02 Thread Ollie Wild
commit 99835abc5d2a7fd3ae0950c8a16fd6d223d408c9
Author: Ollie Wild 
Date:   Fri Apr 29 13:03:57 2011 -0400

Remove unqualified lookups into dependent template base classes from
STL headers.  These break clang.

See http://clang.llvm.org/compatibility.html#dep_lookup_bases.

To be applied to google/main.  Would also like permissiont to submit to
trunk.

M   libstdc++-v3/include/ext/sso_string_base.h
M   libstdc++-v3/include/ext/vstring.h
M   libstdc++-v3/include/ext/vstring.tcc

Tested:
  Tested via buildit bootstrap and tests.

ChangeLog:

2011-05-02  Ollie Wild  

* include/ext/sso_string_base.h (__sso_string_base<>::_M_construct):
Fix unqualified lookup.
(__sso_string_base<>::_M_construct): Likewise.
(__sso_string_base<>::_M_construct): Likewise.
(__sso_string_base<>::_M_assign): Likewise.
(__sso_string_base<>::_M_reserve): Likewise.
(__sso_string_base<>::_M_mutate): Likewise.
(__sso_string_base<>::_M_erase): Likewise.
* include/ext/vstring.h (__versa_string<>::replace): Likewise.
(__versa_string<>::compare): Likewise.
* include/ext/vstring.tcc (__versa_string<>::compare): Likewise.
(__versa_string<>::compare): Likewise.
(__versa_string<>::compare): Likewise.
(__versa_string<>::compare): Likewise.
(__versa_string<>::compare): Likewise.

diff --git a/libstdc++-v3/include/ext/sso_string_base.h 
b/libstdc++-v3/include/ext/sso_string_base.h
index 638eeba..39a62d6 100644
--- a/libstdc++-v3/include/ext/sso_string_base.h
+++ b/libstdc++-v3/include/ext/sso_string_base.h
@@ -432,7 +432,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
// Allocate more space.
__capacity = __len + 1;
_CharT* __another = _M_create(__capacity, __len);
-   _S_copy(__another, _M_data(), __len);
+   this->_S_copy(__another, _M_data(), __len);
_M_dispose();
_M_data(__another);
_M_capacity(__capacity);
@@ -472,7 +472,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 
// Check for out_of_range and length_error exceptions.
__try
- { _S_copy_chars(_M_data(), __beg, __end); }
+ { this->_S_copy_chars(_M_data(), __beg, __end); }
__catch(...)
  {
_M_dispose();
@@ -494,7 +494,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
}
 
   if (__n)
-   _S_assign(_M_data(), __n, __c);
+   this->_S_assign(_M_data(), __n, __c);
 
   _M_set_length_no_wipe(__n);
 }
@@ -519,7 +519,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
}
 
  if (__rsize)
-   _S_copy(_M_data(), __rcs._M_data(), __rsize);
+   this->_S_copy(_M_data(), __rcs._M_data(), __rsize);
 
  _M_set_length(__rsize);
}
@@ -541,14 +541,14 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
  || __res > size_type(_S_local_capacity))
{
  _CharT* __tmp = _M_create(__res, __capacity);
- _S_copy(__tmp, _M_data(), _M_length() + 1);
+ this->_S_copy(__tmp, _M_data(), _M_length() + 1);
  _M_dispose();
  _M_data(__tmp);
  _M_capacity(__res);
}
  else if (!_M_is_local())
{
- _S_copy(_M_local_data, _M_data(), _M_length() + 1);
+ this->_S_copy(_M_local_data, _M_data(), _M_length() + 1);
  _M_destroy(__capacity);
  _M_data(_M_local_data);
}
@@ -567,12 +567,12 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   _CharT* __r = _M_create(__new_capacity, _M_capacity());
 
   if (__pos)
-   _S_copy(__r, _M_data(), __pos);
+   this->_S_copy(__r, _M_data(), __pos);
   if (__s && __len2)
-   _S_copy(__r + __pos, __s, __len2);
+   this->_S_copy(__r + __pos, __s, __len2);
   if (__how_much)
-   _S_copy(__r + __pos + __len2,
-   _M_data() + __pos + __len1, __how_much);
+   this->_S_copy(__r + __pos + __len2,
+ _M_data() + __pos + __len1, __how_much);
   
   _M_dispose();
   _M_data(__r);
@@ -587,8 +587,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   const size_type __how_much = _M_length() - __pos - __n;
 
   if (__how_much && __n)
-   _S_move(_M_data() + __pos, _M_data() + __pos + __n,
-   __how_much);
+   this->_S_move(_M_data() + __pos, _M_data() + __pos + __n, __how_much);
 
   _M_set_length(_M_length() - __n);
 }
diff --git a/libstdc++-v3/include/ext/vstring.h 
b/libstdc++-v3/include/ext/vstring.h
index 90a5683..57f36a6 100644
--- a/libstdc++-v3/include/ext/vstring.h
+++ b/libstdc++-v3/include/ext/vstring.h
@@ -1374,7 +1374,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   && __i2 <= _M_iend());
  __glibcxx_requires_valid_range(__k1, __k2);
  typedef typename std::__is_integer<_InputIterator>::__type _Integral;
-

Re: Turn streamer cache to pointer_map

2011-05-02 Thread Michael Matz
Hi,

On Mon, 2 May 2011, Jan Hubicka wrote:

> !   d_entry.base.from = t;
> !   slot = htab_find_slot (cache->node_map, &d_entry, INSERT);
> !   if (*slot == NULL)
>   {
> /* Determine the next slot to use in the cache.  */
> if (insert_at_next_slot_p)
>   ix = VEC_length (tree, cache->nodes);
> else
>   ix = *ix_p;
> ! 
> !   entry = (struct tree_int_map *)pool_alloc (cache->node_map_entries);
> !   entry->base.from = t;
> !   entry->to = ix;
> !   *slot = entry;
>   
> lto_streamer_cache_add_to_node_array (cache, ix, t);
>   
> --- 348,367 
>bool insert_at_next_slot_p)
>   {
> void **slot;
> unsigned ix;
> bool existed_p;
>   
> gcc_assert (t);
>   
> !   slot = pointer_map_insert (cache->node_map, t);
> !   if (!*slot)

ix might legitimately be zero.  Hence this transformation is not 
equivalent.  You might want to enter ix+1 into the cache with the 
appropriate adjustment at read-out.  Same for the other places.


Ciao,
Michael.


Re: [google] Remove unqualified lookups which break clang (issue4439085)

2011-05-02 Thread Diego Novillo
On Mon, May 2, 2011 at 10:34, Ollie Wild  wrote:

> 2011-05-02  Ollie Wild  
>
>        * include/ext/sso_string_base.h (__sso_string_base<>::_M_construct):
>        Fix unqualified lookup.
>        (__sso_string_base<>::_M_construct): Likewise.
>        (__sso_string_base<>::_M_construct): Likewise.
>        (__sso_string_base<>::_M_assign): Likewise.
>        (__sso_string_base<>::_M_reserve): Likewise.
>        (__sso_string_base<>::_M_mutate): Likewise.
>        (__sso_string_base<>::_M_erase): Likewise.
>        * include/ext/vstring.h (__versa_string<>::replace): Likewise.
>        (__versa_string<>::compare): Likewise.
>        * include/ext/vstring.tcc (__versa_string<>::compare): Likewise.
>        (__versa_string<>::compare): Likewise.
>        (__versa_string<>::compare): Likewise.
>        (__versa_string<>::compare): Likewise.
>        (__versa_string<>::compare): Likewise.

OK for google/main.


Diego.


[build] mips-tfile.c, mips-tdump.c cleanup

2011-05-02 Thread Rainer Orth
Prompted by Joseph's message

http://gcc.gnu.org/ml/gcc-patches/2011-04/msg01796.html

I've done some cleanup on mips-tfile.c and mips-tdump.c that are now
only used by Tru64 UNIX.

Apart from the issues mentioned by Joseph, I'm removing Saber C support,
use of private Size_t/Ptrdiff_t, and STATIC.  Those were the low-hanging
fruit; I currently don't plan to go for other stuff (like removal of the
remaining warnings) since I may obsolete the port in 4.7 (or 4.8 at the
latest).

I suppose that the patch doesn't require approval since the changes to
alpha.h only affect alpha*-dec-osf* and the Makefile.in changes
corresponding to mips-t*.c are private to that port, too.

Mainline bootstrap is currently running (with mips-t{file, dump} already
built in stage1).

Unless someone objects, I'll install on mainline if that passes.

Rainer


2011-04-29  Rainer Orth  

* config/alpha/alpha.h (CODE_MASK, MIPS_IS_STAB, MIPS_MARK_STAB)
(MIPS_UNMARK_STAB, SHASH_SIZE, THASH_SIZE, ALIGN_SYMTABLE_OFFSET):
Move ...
* mips-tfile.c: ... here.
Don't include coretypes.h, tm.h, filenames.h.
(saber_stop): Remove definition and all calls.
[__SABER__]: Remove.
(__LINE__): Remove default.
(Size_t, Ptrdiff_t): Remove definitions.
Replace by size_t, ptrdiff_t.
[!MIPS_DEBUGGING_INFO]: Remove.
(SHASH_SIZE, THASH_SIZE): Remove defaults.
(progname): Add const.
(STATIC): Remove.
Replace all uses by static.
(ALIGN_SYMTABLE_OFFSET): Remove default.
* mips-tdump.c: Don't include coretypes.h, tm.h.
Remove !MIPS_IS_STAB guard.
* Makefile.in (mips-tfile.o): Remove $(RTL_H), coretypes.h,
$(TM_H), filenames.h dependencies.
(mips-tdump.o): Remove $(RTL_H), coretypes.h, $(TM_H) dependencies.

diff --git a/gcc/Makefile.in b/gcc/Makefile.in
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -3580,15 +3580,15 @@ mips-tfile: mips-tfile.o version.o $(LIB
$(LINKER) $(LINKERFLAGS) $(LDFLAGS) -o $@ \
mips-tfile.o version.o $(LIBS)
 
-mips-tfile.o : mips-tfile.c $(CONFIG_H) $(RTL_H) $(SYSTEM_H) coretypes.h \
-   $(TM_H) version.h $(srcdir)/../include/getopt.h $(GSTAB_H) intl.h
+mips-tfile.o : mips-tfile.c $(CONFIG_H) $(SYSTEM_H) \
+   version.h $(srcdir)/../include/getopt.h $(GSTAB_H) intl.h
 
 mips-tdump: mips-tdump.o version.o $(LIBDEPS)
$(LINKER) $(LINKERFLAGS) $(LDFLAGS) -o $@ \
mips-tdump.o version.o $(LIBS)
 
-mips-tdump.o : mips-tdump.c $(CONFIG_H) $(RTL_H) $(SYSTEM_H) coretypes.h \
-   $(TM_H) version.h $(srcdir)/../include/getopt.h stab.def
+mips-tdump.o : mips-tdump.c $(CONFIG_H) $(SYSTEM_H) \
+   version.h $(srcdir)/../include/getopt.h stab.def
 
 #
 # Generate header and source files from the machine description,
diff --git a/gcc/config/alpha/alpha.h b/gcc/config/alpha/alpha.h
--- a/gcc/config/alpha/alpha.h
+++ b/gcc/config/alpha/alpha.h
@@ -1294,25 +1294,5 @@ do { 
\
 
 #define PUT_SDB_EPILOGUE_END(NAME) ((void)(NAME))
 
-/* Macros for mips-tfile.c to encapsulate stabs in ECOFF, and for
-   mips-tdump.c to print them out.
-
-   These must match the corresponding definitions in gdb/mipsread.c.
-   Unfortunately, gcc and gdb do not currently share any directories.  */
-
-#define CODE_MASK 0x8F300
-#define MIPS_IS_STAB(sym) (((sym)->index & 0xFFF00) == CODE_MASK)
-#define MIPS_MARK_STAB(code) ((code)+CODE_MASK)
-#define MIPS_UNMARK_STAB(code) ((code)-CODE_MASK)
-
-/* Override some mips-tfile definitions.  */
-
-#define SHASH_SIZE 511
-#define THASH_SIZE 55
-
-/* Align ecoff symbol tables to avoid OSF1/1.3 nm complaints.  */
-
-#define ALIGN_SYMTABLE_OFFSET(OFFSET) (((OFFSET) + 7) & ~7)
-
 /* The system headers under Alpha systems are generally C++-aware.  */
 #define NO_IMPLICIT_EXTERN_C
diff --git a/gcc/mips-tdump.c b/gcc/mips-tdump.c
--- a/gcc/mips-tdump.c
+++ b/gcc/mips-tdump.c
@@ -22,8 +22,6 @@ along with GCC; see the file COPYING3.  
 
 #include "config.h"
 #include "system.h"
-#include "coretypes.h"
-#include "tm.h"
 #include "version.h"
 #ifdef index
 #undef index
@@ -37,10 +35,8 @@ along with GCC; see the file COPYING3.  
 /* Include getopt.h for the sake of getopt_long.  */
 #include "getopt.h"
 
-#ifndef MIPS_IS_STAB
 /* Macros for mips-tfile.c to encapsulate stabs in ECOFF, and for
-   and mips-tdump.c to print them out.  This is used on the Alpha,
-   which does not include mips.h.
+   mips-tdump.c to print them out.
 
These must match the corresponding definitions in gdb/mipsread.c.
Unfortunately, gcc and gdb do not currently share any directories.  */
@@ -49,7 +45,6 @@ along with GCC; see the file COPYING3.  
 #define MIPS_IS_STAB(sym) (((sym)->index & 0xFFF00) == CODE_MASK)
 #define MIPS_MARK_STAB(code) ((code)+CODE_MASK)
 #define MIPS_UNMARK_STAB(code) ((code)-CODE_MASK)
-#endif
 
 #define uchar  unsigned char
 #define ushort unsigned short
diff --gi

Re: Turn streamer cache to pointer_map

2011-05-02 Thread Richard Guenther
On Mon, May 2, 2011 at 4:16 PM, Jan Hubicka  wrote:
> Hi,
> according to oprofile, libiberty hashing takes about 30% of streaming in time
> and according to callgrind, the most busy cache is node_map cache in the
> streamer.
>
> This patch turns it into pointer-map that also saves about 400MB of memory
> and is bit prettier.  I get about 8-10% speedup on Mozilla streaming.
> There are other uses of tree_int map, I could probably convert them, too.
>
> Bootstrapped/regtested x86_64-linux, OK?
>
> Honza
>
>        * lto-streamer.c (lto_streamer_cache_insert_1,
>        lto_streamer_cache_lookup, lto_streamer_cache_create,
>        lto_streamer_cache_delete): Use pointer map instead of hashtable.
>        * lto-streamer.h (lto_streamer_cache_d): Turn node_map into 
> pointer_map.
> Index: lto-streamer.c
> ===
> *** lto-streamer.c      (revision 173251)
> --- lto-streamer.c      (working copy)
> *** lto_streamer_cache_insert_1 (struct lto_
> *** 348,373 
>                             bool insert_at_next_slot_p)
>  {
>    void **slot;
> -   struct tree_int_map d_entry, *entry;
>    unsigned ix;
>    bool existed_p;
>
>    gcc_assert (t);
>
> !   d_entry.base.from = t;
> !   slot = htab_find_slot (cache->node_map, &d_entry, INSERT);
> !   if (*slot == NULL)
>      {
>        /* Determine the next slot to use in the cache.  */
>        if (insert_at_next_slot_p)
>        ix = VEC_length (tree, cache->nodes);
>        else
>        ix = *ix_p;
> !
> !       entry = (struct tree_int_map *)pool_alloc (cache->node_map_entries);
> !       entry->base.from = t;
> !       entry->to = ix;
> !       *slot = entry;
>
>        lto_streamer_cache_add_to_node_array (cache, ix, t);
>
> --- 348,367 
>                             bool insert_at_next_slot_p)
>  {
>    void **slot;
>    unsigned ix;
>    bool existed_p;
>
>    gcc_assert (t);
>
> !   slot = pointer_map_insert (cache->node_map, t);
> !   if (!*slot)
>      {
>        /* Determine the next slot to use in the cache.  */
>        if (insert_at_next_slot_p)
>        ix = VEC_length (tree, cache->nodes);
>        else
>        ix = *ix_p;
> !        *slot = (void *)(size_t) (ix);
>
>        lto_streamer_cache_add_to_node_array (cache, ix, t);
>
> *** lto_streamer_cache_insert_1 (struct lto_
> *** 376,383 
>      }
>    else
>      {
> !       entry = (struct tree_int_map *) *slot;
> !       ix = entry->to;
>
>        if (!insert_at_next_slot_p && ix != *ix_p)
>        {
> --- 370,376 
>      }
>    else
>      {
> !       ix = (size_t) *slot;
>
>        if (!insert_at_next_slot_p && ix != *ix_p)
>        {
> *** lto_streamer_cache_lookup (struct lto_st
> *** 442,455 
>                           unsigned *ix_p)
>  {
>    void **slot;
> -   struct tree_int_map d_slot;
>    bool retval;
>    unsigned ix;
>
>    gcc_assert (t);
>
> !   d_slot.base.from = t;
> !   slot = htab_find_slot (cache->node_map, &d_slot, NO_INSERT);
>    if (slot == NULL)
>      {
>        retval = false;
> --- 435,446 
>                           unsigned *ix_p)
>  {
>    void **slot;
>    bool retval;
>    unsigned ix;
>
>    gcc_assert (t);
>
> !   slot = pointer_map_contains  (cache->node_map, t);
>    if (slot == NULL)
>      {
>        retval = false;
> *** lto_streamer_cache_lookup (struct lto_st
> *** 458,464 
>    else
>      {
>        retval = true;
> !       ix = ((struct tree_int_map *) *slot)->to;
>      }
>
>    if (ix_p)
> --- 449,455 
>    else
>      {
>        retval = true;
> !       ix = (size_t) *slot;
>      }
>
>    if (ix_p)
> *** lto_streamer_cache_create (void)
> *** 608,618 
>
>    cache = XCNEW (struct lto_streamer_cache_d);
>
> !   cache->node_map = htab_create (101, tree_int_map_hash, tree_int_map_eq, 
> NULL);
> !
> !   cache->node_map_entries = create_alloc_pool ("node map",
> !                                              sizeof (struct tree_int_map),
> !                                              100);
>
>    /* Load all the well-known tree nodes that are always created by
>       the compiler on startup.  This prevents writing them out
> --- 599,605 
>
>    cache = XCNEW (struct lto_streamer_cache_d);
>
> !   cache->node_map = pointer_map_create ();
>
>    /* Load all the well-known tree nodes that are always created by
>       the compiler on startup.  This prevents writing them out
> *** lto_streamer_cache_delete (struct lto_st
> *** 636,643 
>    if (c == NULL)
>      return;
>
> !   htab_delete (c->node_map);
> !   free_alloc_pool (c->node_map_entries);
>    VEC_free (tree, heap, c->nodes);
>    free (c);
>  }
> --- 623,629 
>    if (c == NULL)
>      return;
>
> !   pointer_map_destroy (c->node_map);
>    VEC_free (tree, heap, c->nodes);
>    free (c);
>  }
> Index: lto-streamer.h
> ===
> *** lto-streamer.h      (r

Re: [RFC PATCH, go]: Port to ALPHA arch - sysinfo.go fixup

2011-05-02 Thread Ian Lance Taylor
Uros Bizjak  writes:

> This still doesn't fix the build for alpha due to extra struct.  From
> sysinfo.go:
>
> type Timespec struct { Sec Timespec_sec_t; Nsec Timespec_nsec_t; }
> type Stat_t struct { Dev uint64; Ino uint64; Rdev uint64; Size int64;
> Blocks uint64; Mode uint32; Uid uint32; Gid uint32; Blksize uint32;
> Nlink uint32; __pad0 int32; Go0 struct { Atime Timespec; }; Go1 struct
> { Mtime Timespec; }; Go2 struct { Ctime Timespec; }; __unused
> [2+1]int64; }

> Is there a solution for this problem?

I haven't fixed it yet but I think the way to fix it is to edit
mksysinfo.sh to strip out the unexpected structs.

Ian


Re: Turn streamer cache to pointer_map

2011-05-02 Thread Richard Guenther
On Mon, May 2, 2011 at 4:38 PM, Richard Guenther
 wrote:
> On Mon, May 2, 2011 at 4:16 PM, Jan Hubicka  wrote:
>> Hi,
>> according to oprofile, libiberty hashing takes about 30% of streaming in time
>> and according to callgrind, the most busy cache is node_map cache in the
>> streamer.
>>
>> This patch turns it into pointer-map that also saves about 400MB of memory
>> and is bit prettier.  I get about 8-10% speedup on Mozilla streaming.
>> There are other uses of tree_int map, I could probably convert them, too.
>>
>> Bootstrapped/regtested x86_64-linux, OK?
>>
>> Honza
>>
>>        * lto-streamer.c (lto_streamer_cache_insert_1,
>>        lto_streamer_cache_lookup, lto_streamer_cache_create,
>>        lto_streamer_cache_delete): Use pointer map instead of hashtable.
>>        * lto-streamer.h (lto_streamer_cache_d): Turn node_map into 
>> pointer_map.
>> Index: lto-streamer.c
>> ===
>> *** lto-streamer.c      (revision 173251)
>> --- lto-streamer.c      (working copy)
>> *** lto_streamer_cache_insert_1 (struct lto_
>> *** 348,373 
>>                             bool insert_at_next_slot_p)
>>  {
>>    void **slot;
>> -   struct tree_int_map d_entry, *entry;
>>    unsigned ix;
>>    bool existed_p;
>>
>>    gcc_assert (t);
>>
>> !   d_entry.base.from = t;
>> !   slot = htab_find_slot (cache->node_map, &d_entry, INSERT);
>> !   if (*slot == NULL)
>>      {
>>        /* Determine the next slot to use in the cache.  */
>>        if (insert_at_next_slot_p)
>>        ix = VEC_length (tree, cache->nodes);
>>        else
>>        ix = *ix_p;
>> !
>> !       entry = (struct tree_int_map *)pool_alloc (cache->node_map_entries);
>> !       entry->base.from = t;
>> !       entry->to = ix;
>> !       *slot = entry;
>>
>>        lto_streamer_cache_add_to_node_array (cache, ix, t);
>>
>> --- 348,367 
>>                             bool insert_at_next_slot_p)
>>  {
>>    void **slot;
>>    unsigned ix;
>>    bool existed_p;
>>
>>    gcc_assert (t);
>>
>> !   slot = pointer_map_insert (cache->node_map, t);
>> !   if (!*slot)
>>      {
>>        /* Determine the next slot to use in the cache.  */
>>        if (insert_at_next_slot_p)
>>        ix = VEC_length (tree, cache->nodes);
>>        else
>>        ix = *ix_p;
>> !        *slot = (void *)(size_t) (ix);
>>
>>        lto_streamer_cache_add_to_node_array (cache, ix, t);
>>
>> *** lto_streamer_cache_insert_1 (struct lto_
>> *** 376,383 
>>      }
>>    else
>>      {
>> !       entry = (struct tree_int_map *) *slot;
>> !       ix = entry->to;
>>
>>        if (!insert_at_next_slot_p && ix != *ix_p)
>>        {
>> --- 370,376 
>>      }
>>    else
>>      {
>> !       ix = (size_t) *slot;
>>
>>        if (!insert_at_next_slot_p && ix != *ix_p)
>>        {
>> *** lto_streamer_cache_lookup (struct lto_st
>> *** 442,455 
>>                           unsigned *ix_p)
>>  {
>>    void **slot;
>> -   struct tree_int_map d_slot;
>>    bool retval;
>>    unsigned ix;
>>
>>    gcc_assert (t);
>>
>> !   d_slot.base.from = t;
>> !   slot = htab_find_slot (cache->node_map, &d_slot, NO_INSERT);
>>    if (slot == NULL)
>>      {
>>        retval = false;
>> --- 435,446 
>>                           unsigned *ix_p)
>>  {
>>    void **slot;
>>    bool retval;
>>    unsigned ix;
>>
>>    gcc_assert (t);
>>
>> !   slot = pointer_map_contains  (cache->node_map, t);
>>    if (slot == NULL)
>>      {
>>        retval = false;
>> *** lto_streamer_cache_lookup (struct lto_st
>> *** 458,464 
>>    else
>>      {
>>        retval = true;
>> !       ix = ((struct tree_int_map *) *slot)->to;
>>      }
>>
>>    if (ix_p)
>> --- 449,455 
>>    else
>>      {
>>        retval = true;
>> !       ix = (size_t) *slot;
>>      }
>>
>>    if (ix_p)
>> *** lto_streamer_cache_create (void)
>> *** 608,618 
>>
>>    cache = XCNEW (struct lto_streamer_cache_d);
>>
>> !   cache->node_map = htab_create (101, tree_int_map_hash, tree_int_map_eq, 
>> NULL);
>> !
>> !   cache->node_map_entries = create_alloc_pool ("node map",
>> !                                              sizeof (struct tree_int_map),
>> !                                              100);
>>
>>    /* Load all the well-known tree nodes that are always created by
>>       the compiler on startup.  This prevents writing them out
>> --- 599,605 
>>
>>    cache = XCNEW (struct lto_streamer_cache_d);
>>
>> !   cache->node_map = pointer_map_create ();
>>
>>    /* Load all the well-known tree nodes that are always created by
>>       the compiler on startup.  This prevents writing them out
>> *** lto_streamer_cache_delete (struct lto_st
>> *** 636,643 
>>    if (c == NULL)
>>      return;
>>
>> !   htab_delete (c->node_map);
>> !   free_alloc_pool (c->node_map_entries);
>>    VEC_free (tree, heap, c->nodes);
>>    free (c);
>>  }
>> --- 623,629 
>>    if (c == NULL)
>>      re

Re: Turn streamer cache to pointer_map

2011-05-02 Thread Nathan Froyd
On Mon, May 02, 2011 at 04:46:23PM +0200, Richard Guenther wrote:
> >> *** typedef void (lto_free_section_data_f) (
> >> *** 346,355 
> >>  struct lto_streamer_cache_d
> >>  {
> >>    /* The mapping between tree nodes and slots into the nodes array.  */
> >> !   htab_t node_map;
> >> !
> >> !   /* Node map to store entries into.  */
> >> !   alloc_pool node_map_entries;
> >>
> >>    /* The nodes pickled so far.  */
> >>    VEC(tree,heap) *nodes;
> >> --- 346,352 
> >>  struct lto_streamer_cache_d
> >>  {
> >>    /* The mapping between tree nodes and slots into the nodes array.  */
> >> !   struct pointer_map_t GTY((skip)) *node_map;
> >
> > If you skip node_map you can end up with false entries for re-used
> > trees.  So I don't think that's a good idea.
> 
> Or we can safely mark the whole struct as non-GC (and also allocate
> it that way).

We already do (see lto-streamer.c:lto_streamer_cache_create; there's no
GTY marker on lto_streamer_cache_d.  So Honza's original GTY annotation
there is superfluous.

-Nathan


Re: Trivial patch to fix build with --enable-build-with-cxx

2011-05-02 Thread Eric Botcazou
> 2011-05-02  Dmitry Gorbachev  
>
>   * parser.c (cp_parser_init_declarator): Replace false by NULL.

Replace by NULL_TREE instead and install under the obvious rule.

-- 
Eric Botcazou


Re: Turn streamer cache to pointer_map

2011-05-02 Thread Michael Matz
Hi,

On Mon, 2 May 2011, Richard Guenther wrote:

> >>    /* The mapping between tree nodes and slots into the nodes array.  */
> >> !   struct pointer_map_t GTY((skip)) *node_map;
> >
> > If you skip node_map you can end up with false entries for re-used
> > trees.  So I don't think that's a good idea.
> 
> Or we can safely mark the whole struct as non-GC (and also allocate
> it that way).

The whole struct (lto_streamer_cache_d) isn't marked for GC, and isn't 
alloced in GC.  The GTY((skip)) marker is superfluous.


Ciao,
Michael.

Re: [google] Remove unqualified lookups which break clang (issue4439085)

2011-05-02 Thread Ollie Wild
Submitted to google/main.

Adding libstd...@gcc.gnu.org for trunk approval.

Ollie

On Mon, May 2, 2011 at 9:34 AM, Ollie Wild  wrote:
>
> commit 99835abc5d2a7fd3ae0950c8a16fd6d223d408c9
> Author: Ollie Wild 
> Date:   Fri Apr 29 13:03:57 2011 -0400
>
>    Remove unqualified lookups into dependent template base classes from
>    STL headers.  These break clang.
>
>    See http://clang.llvm.org/compatibility.html#dep_lookup_bases.
>
>    To be applied to google/main.  Would also like permissiont to submit to
>    trunk.
>
> M       libstdc++-v3/include/ext/sso_string_base.h
> M       libstdc++-v3/include/ext/vstring.h
> M       libstdc++-v3/include/ext/vstring.tcc
>
> Tested:
>  Tested via buildit bootstrap and tests.
>
> ChangeLog:
>
> 2011-05-02  Ollie Wild  
>
>        * include/ext/sso_string_base.h (__sso_string_base<>::_M_construct):
>        Fix unqualified lookup.
>        (__sso_string_base<>::_M_construct): Likewise.
>        (__sso_string_base<>::_M_construct): Likewise.
>        (__sso_string_base<>::_M_assign): Likewise.
>        (__sso_string_base<>::_M_reserve): Likewise.
>        (__sso_string_base<>::_M_mutate): Likewise.
>        (__sso_string_base<>::_M_erase): Likewise.
>        * include/ext/vstring.h (__versa_string<>::replace): Likewise.
>        (__versa_string<>::compare): Likewise.
>        * include/ext/vstring.tcc (__versa_string<>::compare): Likewise.
>        (__versa_string<>::compare): Likewise.
>        (__versa_string<>::compare): Likewise.
>        (__versa_string<>::compare): Likewise.
>        (__versa_string<>::compare): Likewise.
>
> diff --git a/libstdc++-v3/include/ext/sso_string_base.h 
> b/libstdc++-v3/include/ext/sso_string_base.h
> index 638eeba..39a62d6 100644
> --- a/libstdc++-v3/include/ext/sso_string_base.h
> +++ b/libstdc++-v3/include/ext/sso_string_base.h
> @@ -432,7 +432,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>                    // Allocate more space.
>                    __capacity = __len + 1;
>                    _CharT* __another = _M_create(__capacity, __len);
> -                   _S_copy(__another, _M_data(), __len);
> +                   this->_S_copy(__another, _M_data(), __len);
>                    _M_dispose();
>                    _M_data(__another);
>                    _M_capacity(__capacity);
> @@ -472,7 +472,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>
>        // Check for out_of_range and length_error exceptions.
>        __try
> -         { _S_copy_chars(_M_data(), __beg, __end); }
> +         { this->_S_copy_chars(_M_data(), __beg, __end); }
>        __catch(...)
>          {
>            _M_dispose();
> @@ -494,7 +494,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>        }
>
>       if (__n)
> -       _S_assign(_M_data(), __n, __c);
> +       this->_S_assign(_M_data(), __n, __c);
>
>       _M_set_length_no_wipe(__n);
>     }
> @@ -519,7 +519,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>            }
>
>          if (__rsize)
> -           _S_copy(_M_data(), __rcs._M_data(), __rsize);
> +           this->_S_copy(_M_data(), __rcs._M_data(), __rsize);
>
>          _M_set_length(__rsize);
>        }
> @@ -541,14 +541,14 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>              || __res > size_type(_S_local_capacity))
>            {
>              _CharT* __tmp = _M_create(__res, __capacity);
> -             _S_copy(__tmp, _M_data(), _M_length() + 1);
> +             this->_S_copy(__tmp, _M_data(), _M_length() + 1);
>              _M_dispose();
>              _M_data(__tmp);
>              _M_capacity(__res);
>            }
>          else if (!_M_is_local())
>            {
> -             _S_copy(_M_local_data, _M_data(), _M_length() + 1);
> +             this->_S_copy(_M_local_data, _M_data(), _M_length() + 1);
>              _M_destroy(__capacity);
>              _M_data(_M_local_data);
>            }
> @@ -567,12 +567,12 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>       _CharT* __r = _M_create(__new_capacity, _M_capacity());
>
>       if (__pos)
> -       _S_copy(__r, _M_data(), __pos);
> +       this->_S_copy(__r, _M_data(), __pos);
>       if (__s && __len2)
> -       _S_copy(__r + __pos, __s, __len2);
> +       this->_S_copy(__r + __pos, __s, __len2);
>       if (__how_much)
> -       _S_copy(__r + __pos + __len2,
> -               _M_data() + __pos + __len1, __how_much);
> +       this->_S_copy(__r + __pos + __len2,
> +                     _M_data() + __pos + __len1, __how_much);
>
>       _M_dispose();
>       _M_data(__r);
> @@ -587,8 +587,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>       const size_type __how_much = _M_length() - __pos - __n;
>
>       if (__how_much && __n)
> -       _S_move(_M_data() + __pos, _M_data() + __pos + __n,
> -               __how_much);
> +       this->_S_move(_M_data() + __pos, _M_data() + __pos + __n, __how_much);
>
>       _M_set_length(_M_length() - __n);
>     }
> diff --git a/libstdc++-v3/include/ext/vstring.h 
> b/libstdc++-v3/include/ext/vstring.h
> index 90a5683..57f36a6 100644
> --- a/libstdc++-v3/include/ext/vstring.h
> +

Re: Turn streamer cache to pointer_map

2011-05-02 Thread Jan Hubicka
> 
> If you skip node_map you can end up with false entries for re-used
> trees.  So I don't think that's a good idea.
The GTY marker is bogus there.  I believed that the cache is GTY annotated
and then the skip would be safe, since whether is in the map is also in the
following array.
But it is not GTY marked, so OK with that marker removed?

Honza


Re: [google] Remove unqualified lookups which break clang (issue4439085)

2011-05-02 Thread Paolo Carlini

On 05/02/2011 04:52 PM, Ollie Wild wrote:

Submitted to google/main.

Adding libstd...@gcc.gnu.org for trunk approval.

This is Ok for mainline and 4_6-branch.

Why nobody noticed so far? Is there a latent C++ front-end bug? Please 
double check (the last time, I took care of filing the corresponding C++ 
front-end issue)


Paolo.


Re: [patch] make default linker --hash-style configurable option

2011-05-02 Thread Joseph S. Myers
On Mon, 2 May 2011, Paul Pluzhnikov wrote:

> Ping? Ping? Ping? Ping?
> 
> This is getting ridiculous. Would someone please accept the patch,
> tell me what to fix in it to make it acceptable, or explain why it is
> a bad idea?

When pinging, please include the URL of the patch being pinged and CC 
relevant maintainers (in this case, build system maintainers).

-- 
Joseph S. Myers
jos...@codesourcery.com


Re: [build] More --enable-threads cleanup

2011-05-02 Thread Arnaud Charlet
> In my last --enable-threads cleanup patch
> 
>   [build, doc] Cleanup --enable-threads support
> http://gcc.gnu.org/ml/gcc-patches/2011-04/msg00735.html
> 
> I missed another opportunity, handled by this patch.

BTW, feel free to also remove any trace of --enable-threads=gnat.

This is a long obsolete option which has never really been used and should
be removed. I never got around the time to submit a patch to that effect,
so if you feel like doing this clean up, that'd be welcome.

Arno


Re: [build] mips-tfile.c, mips-tdump.c cleanup

2011-05-02 Thread Joseph S. Myers
On Mon, 2 May 2011, Rainer Orth wrote:

> Apart from the issues mentioned by Joseph, I'm removing Saber C support,
> use of private Size_t/Ptrdiff_t, and STATIC.  Those were the low-hanging
> fruit; I currently don't plan to go for other stuff (like removal of the
> remaining warnings) since I may obsolete the port in 4.7 (or 4.8 at the
> latest).

The most obvious other low-hanging fruit in the circumstances would be to 
stop these files being built for non-native as a fix for bug 3746, so that 
all-targets cross builds of "make all-gcc" (e.g. through Joern's 
config-list.mk, which is pending review) don't necessarily fall over on 
this target.

-- 
Joseph S. Myers
jos...@codesourcery.com


Re: Turn streamer cache to pointer_map

2011-05-02 Thread Richard Guenther
On Mon, May 2, 2011 at 4:35 PM, Michael Matz  wrote:
> Hi,
>
> On Mon, 2 May 2011, Jan Hubicka wrote:
>
>> !   d_entry.base.from = t;
>> !   slot = htab_find_slot (cache->node_map, &d_entry, INSERT);
>> !   if (*slot == NULL)
>>       {
>>         /* Determine the next slot to use in the cache.  */
>>         if (insert_at_next_slot_p)
>>       ix = VEC_length (tree, cache->nodes);
>>         else
>>       ix = *ix_p;
>> !
>> !       entry = (struct tree_int_map *)pool_alloc (cache->node_map_entries);
>> !       entry->base.from = t;
>> !       entry->to = ix;
>> !       *slot = entry;
>>
>>         lto_streamer_cache_add_to_node_array (cache, ix, t);
>>
>> --- 348,367 
>>                            bool insert_at_next_slot_p)
>>   {
>>     void **slot;
>>     unsigned ix;
>>     bool existed_p;
>>
>>     gcc_assert (t);
>>
>> !   slot = pointer_map_insert (cache->node_map, t);
>> !   if (!*slot)
>
> ix might legitimately be zero.  Hence this transformation is not
> equivalent.  You might want to enter ix+1 into the cache with the
> appropriate adjustment at read-out.  Same for the other places.

Or not use index zero.  Maybe better than also have to deal
with ix + 1 wrapping ...

Richard.

>
> Ciao,
> Michael.
>


Re: Turn streamer cache to pointer_map

2011-05-02 Thread Michael Matz
Hi,

On Mon, 2 May 2011, Richard Guenther wrote:

> >> --- 348,367 
> >>                            bool insert_at_next_slot_p)
> >>   {
> >>     void **slot;
> >>     unsigned ix;
> >>     bool existed_p;
> >>
> >>     gcc_assert (t);
> >>
> >> !   slot = pointer_map_insert (cache->node_map, t);
> >> !   if (!*slot)
> >
> > ix might legitimately be zero.  Hence this transformation is not
> > equivalent.  You might want to enter ix+1 into the cache with the
> > appropriate adjustment at read-out.  Same for the other places.
> 
> Or not use index zero.

I never like these sentinals.

> Maybe better than also have to deal with ix + 1 wrapping ...

We don't handle ix wrapping, why should we now suddenly care about ix+1 
wrapping?


Ciao,
Michael.

[PATCH][C] Change array size overflow check

2011-05-02 Thread Richard Guenther

This changes the code that deals with too large array sizes to
use int_fits_type_p instead of relying on the TREE_OVERFLOW setting
of the tree folder.  The latter will break once we don't treat
sizetypes specially (and they keep being unsigned).

Bootstrapped and tested on x86_64-unknown-linux-gnu, ok for trunk?

Thanks,
Richard.

2011-05-02  Richard Guenther  

* c-decl.c (grokdeclarator): Instead of looking at
TREE_OVERFLOW check if the constant fits in the index type.

Index: trunk/gcc/c-decl.c
===
*** trunk.orig/gcc/c-decl.c 2011-05-02 14:50:36.0 +0200
--- trunk/gcc/c-decl.c  2011-05-02 15:12:15.0 +0200
*** grokdeclarator (const struct c_declarato
*** 5368,5382 
 convert (index_type,
  size_one_node));
  
!   /* If that overflowed, the array is too big.  ???
!  While a size of INT_MAX+1 technically shouldn't
!  cause an overflow (because we subtract 1), the
!  overflow is recorded during the conversion to
!  index_type, before the subtraction.  Handling
!  this case seems like an unnecessary
!  complication.  */
!   if (TREE_CODE (itype) == INTEGER_CST
!   && TREE_OVERFLOW (itype))
  {
if (name)
  error_at (loc, "size of array %qE is too large",
--- 5368,5380 
 convert (index_type,
  size_one_node));
  
!   /* The above overflows when size does not fit
!  in index_type.
!  ???  While a size of INT_MAX+1 technically shouldn't
!  cause an overflow (because we subtract 1), handling
!  this case seems like an unnecessary complication.  */
!   if (TREE_CODE (size) == INTEGER_CST
!   && !int_fits_type_p (size, index_type))
  {
if (name)
  error_at (loc, "size of array %qE is too large",



Re: [Patch,AVR]: Fix PR27663

2011-05-02 Thread Denis Chertykov
2011/5/2 Georg-Johann Lay :
> This is a fix for an optimization flaw when a long value is composed
> from byte values.
>
> For -fsplit-wide-types (which is still default for avr) the code is
> worse than with -fno-split-wide-types. The code for the test case is
> better in either situations, i.e. compared to code without the patch,
> but it is still not optimal.
>
> Fixing this by some combine patterns is the only thing the BE can do.
> I did not write more complex patterns because things get too complex
> with little performance gain.
>
> Tested without regressions.
>
> Johann
>
> 2011-05-02  Georg-Johann Lay  
>
>        PR target/27663
>        * config/avr/predicates.md (const_8_16_24_operand): New predicate.
>        * config/avr/avr.md ("*iorqi.byte0",
>        "*iorqi.byte1-3"): New define_insn_and_split patterns.
>

I'm sorry, but I dot'n like to have a both combiner related patches in
port because code improvement isn't much and your patterns are
difficult to understand and maintain.

May be somebody else have a different oppinion ?
I'm open to discussion.

Denis.


Re: [google] Remove unqualified lookups which break clang (issue4439085)

2011-05-02 Thread Paolo Carlini

On 05/02/2011 04:58 PM, Paolo Carlini wrote:
Why nobody noticed so far? Is there a latent C++ front-end bug? Please 
double check (the last time, I took care of filing the corresponding 
C++ front-end issue)

-- Jason,

is it known that we accept the below?

Paolo.

//

template
  struct base
  {
void bar(T) { }
  };

template
  struct derived
  : base
  {
void
foo(T t)
{ bar(t); }
  };

template class derived;



[PATCH][?/n] TYPE_IS_SIZETYPE fixes

2011-05-02 Thread Richard Guenther

This is another tiny step towards making TYPE_IS_SIZETYPE not special
wrt sign-extension.  In output_constructor_regular_field we call
tree_low_cst without first assuring it won't ICE.  Instead of
doing that simply compute the zero-based index in double-ints
and assert that that result is representable in a HWI.  Being there
I noticed that strange comment and thought it is a good idea
to ICE instead of creating silently wrong code.  The cgraph code
compares a sign-extended tree to a unsigned (but atm still
sign-extended) size_int - that's bogus.  And we can avoid
creating a tree node by simply using double-int functions.

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

Richard.

2011-05-02  Richard Guenther  

* varasm.c (output_constructor_regular_field): Compute zero-based
index with double-ints.  Make sure to ICE instead of producing
wrong code.
* cgraph.c (cgraph_add_thunk): Do not create new tree nodes
in asserts.  Properly use a signed type.

Index: trunk/gcc/varasm.c
===
*** trunk.orig/gcc/varasm.c 2011-05-02 14:50:36.0 +0200
--- trunk/gcc/varasm.c  2011-05-02 15:15:59.0 +0200
*** output_constructor_regular_field (oc_loc
*** 4711,4719 
unsigned int align2;
  
if (local->index != NULL_TREE)
! fieldpos = (tree_low_cst (TYPE_SIZE_UNIT (TREE_TYPE (local->val)), 1)
!   * ((tree_low_cst (local->index, 0)
!   - tree_low_cst (local->min_index, 0;
else if (local->field != NULL_TREE)
  fieldpos = int_byte_position (local->field);
else
--- 4711,4723 
unsigned int align2;
  
if (local->index != NULL_TREE)
! {
!   double_int idx = double_int_sub (tree_to_double_int (local->index),
!  tree_to_double_int (local->min_index));
!   gcc_assert (double_int_fits_in_shwi_p (idx));
!   fieldpos = (tree_low_cst (TYPE_SIZE_UNIT (TREE_TYPE (local->val)), 1)
! * idx.low);
! }
else if (local->field != NULL_TREE)
  fieldpos = int_byte_position (local->field);
else
*** output_constructor_regular_field (oc_loc
*** 4760,4772 
 better be last.  */
  gcc_assert (!fieldsize || !DECL_CHAIN (local->field));
}
!   else if (DECL_SIZE_UNIT (local->field))
!   {
! /* ??? This can't be right.  If the decl size overflows
!a host integer we will silently emit no data.  */
! if (host_integerp (DECL_SIZE_UNIT (local->field), 1))
!   fieldsize = tree_low_cst (DECL_SIZE_UNIT (local->field), 1);
!   }
  }
else
  fieldsize = int_size_in_bytes (TREE_TYPE (local->type));
--- 4764,4771 
 better be last.  */
  gcc_assert (!fieldsize || !DECL_CHAIN (local->field));
}
!   else
!   fieldsize = tree_low_cst (DECL_SIZE_UNIT (local->field), 1);
  }
else
  fieldsize = int_size_in_bytes (TREE_TYPE (local->type));
Index: trunk/gcc/cgraph.c
===
*** trunk.orig/gcc/cgraph.c 2011-05-02 12:20:22.0 +0200
--- trunk/gcc/cgraph.c  2011-05-02 15:42:19.0 +0200
*** cgraph_add_thunk (struct cgraph_node *de
*** 613,620 
node = cgraph_same_body_alias_1 (decl_node, alias, decl);
gcc_assert (node);
gcc_checking_assert (!virtual_offset
!  || tree_int_cst_equal (virtual_offset,
! size_int (virtual_value)));
node->thunk.fixed_offset = fixed_offset;
node->thunk.this_adjusting = this_adjusting;
node->thunk.virtual_value = virtual_value;
--- 613,621 
node = cgraph_same_body_alias_1 (decl_node, alias, decl);
gcc_assert (node);
gcc_checking_assert (!virtual_offset
!  || double_int_equal_p
!   (tree_to_double_int (virtual_offset),
!shwi_to_double_int (virtual_value)));
node->thunk.fixed_offset = fixed_offset;
node->thunk.this_adjusting = this_adjusting;
node->thunk.virtual_value = virtual_value;


Ping^4 Re: Target header etc. cleanup patch

2011-05-02 Thread Joseph S. Myers
Ping^4.  Parts of this patch 
 are still 
pending review, for targets fr30, m32r, mn10300, rx, v850 (target 
maintainers CC:ed).  This version applies cleanly to current trunk.

I have seen no comments from the mn10300 maintainers.  For the other 
targets, Nick wanted to keep abbreviations for certain types 
 and no-one else 
has commented on that issue, though as I noted in 
 I think 
abbreviating const char * is actively bad.  Cstar - defined for mn10300, 
whose maintainers haven't commented - is also the macro I care most about 
getting rid of in what's left of this patch, as it's the one that shows up 
as a false positive in my target macro listing script (the point of the 
original patch was to get rid of several such false positives, plus making 
related cleanups that showed up in the process).

2011-05-02  Joseph Myers  

* config/fr30/fr30-protos.h (Mmode): Don't define.
* config/m32r/m32r-protos.h (Mmode): Don't define.  Expand
definition where used.
* config/mn10300/mn10300-protos.h (Mmode, Cstar, Rclas): Don't
define.  Expand definitions where used.
* config/rx/rx-protos.h (Mmode, Fargs, Rcode): Don't define.
Expand definitions where used.
* config/rx/rx.c (rx_is_legitimate_address, rx_function_arg_size,
rx_function_arg, rx_function_arg_advance,
rx_function_arg_boundary): Expand definitions of those macros.
* config/v850/v850-protos.h (Mmode): Don't define.  Expand
definition where used.

Index: gcc/config/m32r/m32r-protos.h
===
--- gcc/config/m32r/m32r-protos.h   (revision 173254)
+++ gcc/config/m32r/m32r-protos.h   (working copy)
@@ -21,7 +21,6 @@
 
 /* Function prototypes that cannot exist in m32r.h due to dependency
complications.  */
-#define Mmode enum machine_mode
 
 extern void   m32r_init (void);
 extern void   m32r_init_expanders (void);
@@ -52,16 +51,14 @@ extern rtxm32r_return_addr (int);
 extern rtxm32r_function_symbol (const char *);
 
 #ifdef HAVE_MACHINE_MODES
-extern intcall_operand (rtx, Mmode);
-extern intsmall_data_operand (rtx, Mmode);
-extern intaddr24_operand (rtx, Mmode);
-extern intaddr32_operand (rtx, Mmode);
-extern intcall26_operand (rtx, Mmode);
-extern intmemreg_operand (rtx, Mmode);
-extern intsmall_insn_p (rtx, Mmode);
+extern intcall_operand (rtx, enum machine_mode);
+extern intsmall_data_operand (rtx, enum machine_mode);
+extern intaddr24_operand (rtx, enum machine_mode);
+extern intaddr32_operand (rtx, enum machine_mode);
+extern intcall26_operand (rtx, enum machine_mode);
+extern intmemreg_operand (rtx, enum machine_mode);
+extern intsmall_insn_p (rtx, enum machine_mode);
 
 #endif /* HAVE_MACHINE_MODES */
 
 #endif /* RTX_CODE */
-
-#undef  Mmode
Index: gcc/config/rx/rx-protos.h
===
--- gcc/config/rx/rx-protos.h   (revision 173254)
+++ gcc/config/rx/rx-protos.h   (working copy)
@@ -21,11 +21,6 @@
 #ifndef GCC_RX_PROTOS_H
 #define GCC_RX_PROTOS_H
 
-/* A few abbreviations to make the prototypes shorter.  */
-#define Mmode  enum machine_mode
-#define Fargs  CUMULATIVE_ARGS
-#define Rcode  enum rtx_code
-
 extern int rx_align_for_label (void);
 extern voidrx_expand_prologue (void);
 extern int rx_initial_elimination_offset (int, int);
@@ -37,11 +32,13 @@ extern void rx_emit_stack_pu
 extern voidrx_expand_epilogue (bool);
 extern char *  rx_gen_move_template (rtx *, bool);
 extern boolrx_legitimate_constant_p (enum machine_mode, rtx);
-extern boolrx_is_restricted_memory_address (rtx, Mmode);
-extern boolrx_match_ccmode (rtx, Mmode);
+extern boolrx_is_restricted_memory_address (rtx,
+enum machine_mode);
+extern boolrx_match_ccmode (rtx, enum machine_mode);
 extern voidrx_notice_update_cc (rtx body, rtx insn);
-extern voidrx_split_cbranch (Mmode, Rcode, rtx, rtx, rtx);
-extern Mmode   rx_select_cc_mode (Rcode, rtx, rtx);
+extern voidrx_split_cbranch (enum machine_mode, enum rtx_code,
+ rtx, rtx, rtx);
+extern enum machine_mode   rx_select_cc_mode (enum rtx_code, rtx, rtx);
 #endif
 
 #endif /* GCC_RX_PROTOS_H */
Index: gcc/config/rx/rx.c
===
--- gcc/config/rx/rx.c  (revision 173254)
+++ gcc/config/rx/rx.c  (working copy)
@@ -78,7 +78,8 @@ rx_small_data_operand (rtx op)
 }
 
 static bool
-rx_is_legitimate_address (Mmode mode, rtx x, bool strict ATTRIBUTE_UNUSED)
+rx_is_legi

[Patch,AVR]: Fix PR45099

2011-05-02 Thread Georg-Johann Lay
PR45099 is an extension that gives an error when a fixed register is
needed to pass a parameter to a function.

Because the program will show malfunction when such code is generated,
anyway, I think an error is more appropriate than a warning (as
proposed in the PR).

Johann

2011-05-02  Georg-Johann Lay  

PR target/45099

* config/avr/avr.c (avr_function_arg_advance): Error if a fixed
register is needed for a function argument.
Index: config/avr/avr.c
===
--- config/avr/avr.c	(Revision 172902)
+++ config/avr/avr.c	(Arbeitskopie)
@@ -1794,6 +1794,20 @@ avr_function_arg_advance (CUMULATIVE_ARG
   cfun->machine->sibcall_fails = 1;
 }
 
+  /* Test if all registers needed by the ABI are actually available.  If the
+ user has fixed a GPR needed to pass an argument, an (implicit) function
+ call would clobber that fixed register.  See PR45099 for an example.  */
+  
+  if (cum->regno >= 0)
+{
+  int regno;
+
+  for (regno = cum->regno; regno < cum->regno + bytes; regno++)
+if (fixed_regs[regno])
+  error ("Register %s is needed to pass a parameter but is fixed",
+ reg_names[regno]);
+}
+  
   if (cum->nregs <= 0)
 {
   cum->nregs = 0;


Re: Turn streamer cache to pointer_map

2011-05-02 Thread Richard Guenther
On Mon, May 2, 2011 at 5:15 PM, Michael Matz  wrote:
> Hi,
>
> On Mon, 2 May 2011, Richard Guenther wrote:
>
>> >> --- 348,367 
>> >>                            bool insert_at_next_slot_p)
>> >>   {
>> >>     void **slot;
>> >>     unsigned ix;
>> >>     bool existed_p;
>> >>
>> >>     gcc_assert (t);
>> >>
>> >> !   slot = pointer_map_insert (cache->node_map, t);
>> >> !   if (!*slot)
>> >
>> > ix might legitimately be zero.  Hence this transformation is not
>> > equivalent.  You might want to enter ix+1 into the cache with the
>> > appropriate adjustment at read-out.  Same for the other places.
>>
>> Or not use index zero.
>
> I never like these sentinals.

Well.  Or use pointer_map_contains () here.

Richard.

>> Maybe better than also have to deal with ix + 1 wrapping ...
>
> We don't handle ix wrapping, why should we now suddenly care about ix+1
> wrapping?
>
> Ciao,
> Michael.


Re: Turn streamer cache to pointer_map

2011-05-02 Thread Jan Hubicka
> Hi,
> 
> On Mon, 2 May 2011, Richard Guenther wrote:
> 
> > >> --- 348,367 
> > >>                            bool insert_at_next_slot_p)
> > >>   {
> > >>     void **slot;
> > >>     unsigned ix;
> > >>     bool existed_p;
> > >>
> > >>     gcc_assert (t);
> > >>
> > >> !   slot = pointer_map_insert (cache->node_map, t);
> > >> !   if (!*slot)
> > >
> > > ix might legitimately be zero.  Hence this transformation is not
> > > equivalent.  You might want to enter ix+1 into the cache with the
> > > appropriate adjustment at read-out.  Same for the other places.
> > 
> > Or not use index zero.
> 
> I never like these sentinals.
> 
> > Maybe better than also have to deal with ix + 1 wrapping ...
> 
> We don't handle ix wrapping, why should we now suddenly care about ix+1 
> wrapping?


Duh, I actually intended to implement the ix+1 wrapping, but got dragged into 
discussions
about thunks ;)

I am testing the following patch.  Seems sane?

Honza

Index: lto-streamer.c
===
*** lto-streamer.c  (revision 173251)
--- lto-streamer.c  (working copy)
*** lto_streamer_cache_insert_1 (struct lto_
*** 348,373 
 bool insert_at_next_slot_p)
  {
void **slot;
-   struct tree_int_map d_entry, *entry;
unsigned ix;
bool existed_p;
  
gcc_assert (t);
  
!   d_entry.base.from = t;
!   slot = htab_find_slot (cache->node_map, &d_entry, INSERT);
!   if (*slot == NULL)
  {
/* Determine the next slot to use in the cache.  */
if (insert_at_next_slot_p)
ix = VEC_length (tree, cache->nodes);
else
ix = *ix_p;
! 
!   entry = (struct tree_int_map *)pool_alloc (cache->node_map_entries);
!   entry->base.from = t;
!   entry->to = ix;
!   *slot = entry;
  
lto_streamer_cache_add_to_node_array (cache, ix, t);
  
--- 348,367 
 bool insert_at_next_slot_p)
  {
void **slot;
unsigned ix;
bool existed_p;
  
gcc_assert (t);
  
!   slot = pointer_map_insert (cache->node_map, t);
!   if (!*slot)
  {
/* Determine the next slot to use in the cache.  */
if (insert_at_next_slot_p)
ix = VEC_length (tree, cache->nodes);
else
ix = *ix_p;
!*slot = (void *)(size_t) (ix + 1);
  
lto_streamer_cache_add_to_node_array (cache, ix, t);
  
*** lto_streamer_cache_insert_1 (struct lto_
*** 376,383 
  }
else
  {
!   entry = (struct tree_int_map *) *slot;
!   ix = entry->to;
  
if (!insert_at_next_slot_p && ix != *ix_p)
{
--- 370,376 
  }
else
  {
!   ix = (size_t) *slot - 1;
  
if (!insert_at_next_slot_p && ix != *ix_p)
{
*** lto_streamer_cache_lookup (struct lto_st
*** 442,455 
   unsigned *ix_p)
  {
void **slot;
-   struct tree_int_map d_slot;
bool retval;
unsigned ix;
  
gcc_assert (t);
  
!   d_slot.base.from = t;
!   slot = htab_find_slot (cache->node_map, &d_slot, NO_INSERT);
if (slot == NULL)
  {
retval = false;
--- 435,446 
   unsigned *ix_p)
  {
void **slot;
bool retval;
unsigned ix;
  
gcc_assert (t);
  
!   slot = pointer_map_contains  (cache->node_map, t);
if (slot == NULL)
  {
retval = false;
*** lto_streamer_cache_lookup (struct lto_st
*** 458,464 
else
  {
retval = true;
!   ix = ((struct tree_int_map *) *slot)->to;
  }
  
if (ix_p)
--- 449,455 
else
  {
retval = true;
!   ix = (size_t) *slot - 1;
  }
  
if (ix_p)
*** lto_streamer_cache_create (void)
*** 608,618 
  
cache = XCNEW (struct lto_streamer_cache_d);
  
!   cache->node_map = htab_create (101, tree_int_map_hash, tree_int_map_eq, 
NULL);
! 
!   cache->node_map_entries = create_alloc_pool ("node map",
!  sizeof (struct tree_int_map),
!  100);
  
/* Load all the well-known tree nodes that are always created by
   the compiler on startup.  This prevents writing them out
--- 599,605 
  
cache = XCNEW (struct lto_streamer_cache_d);
  
!   cache->node_map = pointer_map_create ();
  
/* Load all the well-known tree nodes that are always created by
   the compiler on startup.  This prevents writing them out
*** lto_streamer_cache_delete (struct lto_st
*** 636,643 
if (c == NULL)
  return;
  
!   htab_delete (c->node_map);
!   free_alloc_pool (c->node_map_entries);
VEC_free (tree, heap, c->nodes);
free (c);
  }
--- 623,629 
if (c == NULL)
  return;
  
!   pointer_map_destroy (c->node_map);
VEC_free (tree, heap, c->nodes);
free (c);
  }
Index: lto-streamer.h
===
*** lt

Re: Ping^4 Re: Target header etc. cleanup patch

2011-05-02 Thread Richard Guenther
On Mon, May 2, 2011 at 5:21 PM, Joseph S. Myers  wrote:
> Ping^4.  Parts of this patch
>  are still
> pending review, for targets fr30, m32r, mn10300, rx, v850 (target
> maintainers CC:ed).  This version applies cleanly to current trunk.
>
> I have seen no comments from the mn10300 maintainers.  For the other
> targets, Nick wanted to keep abbreviations for certain types
>  and no-one else
> has commented on that issue, though as I noted in
>  I think
> abbreviating const char * is actively bad.  Cstar - defined for mn10300,
> whose maintainers haven't commented - is also the macro I care most about
> getting rid of in what's left of this patch, as it's the one that shows up
> as a false positive in my target macro listing script (the point of the
> original patch was to get rid of several such false positives, plus making
> related cleanups that showed up in the process).

Ok except for the changes the target maintainer objects to.  I do agree
with Joseph and if another maintainer also says Ok I think we should
overrule him.

Thanks,
Richard.

> 2011-05-02  Joseph Myers  
>
>        * config/fr30/fr30-protos.h (Mmode): Don't define.
>        * config/m32r/m32r-protos.h (Mmode): Don't define.  Expand
>        definition where used.
>        * config/mn10300/mn10300-protos.h (Mmode, Cstar, Rclas): Don't
>        define.  Expand definitions where used.
>        * config/rx/rx-protos.h (Mmode, Fargs, Rcode): Don't define.
>        Expand definitions where used.
>        * config/rx/rx.c (rx_is_legitimate_address, rx_function_arg_size,
>        rx_function_arg, rx_function_arg_advance,
>        rx_function_arg_boundary): Expand definitions of those macros.
>        * config/v850/v850-protos.h (Mmode): Don't define.  Expand
>        definition where used.
>
> Index: gcc/config/m32r/m32r-protos.h
> ===
> --- gcc/config/m32r/m32r-protos.h       (revision 173254)
> +++ gcc/config/m32r/m32r-protos.h       (working copy)
> @@ -21,7 +21,6 @@
>
>  /* Function prototypes that cannot exist in m32r.h due to dependency
>    complications.  */
> -#define Mmode enum machine_mode
>
>  extern void   m32r_init (void);
>  extern void   m32r_init_expanders (void);
> @@ -52,16 +51,14 @@ extern rtx    m32r_return_addr (int);
>  extern rtx    m32r_function_symbol (const char *);
>
>  #ifdef HAVE_MACHINE_MODES
> -extern int    call_operand (rtx, Mmode);
> -extern int    small_data_operand (rtx, Mmode);
> -extern int    addr24_operand (rtx, Mmode);
> -extern int    addr32_operand (rtx, Mmode);
> -extern int    call26_operand (rtx, Mmode);
> -extern int    memreg_operand (rtx, Mmode);
> -extern int    small_insn_p (rtx, Mmode);
> +extern int    call_operand (rtx, enum machine_mode);
> +extern int    small_data_operand (rtx, enum machine_mode);
> +extern int    addr24_operand (rtx, enum machine_mode);
> +extern int    addr32_operand (rtx, enum machine_mode);
> +extern int    call26_operand (rtx, enum machine_mode);
> +extern int    memreg_operand (rtx, enum machine_mode);
> +extern int    small_insn_p (rtx, enum machine_mode);
>
>  #endif /* HAVE_MACHINE_MODES */
>
>  #endif /* RTX_CODE */
> -
> -#undef  Mmode
> Index: gcc/config/rx/rx-protos.h
> ===
> --- gcc/config/rx/rx-protos.h   (revision 173254)
> +++ gcc/config/rx/rx-protos.h   (working copy)
> @@ -21,11 +21,6 @@
>  #ifndef GCC_RX_PROTOS_H
>  #define GCC_RX_PROTOS_H
>
> -/* A few abbreviations to make the prototypes shorter.  */
> -#define Mmode  enum machine_mode
> -#define Fargs  CUMULATIVE_ARGS
> -#define Rcode  enum rtx_code
> -
>  extern int             rx_align_for_label (void);
>  extern void            rx_expand_prologue (void);
>  extern int             rx_initial_elimination_offset (int, int);
> @@ -37,11 +32,13 @@ extern void             rx_emit_stack_pu
>  extern void            rx_expand_epilogue (bool);
>  extern char *          rx_gen_move_template (rtx *, bool);
>  extern bool            rx_legitimate_constant_p (enum machine_mode, rtx);
> -extern bool            rx_is_restricted_memory_address (rtx, Mmode);
> -extern bool            rx_match_ccmode (rtx, Mmode);
> +extern bool            rx_is_restricted_memory_address (rtx,
> +                                                        enum machine_mode);
> +extern bool            rx_match_ccmode (rtx, enum machine_mode);
>  extern void            rx_notice_update_cc (rtx body, rtx insn);
> -extern void            rx_split_cbranch (Mmode, Rcode, rtx, rtx, rtx);
> -extern Mmode           rx_select_cc_mode (Rcode, rtx, rtx);
> +extern void            rx_split_cbranch (enum machine_mode, enum rtx_code,
> +                                         rtx, rtx, rtx);
> +extern enum machine_mode       rx_select_cc_mode (enum rtx_co

Re: Turn streamer cache to pointer_map

2011-05-02 Thread Richard Guenther
2011/5/2 Jan Hubicka :
>> Hi,
>>
>> On Mon, 2 May 2011, Richard Guenther wrote:
>>
>> > >> --- 348,367 
>> > >>                            bool insert_at_next_slot_p)
>> > >>   {
>> > >>     void **slot;
>> > >>     unsigned ix;
>> > >>     bool existed_p;
>> > >>
>> > >>     gcc_assert (t);
>> > >>
>> > >> !   slot = pointer_map_insert (cache->node_map, t);
>> > >> !   if (!*slot)
>> > >
>> > > ix might legitimately be zero.  Hence this transformation is not
>> > > equivalent.  You might want to enter ix+1 into the cache with the
>> > > appropriate adjustment at read-out.  Same for the other places.
>> >
>> > Or not use index zero.
>>
>> I never like these sentinals.
>>
>> > Maybe better than also have to deal with ix + 1 wrapping ...
>>
>> We don't handle ix wrapping, why should we now suddenly care about ix+1
>> wrapping?
>
>
> Duh, I actually intended to implement the ix+1 wrapping, but got dragged into 
> discussions
> about thunks ;)
>
> I am testing the following patch.  Seems sane?

Ok if it works.

Richard.

> Honza
>
> Index: lto-streamer.c
> ===
> *** lto-streamer.c      (revision 173251)
> --- lto-streamer.c      (working copy)
> *** lto_streamer_cache_insert_1 (struct lto_
> *** 348,373 
>                             bool insert_at_next_slot_p)
>  {
>    void **slot;
> -   struct tree_int_map d_entry, *entry;
>    unsigned ix;
>    bool existed_p;
>
>    gcc_assert (t);
>
> !   d_entry.base.from = t;
> !   slot = htab_find_slot (cache->node_map, &d_entry, INSERT);
> !   if (*slot == NULL)
>      {
>        /* Determine the next slot to use in the cache.  */
>        if (insert_at_next_slot_p)
>        ix = VEC_length (tree, cache->nodes);
>        else
>        ix = *ix_p;
> !
> !       entry = (struct tree_int_map *)pool_alloc (cache->node_map_entries);
> !       entry->base.from = t;
> !       entry->to = ix;
> !       *slot = entry;
>
>        lto_streamer_cache_add_to_node_array (cache, ix, t);
>
> --- 348,367 
>                             bool insert_at_next_slot_p)
>  {
>    void **slot;
>    unsigned ix;
>    bool existed_p;
>
>    gcc_assert (t);
>
> !   slot = pointer_map_insert (cache->node_map, t);
> !   if (!*slot)
>      {
>        /* Determine the next slot to use in the cache.  */
>        if (insert_at_next_slot_p)
>        ix = VEC_length (tree, cache->nodes);
>        else
>        ix = *ix_p;
> !        *slot = (void *)(size_t) (ix + 1);
>
>        lto_streamer_cache_add_to_node_array (cache, ix, t);
>
> *** lto_streamer_cache_insert_1 (struct lto_
> *** 376,383 
>      }
>    else
>      {
> !       entry = (struct tree_int_map *) *slot;
> !       ix = entry->to;
>
>        if (!insert_at_next_slot_p && ix != *ix_p)
>        {
> --- 370,376 
>      }
>    else
>      {
> !       ix = (size_t) *slot - 1;
>
>        if (!insert_at_next_slot_p && ix != *ix_p)
>        {
> *** lto_streamer_cache_lookup (struct lto_st
> *** 442,455 
>                           unsigned *ix_p)
>  {
>    void **slot;
> -   struct tree_int_map d_slot;
>    bool retval;
>    unsigned ix;
>
>    gcc_assert (t);
>
> !   d_slot.base.from = t;
> !   slot = htab_find_slot (cache->node_map, &d_slot, NO_INSERT);
>    if (slot == NULL)
>      {
>        retval = false;
> --- 435,446 
>                           unsigned *ix_p)
>  {
>    void **slot;
>    bool retval;
>    unsigned ix;
>
>    gcc_assert (t);
>
> !   slot = pointer_map_contains  (cache->node_map, t);
>    if (slot == NULL)
>      {
>        retval = false;
> *** lto_streamer_cache_lookup (struct lto_st
> *** 458,464 
>    else
>      {
>        retval = true;
> !       ix = ((struct tree_int_map *) *slot)->to;
>      }
>
>    if (ix_p)
> --- 449,455 
>    else
>      {
>        retval = true;
> !       ix = (size_t) *slot - 1;
>      }
>
>    if (ix_p)
> *** lto_streamer_cache_create (void)
> *** 608,618 
>
>    cache = XCNEW (struct lto_streamer_cache_d);
>
> !   cache->node_map = htab_create (101, tree_int_map_hash, tree_int_map_eq, 
> NULL);
> !
> !   cache->node_map_entries = create_alloc_pool ("node map",
> !                                              sizeof (struct tree_int_map),
> !                                              100);
>
>    /* Load all the well-known tree nodes that are always created by
>       the compiler on startup.  This prevents writing them out
> --- 599,605 
>
>    cache = XCNEW (struct lto_streamer_cache_d);
>
> !   cache->node_map = pointer_map_create ();
>
>    /* Load all the well-known tree nodes that are always created by
>       the compiler on startup.  This prevents writing them out
> *** lto_streamer_cache_delete (struct lto_st
> *** 636,643 
>    if (c == NULL)
>      return;
>
> !   htab_delete (c->node_map);
> !   free_alloc_pool (c->node_map_entries);
>    VEC_free (tree, heap, c->nodes);
>    free (c);
>  }
> --- 

Re: [PATCH][C] Change array size overflow check

2011-05-02 Thread Joseph S. Myers
On Mon, 2 May 2011, Richard Guenther wrote:

> This changes the code that deals with too large array sizes to
> use int_fits_type_p instead of relying on the TREE_OVERFLOW setting
> of the tree folder.  The latter will break once we don't treat
> sizetypes specially (and they keep being unsigned).
> 
> Bootstrapped and tested on x86_64-unknown-linux-gnu, ok for trunk?

An array size in C or C++ ought to be considered to overflow (and so give 
an error if the size is compile-time constant) if the size of the array in 
bytes is greater than or equal to half the address space, because it is 
then no longer possible to compute differences between all array elements, 
and pointers to just past the end of the array, reliably as ptrdiff_t 
values (cf. PR 45779).  Thus, overflow in a signed rather than unsigned 
type is what's relevant.

I don't know if there's a relevant testcase in the testsuite, but the 
patch is OK with the addition of a testcase such as

/* { dg-do compile } */
/* { dg-options "" } */

typedef __SIZE_TYPE__ size_t;

extern char a[((size_t)-1 >> 1) + 1]; /* { dg-error "too large" } */
extern char b[((size_t)-1 >> 1)];
extern int c[(((size_t)-1 >> 1) + 1) / sizeof(int)]; /* { dg-error "too large" 
} */
extern int d[((size_t)-1 >> 1) / sizeof(int)];

supposing it passes.

-- 
Joseph S. Myers
jos...@codesourcery.com


Re: [google] Remove unqualified lookups which break clang (issue4439085)

2011-05-02 Thread Paolo Carlini

On 05/02/2011 05:19 PM, Paolo Carlini wrote:

template
  struct base
  {
void bar(T) { }
  };

template
  struct derived
  : base
  {
void
foo(T t)
{ bar(t); }
  };

template class derived;

Gosh, c++/24163

Paolo.



Re: [PATCH][C] Change array size overflow check

2011-05-02 Thread Richard Guenther
On Mon, 2 May 2011, Joseph S. Myers wrote:

> On Mon, 2 May 2011, Richard Guenther wrote:
> 
> > This changes the code that deals with too large array sizes to
> > use int_fits_type_p instead of relying on the TREE_OVERFLOW setting
> > of the tree folder.  The latter will break once we don't treat
> > sizetypes specially (and they keep being unsigned).
> > 
> > Bootstrapped and tested on x86_64-unknown-linux-gnu, ok for trunk?
> 
> An array size in C or C++ ought to be considered to overflow (and so give 
> an error if the size is compile-time constant) if the size of the array in 
> bytes is greater than or equal to half the address space, because it is 
> then no longer possible to compute differences between all array elements, 
> and pointers to just past the end of the array, reliably as ptrdiff_t 
> values (cf. PR 45779).  Thus, overflow in a signed rather than unsigned 
> type is what's relevant.
> 
> I don't know if there's a relevant testcase in the testsuite, but the 
> patch is OK with the addition of a testcase such as
> 
> /* { dg-do compile } */
> /* { dg-options "" } */
> 
> typedef __SIZE_TYPE__ size_t;
> 
> extern char a[((size_t)-1 >> 1) + 1]; /* { dg-error "too large" } */
> extern char b[((size_t)-1 >> 1)];
> extern int c[(((size_t)-1 >> 1) + 1) / sizeof(int)]; /* { dg-error "too 
> large" } */
> extern int d[((size_t)-1 >> 1) / sizeof(int)];
> 
> supposing it passes.

We do have similar testcases in gcc.dg/large-size-array*.c, but not
exactly testing the bound.  The above testcase also complains with
-pedantic about

t.c:3:13: error: size of array ‘a’ is too large
t.c:4:1: error: overflow in constant expression [-Woverflow]
t.c:5:12: error: size of array ‘c’ is too large
t.c:6:1: error: overflow in constant expression [-Woverflow]

with and without the patch.  I can add -Wno-overflow to the flags.
Ok with that?

Thanks,
Richard.

Re: [google] Multiple source LIPO test cases and bug fixes (issue4441084)

2011-05-02 Thread Xinliang David Li
thanks. Will correct.

David

On Mon, May 2, 2011 at 2:03 AM, Rainer Orth  
wrote:
> David,
>
>> 2011-05-01  David Li  
>>
>>       * testsuite/lib/profopt.exp (proc): Multiple source file support.
>                                     ^
>
> This is wrong, the proc is called profopt-execute.
>
>>       * testsuite/gcc.dg/tree-prof/lipo/lipo.exp (load_lib):
>                                                    ^
>>       Multiple source file support.
>
> Wrong again: not inside any proc.  Just omit.
>
>        Rainer
>
> --
> -
> Rainer Orth, Center for Biotechnology, Bielefeld University
>


Re: [patch] make default linker --hash-style configurable option

2011-05-02 Thread Paul Pluzhnikov
On Mon, May 2, 2011 at 7:59 AM, Joseph S. Myers  wrote:

Thanks for your comments.

> When pinging, please include the URL of the patch being pinged and CC

http://gcc.gnu.org/ml/gcc-patches/2011-04/msg00246.html

> relevant maintainers (in this case, build system maintainers).

All of them? [I've started with two ...]

Thanks!
-- 
Paul Pluzhnikov


Re: [Patch,AVR]: Fix PR45099

2011-05-02 Thread Nathan Froyd
On Mon, May 02, 2011 at 05:23:48PM +0200, Georg-Johann Lay wrote:
> PR45099 is an extension that gives an error when a fixed register is
> needed to pass a parameter to a function.
> 
> Because the program will show malfunction when such code is generated,
> anyway, I think an error is more appropriate than a warning (as
> proposed in the PR).

This seems like something that should be handled by common code.

-Nathan


Re: [PATCH][C] Change array size overflow check

2011-05-02 Thread Joseph S. Myers
On Mon, 2 May 2011, Richard Guenther wrote:

> We do have similar testcases in gcc.dg/large-size-array*.c, but not
> exactly testing the bound.  The above testcase also complains with
> -pedantic about
> 
> t.c:3:13: error: size of array 'a' is too large
> t.c:4:1: error: overflow in constant expression [-Woverflow]
> t.c:5:12: error: size of array 'c' is too large
> t.c:6:1: error: overflow in constant expression [-Woverflow]
> 
> with and without the patch.  I can add -Wno-overflow to the flags.
> Ok with that?

Those overflow errors are bugs (the tests have no overflowing constant 
expression, it must be something the compiler is generating internally), 
and it seems they only appear for 64-bit compilation for me, not for 
32-bit, for some reason.  But as they are independent of the patch, OK 
with -Wno-overflow and with a PR filed for the bogus overflow errors.

(I get the overflow errors for a char array for a size of 
((size_t)-1 >> 4)+1 but not for ((size_t)-1 >> 4), i.e. 1ULL<<60 bytes is 
the point where the bogus errors start.)

-- 
Joseph S. Myers
jos...@codesourcery.com


Re: [google] Patch to support calling multi-versioned functions via new GCC builtin. (issue4440078)

2011-05-02 Thread Xinliang David Li
On Mon, May 2, 2011 at 2:11 AM, Richard Guenther
 wrote:
> On Fri, Apr 29, 2011 at 6:23 PM, Xinliang David Li  wrote:
>> Here is the background for this feature:
>>
>> 1) People relies on function multi-version to explore hw features and
>> squeeze performance, but there is no standard ways of doing so, either
>> a) using indirect function calls with function pointers set at program
>> initialization; b) using manual dispatch at each callsite; b) using
>> features like IFUNC.  The dispatch mechanism needs to be promoted to
>> the language level and becomes the first class citizen;
>
> You are not doing that, you are inventing a new (crude) GCC extension.

To capture the high level semantics and prevent user from lowering the
dispatch calls into forms compiler can not recognize, language
extension is the way to go.

>

>> See above. Multi-way dispatch can be added similarly.
>
> Not with the specified syntax.  So you'd end up with _two_
> language extensions.  That's bad (and unacceptable, IMHO).

This part can be improved.

>
>>
>>>
>>> That's a nice idea, but why not simply process all functions with
>>> a const attribute and no arguments this way?  IMHO
>>>
>>> int testsse (void) __attribute__((const));
>>>
>>> is as good and avoids the new attribute completely.  The pass would
>>> also benefit other uses of this idiom (giving a way to have global
>>> dynamic initializers in C).  The functions may not be strictly 'const'
>>> in a way the compiler autodetects this attribute but it presents
>>> exactly the promises to the compiler that allow this optimization.
>>>
>>> Thus, please split this piece out into a separate patch and use
>>> the const attribute.
>>
>>
>> Sounds good.
>>

>>
>> 1) the function selection may happen in a different function;
>
> Well, sure.  I propose to have the above as lowered form.  If people
> deliberately obfuscate code it's their fault.  Your scheme simply
> makes that obfuscation impossible (or less likely possible).  So
> 1) is not a valid argument.

Lowering too early may defeat the purpose because

1) the desired optimization may not happen subject to many compiler
heuristic changes;
2) it has other side effects such as wrong estimation of function size
which may impact inlining
3) it limits the lowering into one form which may not be ideal  --
with builtin_dispatch, after hoisting optimization, the lowering can
use more efficient IFUNC scheme, for instance.

>
>
> My point is that such optimization is completely independent of
> that dispatch thing.  The above could as well be a selection to
> use different input arrays, one causing alias analysis issues
> and one not.
>
> Thus, a __builtin_dispatch centric optimization pass is the wrong
> way to go.

I agree that many things can implemented in different ways, but a high
level standard builtin_dispatch mechanism doing hoisting
interprocedcurally is cleaner and simpler and targeted for function
multi-versioning -- it does not depend on/rely on later phase's
heuristic tunings to make the right things to happen. Function MV
deserves this level of treatment as it will become more and more
important for some users (e.g., Google).

>
> Now, with FDO I'd expect the foo is inlined into bar (because foo
> is deemed hot),

That is a myth -- the truth is that there are other heuristics which
can prevent this from happening.

> then you only need to deal with loop unswitching,
> which should be easy to drive from FDO.

Same here -- the loop body may not be well formed/recognized. The loop
nests may not be perfectly nested, or other unswitching heuristics may
block it from happening.  This is the common problem form many other
things that get lowered too early. It is cleaner to make the high
level transformation first in IPA, and let unswitching dealing with
intra-procedural optimization.

Thanks,

David

>
> Richard.
>
>>
>>
>> Thanks,
>>
>> David
>>
>>
>>
>>>
>>> Note that we already have special FDO support for indirect to direct
>>> call promotion, so that might work already.
>>>
>>> Thus, with all this, __builtin_dispatch would be more like syntactic
>>> sugar to avoid writing above switch statement yourself.  If you restrict
>>> that sugar to a constant number of candidates it can be replaced by
>>> a macro (or several ones, specialized for the number of candidates).
>>>
>>> Richard.
>>>
  For the call graph that looks like this before cloning :

 func_cold > func_hot > findOnes > IsPopCntSupported > 
 popcnt
                                                |
                                                -> no_popcnt

  where popcnt and no_popcnt are the multi-versioned functions, then after 
 cloning :

 func_cold >IsPopCntSupported > func_hot_clone0 > 
 findOnes_clone0 > popcnt
                              |
                               > func_hot_clone1 > findOnes_clone1 
 > no_popcnt




  Flags

[build] Move Solaris 2 startup files to toplevel libgcc

2011-05-02 Thread Rainer Orth
It has long been on my agenda to perform/complete the toplevel libgcc
migration for my targets.  Although Solaris is the most complicated of
the three, it lays some infrastructure for the others, so I'm starting
with this patch.  The ones for IRIX 6 and Tru64 UNIX will follow once
the dust on this one has settled (and they have been tested :-)

The patch allowed for a considerable simplification of libgcc
configuration for Solaris and some generalizations that will be used by
patches for the other two platforms.

A couple of issues are worth noticing:

* The major point is that it proved possible to generalize/merge the
  several t-slibgcc* fragments currently in gcc/config.  By moving code
  around a bit and introducing a couple of variables, I could come up
  with a version that should work on Solaris, IRIX, Tru64 UNIX and
  Linux.  This is far more readable than the heavily duplicated versions
  we currently have.  The resulting libgcc/config/t-slibgcc is mostly
  identical to current gcc/config/t-slibgcc-elf-ver.

* One wart that turned up as result of the incomplete toplevel libgcc
  conversion is that one needs to keep defining SHLIB_LINK on the gcc
  side so ENABLE_SHARED_LIBGCC is defined correctly.  This is currently
  done in gcc/config/t-slibgcc-darwin and gcc/config/i386/t-nwld.  Until
  this is fixed, I've introduced a new gcc/config/t-slibgcc-dummy,
  properly commented to explain what's going on.  Since I cannot test
  the other targets, I've left them alone.

  Should I file a PR for this issue?

* Another wart was that gcc/ada/gcc-interface/Makefile.in requires
  TARGET_LIBGCC2_CFLAGS, which is otherwise only used in libgcc.  It
  often contains -fPIC, and if the variable is removed, libgnat.so won't
  link (text relocations remain).

  This is probably another ada PR?

* On the libgcc side, several of the t-crtfm fragments are identical
  except for the cpu subdir name.  Since there's already the cpu_type
  configure variable, I'm exporting that to make and make use of it in
  libgcc/config/t-crtfm.  Currently, only sparc uses it, but mips will
  once I complete the IRIX migration, and ia64 could, too.

* There were two copies of gmon-sol2.c, one for sparc, and a modified
  version thereof for i386.  I've done an initial merge that at least
  allowed a successful regtest on Solaris 11/x86, but there is
  considerable further cleanup (and reformatting ;-) potential.  I'll
  probably do so as a followup.

* Instead of doing sed hacks to strip comments from the various
  sol2-*.asm files, it seems to work to simply rename them to .S instead.

* Several libgcc t-* fragements can use of $< instead of duplicating the
  file names.

* I noticed that I had to rename TARGET_LIBGCC2_CFLAGS to
  HOST_LIBGCC2_CFLAGS so it works in libgcc.

* There are several one- or two-line makefile fragments in gcc and
  libgcc.  What is our policy for adding copyright notices to them.  In
  a couple of cases, the files are the only remainder/extract of a
  previously far longer file.  Should they keep the copyright dates of
  the former ones?

This hasn't been fully tested yet (only i386-pc-solaris2.11 so far), but
I'm posting it early for comments.

Thanks.
Rainer


2011-05-02  Rainer Orth  

gcc:
* config.gcc (i[34567]86-*-solaris2*): Remove t-svr4,
t-slibgcc-elf-ver, t-slibgcc-sld from tmake_file, add
t-slibgcc-dummy.
(sparc*-*-solaris2*): Remove sparc/t-sol2, sparc/t-crtfm,
t-slibgcc-elf-ver, t-slibgcc-sld, add t-slibgcc-dummy.
Remove extra_parts.
* config/t-sol2 (TARGET_LIBGCC2_CFLAGS): Define.
* config/i386/t-sol2-10 (LIBGCC, INSTALL_LIBGCC,
EXTRA_MULTILIB_PARTS): Remove.
* config/sparc/t-sol2-64: Likewise.
* config/sparc/t-sol2: Move to libgcc/config/sparc.
* config/sparc/gmon-sol2.c: Move to libgcc/config.
* config/i386/gmon-sol2.c: Remove.
* config/i386/sol2-c1.asm: Move to libgcc/config/i386/sol2-c1.S.
* config/i386/sol2-ci.asm: Move to libgcc/config/i386/sol2-ci.S.
* config/i386/sol2-cn.asm: Move to libgcc/config/i386/sol2-cn.S.
* config/i386/sol2-gc1.asm: Move to libgcc/config/i386/sol2-gc1.S.
* config/sparc/sol2-c1.asm: Move to libgcc/config/sparc/sol2-c1.S.
* config/sparc/sol2-ci.asm: Move to libgcc/config/sparc/sol2-ci.S.
* config/sparc/sol2-cn.asm: Move to libgcc/config/sparc/sol2-cn.S.
* config/t-slibgcc-sld: Move to libgcc/config.
* config/t-slibgcc-dummy: New file.

libgcc:
* Makefile.in (cpu_type): Define.
* config.host   (i[34567]86-*-solaris2*): Move body ...
(*-*-solaris2*): ... here.
New case, generalize.
(sparc-*-linux*): Replace sparc/t-crtfm by t-crtfm.
(sparc64-*-linux*): Likewise.
(sparc64-*-solaris2*, sparcv9-*-solaris2*, sparc-*-solaris2*):
Fold into ...
(sparc*-*-solaris2*): ... this.
New case.
* co

m68k: support -fstack-usage

2011-05-02 Thread Andreas Schwab
Checked into trunk.

Andreas.

2011-05-02  Andreas Schwab  

PR target/47955
* config/m68k/m68k.c (m68k_expand_prologue): Set
current_function_static_stack_size.

Index: gcc/config/m68k/m68k.c
===
--- gcc/config/m68k/m68k.c  (revision 173259)
+++ gcc/config/m68k/m68k.c  (working copy)
@@ -981,6 +981,10 @@ m68k_expand_prologue (void)
 
   m68k_compute_frame_layout ();
 
+  if (flag_stack_usage)
+current_function_static_stack_size
+  = current_frame.size + current_frame.offset;
+
   /* If the stack limit is a symbol, we can check it here,
  before actually allocating the space.  */
   if (crtl->limit_stack

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."


Re: Trivial patch to fix build with --enable-build-with-cxx

2011-05-02 Thread Eric Botcazou
> 2011-05-02  Dmitry Gorbachev  
>
>   * parser.c (cp_parser_init_declarator): Replace false by NULL.

I've installed the attached patch as obvious.


2011-05-02  Dmitry Gorbachev  
Eric Botcazou  

* parser.c (cp_parser_init_declarator): Set pushed_scope to NULL_TREE
instead of inappropriate zero values.


-- 
Eric Botcazou
Index: parser.c
===
--- parser.c	(revision 173209)
+++ parser.c	(working copy)
@@ -14302,7 +14302,7 @@ cp_parser_init_declarator (cp_parser* pa
   bool is_non_constant_init;
   int ctor_dtor_or_conv_p;
   bool friend_p;
-  tree pushed_scope = NULL;
+  tree pushed_scope = NULL_TREE;
   bool range_for_decl_p = false;
 
   /* Gather the attributes that were provided with the
@@ -14609,7 +14609,7 @@ cp_parser_init_declarator (cp_parser* pa
   if (pushed_scope)
 	{
 	  pop_scope (pushed_scope);
-	  pushed_scope = false;
+	  pushed_scope = NULL_TREE;
 	}
   decl = grokfield (declarator, decl_specifiers,
 			initializer, !is_non_constant_init,


Improve jump threading 4 of N

2011-05-02 Thread Jeff Law
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


This is merely an infrastructure patch in preparation for another
improvement in the jump threading code.  It shouldn't affect the code we
generate at all.

Let's consider this CFG (from a routine in cfgexpand.c)


   A
  / \
 B   C
 |  / \
 | D   E
 | |  / \
 | | F   G
  \| |
\|
 H
/ \
   I   J
  / \
 L   M
 |  / \
 | N   O
 | |  / \
 | | P   Q
  \| |
\|
 R


As it turns out some blocks have the same condition (A,I), (C,M), (E,O).
But because of the merge block H, no threading is possible.  What we
want to do is make 3 copies of H, each reachable from one predecessor of
the original H.

To do this we need to know the edge into the joiner block  so that we
can wire up the copy to the right predecessor.  We need the outgoing
edge from the joiner block that is threadable and finally we need the
destination edge.

This is a fairly simple extension to the existing code -- but we're
going to need the ability to store more information in the E->aux field.
 Previously E->aux stored the destination edge for a jump thread.   This
change allows E->aux to store additional data by changing it from a
single edge pointer to instead point to an array of edges.

FWIW, the patch to make copies of H to enable threading is probably the
limit of what can be done with the current threader.   I'm hoping to
start prototyping more generic path isolation code shortly.

Bootstrapped and regression tested on x86_64-unknown-linux-gnu.

OK for trunk?


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJNvuTiAAoJEBRtltQi2kC75OAIAIe77UqINq3jUeKdYMZ/OII1
+x+al4zcsx9YOCw6wdmMjWUS0Z9IcPmuKQIoPXtgq+R1qnADg5OnAiwKKZvdukIc
mhzbp+IBiDezFufv373shlp+hZtPN4QL73TDffWC4F9Eb7mYzADsIuAz2SIRcFVd
HB1UAxiiD8nUA4/uVa8Ree4PA91u8M3OGpC2iwW3eq/sBIzbdCs+TEI2Nps6qDLa
qmjNab/Zunh5OadJgtGB7Uk9pBv/I6zsbHmHCcZjRyOMyg8UXMCJTDjqpgUWJHAg
vIast5ayTI45cwJO69qykqZdrmrNUDpOHf/93HjNMhJvdSqPkB7eHiBvlcy2RdA=
=QsON
-END PGP SIGNATURE-
* tree-ssa-threadupdate.c (remove_ctrl_stmt_and_useless_edges): Clear
AUX field of outgoing edges.
(craete_edge_and_update_destination_phis): Handle AUX field being an
array of edges.  Free the AUX field before clearning it.
(thread_block, thread_through_loop_header): Likewise.
(thread_single_edge, mark_threaded_blocks): Likewise.
(redirect_edges): Delay clearing the AUX field.  Free the AUX field.
(register_jump_thread): Do not attempt to thread to a NULL edge.

Index: tree-ssa-threadupdate.c
===
*** tree-ssa-threadupdate.c (revision 173168)
--- tree-ssa-threadupdate.c (working copy)
*** remove_ctrl_stmt_and_useless_edges (basi
*** 200,209 
--- 200,215 
  static void
  create_block_for_threading (basic_block bb, struct redirection_data *rd)
  {
+   edge_iterator ei;
+   edge e;
+ 
/* We can use the generic block duplication code and simply remove
   the stuff we do not need.  */
rd->dup_block = duplicate_block (bb, NULL, NULL);
  
+   FOR_EACH_EDGE (e, ei, rd->dup_block->succs)
+ e->aux = NULL;
+ 
/* Zero out the profile, since the block is unreachable for now.  */
rd->dup_block->frequency = 0;
rd->dup_block->count = 0;
*** create_edge_and_update_destination_phis 
*** 314,320 
rescan_loop_exit (e, true, false);
e->probability = REG_BR_PROB_BASE;
e->count = bb->count;
!   e->aux = rd->outgoing_edge->aux;
  
/* If there are any PHI nodes at the destination of the outgoing edge
   from the duplicate block, then we will need to add a new argument
--- 320,335 
rescan_loop_exit (e, true, false);
e->probability = REG_BR_PROB_BASE;
e->count = bb->count;
! 
!   if (rd->outgoing_edge->aux)
! {
!   e->aux = (edge *) xmalloc (sizeof (edge) * 1);
!   ((edge *)e->aux)[0] = ((edge *)rd->outgoing_edge->aux)[0];
! }
!   else
! {
!   e->aux = NULL;
! }
  
/* If there are any PHI nodes at the destination of the outgoing edge
   from the duplicate block, then we will need to add a new argument
*** redirect_edges (void **slot, void *data)
*** 406,415 
next = el->next;
free (el);
  
-   /* Go ahead and clear E->aux.  It's not needed anymore and failure
-  to clear it will cause all kinds of unpleasant problems later.  */
-   e->aux = NULL;
- 
thread_stats.num_threaded_edges++;
  
if (rd->dup_block)
--- 421,426 
*** redirect_edges (void **slot, void *data)
*** 429,434 
--- 440,453 
  gcc_assert (e == e2);
  flush_pending_stmts (e2);
}
+ 
+   /* G

Re: [build] Move Solaris 2 startup files to toplevel libgcc

2011-05-02 Thread Joseph S. Myers
On Mon, 2 May 2011, Rainer Orth wrote:

> * Another wart was that gcc/ada/gcc-interface/Makefile.in requires
>   TARGET_LIBGCC2_CFLAGS, which is otherwise only used in libgcc.  It
>   often contains -fPIC, and if the variable is removed, libgnat.so won't
>   link (text relocations remain).
> 
>   This is probably another ada PR?

It would be good for the Ada target library build to rely only on the 
flags in the toplevel libada directory (and if necessary on flags in the 
toplevel libgcc directory if there is something that genuinely should be 
shared), though I don't know how hard that is to fix.  (In general more of 
the logic and source code relating to building Ada files for the target 
should go in the toplevel libada directory.  But there are quite a lot of 
files built for both the host and the target which complicates things, and 
those contribute a few target macros to the list in 
 of those still used 
in target code.)

As a related issue, there are too many macros used to indicate that code 
is being built for the target (USED_FOR_TARGET, IN_TARGET_LIBS, IN_RTS, 
IN_LIBGCC2, __GCC_FLOAT_NOT_NEEDED) - see my comments in 
.

> * There are several one- or two-line makefile fragments in gcc and
>   libgcc.  What is our policy for adding copyright notices to them.  In
>   a couple of cases, the files are the only remainder/extract of a
>   previously far longer file.  Should they keep the copyright dates of
>   the former ones?

The FSF policy is that any file more than ten lines long should have a 
copyright and license notice; files up to ten lines don't need them.

http://www.gnu.org/prep/maintain/html_node/Copyright-Notices.html

-- 
Joseph S. Myers
jos...@codesourcery.com


Patch ping^2: RFA: Add makefile for cross-configuration torture test

2011-05-02 Thread Joern Rennecke

Quoting Joern Rennecke :

2010-04-14  Joern Rennecke  

* config-list.mk: New file.

http://gcc.gnu.org/ml/gcc-patches/2011-04/msg01044.html



Re: Ping^4 Re: Target header etc. cleanup patch

2011-05-02 Thread Bernd Schmidt
On 05/02/2011 05:27 PM, Richard Guenther wrote:
> On Mon, May 2, 2011 at 5:21 PM, Joseph S. Myers  
> wrote:
>> Ping^4.  Parts of this patch
>>  are still
>> pending review, for targets fr30, m32r, mn10300, rx, v850 (target
>> maintainers CC:ed).  This version applies cleanly to current trunk.
>>
>> I have seen no comments from the mn10300 maintainers.  For the other
>> targets, Nick wanted to keep abbreviations for certain types
>>  and no-one else
>> has commented on that issue, though as I noted in
>>  I think
>> abbreviating const char * is actively bad.  Cstar - defined for mn10300,
>> whose maintainers haven't commented - is also the macro I care most about
>> getting rid of in what's left of this patch, as it's the one that shows up
>> as a false positive in my target macro listing script (the point of the
>> original patch was to get rid of several such false positives, plus making
>> related cleanups that showed up in the process).
> 
> Ok except for the changes the target maintainer objects to.  I do agree
> with Joseph and if another maintainer also says Ok I think we should
> overrule him.

I'll say OK then.


Bernd


Re: C++ PATCH for c++/48446 (ICE with VLA)

2011-05-02 Thread Jason Merrill

On 04/14/2011 10:52 AM, Jason Merrill wrote:

This patch avoids this issue by saving bounds values which have side
effects into a local automatic variable (since VLAs can only appear in
automatic variables). We stick with the SAVE_EXPR approach for bounds
without side-effects to avoid breaking vla9.C.


I finally found the code in grokdeclarator that I thought I remembered 
while working on this bug but couldn't find, and the comment there led 
me to put together a testcase broken by this change.  So I'm reverting 
the change to compute_array_index_type in favor of a more aggressive 
version of the precalculation that grokdeclarator already does.


Tested x86_64-pc-linux-gnu, applying to trunk.
commit dc6c2d45b04636be3430ca7722a5f648001659d2
Author: Jason Merrill 
Date:   Fri Apr 29 11:56:33 2011 -0400

PR c++/48446
* decl.c (stabilize_save_expr_r, stabilize_vla_size): New.
(compute_array_index_type): Revert earlier 48446 changes.
(grokdeclarator): Use stabilize_vla_size.

diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index 0a2e1dd..f9dd6de 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -7576,6 +7576,38 @@ check_static_variable_definition (tree decl, tree type)
   return 0;
 }
 
+/* *expr_p is part of the TYPE_SIZE of a variably-sized array.  If any
+   SAVE_EXPRs in *expr_p wrap expressions with side-effects, break those
+   expressions out into temporary variables so that walk_tree doesn't
+   step into them (c++/15764).  */
+
+static tree
+stabilize_save_expr_r (tree *expr_p, int *walk_subtrees, void *data)
+{
+  struct pointer_set_t *pset = (struct pointer_set_t *)data;
+  tree expr = *expr_p;
+  if (TREE_CODE (expr) == SAVE_EXPR)
+{
+  tree op = TREE_OPERAND (expr, 0);
+  cp_walk_tree (&op, stabilize_save_expr_r, data, pset);
+  if (TREE_SIDE_EFFECTS (op))
+   TREE_OPERAND (expr, 0) = get_temp_regvar (TREE_TYPE (op), op);
+}
+  else if (!EXPR_P (expr))
+*walk_subtrees = 0;
+  return NULL;
+}
+
+/* Entry point for the above.  */
+
+static void
+stabilize_vla_size (tree size)
+{
+  struct pointer_set_t *pset = pointer_set_create ();
+  /* Break out any function calls into temporary variables.  */
+  cp_walk_tree (&size, stabilize_save_expr_r, pset, pset);
+}
+
 /* Given the SIZE (i.e., number of elements) in an array, compute an
appropriate index type for the array.  If non-NULL, NAME is the
name of the thing being declared.  */
@@ -7769,16 +7801,8 @@ compute_array_index_type (tree name, tree size, 
tsubst_flags_t complain)
   processing_template_decl = saved_processing_template_decl;
 
   if (!TREE_CONSTANT (itype))
-   {
- /* A variable sized array.  */
- if (TREE_SIDE_EFFECTS (itype))
-   /* Use get_temp_regvar rather than variable_size here so that
-  people walking expressions that use a variable of this type
-  don't walk into this expression.  */
-   itype = get_temp_regvar (TREE_TYPE (itype), itype);
- else
-   itype = variable_size (itype);
-   }
+   /* A variable sized array.  */
+   itype = variable_size (itype);
   /* Make sure that there was no overflow when creating to a signed
 index type.  (For example, on a 32-bit machine, an array with
 size 2^32 - 1 is too big.)  */
@@ -9051,7 +9075,12 @@ grokdeclarator (const cp_declarator *declarator,
  && (decl_context == NORMAL || decl_context == FIELD)
  && at_function_scope_p ()
  && variably_modified_type_p (type, NULL_TREE))
-   finish_expr_stmt (TYPE_SIZE (type));
+   {
+ /* First break out any side-effects.  */
+ stabilize_vla_size (TYPE_SIZE (type));
+ /* And then force evaluation of the SAVE_EXPR.  */
+ finish_expr_stmt (TYPE_SIZE (type));
+   }
 
  if (declarator->kind == cdk_reference)
{
@@ -9126,6 +9155,14 @@ grokdeclarator (const cp_declarator *declarator,
}
 }
 
+  /* We need to stabilize side-effects in VLA sizes for regular array
+ declarations too, not just pointers to arrays.  */
+  if (type != error_mark_node && !TYPE_NAME (type)
+  && (decl_context == NORMAL || decl_context == FIELD)
+  && at_function_scope_p ()
+  && variably_modified_type_p (type, NULL_TREE))
+stabilize_vla_size (TYPE_SIZE (type));
+
   /* A `constexpr' specifier used in an object declaration declares
  the object as `const'.  */
   if (constexpr_p && innermost_code != cdk_function)
diff --git a/gcc/testsuite/c-c++-common/vla-1.c 
b/gcc/testsuite/c-c++-common/vla-1.c
new file mode 100644
index 000..401c4e0
--- /dev/null
+++ b/gcc/testsuite/c-c++-common/vla-1.c
@@ -0,0 +1,21 @@
+/* Test that changes to a variable are reflected in a VLA later in the
+   expression.  */
+/* { dg-options "" } */
+
+#ifdef __cplusplus
+extern "C"
+#endif
+void abort();
+
+int i = 4;
+int f()
+{
+  return i;
+}
+
+int main()
+{
+  if (i

Re: [google/main][RFA] change i386 pc_thunk prefix to be "__x86"

2011-05-02 Thread Andrew Pinski
On Sat, Apr 30, 2011 at 2:14 PM, Chris Demetriou  wrote:
> Makes -S output more easily preprocessable -- otherwise, the __i686 in
> __i686.get_pc_think.reg chokes things.

IIRC the reason why it uses __i686 is because 586 and before does not
need to worry about the return stack addresses.

And really I think having a name which is not able to be produced by a
C code is the best.

Thanks,
Andrew Pinski


[PATCH 10/n, i386]: Merge SSE and AVX patterns using "enable" attribute.

2011-05-02 Thread Uros Bizjak
Hello!

Attached patch merges MMX move patterns in mmx.md and fixes a couple
of problems in i386.md file.

2011-05-02  Uros Bizjak  

* config/i386/mmx.md (*mov_internal_rex64): Use %vmovq for
reg<->xmm moves.
(*mov_internal): Merge with *mov_internal_avx.
(*movv2sf_internal_rex64): Use %vmovq for reg<->xmm moves.  Merge
with *movv2sf_internal_rex64_avx.
(*movv2sf_internal): Merge with *movv2sf_internal_avx.
* config/i386/i386.md (*movdi_internal_rex64) :
Use %v prefix in insn mnemonic to handle TARGET_AVX.
(*movdi_internal): Add "isa" attribute.  Use "maybe_vex" instead of
"vex" in "prefix" attribute calculation.
(*movdf_internal): Output AVX mnemonics.  Add "prefix" attribute.

Tested on x86_64-pc-linux-gnu {,-m32}, committed to mainline SVN.

Uros.
Index: mmx.md
===
--- mmx.md  (revision 173243)
+++ mmx.md  (working copy)
@@ -1,5 +1,5 @@
 ;; GCC machine description for MMX and 3dNOW! instructions
-;; Copyright (C) 2005, 2007, 2008, 2009, 2010
+;; Copyright (C) 2005, 2007, 2008, 2009, 2010, 2011
 ;; Free Software Foundation, Inc.
 ;;
 ;; This file is part of GCC.
@@ -82,8 +82,8 @@
 %vpxor\t%0, %d0
 %vmovq\t{%1, %0|%0, %1}
 %vmovq\t{%1, %0|%0, %1}
-%vmovd\t{%1, %0|%0, %1}
-%vmovd\t{%1, %0|%0, %1}"
+%vmovq\t{%1, %0|%0, %1}
+%vmovq\t{%1, %0|%0, %1}"
   [(set_attr "type" 
"imov,imov,mmx,mmxmov,mmxmov,mmxmov,ssecvt,ssecvt,sselog1,ssemov,ssemov,ssemov,ssemov")
(set_attr "unit" "*,*,*,*,*,*,mmx,mmx,*,*,*,*,*")
(set_attr "prefix_rep" "*,*,*,*,*,*,1,1,*,1,*,*,*")
@@ -98,40 +98,12 @@
(const_string "orig")))
(set_attr "mode" "DI")])
 
-(define_insn "*mov_internal_avx"
-  [(set (match_operand:MMXMODEI8 0 "nonimmediate_operand"
-"=!?y,!y,!?y,m  ,!y ,*Y2,*Y2,*Y2 ,m  ,r  ,m")
-   (match_operand:MMXMODEI8 1 "vector_move_operand"
-"C   ,!y,m  ,!?y,*Y2,!y ,C  ,*Y2m,*Y2,irm,r"))]
-  "TARGET_AVX
-   && !(MEM_P (operands[0]) && MEM_P (operands[1]))"
-  "@
-pxor\t%0, %0
-movq\t{%1, %0|%0, %1}
-movq\t{%1, %0|%0, %1}
-movq\t{%1, %0|%0, %1}
-movdq2q\t{%1, %0|%0, %1}
-movq2dq\t{%1, %0|%0, %1}
-vpxor\t%0, %0, %0
-vmovq\t{%1, %0|%0, %1}
-vmovq\t{%1, %0|%0, %1}
-#
-#"
-  [(set_attr "type" 
"mmx,mmxmov,mmxmov,mmxmov,ssecvt,ssecvt,sselog1,ssemov,ssemov,*,*")
-   (set_attr "unit" "*,*,*,*,mmx,mmx,*,*,*,*,*")
-   (set_attr "prefix_rep" "*,*,*,*,1,1,*,*,*,*,*")
-   (set (attr "prefix")
- (if_then_else (eq_attr "alternative" "6,7,8")
-   (const_string "vex")
-   (const_string "orig")))
-   (set_attr "mode" "DI,DI,DI,DI,DI,DI,TI,DI,DI,DI,DI")])
-
 (define_insn "*mov_internal"
   [(set (match_operand:MMXMODEI8 0 "nonimmediate_operand"
 "=!?y,!y,!?y,m  ,!y ,*Y2,*Y2,*Y2 ,m  ,*x,*x,*x,m ,r  ,m")
(match_operand:MMXMODEI8 1 "vector_move_operand"
 "C   ,!y,m  ,!?y,*Y2,!y ,C  ,*Y2m,*Y2,C ,*x,m ,*x,irm,r"))]
-  "TARGET_MMX
+  "!TARGET_64BIT && TARGET_MMX
&& !(MEM_P (operands[0]) && MEM_P (operands[1]))"
   "@
 pxor\t%0, %0
@@ -140,19 +112,38 @@
 movq\t{%1, %0|%0, %1}
 movdq2q\t{%1, %0|%0, %1}
 movq2dq\t{%1, %0|%0, %1}
-pxor\t%0, %0
-movq\t{%1, %0|%0, %1}
-movq\t{%1, %0|%0, %1}
+%vpxor\t%0, %d0
+%vmovq\t{%1, %0|%0, %1}
+%vmovq\t{%1, %0|%0, %1}
 xorps\t%0, %0
 movaps\t{%1, %0|%0, %1}
 movlps\t{%1, %0|%0, %1}
 movlps\t{%1, %0|%0, %1}
 #
 #"
-  [(set_attr "type" 
"mmx,mmxmov,mmxmov,mmxmov,ssecvt,ssecvt,sselog1,ssemov,ssemov,sselog1,ssemov,ssemov,ssemov,*,*")
+  [(set (attr "isa")
+ (if_then_else (eq_attr "alternative" "9,10,11,12")
+   (const_string "noavx")
+   (const_string "base")))
+   (set_attr "type" 
"mmx,mmxmov,mmxmov,mmxmov,ssecvt,ssecvt,sselog1,ssemov,ssemov,sselog1,ssemov,ssemov,ssemov,*,*")
(set_attr "unit" "*,*,*,*,mmx,mmx,*,*,*,*,*,*,*,*,*")
-   (set_attr "prefix_rep" "*,*,*,*,1,1,*,1,*,*,*,*,*,*,*")
-   (set_attr "prefix_data16" "*,*,*,*,*,*,*,*,1,*,*,*,*,*,*")
+   (set (attr "prefix_rep")
+ (if_then_else
+   (ior (eq_attr "alternative" "4,5")
+   (and (eq_attr "alternative" "7")
+(eq (symbol_ref "TARGET_AVX") (const_int 0
+   (const_string "1")
+   (const_string "*")))
+   (set (attr "prefix_data16")
+ (if_then_else
+   (and (eq_attr "alternative" "8")
+   (eq (symbol_ref "TARGET_AVX") (const_int 0)))
+   (const_string "1")
+   (const_string "*")))
+   (set (attr "prefix")
+ (if_then_else (eq_attr "alternative" "6,7,8")
+   (const_string "maybe_vex")
+   (const_string "orig")))
(set_attr "mode" "DI,DI,DI,DI,DI,DI,TI,DI,DI,V4SF,V4SF,V2SF,V2SF,DI,DI")])
 
 (define_expand "movv2sf"
@@ -164,38 +155,6 @@
   DONE;
 })
 
-(define_insn "*movv2sf_internal_rex64_avx"
-  [(set (match_operand:V2SF 0 "nonimmediate_operand"
-"=rm,r,!?y,!y,!?y,m  ,!y,Y2,x,x,x,m,r,x")
-

Re: [google] Patch to support calling multi-versioned functions via new GCC builtin. (issue4440078)

2011-05-02 Thread Sriraman Tallam
Hi,

  I want to submit this patch to google/main to make sure it is
available for our internal use at Google in order to materialize some
optimization opportunities. Let us continue this dicussion as I make
changes and submit this for review for trunk.

Thanks,
-Sri.


On Mon, May 2, 2011 at 9:41 AM, Xinliang David Li  wrote:
> On Mon, May 2, 2011 at 2:11 AM, Richard Guenther
>  wrote:
>> On Fri, Apr 29, 2011 at 6:23 PM, Xinliang David Li  
>> wrote:
>>> Here is the background for this feature:
>>>
>>> 1) People relies on function multi-version to explore hw features and
>>> squeeze performance, but there is no standard ways of doing so, either
>>> a) using indirect function calls with function pointers set at program
>>> initialization; b) using manual dispatch at each callsite; b) using
>>> features like IFUNC.  The dispatch mechanism needs to be promoted to
>>> the language level and becomes the first class citizen;
>>
>> You are not doing that, you are inventing a new (crude) GCC extension.
>
> To capture the high level semantics and prevent user from lowering the
> dispatch calls into forms compiler can not recognize, language
> extension is the way to go.
>
>>
>
>>> See above. Multi-way dispatch can be added similarly.
>>
>> Not with the specified syntax.  So you'd end up with _two_
>> language extensions.  That's bad (and unacceptable, IMHO).
>
> This part can be improved.
>
>>
>>>

 That's a nice idea, but why not simply process all functions with
 a const attribute and no arguments this way?  IMHO

 int testsse (void) __attribute__((const));

 is as good and avoids the new attribute completely.  The pass would
 also benefit other uses of this idiom (giving a way to have global
 dynamic initializers in C).  The functions may not be strictly 'const'
 in a way the compiler autodetects this attribute but it presents
 exactly the promises to the compiler that allow this optimization.

 Thus, please split this piece out into a separate patch and use
 the const attribute.
>>>
>>>
>>> Sounds good.
>>>
>
>>>
>>> 1) the function selection may happen in a different function;
>>
>> Well, sure.  I propose to have the above as lowered form.  If people
>> deliberately obfuscate code it's their fault.  Your scheme simply
>> makes that obfuscation impossible (or less likely possible).  So
>> 1) is not a valid argument.
>
> Lowering too early may defeat the purpose because
>
> 1) the desired optimization may not happen subject to many compiler
> heuristic changes;
> 2) it has other side effects such as wrong estimation of function size
> which may impact inlining
> 3) it limits the lowering into one form which may not be ideal  --
> with builtin_dispatch, after hoisting optimization, the lowering can
> use more efficient IFUNC scheme, for instance.
>
>>
>>
>> My point is that such optimization is completely independent of
>> that dispatch thing.  The above could as well be a selection to
>> use different input arrays, one causing alias analysis issues
>> and one not.
>>
>> Thus, a __builtin_dispatch centric optimization pass is the wrong
>> way to go.
>
> I agree that many things can implemented in different ways, but a high
> level standard builtin_dispatch mechanism doing hoisting
> interprocedcurally is cleaner and simpler and targeted for function
> multi-versioning -- it does not depend on/rely on later phase's
> heuristic tunings to make the right things to happen. Function MV
> deserves this level of treatment as it will become more and more
> important for some users (e.g., Google).
>
>>
>> Now, with FDO I'd expect the foo is inlined into bar (because foo
>> is deemed hot),
>
> That is a myth -- the truth is that there are other heuristics which
> can prevent this from happening.
>
>> then you only need to deal with loop unswitching,
>> which should be easy to drive from FDO.
>
> Same here -- the loop body may not be well formed/recognized. The loop
> nests may not be perfectly nested, or other unswitching heuristics may
> block it from happening.  This is the common problem form many other
> things that get lowered too early. It is cleaner to make the high
> level transformation first in IPA, and let unswitching dealing with
> intra-procedural optimization.
>
> Thanks,
>
> David
>
>>
>> Richard.
>>
>>>
>>>
>>> Thanks,
>>>
>>> David
>>>
>>>
>>>

 Note that we already have special FDO support for indirect to direct
 call promotion, so that might work already.

 Thus, with all this, __builtin_dispatch would be more like syntactic
 sugar to avoid writing above switch statement yourself.  If you restrict
 that sugar to a constant number of candidates it can be replaced by
 a macro (or several ones, specialized for the number of candidates).

 Richard.

>  For the call graph that looks like this before cloning :
>
> func_cold > func_hot > findOnes > IsPopCntSupported > 
> popcnt
>>

Re: [google] Patch to support calling multi-versioned functions via new GCC builtin. (issue4440078)

2011-05-02 Thread Xinliang David Li
Ok. There may be more correctness related comments -- but those can be
addressed when available. For trunk, you need to address issues such
as multi-way dispatch.

Thanks,

David

On Mon, May 2, 2011 at 12:11 PM, Sriraman Tallam  wrote:
> Hi,
>
>  I want to submit this patch to google/main to make sure it is
> available for our internal use at Google in order to materialize some
> optimization opportunities. Let us continue this dicussion as I make
> changes and submit this for review for trunk.
>
> Thanks,
> -Sri.
>
>
> On Mon, May 2, 2011 at 9:41 AM, Xinliang David Li  wrote:
>> On Mon, May 2, 2011 at 2:11 AM, Richard Guenther
>>  wrote:
>>> On Fri, Apr 29, 2011 at 6:23 PM, Xinliang David Li  
>>> wrote:
 Here is the background for this feature:

 1) People relies on function multi-version to explore hw features and
 squeeze performance, but there is no standard ways of doing so, either
 a) using indirect function calls with function pointers set at program
 initialization; b) using manual dispatch at each callsite; b) using
 features like IFUNC.  The dispatch mechanism needs to be promoted to
 the language level and becomes the first class citizen;
>>>
>>> You are not doing that, you are inventing a new (crude) GCC extension.
>>
>> To capture the high level semantics and prevent user from lowering the
>> dispatch calls into forms compiler can not recognize, language
>> extension is the way to go.
>>
>>>
>>
 See above. Multi-way dispatch can be added similarly.
>>>
>>> Not with the specified syntax.  So you'd end up with _two_
>>> language extensions.  That's bad (and unacceptable, IMHO).
>>
>> This part can be improved.
>>
>>>

>
> That's a nice idea, but why not simply process all functions with
> a const attribute and no arguments this way?  IMHO
>
> int testsse (void) __attribute__((const));
>
> is as good and avoids the new attribute completely.  The pass would
> also benefit other uses of this idiom (giving a way to have global
> dynamic initializers in C).  The functions may not be strictly 'const'
> in a way the compiler autodetects this attribute but it presents
> exactly the promises to the compiler that allow this optimization.
>
> Thus, please split this piece out into a separate patch and use
> the const attribute.


 Sounds good.

>>

 1) the function selection may happen in a different function;
>>>
>>> Well, sure.  I propose to have the above as lowered form.  If people
>>> deliberately obfuscate code it's their fault.  Your scheme simply
>>> makes that obfuscation impossible (or less likely possible).  So
>>> 1) is not a valid argument.
>>
>> Lowering too early may defeat the purpose because
>>
>> 1) the desired optimization may not happen subject to many compiler
>> heuristic changes;
>> 2) it has other side effects such as wrong estimation of function size
>> which may impact inlining
>> 3) it limits the lowering into one form which may not be ideal  --
>> with builtin_dispatch, after hoisting optimization, the lowering can
>> use more efficient IFUNC scheme, for instance.
>>
>>>
>>>
>>> My point is that such optimization is completely independent of
>>> that dispatch thing.  The above could as well be a selection to
>>> use different input arrays, one causing alias analysis issues
>>> and one not.
>>>
>>> Thus, a __builtin_dispatch centric optimization pass is the wrong
>>> way to go.
>>
>> I agree that many things can implemented in different ways, but a high
>> level standard builtin_dispatch mechanism doing hoisting
>> interprocedcurally is cleaner and simpler and targeted for function
>> multi-versioning -- it does not depend on/rely on later phase's
>> heuristic tunings to make the right things to happen. Function MV
>> deserves this level of treatment as it will become more and more
>> important for some users (e.g., Google).
>>
>>>
>>> Now, with FDO I'd expect the foo is inlined into bar (because foo
>>> is deemed hot),
>>
>> That is a myth -- the truth is that there are other heuristics which
>> can prevent this from happening.
>>
>>> then you only need to deal with loop unswitching,
>>> which should be easy to drive from FDO.
>>
>> Same here -- the loop body may not be well formed/recognized. The loop
>> nests may not be perfectly nested, or other unswitching heuristics may
>> block it from happening.  This is the common problem form many other
>> things that get lowered too early. It is cleaner to make the high
>> level transformation first in IPA, and let unswitching dealing with
>> intra-procedural optimization.
>>
>> Thanks,
>>
>> David
>>
>>>
>>> Richard.
>>>


 Thanks,

 David



>
> Note that we already have special FDO support for indirect to direct
> call promotion, so that might work already.
>
> Thus, with all this, __builtin_dispatch would be more like syntactic
> sugar to avoid writing abov

[google] Normalize version number for google/gcc-4_6 (issue4454049)

2011-05-02 Thread Diego Novillo

Since google/gcc-4_6 follows the 4.6 branch, changes in minor
revisions cause unnecessary churn in directory names.

Fixed with this.  OK for google/gcc-4_6?

Google ref 4335466.

* BASE-VER: Change to 4.6.x-google.

diff --git a/gcc/BASE-VER b/gcc/BASE-VER
index 4110f74..33d4edd 100644
--- a/gcc/BASE-VER
+++ b/gcc/BASE-VER
@@ -1 +1 @@
-4.6.1-google
+4.6.x-google

--
This patch is available for review at http://codereview.appspot.com/4454049


Re: [google] Normalize version number for google/gcc-4_6 (issue4454049)

2011-05-02 Thread Ollie Wild
On Mon, May 2, 2011 at 2:53 PM, Diego Novillo  wrote:
>
> Since google/gcc-4_6 follows the 4.6 branch, changes in minor
> revisions cause unnecessary churn in directory names.
>
> Fixed with this.  OK for google/gcc-4_6?

Yes, okay for google/gcc-4_6.

Thanks,
Ollie


[PATCH] Fix bt[lq] related miscompilation (PR target/48774)

2011-05-02 Thread Jakub Jelinek
Hi!

As written in the PR, the testcase in the patch is miscompiled on
x86_64-linux, because during IRA a *btdi operand is changed from
register to CONST_INT 1 (to which that register was initialized).
Unfortunately when both 2nd and 3rd ZERO_EXTEND operands are constant
integers, *testqi_ext_3{,_rex64} patterns match it wrongly too,
but of course when splitting it into andl/q (which isn't desirable on
TARGET_USE_BT targets anyway) using CCCmode is wrong, as the jump then
looks at the carry bit set by bt{l,q}, while after and{l,q} the interesting
bit is the zero flag.

The following patch is one of the many possibilities to fix it,
bootstrapped/regtested on x86_64-linux and i686-linux.

Other options include just doing != CCCmode tests and remove the const1_rtx
checks from the patch, or on the other side also testing TARGET_USE_BT ||
-Os, or for the define_insn moving *bt pattern earlier (the splitter
would still need guarding), or perhaps representing bt{l,q} insns
differently in RTL.  I believe this bug is latent starting with 4.4,
when *bt insn has been added.

2011-05-02  Jakub Jelinek  

PR target/48774
* config/i386/i386.md (testqi_ext_3_rex64, textqi_ext_3,
split after testqi_ext_3*): Don't match CCCmode set with
const1_rtx as last ZERO_EXTRACT operand.

* gcc.dg/pr48774.c: New test.

--- gcc/config/i386/i386.md.jj  2011-05-02 18:39:23.0 +0200
+++ gcc/config/i386/i386.md 2011-05-02 19:09:23.0 +0200
@@ -7756,6 +7756,8 @@ (define_insn "*testqi_ext_3_rex64"
 (const_int 0)))]
   "TARGET_64BIT
&& ix86_match_ccmode (insn, CCNOmode)
+   && (GET_MODE (SET_DEST (PATTERN (insn))) != CCCmode
+   || operands[2] != const1_rtx)
&& INTVAL (operands[1]) > 0
&& INTVAL (operands[2]) >= 0
/* Ensure that resulting mask is zero or sign extended operand.  */
@@ -,6 +7779,8 @@ (define_insn "*testqi_ext_3"
   (match_operand:SI 2 "const_int_operand" ""))
 (const_int 0)))]
   "ix86_match_ccmode (insn, CCNOmode)
+   && (GET_MODE (SET_DEST (PATTERN (insn))) != CCCmode
+   || operands[2] != const1_rtx)
&& INTVAL (operands[1]) > 0
&& INTVAL (operands[2]) >= 0
&& INTVAL (operands[1]) + INTVAL (operands[2]) <= 32
@@ -7794,7 +7798,8 @@ (define_split
 (match_operand 3 "const_int_operand" "")
 (match_operand 4 "const_int_operand" ""))
   (const_int 0)]))]
-  "ix86_match_ccmode (insn, CCNOmode)"
+  "ix86_match_ccmode (insn, CCNOmode)
+   && (GET_MODE (operands[0]) != CCCmode || operands[4] != const1_rtx)"
   [(set (match_dup 0) (match_op_dup 1 [(match_dup 2) (const_int 0)]))]
 {
   rtx val = operands[2];
--- gcc/testsuite/gcc.dg/pr48774.c.jj   2011-05-02 19:12:32.0 +0200
+++ gcc/testsuite/gcc.dg/pr48774.c  2011-05-02 11:03:55.0 +0200
@@ -0,0 +1,38 @@
+/* PR target/48774 */
+/* { dg-do run } */
+/* { dg-options "-O2 -funroll-loops" } */
+
+extern void abort (void);
+unsigned long int s[24]
+  = { 12, ~1, 12, ~2, 12, ~4, 12, ~8, 12, ~16, 12, ~32,
+  12, ~64, 12, ~128, 12, ~256, 12, ~512, 12, ~1024, 12, ~2048 };
+struct { int n; unsigned long *e[12]; } g
+  = { 12, { &s[0], &s[2], &s[4], &s[6], &s[8], &s[10], &s[12], &s[14],
+   &s[16], &s[18], &s[20], &s[22] } };
+int c[12];
+
+__attribute__((noinline, noclone)) void
+foo (void)
+{
+  int i, j;
+  for (i = 0; i < g.n; i++)
+for (j = 0; j < g.n; j++)
+  {
+   if (i == j && j < g.e[0][0] && (g.e[i][1] & (1UL << j)))
+ abort ();
+   if (j < g.e[0][0] && (g.e[i][1] & (1UL << j)))
+ c[i]++;
+  }
+}
+
+int
+main ()
+{
+  int i;
+  asm volatile ("" : "+m" (s), "+m" (g), "+m" (c));
+  foo ();
+  for (i = 0; i < 12; i++)
+if (c[i] != 11)
+  abort ();
+  return 0;
+}

Jakub


Re: [google] Patch to support calling multi-versioned functions via new GCC builtin. (issue4440078)

2011-05-02 Thread Sriraman Tallam
Thanks. I committed this patch.

-Sri.

svn commit
Sendinggcc/ChangeLog.google-main
Sendinggcc/Makefile.in
Sendinggcc/builtin-types.def
Sendinggcc/builtins.def
Sendinggcc/c-family/c-common.c
Sendinggcc/common.opt
Sendinggcc/doc/invoke.texi
Adding gcc/mversn-dispatch.c
Sendinggcc/params.def
Sendinggcc/passes.c
Adding gcc/testsuite/g++.dg/mversn10.C
Adding gcc/testsuite/g++.dg/mversn10a.C
Adding gcc/testsuite/g++.dg/mversn12.C
Adding gcc/testsuite/g++.dg/mversn14.C
Adding gcc/testsuite/g++.dg/mversn14a.C
Adding gcc/testsuite/g++.dg/mversn16.C
Adding gcc/testsuite/g++.dg/mversn8.C
Adding gcc/testsuite/g++.dg/mversn9.C
Adding gcc/testsuite/g++.dg/torture/mversn11.C
Adding gcc/testsuite/g++.dg/torture/mversn5.C
Adding gcc/testsuite/g++.dg/torture/mversn5.h
Adding gcc/testsuite/g++.dg/torture/mversn5a.C
Adding gcc/testsuite/g++.dg/tree-prof/mversn13.C
Adding gcc/testsuite/g++.dg/tree-prof/mversn15.C
Adding gcc/testsuite/g++.dg/tree-prof/mversn15a.C
Adding gcc/testsuite/gcc.dg/mversn2.c
Adding gcc/testsuite/gcc.dg/mversn3.c
Adding gcc/testsuite/gcc.dg/mversn4.c
Adding gcc/testsuite/gcc.dg/mversn4.h
Adding gcc/testsuite/gcc.dg/mversn4a.c
Adding gcc/testsuite/gcc.dg/mversn6.c
Adding gcc/testsuite/gcc.dg/mversn7.c
Adding gcc/testsuite/gcc.dg/torture/mversn1.c
Sendinggcc/timevar.def
Sendinggcc/tree-pass.h
Transmitting file data ...
Committed revision 173271.


On Mon, May 2, 2011 at 12:32 PM, Xinliang David Li  wrote:
> Ok. There may be more correctness related comments -- but those can be
> addressed when available. For trunk, you need to address issues such
> as multi-way dispatch.
>
> Thanks,
>
> David
>
> On Mon, May 2, 2011 at 12:11 PM, Sriraman Tallam  wrote:
>> Hi,
>>
>>  I want to submit this patch to google/main to make sure it is
>> available for our internal use at Google in order to materialize some
>> optimization opportunities. Let us continue this dicussion as I make
>> changes and submit this for review for trunk.
>>
>> Thanks,
>> -Sri.
>>
>>
>> On Mon, May 2, 2011 at 9:41 AM, Xinliang David Li  wrote:
>>> On Mon, May 2, 2011 at 2:11 AM, Richard Guenther
>>>  wrote:
 On Fri, Apr 29, 2011 at 6:23 PM, Xinliang David Li  
 wrote:
> Here is the background for this feature:
>
> 1) People relies on function multi-version to explore hw features and
> squeeze performance, but there is no standard ways of doing so, either
> a) using indirect function calls with function pointers set at program
> initialization; b) using manual dispatch at each callsite; b) using
> features like IFUNC.  The dispatch mechanism needs to be promoted to
> the language level and becomes the first class citizen;

 You are not doing that, you are inventing a new (crude) GCC extension.
>>>
>>> To capture the high level semantics and prevent user from lowering the
>>> dispatch calls into forms compiler can not recognize, language
>>> extension is the way to go.
>>>

>>>
> See above. Multi-way dispatch can be added similarly.

 Not with the specified syntax.  So you'd end up with _two_
 language extensions.  That's bad (and unacceptable, IMHO).
>>>
>>> This part can be improved.
>>>

>
>>
>> That's a nice idea, but why not simply process all functions with
>> a const attribute and no arguments this way?  IMHO
>>
>> int testsse (void) __attribute__((const));
>>
>> is as good and avoids the new attribute completely.  The pass would
>> also benefit other uses of this idiom (giving a way to have global
>> dynamic initializers in C).  The functions may not be strictly 'const'
>> in a way the compiler autodetects this attribute but it presents
>> exactly the promises to the compiler that allow this optimization.
>>
>> Thus, please split this piece out into a separate patch and use
>> the const attribute.
>
>
> Sounds good.
>
>>>
>
> 1) the function selection may happen in a different function;

 Well, sure.  I propose to have the above as lowered form.  If people
 deliberately obfuscate code it's their fault.  Your scheme simply
 makes that obfuscation impossible (or less likely possible).  So
 1) is not a valid argument.
>>>
>>> Lowering too early may defeat the purpose because
>>>
>>> 1) the desired optimization may not happen subject to many compiler
>>> heuristic changes;
>>> 2) it has other side effects such as wrong estimation of function size
>>> which may impact inlining
>>> 3) it limits the lowering into one form which may not be ideal  --
>>> with builtin_dispatch, after hoisting optimization, the lowering can
>>> use more efficient IFUNC scheme, for inst

Re: [google] Patch to support calling multi-versioned functions via new GCC builtin. (issue4440078)

2011-05-02 Thread Eric Botcazou
> Thanks. I committed this patch.
>
> -Sri.
>
> svn commit
> Sendinggcc/ChangeLog.google-main
> Sendinggcc/Makefile.in
> Sendinggcc/builtin-types.def
> Sendinggcc/builtins.def
> Sendinggcc/c-family/c-common.c
> Sendinggcc/common.opt
> Sendinggcc/doc/invoke.texi
> Adding gcc/mversn-dispatch.c
> Sendinggcc/params.def
> Sendinggcc/passes.c
> Adding gcc/testsuite/g++.dg/mversn10.C
> Adding gcc/testsuite/g++.dg/mversn10a.C
> Adding gcc/testsuite/g++.dg/mversn12.C
> Adding gcc/testsuite/g++.dg/mversn14.C
> Adding gcc/testsuite/g++.dg/mversn14a.C
> Adding gcc/testsuite/g++.dg/mversn16.C
> Adding gcc/testsuite/g++.dg/mversn8.C
> Adding gcc/testsuite/g++.dg/mversn9.C
> Adding gcc/testsuite/g++.dg/torture/mversn11.C
> Adding gcc/testsuite/g++.dg/torture/mversn5.C
> Adding gcc/testsuite/g++.dg/torture/mversn5.h
> Adding gcc/testsuite/g++.dg/torture/mversn5a.C
> Adding gcc/testsuite/g++.dg/tree-prof/mversn13.C
> Adding gcc/testsuite/g++.dg/tree-prof/mversn15.C
> Adding gcc/testsuite/g++.dg/tree-prof/mversn15a.C
> Adding gcc/testsuite/gcc.dg/mversn2.c
> Adding gcc/testsuite/gcc.dg/mversn3.c
> Adding gcc/testsuite/gcc.dg/mversn4.c
> Adding gcc/testsuite/gcc.dg/mversn4.h
> Adding gcc/testsuite/gcc.dg/mversn4a.c
> Adding gcc/testsuite/gcc.dg/mversn6.c
> Adding gcc/testsuite/gcc.dg/mversn7.c
> Adding gcc/testsuite/gcc.dg/torture/mversn1.c
> Sendinggcc/timevar.def
> Sendinggcc/tree-pass.h
> Transmitting file data ...
> Committed revision 173271.

Please avoid posting useless messages like this on gcc-patches@.  The same 
information is duplicated on gcc-cvs@.  See http://gcc.gnu.org/svnwrite.html

-- 
Eric Botcazou


Re: [google] Patch to support calling multi-versioned functions via new GCC builtin. (issue4440078)

2011-05-02 Thread Sriraman Tallam
On Mon, May 2, 2011 at 1:44 PM, Eric Botcazou  wrote:
>> Thanks. I committed this patch.
>>
>> -Sri.
>>
>> svn commit
>> Sending        gcc/ChangeLog.google-main
>> Sending        gcc/Makefile.in
>> Sending        gcc/builtin-types.def
>> Sending        gcc/builtins.def
>> Sending        gcc/c-family/c-common.c
>> Sending        gcc/common.opt
>> Sending        gcc/doc/invoke.texi
>> Adding         gcc/mversn-dispatch.c
>> Sending        gcc/params.def
>> Sending        gcc/passes.c
>> Adding         gcc/testsuite/g++.dg/mversn10.C
>> Adding         gcc/testsuite/g++.dg/mversn10a.C
>> Adding         gcc/testsuite/g++.dg/mversn12.C
>> Adding         gcc/testsuite/g++.dg/mversn14.C
>> Adding         gcc/testsuite/g++.dg/mversn14a.C
>> Adding         gcc/testsuite/g++.dg/mversn16.C
>> Adding         gcc/testsuite/g++.dg/mversn8.C
>> Adding         gcc/testsuite/g++.dg/mversn9.C
>> Adding         gcc/testsuite/g++.dg/torture/mversn11.C
>> Adding         gcc/testsuite/g++.dg/torture/mversn5.C
>> Adding         gcc/testsuite/g++.dg/torture/mversn5.h
>> Adding         gcc/testsuite/g++.dg/torture/mversn5a.C
>> Adding         gcc/testsuite/g++.dg/tree-prof/mversn13.C
>> Adding         gcc/testsuite/g++.dg/tree-prof/mversn15.C
>> Adding         gcc/testsuite/g++.dg/tree-prof/mversn15a.C
>> Adding         gcc/testsuite/gcc.dg/mversn2.c
>> Adding         gcc/testsuite/gcc.dg/mversn3.c
>> Adding         gcc/testsuite/gcc.dg/mversn4.c
>> Adding         gcc/testsuite/gcc.dg/mversn4.h
>> Adding         gcc/testsuite/gcc.dg/mversn4a.c
>> Adding         gcc/testsuite/gcc.dg/mversn6.c
>> Adding         gcc/testsuite/gcc.dg/mversn7.c
>> Adding         gcc/testsuite/gcc.dg/torture/mversn1.c
>> Sending        gcc/timevar.def
>> Sending        gcc/tree-pass.h
>> Transmitting file data ...
>> Committed revision 173271.
>
> Please avoid posting useless messages like this on gcc-patches@.  The same
> information is duplicated on gcc-cvs@.  See http://gcc.gnu.org/svnwrite.html

Alright & sorry.

-Sri.

>
> --
> Eric Botcazou
>


Re: [google/main][RFA] change i386 pc_thunk prefix to be "__x86"

2011-05-02 Thread Chris Demetriou
On Mon, May 2, 2011 at 11:49, Andrew Pinski  wrote:
> On Sat, Apr 30, 2011 at 2:14 PM, Chris Demetriou  wrote:
>> Makes -S output more easily preprocessable -- otherwise, the __i686 in
>> __i686.get_pc_think.reg chokes things.
>
> IIRC the reason why it uses __i686 is because 586 and before does not
> need to worry about the return stack addresses.
>
> And really I think having a name which is not able to be produced by a
> C code is the best.

the "." prevents in either case, of course.
And of course, either name involvinv __i686 or __x86 is reserved for
implementation AFAIK.

"__i686" is a preprocessor token, and when compiling with certain
flags (-mcpu=i686 and perhaps others, IIRC -- I forget), it's a macro
defined to 1.
So, when preprocessing -S output (for whatever reason) with cpu set to
i686, that beautiful:
  __i686.get_pc_thunk.
gets turned into...
  1.get_pc_thunk..


My favorite old annoyance from this was the glibc source that (at
least used to) include (inline IIRC) asm code with calls to
__i686.get_pc_thunk..
You couldn't compile them with -mcpu=i686 or with an i686-configured toolchain.
And, there (at the time at least) IIRC the response was "not a bug."
(I've not looked at that code for a long time -- dunno if it's been
fixed in stock glibc.)

anyway, that's one specific example where (historically) this would
have been useful.
i've seen others -- enough that we made this change in our compiler a
few of years ago.


chris


Re: Improve jump threading 4 of N

2011-05-02 Thread Richard Guenther
On Mon, May 2, 2011 at 7:07 PM, Jeff Law  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
>
> This is merely an infrastructure patch in preparation for another
> improvement in the jump threading code.  It shouldn't affect the code we
> generate at all.
>
> Let's consider this CFG (from a routine in cfgexpand.c)
>
>
>           A
>          / \
>         B   C
>         |  / \
>         | D   E
>         | |  / \
>         | | F   G
>          \| |
>            \|
>             H
>            / \
>           I   J
>          / \
>         L   M
>         |  / \
>         | N   O
>         | |  / \
>         | | P   Q
>          \| |
>            \|
>             R
>
>
> As it turns out some blocks have the same condition (A,I), (C,M), (E,O).
> But because of the merge block H, no threading is possible.  What we
> want to do is make 3 copies of H, each reachable from one predecessor of
> the original H.
>
> To do this we need to know the edge into the joiner block  so that we
> can wire up the copy to the right predecessor.  We need the outgoing
> edge from the joiner block that is threadable and finally we need the
> destination edge.
>
> This is a fairly simple extension to the existing code -- but we're
> going to need the ability to store more information in the E->aux field.
>  Previously E->aux stored the destination edge for a jump thread.   This
> change allows E->aux to store additional data by changing it from a
> single edge pointer to instead point to an array of edges.
>
> FWIW, the patch to make copies of H to enable threading is probably the
> limit of what can be done with the current threader.   I'm hoping to
> start prototyping more generic path isolation code shortly.
>
> Bootstrapped and regression tested on x86_64-unknown-linux-gnu.
>
> OK for trunk?

For (edge *)xmalloc (sizeof (edge) * 1) use XNEWVEC and friends.
I wonder if it makes sense to use a VEC instead (will the vector
be of variable size?).  Maybe wrap accesses to e->aux with
a macro or some inline functions.

Ok with the allocation change.

Thanks,
Richard.

>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
>
> iQEcBAEBAgAGBQJNvuTiAAoJEBRtltQi2kC75OAIAIe77UqINq3jUeKdYMZ/OII1
> +x+al4zcsx9YOCw6wdmMjWUS0Z9IcPmuKQIoPXtgq+R1qnADg5OnAiwKKZvdukIc
> mhzbp+IBiDezFufv373shlp+hZtPN4QL73TDffWC4F9Eb7mYzADsIuAz2SIRcFVd
> HB1UAxiiD8nUA4/uVa8Ree4PA91u8M3OGpC2iwW3eq/sBIzbdCs+TEI2Nps6qDLa
> qmjNab/Zunh5OadJgtGB7Uk9pBv/I6zsbHmHCcZjRyOMyg8UXMCJTDjqpgUWJHAg
> vIast5ayTI45cwJO69qykqZdrmrNUDpOHf/93HjNMhJvdSqPkB7eHiBvlcy2RdA=
> =QsON
> -END PGP SIGNATURE-
>


[Patch, Fortran] PR18918: Implement THIS_IMAGE(coarray) for num_images() > 1

2011-05-02 Thread Tobias Burnus
With this patch, now all coarray index intrinsics are implemented for 
num_images() >= 1 - except for bugs.


Built and regtesting on x86-64-linux. The testcase was also tested with 
-fcoarray=single and with -fcoarray=lib -lcaf_mpi with mpirun -n 8.

OK for the trunk?

Tobias

PS: I would like to place the test case under gfortran.dg/coarray/; 
however, the patch is still pending: 
http://gcc.gnu.org/ml/fortran/2011-04/msg00331.html
2010-05-02  Tobias Burnus  

	PR fortran/18918
	* trans-intrinsic.c (trans_this_image): Implement version with
	coarray argument.
	(conv_intrinsic_cobound): Simplify code.
	(gfc_conv_intrinsic_function): Call trans_this_image for
	this_image(coarray) except for -fcoarray=single.

2010-05-02  Tobias Burnus  

	PR fortran/18918
	* gfortran.dg/coarray_20.f90: New.

diff --git a/gcc/fortran/trans-intrinsic.c b/gcc/fortran/trans-intrinsic.c
index 180aba1..10dadf7 100644
--- a/gcc/fortran/trans-intrinsic.c
+++ b/gcc/fortran/trans-intrinsic.c
@@ -923,10 +923,199 @@ gfc_conv_intrinsic_exponent (gfc_se *se, gfc_expr *expr)
 
 
 static void
-trans_this_image (gfc_se * se, gfc_expr *expr ATTRIBUTE_UNUSED)
+trans_this_image (gfc_se * se, gfc_expr *expr)
 {
+  stmtblock_t loop;
+  tree type, desc, dim_arg, cond, tmp, m, loop_var, exit_label, min_var,
+   lbound, ubound, extent, ml;
+  gfc_se argse;
+  gfc_ss *ss;
+  int rank, corank;
+
+  /* The case -fcoarray=single is handled elsewhere.  */
+  gcc_assert (gfc_option.coarray != GFC_FCOARRAY_SINGLE);
+
   gfc_init_coarray_decl ();
-  se->expr = gfort_gvar_caf_this_image;
+
+  /* Argument-free version: THIS_IMAGE().  */
+  if (expr->value.function.actual->expr == NULL)
+{
+  se->expr = gfort_gvar_caf_this_image;
+  return;
+}
+
+  /* Coarray-argument version: THIS_IMAGE(coarray [, dim]).  */
+
+  type = gfc_get_int_type (gfc_default_integer_kind);
+  corank = gfc_get_corank (expr->value.function.actual->expr);
+  rank = expr->value.function.actual->expr->rank;
+
+  /* Obtain the descriptor of the COARRAY.  */
+  gfc_init_se (&argse, NULL);
+  ss = gfc_walk_expr (expr->value.function.actual->expr);
+  gcc_assert (ss != gfc_ss_terminator);
+  ss->data.info.codimen = corank;
+  gfc_conv_expr_descriptor (&argse, expr->value.function.actual->expr, ss);
+  gfc_add_block_to_block (&se->pre, &argse.pre);
+  gfc_add_block_to_block (&se->post, &argse.post);
+  desc = argse.expr;
+
+  if (se->ss)
+{
+  /* Create an implicit second parameter from the loop variable.  */
+  gcc_assert (!expr->value.function.actual->next->expr);
+  gcc_assert (corank > 0);
+  gcc_assert (se->loop->dimen == 1);
+  gcc_assert (se->ss->expr == expr);
+
+  dim_arg = se->loop->loopvar[0];
+  dim_arg = fold_build2_loc (input_location, PLUS_EXPR,
+ gfc_array_index_type, dim_arg,
+ gfc_rank_cst[rank]);
+  gfc_advance_se_ss_chain (se);
+}
+  else
+{
+  /* Use the passed DIM= argument.  */
+  gcc_assert (expr->value.function.actual->next->expr);
+  gfc_init_se (&argse, NULL);
+  gfc_conv_expr_type (&argse, expr->value.function.actual->next->expr,
+			  gfc_array_index_type);
+  gfc_add_block_to_block (&se->pre, &argse.pre);
+  dim_arg = argse.expr;
+
+  if (INTEGER_CST_P (dim_arg))
+	{
+	  int hi, co_dim;
+
+	  hi = TREE_INT_CST_HIGH (dim_arg);
+	  co_dim = TREE_INT_CST_LOW (dim_arg);
+	  if (hi || co_dim < 1
+	  || co_dim > GFC_TYPE_ARRAY_CORANK (TREE_TYPE (desc)))
+	gfc_error ("'dim' argument of %s intrinsic at %L is not a valid "
+		   "dimension index", expr->value.function.isym->name,
+		   &expr->where);
+	}
+ else if (gfc_option.rtcheck & GFC_RTCHECK_BOUNDS)
+	{
+	  dim_arg = gfc_evaluate_now (dim_arg, &se->pre);
+	  cond = fold_build2_loc (input_location, LT_EXPR, boolean_type_node,
+  dim_arg,
+  build_int_cst (TREE_TYPE (dim_arg), 1));
+	  tmp = gfc_rank_cst[GFC_TYPE_ARRAY_CORANK (TREE_TYPE (desc))];
+	  tmp = fold_build2_loc (input_location, GT_EXPR, boolean_type_node,
+ dim_arg, tmp);
+	  cond = fold_build2_loc (input_location, TRUTH_ORIF_EXPR,
+  boolean_type_node, cond, tmp);
+	  gfc_trans_runtime_check (true, false, cond, &se->pre, &expr->where,
+			   gfc_msg_fault);
+	}
+}
+
+  /* Used algorithm; cf. Fortran 2008, C.10. Note, due to the scalarizer,
+ one always has a dim_arg argument.
+
+ m = this_images() - 1
+ i = rank
+ min_var = min (corank - 2, dim_arg)
+ for (;;)
+   {
+	 extent = gfc_extent(i)
+	 ml = m
+	 m  = m/extent
+	 if (i >= min_var) 
+	   goto exit_label
+	 i++
+   }
+ exit_label:
+ sub(dim_arg) = (dim_arg < corank) ? ml - m*extent + lcobound(dim_arg)
+   : m + lcobound(corank)
+  */
+
+  m = gfc_create_var (type, NULL); 
+  ml = gfc_create_var (type, NULL); 
+  loop_var = gfc_create_var (integer_type_node, NULL); 
+  min_var = gfc_create_var (integer_type_node, NULL); 
+
+  /* m = this_image () - 1.  */
+  tmp = fold_convert (type, gfort_gvar_caf_this_image);
+

Re: [google] Patch to support calling multi-versioned functions via new GCC builtin. (issue4440078)

2011-05-02 Thread Richard Guenther
On Mon, May 2, 2011 at 6:41 PM, Xinliang David Li  wrote:
> On Mon, May 2, 2011 at 2:11 AM, Richard Guenther
>  wrote:
>> On Fri, Apr 29, 2011 at 6:23 PM, Xinliang David Li  
>> wrote:
>>> Here is the background for this feature:
>>>
>>> 1) People relies on function multi-version to explore hw features and
>>> squeeze performance, but there is no standard ways of doing so, either
>>> a) using indirect function calls with function pointers set at program
>>> initialization; b) using manual dispatch at each callsite; b) using
>>> features like IFUNC.  The dispatch mechanism needs to be promoted to
>>> the language level and becomes the first class citizen;
>>
>> You are not doing that, you are inventing a new (crude) GCC extension.
>
> To capture the high level semantics and prevent user from lowering the
> dispatch calls into forms compiler can not recognize, language
> extension is the way to go.

I don't think so.  With your patch only two passes understand the new
high-level form, the rest of the gimple passes are just confused.

>>
>
>>> See above. Multi-way dispatch can be added similarly.
>>
>> Not with the specified syntax.  So you'd end up with _two_
>> language extensions.  That's bad (and unacceptable, IMHO).
>
> This part can be improved.
>
>>
>>>

 That's a nice idea, but why not simply process all functions with
 a const attribute and no arguments this way?  IMHO

 int testsse (void) __attribute__((const));

 is as good and avoids the new attribute completely.  The pass would
 also benefit other uses of this idiom (giving a way to have global
 dynamic initializers in C).  The functions may not be strictly 'const'
 in a way the compiler autodetects this attribute but it presents
 exactly the promises to the compiler that allow this optimization.

 Thus, please split this piece out into a separate patch and use
 the const attribute.
>>>
>>>
>>> Sounds good.
>>>
>
>>>
>>> 1) the function selection may happen in a different function;
>>
>> Well, sure.  I propose to have the above as lowered form.  If people
>> deliberately obfuscate code it's their fault.  Your scheme simply
>> makes that obfuscation impossible (or less likely possible).  So
>> 1) is not a valid argument.
>
> Lowering too early may defeat the purpose because
>
> 1) the desired optimization may not happen subject to many compiler
> heuristic changes;
> 2) it has other side effects such as wrong estimation of function size
> which may impact inlining

May, may ... so you say all this can't happen under any circumstance
with your special code and passes?  Which nobody will see benefit
from unless they rewrite their code?  Well, I say if we can improve
_some_ of the existing usages that's better than never doing wrong
on a new language extension.  One that I'm not convinced is the way
to go (you didn't address at all the inability to use float arguments
and the ABI issues with using variadic arguments - after all you
did a poor-mans language extension by using GCC builtins instead
of inventing a true one).

> 3) it limits the lowering into one form which may not be ideal  --
> with builtin_dispatch, after hoisting optimization, the lowering can
> use more efficient IFUNC scheme, for instance.

I see no reason why we cannot transform a switch-indirect-call
pattern into an IFUNC call.

>> My point is that such optimization is completely independent of
>> that dispatch thing.  The above could as well be a selection to
>> use different input arrays, one causing alias analysis issues
>> and one not.
>>
>> Thus, a __builtin_dispatch centric optimization pass is the wrong
>> way to go.
>
> I agree that many things can implemented in different ways, but a high
> level standard builtin_dispatch mechanism doing hoisting
> interprocedcurally is cleaner and simpler and targeted for function
> multi-versioning -- it does not depend on/rely on later phase's
> heuristic tunings to make the right things to happen. Function MV
> deserves this level of treatment as it will become more and more
> important for some users (e.g., Google).

But inventing a new language extension to benefit from whatever
improvements we implement isn't the obviously best choice.

>> Now, with FDO I'd expect the foo is inlined into bar (because foo
>> is deemed hot),
>
> That is a myth -- the truth is that there are other heuristics which
> can prevent this from happening.

Huh, sure.  That doesn't make my expectation a myth.

>> then you only need to deal with loop unswitching,
>> which should be easy to drive from FDO.
>
> Same here -- the loop body may not be well formed/recognized. The loop
> nests may not be perfectly nested, or other unswitching heuristics may
> block it from happening.  This is the common problem form many other
> things that get lowered too early. It is cleaner to make the high
> level transformation first in IPA, and let unswitching dealing with
> intra-procedural optimization.

If it's not well

Re: Improve jump threading 4 of N

2011-05-02 Thread Jeff Law
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 05/02/11 15:18, Richard Guenther wrote:

> 
>> For (edge *)xmalloc (sizeof (edge) * 1) use XNEWVEC and friends.
Yup.  Good catch.  Will fix.  Old habits die hard.

>> I wonder if it makes sense to use a VEC instead (will the vector
>> be of variable size?).  Maybe wrap accesses to e->aux with
>> a macro or some inline functions.
It's fixed size (2 edges once I add support for copying the joiner block).

Wrappers are probably a good idea as well.

I've got no opinion on using a VEC if folks chime in with the request,
I'll make that change.

jeff
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJNvyNeAAoJEBRtltQi2kC7SBkIAI3xXdlmEgfjD/Jd/48h63Oa
CF+qfjm3hQYLBr31UzQB82CdWgm2i7p9WLWdlMsNwnB4sEjriTE1bqnYKK6xQfnP
xlP1cUHmBij3s7IbezGN1OeL5d3lDJ8tLH3gumroutgPgktQMNMLUU7wQbf9AdlY
q1n9MVurPgCvU4K0/neX+u16r4Uo5nMx+OuKUiizR1aOI1GweykQxa9zABZ3ivnz
Yfof9jfZFappwvqRl4cAeCW1YFbXg2XdfxmVET4Bb5XvNhyLB94cTVfqIVrM1DWX
j2+UsDkexDtUyA0jxzF6+xK8vdHPcou23R8AHjSqbOvzzUUmtuKnhKYmKptLgu0=
=Ib0z
-END PGP SIGNATURE-


Re: Improve jump threading 4 of N

2011-05-02 Thread Richard Guenther
On Mon, May 2, 2011 at 11:34 PM, Jeff Law  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 05/02/11 15:18, Richard Guenther wrote:
>
>>
>>> For (edge *)xmalloc (sizeof (edge) * 1) use XNEWVEC and friends.
> Yup.  Good catch.  Will fix.  Old habits die hard.
>
>>> I wonder if it makes sense to use a VEC instead (will the vector
>>> be of variable size?).  Maybe wrap accesses to e->aux with
>>> a macro or some inline functions.
> It's fixed size (2 edges once I add support for copying the joiner block).
>
> Wrappers are probably a good idea as well.
>
> I've got no opinion on using a VEC if folks chime in with the request,
> I'll make that change.

If it's fixed size there's no need for a VEC, it would be just overhead.

Richard.

> jeff
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
>
> iQEcBAEBAgAGBQJNvyNeAAoJEBRtltQi2kC7SBkIAI3xXdlmEgfjD/Jd/48h63Oa
> CF+qfjm3hQYLBr31UzQB82CdWgm2i7p9WLWdlMsNwnB4sEjriTE1bqnYKK6xQfnP
> xlP1cUHmBij3s7IbezGN1OeL5d3lDJ8tLH3gumroutgPgktQMNMLUU7wQbf9AdlY
> q1n9MVurPgCvU4K0/neX+u16r4Uo5nMx+OuKUiizR1aOI1GweykQxa9zABZ3ivnz
> Yfof9jfZFappwvqRl4cAeCW1YFbXg2XdfxmVET4Bb5XvNhyLB94cTVfqIVrM1DWX
> j2+UsDkexDtUyA0jxzF6+xK8vdHPcou23R8AHjSqbOvzzUUmtuKnhKYmKptLgu0=
> =Ib0z
> -END PGP SIGNATURE-
>


[patch, ia64, pa] Improve UNIX 2003 compatibility on HP-UX 11.31

2011-05-02 Thread Steve Ellcey
This patch improves unix 2003 conformance on HP-UX 11.31 systems
by linking in the unix2003.o object instead of the unix98.o object.
The only difference I am aware of between the two is that linking in
unix2003.o alters the behaviour of snprintf when the buffer is not
large enough to hold the string being printed.  It used to return -1,
but with unix2003.o linked in it will return the number of characters
that would have been printed if it hadn't been truncated.

For IA64 HP-UX 11.31 I just link in this file instead of unix98.o.
This is similar to how I handled unix98.o before, it just gets linked
in and there are no options to choose one vs. the other.

For HPPA HP-UX 11.31 I added -munix=2003 to match the existing -munix=93
and -munix=95 flags and made 2003 the default for 11.31 systems.

I already ran the PA changes past Dave Anglin and will check this in
later this week if there are no objections.

Tested on 11.31 PA and IA64 systems.

Steve Ellcey
s...@cup.hp.com


2011-05-02  Steve Ellcey  

* config.gcc (hppa*64*-*-hpux11*): Modify tm_file and extra_options
for 11.31.
(hppa[12]*-*-hpux11*): Ditto.
(ia64*-*-hpux*): Add ia64/hpux-unix2003.h to tm_file.
* config/ia64/hpux-unix2003.h: New.
* config/pa/pa-hpux1131.opt: New.
* config/pa/pa-hpux1131.h: New.
* config/pa/pa64-hpux.h (STARTFILE_SPEC): Use unix2003.o if requested.
* config/pa/pa-hpux.opt (flag_pa_unix): Check TARGET_HPUX_11_31 value.
config/pa/pa.h (TARGET_HPUX_11_31): Provide default (0) value.


Index: config.gcc
===
--- config.gcc  (revision 173240)
+++ config.gcc  (working copy)
@@ -1063,10 +1063,14 @@
 pa/pa64-regs.h pa/pa-hpux.h pa/pa-hpux1010.h \
 pa/pa-hpux11.h"
case ${target} in
-   *-*-hpux11.[1-9]*)
+   *-*-hpux11.[12]*)
tm_file="${tm_file} pa/pa-hpux.h pa/pa-64.h pa/pa64-hpux.h"
extra_options="${extra_options} pa/pa-hpux.opt"
;;
+   *-*-hpux11.[3-9]*)
+   tm_file="${tm_file} pa/pa-hpux1131.h pa/pa-64.h pa/pa64-hpux.h"
+   extra_options="${extra_options} pa/pa-hpux1131.opt"
+   ;;
*)
tm_file="${tm_file} pa/pa-64.h pa/pa64-hpux.h"
;;
@@ -,10 +1115,14 @@
extra_options="${extra_options} pa/pa-hpux.opt pa/pa-hpux1010.opt \
   hpux11.opt"
case ${target} in
-   *-*-hpux11.[1-9]*)
+   *-*-hpux11.[12]*)
tm_file="${tm_file} pa/pa-hpux.h"
extra_options="${extra_options} pa/pa-hpux.opt"
;;
+   *-*-hpux11.[3-9]*)
+   tm_file="${tm_file} pa/pa-hpux1131.h"
+   extra_options="${extra_options} pa/pa-hpux1131.opt"
+   ;;
esac
tmake_file="pa/t-pa-hpux11 pa/t-pa-hpux pa/t-hpux-shlib"
# Set the libgcc version number
@@ -1580,6 +1588,11 @@
extra_options="${extra_options} ia64/ilp32.opt hpux11.opt"
use_gcc_stdint=wrap
tm_file="${tm_file} hpux-stdint.h"
+   case ${target} in
+   *-*-hpux11.3*)
+   tm_file="${tm_file} ia64/hpux-unix2003.h"
+   ;;
+   esac
;;
 ia64-hp-*vms*)
tm_file="${tm_file} elfos.h ia64/sysv4.h ia64/elf.h ia64/vms.h 
ia64/vms64.h"
Index: config/ia64/hpux-unix2003.h
===
--- config/ia64/hpux-unix2003.h (revision 0)
+++ config/ia64/hpux-unix2003.h (revision 0)
@@ -0,0 +1,8 @@
+
+/* For HP-UX 11.31 and greater, use unix2003.o instead of unix98.o to
+   get correct C99 snprintf behaviour with buffer overflow.  */
+
+#undef STARTFILE_SPEC
+#define STARTFILE_SPEC "%{!shared:%{static:crt0%O%s} \
+ %{mlp64:/usr/lib/hpux64/unix2003%O%s} \
+ %{!mlp64:/usr/lib/hpux32/unix2003%O%s}}"
Index: config/pa/pa64-hpux.h
===
--- config/pa/pa64-hpux.h   (revision 173240)
+++ config/pa/pa64-hpux.h   (working copy)
@@ -304,8 +304,15 @@
 /* The following STARTFILE_SPEC and ENDFILE_SPEC defines provide the
magic needed to run initializers and finalizers.  */
 #undef STARTFILE_SPEC
-#if TARGET_HPUX_11_11
+#if TARGET_HPUX_11_31
 #define STARTFILE_SPEC \
+  "%{!shared: %{!symbolic: crt0%O%s} \
+ %{munix=95:unix95.o%s} %{munix=98:unix98.o%s} \
+ %{!munix=93:%{!munix=95:%{!munix=98:unix2003%O%s \
+ %{static:crtbeginT%O%s} \
+   %{!static:%{!shared:crtbegin%O%s} %{shared:crtbeginS%O%s}}"
+#elif TARGET_HPUX_11_11
+#define STARTFILE_SPEC \
   "%{!shared: %{!symbolic: crt0%O%s} %{munix=95:unix95.o%s} \
  %{!munix=93:%{!munix=95:unix98%O%s}}} %{static:crtbeginT%O%s} \
%{!static:%{!shared:crtbegin%O%s} %{shared:crtbeginS%O%s}}"
Index: config/pa/pa-hpux.opt
=

Re: Improve jump threading 4 of N

2011-05-02 Thread Diego Novillo
On Mon, May 2, 2011 at 17:34, Jeff Law  wrote:

> I've got no opinion on using a VEC if folks chime in with the request,
> I'll make that change.

I have a slight preference for VEC by default.


Diego.


  1   2   >