Re: [Patch, ARM] Enable GCC to support new ARM core cortex-m0+

[Terry Guo]

Ping.

On Fri, Apr 6, 2012 at 2:15 PM, Terry Guo  wrote:
> Hello,
>
> This simple patch is to enable GCC to accept new option -mcpu=cortex-m0plus
> in order to support newly released Cortex-M0+. Is it OK to trunk, 4.7 branch
> and 4.6 branch?
>
> BR,
> Terry
>
> 2012-04-06  Terry Guo  
>
>        * config/arm/arm-cores.def: Added core cortex-m0plus.
>        * config/arm/arm-tune.md: Regenerated.
>        * config/arm/arm-tables.opt: Regenerated.
>        * doc/invoke.texi: Added entry for cpu ARM Cortex-M0PLUS.

Re: [patch, fortran-dev] Use fixed variable sizes for stride calculations

[Thomas Koenig]

Hi,


this patch uses division by known sizes (which can usually be replaced
by a simple shift because intrinsics have sizes of power of two) instead
of division by the size extracted from the array descriptor itself.

This should save about 20 cycles for a single calculation.

I'll go through the rest of the library to identify other possibilities
for this.

Regression-tested, no new failures.

OK for the branch?


Full patch at http://gcc.gnu.org/ml/fortran/2012-03/msg00120.html

Ping?

Thomas

Re: [Patch, Fortran] PR52729 - fix module-proc decl access for BLOCK/SELECT TYPE

[Tobias Burnus]

Ping.

On 04/03/2012 01:59 PM, Tobias Burnus wrote:

A rather obvious patch.

The module procedure had the FL_PROCEDURE due its use ("CALL sub" or 
"func()") - but no interface and no type. Thus, there was no attempt 
to search for the symbol in the parent namespace, which causes failures.


Build and tested on x86-84-linux.
OK for the trunk?



PS: I lost track. Are there patches which still have to be reviewed?


Seemingly: Plenty. Also, some reviewed patches seem to uncommitted.

Tobias

Re: [PATCH] Fix PR52881, more loop preserving fallout with RTL optimizers

[Richard Guenther]

On Tue, 10 Apr 2012, Steven Bosscher wrote:

> On Tue, Apr 10, 2012 at 4:56 PM, Richard Guenther  wrote:
> > I'm sure more RTL optimiziation fallout will pop up - and I wonder
> > if we should simply avoid modifying the CFG all over the place and
> > instead do that in cleanup_cfg.  Thus, in the if-conversion case,
> > simply do the speculation and leave the empty forwarder blocks
> > to be cleaned up by cleanup_cfg (or for CSE to leave unconditional
> > jumps conditional, as if (0/1), for example).
> 
> The problem with that could be that if(0|1) is not a valid instruction
> for every machine. You may need to set a register (pseudo, or hard
> reg) that may not be available (e.g. if it is live).

Hmm.  But we'd have such if(0|1) only in the short period between
the pass changing it to that and the next cleanup_cfg run, which would
ideally be right after that pass.  Alternatively passes could leave
the CFG not updated (thus, keep dead edges) but update the conditional
jump instructions only.

That said, currently I'm following the idea of fixing up all places
that pop up ...

Richard.

Re: [Patch, Fortran] PR52729 - fix module-proc decl access for BLOCK/SELECT TYPE

[Thomas Koenig]

Am 11.04.2012 10:01, schrieb Tobias Burnus:

Ping.


OK.

Thanks for the patch!

Thomas

Re: [Patch, ARM] Enable GCC to support new ARM core cortex-m0+

[Richard Earnshaw]

On 06/04/12 07:15, Terry Guo wrote:
> Hello,
> 
> This simple patch is to enable GCC to accept new option -mcpu=cortex-m0plus
> in order to support newly released Cortex-M0+. Is it OK to trunk, 4.7 branch
> and 4.6 branch?
> 
> BR,
> Terry
> 
> 2012-04-06  Terry Guo  
> 
> * config/arm/arm-cores.def: Added core cortex-m0plus.
> * config/arm/arm-tune.md: Regenerated.
> * config/arm/arm-tables.opt: Regenerated.
> * doc/invoke.texi: Added entry for cpu ARM Cortex-M0PLUS.
> 

This is ok for trunk only.  It's not suitable for the release branches
as it is a new feature.

R.

Re: Guard use of modulo in cshift (speedup protein)

[Richard Guenther]

On Tue, Apr 10, 2012 at 5:40 PM, Michael Matz  wrote:
> Hi,
>
> On Tue, 10 Apr 2012, Steven Bosscher wrote:
>
>> This is OK.
>
> r186283.
>
>> Do you think it would be worthwhile to do this transformation in the
>> middle end too, based on profile information for values?
>
> I'd think so, but it probably requires a new profiler that counts for how
> often 0 <= A <= B for every "A % B".  Just profiling the range of values
> might be misleading (because A <= N and B <= M and N <= M doesn't imply
> that A <= B often holds).
>
> But it would possibly be an interesting experiment already to do such
> transformation generally (without profiling) and see what it gives on some
> benchmarks.  Just to get a feel what's on the plate.

The question is, of course, why on earth is a modulo operation in the
loop setup so expensive that avoiding it improves the performance of
the overall routine so much ... did you expect the code-gen difference
of your patch?

Richard.

>> IIRC value-prof
>> handles constant divmod but not ranges for modulo operations.
>

> Ciao,
> Michael.

Re: Guard use of modulo in cshift (speedup protein)

[Thomas Koenig]

Hi Michael,

could you replace


+  if (shift<  0 || shift>= len)


by

> +  if (unlikely(shift<  0 || shift>= len))

?  This could save a few more cycles.

Thomas

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

[Richard Guenther]

On Tue, Apr 10, 2012 at 6:05 PM, Michael Matz  wrote:
> Hi,
>
> On Tue, 10 Apr 2012, Richard Guenther wrote:
>
>> > +         vec_inv = build_constructor (vectype, v);
>> > +         new_temp = vect_init_vector (stmt, vec_inv, vectype, gsi);
>> > +         new_stmt = SSA_NAME_DEF_STMT (new_temp);
>> > +         mark_symbols_for_renaming (new_stmt);
>>
>> This should not be necessary - in fact please manually set the proper
>> VUSE here.
>
> I don't see how I could know the right VUSE.  It might not even exist yet.
> Reusing the existing vuse from the load that is replaced isn't correct.
> Consider that there are (unrelated) stores or calls before the load, and
> those are vectorized.  When updating their operands they'll get a new
> vdef, and I'd need to use _that_ one:
>
> original:
>  #vdef MEM_1
>  scalar_store =   (this insn will be removed by vectorizable_store)
>  #vuse MEM_1
>  ... = A[i]
>
> --->
>
>  #vdef MEM   (note, no ssaname yet)
>  vect_store = ...
>  #vuse MEM_1
>  ... = A[i]  ( will be later removed as unused LHS)
>  #vuse XXX
>  ... = A[i]
>  #vuse XXX
>  ... = A[i+stride]
>
> So, which SSA name to use for XXX, when the vect_store doesn't yet know
> (which it doesn't).
>
> Tracking (and generating) proper VDEF SSA names is possible (we only
> vectorize a single BB, and that in stmt order), but that requires some
> rework of the vectorizer main loops, which should be a separate patch.
> Agreed?

Yeah, ok.  Still the renaming is not necessary here, the operand scanner
does that automagically.  The vectorizer forcefully rewrites virtual SSA form
anyways :/

Richard.

>
> Ciao,
> Michael.

Re: [PATCH] Atom: Enabling unroll at O2 optimization level

[Richard Guenther]

On Tue, Apr 10, 2012 at 8:43 PM, Igor Zamyatin  wrote:
> Hi All!
>
> Here is a patch that enables unroll at O2 for Atom.
>
> This gives good performance boost on EEMBC 2.0 (~+8% in Geomean for 32
> bits) with quite moderate code size increase (~5% for EEMBC2.0, 32
> bits).

5% is not moderate.  Your patch does enable unrolling at -O2 but not -O3,
why? Why do you disable register renaming?  check_imull requires a function
comment.

This completely looks like a hack for EEMBC2.0, so it's definitely not ok.

-O2 is not supposed to give best benchmark results.

Thanks,
Richard.

>
> Tested for i386 and x86-64, ok for trunk?
>
> Thanks,
> Igor
>
> ChangeLog:
>
> 2012-04-10  Yakovlev Vladimir  
>
>        * gcc/config/i386/i386.c (check_imull): New routine.
>        (ix86_loop_unroll_adjust): New target hook.
>        (ix86_option_override_internal): Enable unrolling on Atom at -O2.
>        (TARGET_LOOP_UNROLL_ADJUST): New define.

[PATCH] Atom: Scheduler improvements for better imul placement

[Igor Zamyatin]

Hi All!

It is known that imul placement is rather critical for Atom processors
and changes try to improve imul scheduling for Atom.

This gives +5% performance on several tests from new OA 2.0 testsuite
from EEMBC.

Tested for i386 and x86-64, ok for trunk?


ChangeLog:

2012-04-10  Yuri Rumyantsev  

* config/i386/i386.c (x86_sched_reorder): New function.
Add new function x86_sched_reorder
to take advantage of Atom pipelened IMUL execution.


imul_sched.patch
Description: Binary data

Re: [PATCH, rs6000] Fix PR16458, eliminate redudant compares

[Richard Guenther]

On Tue, Apr 10, 2012 at 8:50 PM, David Edelsohn  wrote:
> On Tue, Apr 10, 2012 at 1:36 PM, Peter Bergner  wrote:
>
>> 2012-mm-dd  Peter Bergner  
>>            Michael Matz  
>>
>> gcc/
>>        PR target/16458
>>        * rtlanal.c (unsigned_reg_p): New function.
>>        * rtl.h (unsigned_reg_p): Prototype it.
>>        * config/rs6000/rs6000.c (rs6000_generate_compare): Use it.
>>        Update comment.
>>        * expr.c (expand_expr_real_1): Set register attributes.
>>        * stmt.c (expand_case): Likewise.
>>
>> gcc/testsuite/
>>        PR target/16458
>>        * gcc.target/powerpc/pr16458-1.c: New test.
>>        * gcc.target/powerpc/pr16458-2.c: Likewise.
>>        * gcc.target/powerpc/pr16458-3.c: Likewise.
>>        * gcc.target/powerpc/pr16458-4.c: Likewise.
>
> The rs6000 and testsuite parts of the patch are okay with me.

The rest is ok as well.

Thanks,
Richard.

> Thanks, David

Re: follow up patch to clean up TODO_dump_func

[Richard Guenther]

On Tue, Apr 10, 2012 at 8:54 PM, Xinliang David Li  wrote:
> Hi Richard, this is a follow up patch for more cleanups.
>
> Bootstrap and tested on x86-64/linux.
>
> Ok for trunk?

Ok.

Thanks,
Richard.

> thanks,
>
> David

Re: [Patch] tree-parloops.c (eliminate_local_variables): Add braces to suppress warnings

[Richard Guenther]

On Tue, Apr 10, 2012 at 9:08 PM, NightStrike  wrote:
> On Tue, Apr 10, 2012 at 10:38 AM, Richard Guenther
>  wrote:
>> On Tue, Apr 10, 2012 at 3:06 PM, JonY  wrote:
>>> On 4/10/2012 20:37, Richard Guenther wrote:
 On Tue, Apr 10, 2012 at 2:15 PM, JonY wrote:
> Hi,
>
> Patch OK?

 What kind of warning?

>>>
>>> Oops, I forgot to mention gcc was complaining about missing braces.
>>
>> Not for me.  And I fail to see why it should.
>
> This is the warning:
>
> ../../../../build/gcc/src/gcc/tree-parloops.c:724: warning: suggest
> explicit braces to avoid ambiguous `else'

> ./xgcc -B. -c   -g -DIN_GCC   -W -Wall -Wwrite-strings -Wcast-qual 
> -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic 
> -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings 
> -Wold-style-definition -Wc++-compat -fno-common  -DHAVE_CONFIG_H -I. -I. 
> -I/space/rguenther/src/svn/trunk/gcc -I/space/rguenther/src/svn/trunk/gcc/. 
> -I/space/rguenther/src/svn/trunk/gcc/../include 
> -I/space/rguenther/src/svn/trunk/gcc/../libcpp/include  
> -I/space/rguenther/src/svn/trunk/gcc/../libdecnumber 
> -I/space/rguenther/src/svn/trunk/gcc/../libdecnumber/bid -I../libdecnumber
> /space/rguenther/src/svn/trunk/gcc/tree-parloops.c -o tree-parloops.o

no warning from trunk.  Which GCC version emits this warning?  Note that
we do not try to keep stage1 warning-free but only later stages (which is
why we use -Werror there).

Richard.

Re: [Patch, Fortran, F03] PR52909: Procedure pointers not private to modules

[Janus Weil]

Hi Tobias,

> Hence, we should really think about -fabi-version= (and .mod 
> compatibility).
> Unless, we are positive that we will break the ABI for the array descriptor in
> 4.8, I am in favour of adding -fabi-version= already for the proc-pointer
> patch.
>
> Comments?

well, my feeling is that adding an "-fabi-version" machinery just for
the proc-pointer problem would be overkill, because ...

1) Different assembler names for proc-pointers will usually result in
linker errors, when mixing code compiled with different gfortran
versions. So at least the user knows that there is a problem and will
not silently get wrong results or random segfaults (as it probabably
would be the case for mixing different array descriptor versions).

2) Although proc-pointers have been supported by gfortran for about
three years now, I don't think there are many libraries around which
use proc-pointers and are redistributed in binary form. So I would not
see this as a major problem (but maybe I just underestimate this
issue).

3) As you mentioned, the .mod version incompatibility also severely
limits the mixing of code compiled with different compiler versions.
And the proc-pointer name mangling (which is under discussion here)
*only* concerns proc-pointers inside modules.

I would surely appreciate some input from others, also from users (in
particular from Andrew as the bug reporter). In general: Is ABI
compatibility of different gfortran versions important to gfortran
users? (For me personally, as a user, not so much. I usually don't
link my own code with pre-compiled Fortran libraries).

The question is also: Should I rather commit the patch to the branch,
so that it will only be merged to trunk together with the new array
descriptor (once it is finished)?

Cheers,
Janus

[PATCH 09/11] Fix va_arg type location

[Dodji Seketeli]

Now that diagnostics first point to the spelling location of tokens
coming from macro expansion, the test case
gcc/testsuite/g++.old-deja/g++.other/vaarg3.C shows that when I write
va_args (args, some_type), the location that is recorded for
"some_type" is not correct.  We wrongly record a location that is in
the system header where the va_args macro is defined.

This patch changes that to correctly record the location for the type
operand of the va_arg expression.

With this patch applied, the
gcc/testsuite/g++.old-deja/g++.other/vaarg3.C test PASSes with and
without -ftrack-macro-expansion.

Tested on x86_64-unknown-linux-gnu against trunk.

Note that the bootstrap with -ftrack-macro-expansion exhibits other
separate issues that are addressed in subsequent patches.  This patch
just fixes one class of problems.

The patch does pass bootstrap with -ftrack-macro-expansion turned off,
though.

gcc/cp/

* cp-tree.h (build_x_va_arg): Take an additional location
parameter.
* call.c (build_x_va_arg): Take a loc parameter for the location
of the type of the va_arg expression.
* parser.c (cp_parser_primary_expression): Pass the type of the
type in the va_arg expression to build_x_va_arg.
* pt.c (tsubst_copy): Adjust calls to build_x_va_arg.
---
 gcc/cp/call.c|4 ++--
 gcc/cp/cp-tree.h |2 +-
 gcc/cp/parser.c  |4 +++-
 gcc/cp/pt.c  |6 --
 4 files changed, 10 insertions(+), 6 deletions(-)

diff --git a/gcc/cp/call.c b/gcc/cp/call.c
index f2ea19b..6a26d6d 100644
--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -6073,7 +6073,7 @@ convert_arg_to_ellipsis (tree arg)
 /* va_arg (EXPR, TYPE) is a builtin. Make sure it is not abused.  */
 
 tree
-build_x_va_arg (tree expr, tree type)
+build_x_va_arg (source_location loc, tree expr, tree type)
 {
   if (processing_template_decl)
 return build_min (VA_ARG_EXPR, type, expr);
@@ -6099,7 +6099,7 @@ build_x_va_arg (tree expr, tree type)
   return expr;
 }
 
-  return build_va_arg (input_location, expr, type);
+  return build_va_arg (loc, expr, type);
 }
 
 /* TYPE has been given to va_arg.  Apply the default conversions which
diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index db5e8a5..9dd7510 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -4886,7 +4886,7 @@ extern void push_defarg_context   (tree);
 extern void pop_defarg_context (void);
 extern tree convert_default_arg(tree, tree, tree, int);
 extern tree convert_arg_to_ellipsis(tree);
-extern tree build_x_va_arg (tree, tree);
+extern tree build_x_va_arg (source_location, tree, tree);
 extern tree cxx_type_promotes_to   (tree);
 extern tree type_passed_as (tree);
 extern tree convert_for_arg_passing(tree, tree);
diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index eac60f1..12cfdc1 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -4168,6 +4168,7 @@ cp_parser_primary_expression (cp_parser *parser,
  {
tree expression;
tree type;
+   source_location type_location;
 
/* The `__builtin_va_arg' construct is used to handle
   `va_arg'.  Consume the `__builtin_va_arg' token.  */
@@ -4179,6 +4180,7 @@ cp_parser_primary_expression (cp_parser *parser,
  /*cast_p=*/false, 
NULL);
/* Look for the `,'.  */
cp_parser_require (parser, CPP_COMMA, RT_COMMA);
+   type_location = cp_lexer_peek_token (parser->lexer)->location;
/* Parse the type-id.  */
type = cp_parser_type_id (parser);
/* Look for the closing `)'.  */
@@ -4188,7 +4190,7 @@ cp_parser_primary_expression (cp_parser *parser,
if (cp_parser_non_integral_constant_expression (parser,
NIC_VA_ARG))
  return error_mark_node;
-   return build_x_va_arg (expression, type);
+   return build_x_va_arg (type_location, expression, type);
  }
 
case RID_OFFSETOF:
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index ee38254..0c3f7c0 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -12440,7 +12440,8 @@ tsubst_copy (tree t, tree args, tsubst_flags_t 
complain, tree in_decl)
   gcc_unreachable ();
 
 case VA_ARG_EXPR:
-  return build_x_va_arg (tsubst_copy (TREE_OPERAND (t, 0), args, complain,
+  return build_x_va_arg (EXPR_LOCATION (t),
+tsubst_copy (TREE_OPERAND (t, 0), args, complain,
  in_decl),
 tsubst (TREE_TYPE (t), args, complain, in_decl));
 
@@ -14273,7 +14274,8 @@ tsubst_copy_and_build (tree t,
   }
 
 case VA_ARG_EXPR:
-  return build_x_va_arg (RECUR (TREE_OPERAND (t, 0)),
+  return build_x_va_arg (EXPR_LOCATION (t),
+ 

Re: [RS6000] Stack tie fix.

[Richard Guenther]

On Wed, Apr 11, 2012 at 6:15 AM, Alan Modra  wrote:
> On Fri, Apr 06, 2012 at 05:25:15PM +0200, Olivier Hainque wrote:
>>  Have you discovered where the problem you are still observing
>>  is coming from (with another case on 4.4) ? I was planning to look
>>  into it and realized that maybe you were already doing so.
>
> In gcc-4.4, alias.c:write_dependence_p has
>
>  if (DIFFERENT_ALIAS_SETS_P (x, mem))
>    return 0;
>
> immediately after the tests for (mem:BLK (scratch)) and
> ALIAS_SET_MEMORY_BARRIER.  On find_num.c the read from the stack arr[]
> is alias set 3, the stack tie is alias set 2, so they are seen as not
> conflicting.
>
> For mainline we have the same alias sets but with the addresses
> involved, (unspec [reg 1] UNSPEC_TIE) and (plus (reg 9) (reg 3)), we
> run all the way down to rtx_refs_may_alias_p where ao_ref_from_mem for
> the stack tie returns false.  So anti_dependence returns true.
>
> Hmm, the fact that alias analysis on mainline treats my fancy barriers
> like this says I may as well have not bothered.  (mem:BLK (scratch))
> performs identically at the moment.

Well - you are expecting generic code to understand your arch-specific
UNSPEC.  It of course cannot.  From reading back a bit I understand
that you want alias analysis to consider this a barrier for all memory
accesses that all mentioned registers possibly point to?  I'd have used

 (USE (mem:BLK (reg 1)))
 (CLOBBER (mem:BLK (reg 1)))

repeated, for each register (maybe you can avoid the USE if the CLOBBER
is implicitely considered a use, or maybe we don't need to care because
we do not specify what piece of memory is possibly clobbered, we just
specify its base address).

Oh, and the above would need to be handled explicitely anyway in alias.c

Richard.

> --
> Alan Modra
> Australia Development Lab, IBM

Re: [Patch, Fortran] PR52729 - fix module-proc decl access for BLOCK/SELECT TYPE

[Janus Weil]

>> PS: I lost track. Are there patches which still have to be reviewed?
>
> Seemingly: Plenty. Also, some reviewed patches seem to uncommitted.

Maybe it would make sense to reactivate
http://gcc.gnu.org/wiki/GFortranPatchTracker and collect the pending
patches there?

Cheers,
Janus

[PATCH 08/11] Make conversion warnings work on NULL with -ftrack-macro-expansion

[Dodji Seketeli]

There are various conversion related warnings that trigger on
potentially dangerous uses of NULL (or __null).  NULL is defined as a
macro in a system header, so calling warning or warning_at on a virtual
location of NULL yields no diagnostic.  So the test accompanying this
patch (as well as others), was failling when run with
-ftrack-macro-expansion.

I think it's necessary to use the location of NULL that is in the main
source code (instead of, e.g, the spelling location that is in the
system header where the macro is defined) in those cases.  Note that for
__null, we don't have the issue.

I have augmented the test of this patch to check that we don't regress
when handling __null.

Tested on x86_64-unknown-linux-gnu against trunk.

Note that the bootstrap with -ftrack-macro-expansion exhibits other
separate issues that are addressed in subsequent patches.  This patch
just fixes one class of problems.

The patch does pass bootstrap with -ftrack-macro-expansion turned off,
though.

gcc/cp/

* call.c (conversion_null_warnings): When on NULL, resolve
location to the point in the main source code, rather than to the
spelling location.
* cvt.c (build_expr_type_conversion): Likewise.
* typeck.c (cp_build_binary_op): Likewise.

gcc/testsuite/

* g++.dg/warn/Wconversion-null-2.C: Add testing for __null,
alongside the previous testing for NULL.
---
 gcc/cp/call.c  |   18 -
 gcc/cp/cvt.c   |   18 -
 gcc/cp/typeck.c|   20 +--
 gcc/testsuite/g++.dg/warn/Wconversion-null-2.C |   31 +++-
 4 files changed, 79 insertions(+), 8 deletions(-)

diff --git a/gcc/cp/call.c b/gcc/cp/call.c
index 3c3dabb..f2ea19b 100644
--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -5538,12 +5538,26 @@ conversion_null_warnings (tree totype, tree expr, tree 
fn, int argnum)
   if (expr == null_node && TREE_CODE (totype) != BOOLEAN_TYPE
   && ARITHMETIC_TYPE_P (totype))
 {
+  source_location loc = input_location;
+  /* The location of the warning here is most certainly the one for
+the token that represented null_node in the source code.
+That is either NULL or __null.  If it is NULL, then that
+macro is defined in a system header and, as a consequence,
+warning_at won't emit any diagnostic for it.  In this case,
+we are going to resolve that location to the point in the
+source code where the expression that triggered this error
+message is, rather than the point where the NULL macro is
+defined.  */
+  if (in_system_header_at (input_location))
+   loc = linemap_resolve_location (line_table, loc,
+   LRK_MACRO_EXPANSION_POINT,
+   NULL);
   if (fn)
-   warning_at (input_location, OPT_Wconversion_null,
+   warning_at (loc, OPT_Wconversion_null,
"passing NULL to non-pointer argument %P of %qD",
argnum, fn);
   else
-   warning_at (input_location, OPT_Wconversion_null,
+   warning_at (loc, OPT_Wconversion_null,
"converting to non-pointer type %qT from NULL", totype);
 }
 
diff --git a/gcc/cp/cvt.c b/gcc/cp/cvt.c
index c411a47..73bdf71 100644
--- a/gcc/cp/cvt.c
+++ b/gcc/cp/cvt.c
@@ -1468,8 +1468,22 @@ build_expr_type_conversion (int desires, tree expr, bool 
complain)
   if (expr == null_node
   && (desires & WANT_INT)
   && !(desires & WANT_NULL))
-warning_at (input_location, OPT_Wconversion_null,
-   "converting NULL to non-pointer type");
+{
+  source_location loc = input_location;
+  /* The location of the warning here is the one for the
+(expansion of the) NULL macro, or for __null.  If it is for
+NULL, then, as that that macro is defined in a system header,
+warning_at won't emit any diagnostic.  In this case, we are
+going to resolve that location to the point in the source
+code where the expression that triggered this warning is,
+rather than the point where the NULL macro is defined.  */
+  if (in_system_header_at (loc))
+   loc = linemap_resolve_location (line_table, loc,
+   LRK_MACRO_EXPANSION_POINT,
+   NULL);
+  warning_at (loc, OPT_Wconversion_null,
+ "converting NULL to non-pointer type");
+}
 
   basetype = TREE_TYPE (expr);
 
diff --git a/gcc/cp/typeck.c b/gcc/cp/typeck.c
index d2ed940..d096f1e 100644
--- a/gcc/cp/typeck.c
+++ b/gcc/cp/typeck.c
@@ -3798,9 +3798,23 @@ cp_build_binary_op (location_t location,
  || (!null_ptr_cst_p (orig_op1) 
  && !TYPE_PTR_P (type1) && !TYPE_PTR_TO_MEMBER_P (type1)))
   && (complain & tf_warning))
-/* Some sort of arithmetic operation involvi

[Doc] Move paragraph about multiple attributes

[Tristan Gingold]

Hi,

this paragraph is inside the 'i386 type attributes' section, while it isn't 
target specific.

This patch moves it at the end of the attribute list.  Maybe we should remove 
it completely
as there is an 'attribute syntax' section.

Ok for trunk ?

Tristan.

2012-04-11  Tristan Gingold  

* doc/extend.texi (Type Attributes): Move paragraph.

index bb43825..c33ec66 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -5372,6 +5372,10 @@ typeinfo node and exception handling will break.
 
 @end table
 
+To specify multiple attributes, separate them by commas within the
+double parentheses: for example, @samp{__attribute__ ((aligned (16),
+packed))}.
+
 @subsection ARM Type Attributes
 
 On those ARM targets that support @code{dllimport} (such as Symbian
@@ -5427,10 +5431,6 @@ Currently @option{-m[no-]ms-bitfields} is provided for 
the Microsoft Windows X86
 compilers to match the native Microsoft compiler.
 @end table
 
-To specify multiple attributes, separate them by commas within the
-double parentheses: for example, @samp{__attribute__ ((aligned (16),
-packed))}.
-
 @anchor{PowerPC Type Attributes}
 @subsection PowerPC Type Attributes
 

[steve.mcint...@linaro.org: Re: Armhf dynamic linker path]

[Steve McIntyre]

Bugger, missed the thread fork and didn't send this invitation to
everybody yet.

- Forwarded message from Steve McIntyre  -

Date: Wed, 11 Apr 2012 02:06:09 +0100
From: Steve McIntyre 
To: Jon Masters 
Cc: cross-dis...@lists.linaro.org, Adam Conrad ,
linaro-toolch...@lists.linaro.org, Jeff Law 
Subject: Re: Armhf dynamic linker path
User-Agent: Mutt/1.5.20 (2009-06-14)

On Tue, Apr 10, 2012 at 05:56:38PM -0400, Jon Masters wrote:
>
>Anyway. My proposal is that we all join the call that Steve is putting
>together on Thursday pm/eve, using my Red Hat bridge. He'll send out the
>information. I would very much appreciate it if you (Jeff) could join
>because you are widely known as a calming voice of reason and sanity (if
>only you scaled to the point we could have one of you on every call). I
>would also like it very much if anyone in the Fedora community who wants
>to share their input could also dial into that meeting. Let's have this
>out, get it finally nailed down, and move on.

And here's the details as promised.

I've started a wiki page at 

https://wiki.linaro.org/OfficeofCTO/HardFloat/LinkerPathCallApr2012

with a strawman agenda for now, and a Doodle poll at 

http://www.doodle.com/93bitkqeb7auyxn7

to see when the best time is for the call on Thursday/Friday. Please
fill in the times that work for you ASAP and I'll announce the result
during Wednesday. Ideally we'd like stakeholders from all the relevant
distros and the upstream toolchain developers to be there, able to
represent their groups and (importantly) able to make a decision here
on what we should do.

Apologies for the short notice, but we need a decision quickly.

Cheers,
-- 
Steve McIntyresteve.mcint...@linaro.org
 Linaro.org | Open source software for ARM SoCs


___
linaro-toolchain mailing list
linaro-toolch...@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain


- End forwarded message -
Cheers,
-- 
Steve McIntyresteve.mcint...@linaro.org
 Linaro.org | Open source software for ARM SoCs

Re: [Patch, Fortran, F03] PR52909: Procedure pointers not private to modules

[Tobias Burnus]

Hi Janus,


On 04/11/2012 10:58 AM, Janus Weil wrote:

Hence, we should really think about -fabi-version=  (and .mod compatibility).
Unless, we are positive that we will break the ABI for the array descriptor in
4.8, I am in favour of adding -fabi-version=  already for the proc-pointer
patch.

Comments?

well, my feeling is that adding an "-fabi-version" machinery just for
the proc-pointer problem would be overkill


It might be - but we do have to worry about the ABI. We can decide that 
it may not matter in this case, but users and even more distributors do 
care about a stable (or backward compatible) ABI and a stable (or 
backward compatible) .mod format.



1) Different assembler names for proc-pointers will usually result in
linker errors, when mixing code compiled with different gfortran
versions. So at least the user knows that there is a problem and will
not silently get wrong results or random segfaults (as it probabably
would be the case for mixing different array descriptor versions).


True. Thus, the array descriptor change is really disruptive. However, 
that does not mean that others aren't affected by other ABI changes.



2) Although proc-pointers have been supported by gfortran for about
three years now, I don't think there are many libraries around which
use proc-pointers and are redistributed in binary form. So I would not
see this as a major problem (but maybe I just underestimate this
issue).


I concur that in this case, the problem is less likely to occur - due to 
various reasons. I am not arguing that we have to add -fabi-version=, 
but we should seriously considering doing so and in either case ABI 
change should be documented in the release notes.


Additionally, besides the case of having no access to the library, the 
case that a pre-compiled library exists is not that low. At least if 
you  work under Linux, where the distribution or some third party 
already has builds. Or if you work on a HPC system where the admins have 
precompiled libraries. (For instance, I have never compiled ScaLapack my 
self.)



3) As you mentioned, the .mod version incompatibility also severely
limits the mixing of code compiled with different compiler versions.
And the proc-pointer name mangling (which is under discussion here)
*only* concerns proc-pointers inside modules.


Note however, that GCC 4.7 and 4.8 do share the same .mod version!


In general: Is ABI ompatibility of different gfortran versions important to 
gfortran
users? (For me personally, as a user, not so much. I usually don't link my own 
code with pre-compiled Fortran libraries).


For me it is very important. Fortunately, most Fortran libraries do not 
use modules and are thus not affected by .mod version issues. There are 
several closed-source libraries and programs. (For the latter, 
compatibility matters as they might be only dynamically linked to 
libraries such as LAPACK.) One library, which I use, is AMD's math 
library. And I know that AMD was struggling before with ABI issues. 
Namely, they had to decide which  gfortran version thy should be  build 
against. Since libgfortran is now backward compatible down to 4.3, they 
are fine at the moment.


The other libraries I use are installed either via the Linux 
distribution or by the HPC admins. Those include BLAS, LAPACK, 
ScaLAPACK, MPI, HDF5, NetCDF, libxc. Some of them ship with .mod files 
and I have heard several complains about their incompatibility. Both 
from users and from Linux distributions.


Frankly, I do not know whether, e.g., libxc uses proc-pointers on module 
level or not. Probably none of the libraries I use would be affected - 
and if, those probably have their source-code available.


To conclude:
* ABI compatibility - especially for libgfortran -  is very important 
and Linux distributions, HPC centers and closed-source software 
distributors rely on it. (Also users expect that their old program still 
runs after an updated - also on systems where no .so versioning is 
possible. [Think of Windows.])
* .mod incompatibility seems to be less an issue, but it also causes 
grieve for users and distributors. As modules (and other F90+ features) 
get more widely used, the problem will grow.



The question is also: Should I rather commit the patch to the branch,
so that it will only be merged to trunk together with the new array
descriptor (once it is finished)?


Regarding your patch, I see three options:

a) Committing it to the branch. Pro: No ABI breakage through the patch 
as the current branch already will break the ABI.

b) Committing to the trunk as is - but with a note in the release notes.
c) Ditto but with backward compatibility through -fabi-version=

Given that it is unclear when the branch will be ready, I prefer (b) or (c).

And I would like to see others commentin on ABI and .mod compatibility 
and also  -fabi-version= *in general*. Plus comments whether (a), (b), 
or (c) is the best choice for *this* patch.


Tobias

Re: [Doc] Move paragraph about multiple attributes

[Richard Guenther]

On Wed, Apr 11, 2012 at 11:33 AM, Tristan Gingold  wrote:
> Hi,
>
> this paragraph is inside the 'i386 type attributes' section, while it isn't 
> target specific.
>
> This patch moves it at the end of the attribute list.  Maybe we should remove 
> it completely
> as there is an 'attribute syntax' section.

I think it's good to have it repeated here.

> Ok for trunk ?

Ok.

Thanks,
Richard.

> Tristan.
>
> 2012-04-11  Tristan Gingold  
>
>        * doc/extend.texi (Type Attributes): Move paragraph.
>
> index bb43825..c33ec66 100644
> --- a/gcc/doc/extend.texi
> +++ b/gcc/doc/extend.texi
> @@ -5372,6 +5372,10 @@ typeinfo node and exception handling will break.
>
>  @end table
>
> +To specify multiple attributes, separate them by commas within the
> +double parentheses: for example, @samp{__attribute__ ((aligned (16),
> +packed))}.
> +
>  @subsection ARM Type Attributes
>
>  On those ARM targets that support @code{dllimport} (such as Symbian
> @@ -5427,10 +5431,6 @@ Currently @option{-m[no-]ms-bitfields} is provided for 
> the Microsoft Windows X86
>  compilers to match the native Microsoft compiler.
>  @end table
>
> -To specify multiple attributes, separate them by commas within the
> -double parentheses: for example, @samp{__attribute__ ((aligned (16),
> -packed))}.
> -
>  @anchor{PowerPC Type Attributes}
>  @subsection PowerPC Type Attributes
>
>

jcf-reader: support for JSR 292 classfile extensions

[Andrew Haley]

This adds support for the new (Version 51.0) class file format.  It
doesn't actually generate code for invokedynamic bcause we don't have
any runtime support yet, but it's a start.  jcf-dump prints all of the
new attributes.

Andrew.


2012-04-11  Andrew Haley  

* jcf.h (bootstrap_method): New.
(BootstrapMethods): New.
(JCF): Add BootstrapMethods.
(enum cpool_tag): Add MethodHandle, MethodType, and InvokeDynamic.
* jcf-reader.c (jcf_parse_bootstrap_methods): New.
(jcf_parse_constant_pool): Handlers for MethodHandle, MethodType,
and InvokeDynamic.
(jcf_parse_bootstrap_methods): New.
* javaop.def (invokedynamic): New opcode.
* jcf-parse.c (get_constant): An unknown constant type should not
be an internal error, but a fatal one.  Make it so.
* jcf-dump.c (HANDLE_BOOTSTRAP_METHODS_ATTRIBUTE): New.
(HANDLE_END_BOOTSTRAP_METHODS): New.
(print_constant): Handlers for MethodHandle, MethodType, and
InvokeDynamic.

Index: java/jcf-dump.c
===
--- java/jcf-dump.c (revision 186103)
+++ java/jcf-dump.c (working copy)
@@ -430,7 +430,24 @@
   print_element_value (out, jcf, 1);   \
 }

+#define HANDLE_BOOTSTRAP_METHODS_ATTRIBUTE()   \
+{  \
+  COMMON_HANDLE_ATTRIBUTE(jcf, attribute_name, attribute_length);  \
+  fputc ('\n', out); jcf_parse_bootstrap_methods (jcf, attribute_length); \
+}

+#define HANDLE_END_BOOTSTRAP_METHODS(NUM_METHODS)  \
+  {\
+int i; \
+for (i = 0; i < NUM_METHODS; i++)  \
+  {
\
+   bootstrap_method *m = &jcf->bootstrap_methods.methods[i];   \
+   fprintf (out, "  %d: ", i); \
+   print_constant (out, jcf, m->method_ref, 1);\
+   fprintf (out, "\n");\
+  }
\
+  }
+
 #define PROCESS_OTHER_ATTRIBUTE(JCF, INDEX, LENGTH) \
 { COMMON_HANDLE_ATTRIBUTE(JCF, INDEX, LENGTH); \
   fputc ('\n', out); JCF_SKIP (JCF, LENGTH); }
@@ -898,6 +915,53 @@
fputc ('\"', out);
   }
   break;
+case CONSTANT_MethodHandle:
+  {
+   int kind = JPOOL_USHORT1 (jcf, index);
+   if (verbosity > 0)
+ fprintf (out, "MethodHandle kind: %d=", kind);
+   switch(kind) {
+   case 1:
+   case 2:
+   case 3:
+   case 4:
+ if (verbosity > 0)
+   fprintf (out, "Fieldref: %ld=", JPOOL_USHORT2 (jcf, index));
+ print_constant (out, jcf, JPOOL_USHORT2 (jcf, index), 0);
+   case 5:
+   case 6:
+   case 7:
+   case 8:
+ if (verbosity > 0)
+   fprintf (out, "Methodref: %ld=", JPOOL_USHORT2 (jcf, index));
+ print_constant (out, jcf, JPOOL_USHORT2 (jcf, index), 0);
+ break;
+   case 9:
+ if (verbosity > 0)
+   fprintf (out, "InterfaceMethodref: %ld=", JPOOL_USHORT2 (jcf, 
index));
+ print_constant (out, jcf, JPOOL_USHORT2 (jcf, index), 0);
+ break;
+   }
+   break;
+  }
+case CONSTANT_MethodType:
+  if (verbosity > 0)
+   fprintf (out, "MethodType %ld: ", JPOOL_USHORT1 (jcf, index));
+  print_signature (out, jcf, JPOOL_USHORT1 (jcf, index), 0);
+  break;
+case CONSTANT_InvokeDynamic:
+  {
+   uint16 name_and_type = JPOOL_USHORT2 (jcf, index);
+   if (verbosity > 0)
+ fprintf (out, "InvokeDynamic: ");
+   fprintf (out, "bootstrap_method: %ld ", JPOOL_USHORT1 (jcf, index));
+   if (verbosity == 2)
+ fprintf (out, " name_and_type: %d=<", name_and_type);
+   print_constant_terse (out, jcf, name_and_type, CONSTANT_NameAndType);
+   if (verbosity == 2)
+ fputc ('>', out);
+   break;
+  }
 default:
   fprintf (out, "(Unknown constant type %d)", kind);
 }
Index: java/jcf-parse.c
===
--- java/jcf-parse.c(revision 186103)
+++ java/jcf-parse.c(working copy)
@@ -1113,8 +1113,8 @@
   jcf->cpool.data[index].t = value;
   return value;
  bad:
-  internal_error ("bad value constant type %d, index %d",
- JPOOL_TAG (jcf, index), index);
+  fatal_error ("bad value constant type %d, index %d",
+  JPOOL_TAG (jcf, index), index);
 }

 tree
Index: java/javaop.def
===
--- java/javaop.def (revision 186103)
+++ java/javaop.def (working copy)
@@ -292,6 +292,7 @@
 JAVAOP (

Re: [i386, patch, RFC] HLE support in GCC

[Kirill Yukhin]

Folks,
Thanks a lot for inputs and suggestions!
Here is updated version of patch.

ChangeLog entry:
2012-04-11  Kirill Yukhin  

* builtins.c (get_memmodel): Remove check of upper bound.
(expand_builtin_atomic_compare_exchange): Mask memmodel values.
* config/i386/cpuid.h (bit_HLE): New.
* config/i386/driver-i386.c (host_detect_local_cpu): Detect
HLE support.
* config/i386/i386-c.c (ix86_target_macros_internal): Set
HLE defines.
(ix86_target_string)<-mhle>: New.
(ix86_option_override_internal): Ditto.
(ix86_valid_target_attribute_inner_p): Ditto.
* config/i386/i386.h (PTION_ISA_HLE): Ditto.
(IX86_HLE_ACQUIRE): Ditto.
(IX86_HLE_RELEASE): Ditto.
* config/i386/i386.opt (mhle): Ditto.
* config/i386/sync.md(atomic_compare_and_swap): Pass
success model to instruction emitter.
(atomic_compare_and_swap_single): Define and use argument
for success model.
(atomic_compare_and_swap_double): Ditto.

testsuite/ChangeLog entry:
2012-04-11  Kirill Yukhin  

* gcc.target/i386/hle-cmpxchg-acq-1.c: New.
* gcc.target/i386/hle-cmpxchg-rel-1.c: Ditto.

Tests passing, bootstrap in progress.

Comments?
If it is ok, I'll proceed with implementation of rest builtins in the same way

Thanks, K


hle-rfc-3.gcc.patch
Description: Binary data

Re: [Doc] Move paragraph about multiple attributes

[Tristan Gingold]

On Apr 11, 2012, at 12:03 PM, Richard Guenther wrote:

> On Wed, Apr 11, 2012 at 11:33 AM, Tristan Gingold  wrote:
>> Hi,
>> 
>> this paragraph is inside the 'i386 type attributes' section, while it isn't 
>> target specific.
>> 
>> This patch moves it at the end of the attribute list.  Maybe we should 
>> remove it completely
>> as there is an 'attribute syntax' section.
> 
> I think it's good to have it repeated here.
> 
>> Ok for trunk ?
> 
> Ok.

Thanks, committed.

Tristan.

> 
> Thanks,
> Richard.
> 
>> Tristan.
>> 
>> 2012-04-11  Tristan Gingold  
>> 
>>* doc/extend.texi (Type Attributes): Move paragraph.
>> 
>> index bb43825..c33ec66 100644
>> --- a/gcc/doc/extend.texi
>> +++ b/gcc/doc/extend.texi
>> @@ -5372,6 +5372,10 @@ typeinfo node and exception handling will break.
>> 
>>  @end table
>> 
>> +To specify multiple attributes, separate them by commas within the
>> +double parentheses: for example, @samp{__attribute__ ((aligned (16),
>> +packed))}.
>> +
>>  @subsection ARM Type Attributes
>> 
>>  On those ARM targets that support @code{dllimport} (such as Symbian
>> @@ -5427,10 +5431,6 @@ Currently @option{-m[no-]ms-bitfields} is provided 
>> for the Microsoft Windows X86
>>  compilers to match the native Microsoft compiler.
>>  @end table
>> 
>> -To specify multiple attributes, separate them by commas within the
>> -double parentheses: for example, @samp{__attribute__ ((aligned (16),
>> -packed))}.
>> -
>>  @anchor{PowerPC Type Attributes}
>>  @subsection PowerPC Type Attributes
>> 
>> 

Re: [i386, patch, RFC] HLE support in GCC

[Jakub Jelinek]

Hi!

On Wed, Apr 11, 2012 at 02:35:38PM +0400, Kirill Yukhin wrote:

What is TARGET_HLE good for?  I thought the point of HLE prefixes
is that they are silently ignored on older CPUs.  So, HLE should be
always enabled IMHO.  If you don't use __ATOMIC_HLE_* bits in __atomic_*
in your source, it won't be emitted, if you use them, you are supposedly
intending to compile code that will use normal locking on older CPUs
and HLE TM on new CPUs.

+  if (isa_flag & OPTION_MASK_ISA_HLE) {
+char buf[64];
+
+sprintf (buf, "__ATOMIC_HLE_ACQUIRE=%d", IX86_HLE_ACQUIRE);
+def_or_undef (parse_in, buf);
+
+sprintf (buf, "__ATOMIC_HLE_RELEASE=%d", IX86_HLE_RELEASE);
+def_or_undef (parse_in, buf);

So IMHO the above two macros should be defined always.

+def_or_undef (parse_in, "__HLE__");

And I don't see a point for this macro (nor the -m*=native stuff in the
patch).

@@ -2344,6 +2345,12 @@ extern void debug_dispatch_window (int);
 #define TARGET_RECIP_VEC_DIV   ((recip_mask & RECIP_MASK_VEC_DIV) != 0)
 #define TARGET_RECIP_VEC_SQRT  ((recip_mask & RECIP_MASK_VEC_SQRT) != 0)
 
+#define IX86_HLE_ACQUIRE (1 << (sizeof(MEMMODEL_LAST) * 8 -\
+   __builtin_clz (MEMMODEL_LAST)))
+
+#define IX86_HLE_RELEASE (1 << (sizeof(MEMMODEL_LAST) * 8 - \
+   __builtin_clz (MEMMODEL_LAST) - 1))

I don't think you can use __builtin_clz in GCC source, at least
not conditionally on the host compiler.  If you use
clz_hwi instead, it will DTRT even for compilers that don't support
__builtin_clz.

--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/hle-cmpxchg-rel-1.c
@@ -0,0 +1,9 @@
+/* { dg-do compile } */
+/* { dg-options "-mhle -dp" } */
+/* { dg-final { scan-assembler "lock release cmpxchg" } } */

Isn't the prefix called xrelease?  At least in my binutils version
it is...  And, why the -dp switch?

+
+int
+hle_cmpxchg (int *p, int oldv, int newv)
+{
+  return __atomic_compare_exchange_n (p, &oldv, newv, 0, __ATOMIC_RELEASE | 
__ATOMIC_HLE_RELEASE, __ATOMIC_ACQUIRE);
+}

Jakub

Re: [PATCH] ARM: Use different linker path for hardfloat ABI

[Richard Earnshaw]

On 05/04/12 14:34, Dennis Gilmore wrote:
> Fedora at least plans to not support installing hfp and sfp on the same
> system, while not completely decided I don't think we will be
> supporting running 32 bit arm binaries on 64 bit arm.  there is not
>  a legacy support use case that I can think of i.e. existing common
>  proprietary software. Though I imagine that we will use /lib64 for
>  consistency with existing 64 bit arches.

Regardless of what Fedora wants to support in its own environments, it's
important that what they do doesn't prevent other distros from
supporting multiple flavours if they so wish.  That means that there
must be at least common agreement on the fundamental naming of the
dynamic loader (assuming that the libraries themselves can be found via
some config magic).

R.

[v3] libstdc++/52931

[Paolo Carlini]

Hi,

tested x86_64-linux, committed to mainline.

Thanks,
Paolo.

/
2012-04-11  Paolo Carlini  

PR libstdc++/52931
* include/bits/functional_hash.h (struct hash): Remove definition.
* testsuite/20_util/hash/52931.cc: New.
Index: include/bits/functional_hash.h
===
--- include/bits/functional_hash.h  (revision 186297)
+++ include/bits/functional_hash.h  (working copy)
@@ -1,6 +1,7 @@
 // functional_hash.h header -*- C++ -*-
 
-// Copyright (C) 2007, 2008, 2009, 2010, 2011 Free Software Foundation, Inc.
+// Copyright (C) 2007, 2008, 2009, 2010, 2011, 2012
+// Free Software Foundation, Inc.
 //
 // This file is part of the GNU ISO C++ Library.  This library is free
 // software; you can redistribute it and/or modify it under the
@@ -55,12 +56,7 @@
 
   /// Primary class template hash.
   template
-struct hash : public __hash_base
-{
-  static_assert(sizeof(_Tp) < 0,
-   "std::hash is not specialized for this type");
-  size_t operator()(const _Tp&) const noexcept;
-};
+struct hash;
 
   /// Partial specializations for pointer types.
   template
Index: testsuite/20_util/hash/52931.cc
===
--- testsuite/20_util/hash/52931.cc (revision 0)
+++ testsuite/20_util/hash/52931.cc (revision 0)
@@ -0,0 +1,32 @@
+// { dg-options "-std=gnu++11" }
+// { dg-do compile }
+
+// Copyright (C) 2012 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library.  This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+//
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+// GNU General Public License for more details.
+//
+// You should have received a copy of the GNU General Public License
+// along with this library; see the file COPYING3.  If not see
+// .
+
+#include 
+#include 
+
+class S{}; // No hash specialization
+
+template
+auto f(int) -> decltype(std::hash(), std::true_type());
+
+template
+auto f(...) -> decltype(std::false_type());
+
+static_assert(!decltype(f(0))::value, "");

Re: [i386, patch, RFC] HLE support in GCC

[Uros Bizjak]

On Wed, Apr 11, 2012 at 12:51 PM, Jakub Jelinek  wrote:

> What is TARGET_HLE good for?  I thought the point of HLE prefixes
> is that they are silently ignored on older CPUs.  So, HLE should be
> always enabled IMHO.  If you don't use __ATOMIC_HLE_* bits in __atomic_*
> in your source, it won't be emitted, if you use them, you are supposedly
> intending to compile code that will use normal locking on older CPUs
> and HLE TM on new CPUs.

I think that we should keep -mhle, since it controls if we want HLE
prefixes or not, saving a byte per lock prefix if we know that binary
won't run on HLE enabled processor.

You will also need to check assembler support for new prefixes and
emit ASM_BYTE "0xXX" if not supported. Please see how
HAVE_AS_IX86_SAHF is handled.

+{
+  static char buf[128], hle[16]="";
+  if (INTVAL (operands[4]) & IX86_HLE_ACQUIRE)
+snprintf (hle, sizeof (hle), "xacquire ");
+  else if (INTVAL (operands[4]) & IX86_HLE_RELEASE)
+snprintf (hle, sizeof (hle), "release ");
+

Ouch...

const char *hle;

if (INTVAL (...)
  hle = "xacquire ";
else if (INTVAL (...)
  hle = "xrelease ";
else
  hle = "";

I assume that all this will be moved to a helper function that will
also handle HAVE_AS_IX86_HLE.

Uros.

[SH] Merge SCHED_REORDER macro into ready_reorder function

[Oleg Endo]

Hi,

The attached patch merges the SCHED_REORDER macro into the ready_reorder
function, since the macro is used only in that function.
Tested with 'make all-gcc'
OK?

Cheers,
Oleg


ChangeLog:

* config/sh/sh.c (SCHED_REORDER): Merge macro into ...
(ready_reorder): ... this function.


Index: gcc/config/sh/sh.c
===
--- gcc/config/sh/sh.c	(revision 186311)
+++ gcc/config/sh/sh.c	(working copy)
@@ -10559,22 +10559,14 @@
   a[i + 1] = insn;
 }
 
-#define SCHED_REORDER(READY, N_READY)	\
-  do	\
-{	\
-  if ((N_READY) == 2)		\
-	swap_reorder (READY, N_READY);	\
-  else if ((N_READY) > 2)		\
-	qsort (READY, N_READY, sizeof (rtx), rank_for_reorder);		\
-}	\
-  while (0)
-
-/* Sort the ready list READY by ascending priority, using the SCHED_REORDER
-   macro.  */
+/* Sort the ready list by ascending priority.  */
 static void
 ready_reorder (rtx *ready, int nready)
 {
-  SCHED_REORDER (ready, nready);
+  if (nready == 2)
+swap_reorder (ready, nready);
+  else if (nready > 2)
+ qsort (ready, nready, sizeof (rtx), rank_for_reorder);
 }
 
 /* Count life regions of r0 for a block.  */

Re: [PATCH, rs6000] Fix PR16458, eliminate redudant compares

[Peter Bergner]

On Wed, 2012-04-11 at 10:43 +0200, Richard Guenther wrote:
> On Tue, Apr 10, 2012 at 8:50 PM, David Edelsohn  wrote:
> > On Tue, Apr 10, 2012 at 1:36 PM, Peter Bergner  wrote:
> >
> >> 2012-mm-dd  Peter Bergner  
> >>Michael Matz  
> >>
> >> gcc/
> >>PR target/16458
> >>* rtlanal.c (unsigned_reg_p): New function.
> >>* rtl.h (unsigned_reg_p): Prototype it.
> >>* config/rs6000/rs6000.c (rs6000_generate_compare): Use it.
> >>Update comment.
> >>* expr.c (expand_expr_real_1): Set register attributes.
> >>* stmt.c (expand_case): Likewise.
> >>
> >> gcc/testsuite/
> >>PR target/16458
> >>* gcc.target/powerpc/pr16458-1.c: New test.
> >>* gcc.target/powerpc/pr16458-2.c: Likewise.
> >>* gcc.target/powerpc/pr16458-3.c: Likewise.
> >>* gcc.target/powerpc/pr16458-4.c: Likewise.
> >
> > The rs6000 and testsuite parts of the patch are okay with me.
> 
> The rest is ok as well.

Thanks, I have committed this as revision 186312.

Peter

[SH] Remove old secondary reload code

[Oleg Endo]

Hi,

The attached patch removes the old if'ed out secondary reload code in
sh.h.
Tested with 'make all-gcc'
OK?

Cheers,
Oleg


ChangeLog:

* config/sh/sh.h: Remove old secondary reload code.
Index: gcc/config/sh/sh.h
===
--- gcc/config/sh/sh.h	(revision 186311)
+++ gcc/config/sh/sh.h	(working copy)
@@ -1216,80 +1216,6 @@
 #define ZERO_EXTRACT_ANDMASK(EXTRACT_SZ_RTX, EXTRACT_POS_RTX)\
   (((1 << INTVAL (EXTRACT_SZ_RTX)) - 1) << INTVAL (EXTRACT_POS_RTX))
 
-#if 0
-#define SECONDARY_INOUT_RELOAD_CLASS(CLASS,MODE,X,ELSE) \
-  REGCLASS_HAS_FP_REG (CLASS) 	\
-  && (REG_P (X)			\
-  && (GENERAL_OR_AP_REGISTER_P (REGNO (X))\
-	  || (FP_REGISTER_P (REGNO (X)) && (MODE) == SImode		\
-	  && TARGET_FMOVD	\
- || (REGCLASS_HAS_GENERAL_REG (CLASS) \
-	 && REG_P (X)			\
-	 && FP_REGISTER_P (REGNO (X	\
-&& ! TARGET_SHMEDIA			\
-&& ((MODE) == SFmode || (MODE) == SImode))\
-   ? FPUL_REGS\
-   : (((CLASS) == FPUL_REGS		\
-   || (REGCLASS_HAS_FP_REG (CLASS)	\
-	   && ! TARGET_SHMEDIA && MODE == SImode))			\
-  && (MEM_P (X)			\
-	  || (REG_P (X)			\
-	  && (REGNO (X) >= FIRST_PSEUDO_REGISTER			\
-		  || REGNO (X) == T_REG	\
-		  || system_reg_operand (X, VOIDmode)		\
-   ? GENERAL_REGS			\
-   : (((CLASS) == TARGET_REGS		\
-   || (TARGET_SHMEDIA && (CLASS) == SIBCALL_REGS))			\
-  && !satisfies_constraint_Csy (X)	\
-  && (!REG_P (X) || ! GENERAL_REGISTER_P (REGNO (X		\
-   ? GENERAL_REGS			\
-   : (((CLASS) == MAC_REGS || (CLASS) == PR_REGS)			\
-  && REG_P (X) && ! GENERAL_REGISTER_P (REGNO (X))			\
-  && (CLASS) != REGNO_REG_CLASS (REGNO (X)))			\
-   ? GENERAL_REGS			\
-   : ((CLASS) != GENERAL_REGS && REG_P (X)\
-  && TARGET_REGISTER_P (REGNO (X)))	\
-   ? GENERAL_REGS : (ELSE))
-
-#define SECONDARY_OUTPUT_RELOAD_CLASS(CLASS,MODE,X) \
- SECONDARY_INOUT_RELOAD_CLASS(CLASS,MODE,X,NO_REGS)
-
-#define SECONDARY_INPUT_RELOAD_CLASS(CLASS,MODE,X)  \
-  ((REGCLASS_HAS_FP_REG (CLASS) 	\
-&& ! TARGET_SHMEDIA			\
-&& immediate_operand ((X), (MODE))	\
-&& ! ((fp_zero_operand (X) || fp_one_operand (X))			\
-	  && (MODE) == SFmode && fldi_ok ()))\
-   ? R0_REGS\
-   : ((CLASS) == FPUL_REGS		\
-  && ((REG_P (X)			\
-	   && (REGNO (X) == MACL_REG || REGNO (X) == MACH_REG		\
-	   || REGNO (X) == T_REG))	\
-	  || GET_CODE (X) == PLUS))	\
-   ? GENERAL_REGS			\
-   : (CLASS) == FPUL_REGS && immediate_operand ((X), (MODE))		\
-   ? (satisfies_constraint_I08 (X)	\
-  ? GENERAL_REGS			\
-  : R0_REGS)			\
-   : ((CLASS) == FPSCR_REGS		\
-  && ((REG_P (X) && REGNO (X) >= FIRST_PSEUDO_REGISTER)		\
-	  || (MEM_P (X) && GET_CODE (XEXP ((X), 0)) == PLUS)))		\
-   ? GENERAL_REGS			\
-   : (REGCLASS_HAS_FP_REG (CLASS) 	\
-  && TARGET_SHMEDIA			\
-  && immediate_operand ((X), (MODE))\
-  && (X) != CONST0_RTX (GET_MODE (X))\
-  && GET_MODE (X) != V4SFmode)	\
-   ? GENERAL_REGS			\
-   : (((MODE) == QImode || (MODE) == HImode)\
-  && TARGET_SHMEDIA && inqhi_operand ((X), (MODE)))			\
-   ? GENERAL_REGS			\
-   : (TARGET_SHMEDIA && (CLASS) == GENERAL_REGS\
-  && (GET_CODE (X) == LABEL_REF || PIC_ADDR_P (X)))			\
-   ? TARGET_REGS			\
-   : SECONDARY_INOUT_RELOAD_CLASS((CLASS),(MODE),(X), NO_REGS))
-#endif
-
 /* Return the maximum number of consecutive registers
needed to represent mode MODE in a register of class CLASS.
 

Re: Guard use of modulo in cshift (speedup protein)

[Michael Matz]

Hi,

On Wed, 11 Apr 2012, Richard Guenther wrote:

> > But it would possibly be an interesting experiment already to do such 
> > transformation generally (without profiling) and see what it gives on 
> > some benchmarks.  Just to get a feel what's on the plate.
> 
> The question is, of course, why on earth is a modulo operation in the 
> loop setup so expensive that avoiding it improves the performance of the 
> overall routine so much ...

Because in most cases in protein the loop actually runs only one or two 
times or not at all, hence loop setup is more expensive than the loop 
itself.

> did you expect the code-gen difference of your patch?

Which code-gen difference?  I expected that in the protein case the 
division isn't executed, if that was what your question was about.  If it 
wasn't, please reformulate :)


Ciao,
Michael.

Re: [PATCH] ARM: Use different linker path for hardfloat ABI

[Jeff Law]

On 04/10/2012 09:37 AM, Steve McIntyre wrote:


Aargh. Again, use of a standard triplet for arm hard-float was agreed
by all parties at the Plumbers' meeting last September. For exactly
this reason. Now it seems that a number of people have totally ignored
that consensus for the last six months.
More correctly, I don't think the ARM community disseminated the 
substance of that agreement to the GCC and other communities.


I think standardizing the triplet is a no-brainer and independent of 
whether or not the triplet shows up in the path/name of the dynamic 
linker.  Furthermore, the ARM GCC maintainers have the ability to 
standardize the triplet without a long debate on the subject.


Jeff

[PATCH] Fix PR52918

[Richard Guenther]

This fixes the corresponding SJLJ part of preserving loops over
EH lowering.  The unfortunate thing is, of course, that factoring
the SJLJ breaks the loop structure quite badly because we create
mutliple entry loops all over the place.

Well.  That's a pre-existing missed optimization.

Kai bootstrapped and tested this on mingw, I'm including it in a
x86_64 bootstrap & regtest cycle.

Richard.

2012-04-11  Richard Guenther  

PR middle-end/52918
* except.c (sjlj_emit_dispatch_table): Properly update loop
structure.

* g++.dg/torture/pr52918-1.C: New testcase.
* g++.dg/torture/pr52918-2.C: Likewise.

Index: gcc/except.c
===
--- gcc/except.c(revision 186302)
+++ gcc/except.c(working copy)
@@ -1344,6 +1344,28 @@ sjlj_emit_dispatch_table (rtx dispatch_l
e = make_edge (bb, bb->next_bb, EDGE_FALLTHRU);
e->count = bb->count;
e->probability = REG_BR_PROB_BASE;
+   if (current_loops)
+ {
+   struct loop *loop = bb->next_bb->loop_father;
+   /* If we created a pre-header block, add the new block to the
+  outer loop, otherwise to the loop itself.  */
+   if (bb->next_bb == loop->header)
+ add_bb_to_loop (bb, loop_outer (loop));
+   else
+ add_bb_to_loop (bb, loop);
+   /* ???  For multiple dispatches we will end up with edges
+  from the loop tree root into this loop, making it a
+  multiple-entry loop.  Discard all affected loops.  */
+   if (num_dispatch > 1)
+ {
+   for (loop = bb->loop_father;
+loop_outer (loop); loop = loop_outer (loop))
+ {
+   loop->header = NULL;
+   loop->latch = NULL;
+ }
+ }
+ }
 
disp_index++;
   }
@@ -1364,6 +1386,24 @@ sjlj_emit_dispatch_table (rtx dispatch_l
   e = make_edge (bb, bb->next_bb, EDGE_FALLTHRU);
   e->count = bb->count;
   e->probability = REG_BR_PROB_BASE;
+  if (current_loops)
+   {
+ struct loop *loop = bb->next_bb->loop_father;
+ /* If we created a pre-header block, add the new block to the
+outer loop, otherwise to the loop itself.  */
+ if (bb->next_bb == loop->header)
+   add_bb_to_loop (bb, loop_outer (loop));
+ else
+   add_bb_to_loop (bb, loop);
+   }
+}
+  else
+{
+  /* We are not wiring up edges here, but as the dispatcher call
+ is at function begin simply associate the block with the
+outermost (non-)loop.  */
+  if (current_loops)
+   add_bb_to_loop (bb, current_loops->tree_root);
 }
 }
 
Index: gcc/testsuite/g++.dg/torture/pr52918-1.C
===
--- gcc/testsuite/g++.dg/torture/pr52918-1.C(revision 0)
+++ gcc/testsuite/g++.dg/torture/pr52918-1.C(revision 0)
@@ -0,0 +1,39 @@
+// { dg-do compile }
+
+typedef __SIZE_TYPE__ size_t;
+class bad_alloc   { };
+typedef struct {
+} __gthread_mutex_t;
+int __gthread_mutex_unlock (__gthread_mutex_t *__mutex);
+class __concurrence_unlock_error   {
+};
+inline void   __throw_concurrence_unlock_error()   {
+throw __concurrence_unlock_error();
+}
+class __mutex   {
+__gthread_mutex_t _M_mutex;
+public:
+void unlock() {
+   if (__gthread_mutex_unlock(&_M_mutex) != 0)
+ __throw_concurrence_unlock_error();  
+}
+};
+class free_list   {
+typedef __mutex __mutex_type;
+__mutex_type& _M_get_mutex();
+void _M_get(size_t __sz) throw(bad_alloc);
+};
+void  free_list::_M_get(size_t __sz) throw(bad_alloc)
+{
+  __mutex_type& __bfl_mutex = _M_get_mutex();
+  __bfl_mutex.unlock();
+  int __ctr = 2;
+  while (__ctr)  {
+  size_t* __ret = 0;
+  --__ctr;
+  try {
+ __ret = (size_t*) (::operator new(__sz + sizeof(size_t)));   
+  }
+  catch(const bad_alloc&) { }
+  }
+}
Index: gcc/testsuite/g++.dg/torture/pr52918-2.C
===
--- gcc/testsuite/g++.dg/torture/pr52918-2.C(revision 0)
+++ gcc/testsuite/g++.dg/torture/pr52918-2.C(revision 0)
@@ -0,0 +1,40 @@
+// { dg-do compile }
+
+typedef __SIZE_TYPE__ size_t;
+void*   __cxa_allocate_exception(size_t) throw();
+typedef struct { } __gthread_mutex_t;
+extern int __gthr_win32_mutex_unlock (__gthread_mutex_t *);
+int __gthread_mutex_lock (__gthread_mutex_t *__mutex);
+int __gthread_mutex_unlock (__gthread_mutex_t *__mutex);
+void   __throw_concurrence_lock_error();
+void   __throw_concurrence_unlock_error();
+class __mutex   {
+__gthread_mutex_t _M_mutex;
+public:
+void lock() {
+   if (__gthread_mutex_lock(&_M_mutex) != 0)
+ __throw_concurrence_lock_error();
+}
+void unlock() {
+   if (__gthread_mutex_unlock(&_M_mutex) != 0

[PATCH] Fix chrec predicates, PR52621

[Richard Guenther]

For PR52621 we analyze a loop nest (for prefetching) and
end up with {(integer(kind=8)) {0, +, {2, +, 2}_2}_2, +, 1}_3
which we pass to various predicates in analyze_overlapping_iterations
(the loop nest has loop->num == 1, 2 and 3 are nested in it).

First, evolution_function_is_univariate_p returns true for it
because of bogus default cases (the outermost default case looks
wrong, too, but fixing it is not required to fix this bug).

Second, evolution_function_is_affine_multivariate_p returns true
for it - something that is not true either - it's not affine after
all.  And the culprit here is evolution_function_is_invariant_rec_p
which does not consider varying in nested loops properly.

Bootstrap and regtest pending on x86_64-unknown-linux-gnu.

I'm not terribly familiar with the SCEV notation nor its code
and unfortunately Sebastian is not responding :/  So I'm going
to take the bootstrap & regtest result as hint on whether I am right.

Richard.

2012-04-11  Richard Guenther  

PR middle-end/52621
* tree-chrec.c (evolution_function_is_invariant_rec_p): Properly
consider loop nesting.
(evolution_function_is_univariate_p): Properly check the remainder
for chrecs.

* gfortran.dg/pr52621.f90: New testcase.

Index: gcc/tree-chrec.c
===
*** gcc/tree-chrec.c(revision 186302)
--- gcc/tree-chrec.c(working copy)
*** evolution_function_is_invariant_rec_p (t
*** 1011,1016 
--- 1029,1036 
if (TREE_CODE (chrec) == POLYNOMIAL_CHREC)
  {
if (CHREC_VARIABLE (chrec) == (unsigned) loopnum
+ || flow_loop_nested_p (get_loop (loopnum),
+get_loop (CHREC_VARIABLE (chrec)))
  || !evolution_function_is_invariant_rec_p (CHREC_RIGHT (chrec),
 loopnum)
  || !evolution_function_is_invariant_rec_p (CHREC_LEFT (chrec),
*** evolution_function_is_univariate_p (cons
*** 1114,1119 
--- 1134,1141 
  break;
  
default:
+ if (tree_contains_chrecs (CHREC_LEFT (chrec), NULL))
+   return false;
  break;
}
  
*** evolution_function_is_univariate_p (cons
*** 1127,1132 
--- 1149,1156 
  break;
  
default:
+ if (tree_contains_chrecs (CHREC_RIGHT (chrec), NULL))
+   return false;
  break;
}
  
Index: gcc/testsuite/gfortran.dg/pr52621.f90
===
*** gcc/testsuite/gfortran.dg/pr52621.f90   (revision 0)
--- gcc/testsuite/gfortran.dg/pr52621.f90   (revision 0)
***
*** 0 
--- 1,20 
+ ! { dg-do compile }
+ ! { dg-options "-O2 -fprefetch-loop-arrays" }
+ 
+   SUBROUTINE GHDSYM(IZ,IS,LMMAX,S,LMS,Y,L2M,DRL,NLAY2,K0,DCUT)!,
+ !
+   COMPLEX Y(L2M,L2M),H(33),S(LMS)
+   COMPLEX RU,CI,CZ,K0,FF,Z,Z1,Z2,Z3,ST
+ !
+   DO 140 KK=1,4
+ DO 130 L=1,L2M
+L1=L*L-L
+DO 120 M=1,L
+   IPM=L1+M
+   IMM=L1-M+2
+   S(IPM)=S(IPM)+Z3*Y(L,M)
+   IF (M.NE.1) S(IMM)=S(IMM)+Z3*Y(M-1,L)*CSGN
+ 120CONTINUE
+ 130 CONTINUE
+ 140   CONTINUE
+   END

Re: jcf-reader: support for JSR 292 classfile extensions

[Richard Guenther]

On Wed, Apr 11, 2012 at 12:22 PM, Andrew Haley  wrote:
> This adds support for the new (Version 51.0) class file format.  It
> doesn't actually generate code for invokedynamic bcause we don't have
> any runtime support yet, but it's a start.  jcf-dump prints all of the
> new attributes.

This breaks bootstrap for me:

In file included from
/space/rguenther/src/svn/trunk/gcc/java/jcf-parse.c:1009:0:
/space/rguenther/src/svn/trunk/gcc/java/jcf-reader.c:550:1: error:
'int jcf_parse_bootstrap_methods(JCF*, int)' defined but not used
[-Werror=unused-function]
 jcf_parse_bootstrap_methods (JCF* jcf, int attribute_length ATTRIBUTE_UNUSED)
 ^
cc1plus: all warnings being treated as errors
make[3]: *** [java/jcf-parse.o] Error 1
make[3]: *** Waiting for unfinished jobs


> Andrew.
>
>
> 2012-04-11  Andrew Haley  
>
>        * jcf.h (bootstrap_method): New.
>        (BootstrapMethods): New.
>        (JCF): Add BootstrapMethods.
>        (enum cpool_tag): Add MethodHandle, MethodType, and InvokeDynamic.
>        * jcf-reader.c (jcf_parse_bootstrap_methods): New.
>        (jcf_parse_constant_pool): Handlers for MethodHandle, MethodType,
>        and InvokeDynamic.
>        (jcf_parse_bootstrap_methods): New.
>        * javaop.def (invokedynamic): New opcode.
>        * jcf-parse.c (get_constant): An unknown constant type should not
>        be an internal error, but a fatal one.  Make it so.
>        * jcf-dump.c (HANDLE_BOOTSTRAP_METHODS_ATTRIBUTE): New.
>        (HANDLE_END_BOOTSTRAP_METHODS): New.
>        (print_constant): Handlers for MethodHandle, MethodType, and
>        InvokeDynamic.
>
> Index: java/jcf-dump.c
> ===
> --- java/jcf-dump.c     (revision 186103)
> +++ java/jcf-dump.c     (working copy)
> @@ -430,7 +430,24 @@
>   print_element_value (out, jcf, 1);                                   \
>  }
>
> +#define HANDLE_BOOTSTRAP_METHODS_ATTRIBUTE()                           \
> +{                                                                      \
> +  COMMON_HANDLE_ATTRIBUTE(jcf, attribute_name, attribute_length);      \
> +  fputc ('\n', out); jcf_parse_bootstrap_methods (jcf, attribute_length); \
> +}
>
> +#define HANDLE_END_BOOTSTRAP_METHODS(NUM_METHODS)                      \
> +  {                                                                    \
> +    int i;                                                             \
> +    for (i = 0; i < NUM_METHODS; i++)                                  \
> +      {                                                                      
>   \
> +       bootstrap_method *m = &jcf->bootstrap_methods.methods[i];       \
> +       fprintf (out, "  %d: ", i);                                     \
> +       print_constant (out, jcf, m->method_ref, 1);                    \
> +       fprintf (out, "\n");                                            \
> +      }                                                                      
>   \
> +  }
> +
>  #define PROCESS_OTHER_ATTRIBUTE(JCF, INDEX, LENGTH) \
>  { COMMON_HANDLE_ATTRIBUTE(JCF, INDEX, LENGTH); \
>   fputc ('\n', out); JCF_SKIP (JCF, LENGTH); }
> @@ -898,6 +915,53 @@
>        fputc ('\"', out);
>       }
>       break;
> +    case CONSTANT_MethodHandle:
> +      {
> +       int kind = JPOOL_USHORT1 (jcf, index);
> +       if (verbosity > 0)
> +         fprintf (out, "MethodHandle kind: %d=", kind);
> +       switch(kind) {
> +       case 1:
> +       case 2:
> +       case 3:
> +       case 4:
> +         if (verbosity > 0)
> +           fprintf (out, "Fieldref: %ld=", JPOOL_USHORT2 (jcf, index));
> +         print_constant (out, jcf, JPOOL_USHORT2 (jcf, index), 0);
> +       case 5:
> +       case 6:
> +       case 7:
> +       case 8:
> +         if (verbosity > 0)
> +           fprintf (out, "Methodref: %ld=", JPOOL_USHORT2 (jcf, index));
> +         print_constant (out, jcf, JPOOL_USHORT2 (jcf, index), 0);
> +         break;
> +       case 9:
> +         if (verbosity > 0)
> +           fprintf (out, "InterfaceMethodref: %ld=", JPOOL_USHORT2 (jcf, 
> index));
> +         print_constant (out, jcf, JPOOL_USHORT2 (jcf, index), 0);
> +         break;
> +       }
> +       break;
> +      }
> +    case CONSTANT_MethodType:
> +      if (verbosity > 0)
> +       fprintf (out, "MethodType %ld: ", JPOOL_USHORT1 (jcf, index));
> +      print_signature (out, jcf, JPOOL_USHORT1 (jcf, index), 0);
> +      break;
> +    case CONSTANT_InvokeDynamic:
> +      {
> +       uint16 name_and_type = JPOOL_USHORT2 (jcf, index);
> +       if (verbosity > 0)
> +         fprintf (out, "InvokeDynamic: ");
> +       fprintf (out, "bootstrap_method: %ld ", JPOOL_USHORT1 (jcf, index));
> +       if (verbosity == 2)
> +         fprintf (out, " name_and_type: %d=<", name_and_type);
> +       print_constant_terse (out, jcf, name_and_type, CONSTANT_NameAndType);
> +       if (verbosity == 2)
> +         fputc ('>', out);
> +       break;
> +      }
>     default:
>       fpr

[Patch, Fortran] PR52916 - fix TREE_PUBLIC() = 0 for module procedures

[Tobias Burnus]

Dear all,

my recent patch for setting PRIVATE module variables and procedures to 
TREE_PUBLIC()=0 had a flaw: I completely forgot about generic 
interfaces. Even if the specific name is PRIVATE, the specific function 
is still callable through the a (public) generic name.


Thanks to HJ for the report. (The bug causes a failures of SPEC CPU 2006.)

I think the handling of type-bound procedures is correct. However, I 
wouldn't mind if someone could confirm it. I only check for the specific 
entries as GENERIC, OPERATOR and ASSIGNMENT use a type-bound-proc name, 
which is already handled. I also didn't try to optimize for private DT, 
private generics etc. First, I think it is not needed. And secondly, 
through inheritance, it can get extremely complicated.


Build and regtested on x86-64-linux.
OK for the trunk?

Tobias
2012-04-11  Tobias Burnus  

	PR fortran/52916
	PR fortran/40973
	* gfortran.h (symbol_attribute): Add public_used.
	* interface.c (check_sym_interfaces, check_uop_interfaces,
	gfc_check_interfaces): Set it.
	* resolve.c (resolve_typebound_procedure): Ditto.
	* trans-decl.c (build_function_decl): Use it.

2012-04-11  Tobias Burnus  

	PR fortran/52916
	PR fortran/40973
	* gfortran.dg/public_private_module_3.f90: New.
	* gfortran.dg/public_private_module_4.f90: New.

diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h
index 8e83cb4..5480663 100644
--- a/gcc/fortran/gfortran.h
+++ b/gcc/fortran/gfortran.h
@@ -726,6 +728,10 @@ typedef struct
   unsigned sequence:1, elemental:1, pure:1, recursive:1;
   unsigned unmaskable:1, masked:1, contained:1, mod_proc:1, abstract:1;
 
+  /* Set if a (public) symbol [e.g. generic name] exposes this symbol,
+ which is relevant for private module procedures.  */
+  unsigned public_used:1;
+
   /* This is set if a contained procedure could be declared pure.  This is
  used for certain optimizations that require the result or arguments
  cannot alias.  Note that this is zero for PURE procedures.  */
diff --git a/gcc/fortran/interface.c b/gcc/fortran/interface.c
index 298ae23..c04a4d0 100644
--- a/gcc/fortran/interface.c
+++ b/gcc/fortran/interface.c
@@ -1390,6 +1392,9 @@ check_sym_interfaces (gfc_symbol *sym)
 
   for (p = sym->generic; p; p = p->next)
 	{
+	  if (sym->attr.access != ACCESS_PRIVATE)
+	p->sym->attr.public_used = 1;
+
 	  if (p->sym->attr.mod_proc
 	  && (p->sym->attr.if_source != IFSRC_DECL
 		  || p->sym->attr.procedure))
@@ -1415,11 +1420,16 @@ check_uop_interfaces (gfc_user_op *uop)
   char interface_name[100];
   gfc_user_op *uop2;
   gfc_namespace *ns;
+  gfc_interface *p;
 
   sprintf (interface_name, "operator interface '%s'", uop->name);
   if (check_interface0 (uop->op, interface_name))
 return;
 
+  if (uop->access != ACCESS_PRIVATE)
+for (p = uop->op; p; p = p->next)
+  p->sym->attr.public_used = 1;
+
   for (ns = gfc_current_ns; ns; ns = ns->parent)
 {
   uop2 = gfc_find_uop (uop->name, ns);
@@ -1489,6 +1499,7 @@ void
 gfc_check_interfaces (gfc_namespace *ns)
 {
   gfc_namespace *old_ns, *ns2;
+  gfc_interface *p;
   char interface_name[100];
   int i;
 
@@ -1513,6 +1524,10 @@ gfc_check_interfaces (gfc_namespace *ns)
   if (check_interface0 (ns->op[i], interface_name))
 	continue;
 
+  for (p = ns->op[i]; p; p = p->next)
+	p->sym->attr.public_used = 1;
+
+
   if (ns->op[i])
 	gfc_check_operator_interface (ns->op[i]->sym, (gfc_intrinsic_op) i,
   ns->op[i]->where);
diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
index b63a0c6..bd94605 100644
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -11304,6 +11335,7 @@ resolve_typebound_procedure (gfc_symtree* stree)
   gcc_assert (stree->n.tb->u.specific);
   proc = stree->n.tb->u.specific->n.sym;
   where = stree->n.tb->where;
+  proc->attr.public_used = 1;
 
   /* Default access should already be resolved from the parser.  */
   gcc_assert (stree->n.tb->access != ACCESS_UNKNOWN);
diff --git a/gcc/fortran/trans-decl.c b/gcc/fortran/trans-decl.c
index aec96aa..46378b6 100644
--- a/gcc/fortran/trans-decl.c
+++ b/gcc/fortran/trans-decl.c
@@ -1844,7 +1858,8 @@ build_function_decl (gfc_symbol * sym, bool global)
 
   if (!current_function_decl
   && !sym->attr.entry_master && !sym->attr.is_main_program
-  && (sym->attr.access != ACCESS_PRIVATE || sym->binding_label))
+  && (sym->attr.access != ACCESS_PRIVATE || sym->binding_label
+	  || sym->attr.public_used))
 TREE_PUBLIC (fndecl) = 1;
 
   attributes = add_attributes_to_decl (attr, NULL_TREE);
--- /dev/null	2012-04-10 19:58:22.131728097 +0200
+++ gcc/gcc/testsuite/gfortran.dg/public_private_module_3.f90	2012-04-11 14:15:53.0 +0200
@@ -0,0 +1,60 @@
+! { dg-do compile }
+!
+! To be used by public_private_module_4.f90
+!
+! PR fortran/52916
+! Cf. PR fortran/40973
+!
+! Ensure that PRIVATE specific functions do not get
+! marked as TREE_PUBLIC() = 0, if the generic name is
+! PUBLIC.
+!
+module m
+  interface gen
+module proce

Re: [i386, patch, RFC] HLE support in GCC

[Andi Kleen]

> Tests passing, bootstrap in progress.
> 
> Comments?

Do you really imply ACQUIRE/RELEASE with HLE_ACQUIRE/RELEASE now? I don't
see that in the code. I think that's really required, otherwise the optimizer
will do the wrong thing and move memory references outside the region.

I second Jakub in disliking -mhle.

release is spelled xrelease.

-Andi

Re: [SH] PR 50751 - add HImode displacement addressing support

[Kaz Kojima]

Oleg Endo  wrote:
>> BTW, do you have the numbers of CSiBE with this?
>> 
> 
> Only for "-m4-single -ml -O2 -mpretend-cmove" so far.
> Not so spectacular :T
> I'll also do a comparison of more variants to see if something went
> really bad.  It's a bit difficult to isolate the degradations because
> there's quite some code reordering happening after the patch... 

Thanks for numbers!  Looks good considering that HImode would be
less frequently used than QImode in the usual working set.

Regards,
kaz

Re: [SH] Remove old secondary reload code

[Kaz Kojima]

Oleg Endo  wrote:
> The attached patch removes the old if'ed out secondary reload code in
> sh.h.
> Tested with 'make all-gcc'
> OK?

OK.

Regards,
kaz

Re: [SH] Merge SCHED_REORDER macro into ready_reorder function

[Kaz Kojima]

Oleg Endo  wrote:
> The attached patch merges the SCHED_REORDER macro into the ready_reorder
> function, since the macro is used only in that function.
> Tested with 'make all-gcc'
> OK?

OK.

Regards,
kaz

Re: [i386, patch, RFC] HLE support in GCC

[Jakub Jelinek]

On Wed, Apr 11, 2012 at 03:06:35PM +0200, Andi Kleen wrote:
> Do you really imply ACQUIRE/RELEASE with HLE_ACQUIRE/RELEASE now? I don't
> see that in the code. I think that's really required, otherwise the optimizer
> will do the wrong thing and move memory references outside the region.

IMHO the separate bits for HLE_ACQUIRE/RELEASE are desirable, you could very
well use __ATOMIC_ACQ_REL or __ATOMIC_SEQ_CST if you want stronger memory
barrier, still coupled with either __ATOMIC_HLE_ACQUIRE or
__ATOMIC_HLE_RELEASE...

Jakub

Re: jcf-reader: support for JSR 292 classfile extensions

[Andrew Haley]

On 04/11/2012 01:43 PM, Richard Guenther wrote:
> This breaks bootstrap for me:
>
> In file included from
> /space/rguenther/src/svn/trunk/gcc/java/jcf-parse.c:1009:0:
> /space/rguenther/src/svn/trunk/gcc/java/jcf-reader.c:550:1: error:
> 'int jcf_parse_bootstrap_methods(JCF*, int)' defined but not used
> [-Werror=unused-function]
>  jcf_parse_bootstrap_methods (JCF* jcf, int attribute_length ATTRIBUTE_UNUSED)
>  ^
> cc1plus: all warnings being treated as errors
> make[3]: *** [java/jcf-parse.o] Error 1
> make[3]: *** Waiting for unfinished jobs
>

Sorry.

Andrew.


2012-04-11  Andrew Haley  

* jcf-reader.c (jcf_parse_bootstrap_methods): Add
ATTRIBUTE_UNUSED.

Index: gcc/java/jcf-reader.c
===
--- gcc/java/jcf-reader.c   (revision 186307)
+++ gcc/java/jcf-reader.c   (working copy)
@@ -36,7 +36,7 @@
 static int jcf_parse_one_method (JCF *, int);
 static int jcf_parse_methods (JCF *);
 static int jcf_parse_final_attributes (JCF *);
-static int jcf_parse_bootstrap_methods (JCF *, int );
+static int jcf_parse_bootstrap_methods (JCF *, int) ATTRIBUTE_UNUSED;
 #ifdef NEED_PEEK_ATTRIBUTE
 static int peek_attribute (JCF *, int, const char *, int);
 #endif

Re: [i386, patch, RFC] HLE support in GCC

[Andi Kleen]

On Wed, Apr 11, 2012 at 03:12:44PM +0200, Jakub Jelinek wrote:
> On Wed, Apr 11, 2012 at 03:06:35PM +0200, Andi Kleen wrote:
> > Do you really imply ACQUIRE/RELEASE with HLE_ACQUIRE/RELEASE now? I don't
> > see that in the code. I think that's really required, otherwise the 
> > optimizer
> > will do the wrong thing and move memory references outside the region.
> 
> IMHO the separate bits for HLE_ACQUIRE/RELEASE are desirable, you could very
> well use __ATOMIC_ACQ_REL or __ATOMIC_SEQ_CST if you want stronger memory

That would still work, right? If you have multiple the stronger wins.

> barrier, still coupled with either __ATOMIC_HLE_ACQUIRE or
> __ATOMIC_HLE_RELEASE...

If the compiler barrier is not implied I can just see lots of buggy code that 
subtly breaks with higher optimizer levels, compiler updates etc. Of course 
it will be all gccs fault.

-Andi

-- 
a...@linux.intel.com -- Speaking for myself only.

Re: [patch optimization]: Add some basic folding for ==/!= comparison

[Kai Tietz]

Ping?

2012/4/5 Kai Tietz :
> Hello,
>
> this patch adds some basic folding capabilities to fold-const for
> equal and none-equal comparisons
> on integer typed argument.
>
> ChangeLog
>
> 2012-04-05  Kai Tietz  
>
>        * fold-const.c (fold_comparison_1): New
>        function.
>        (fold_comparison): Use fold_comparison_1.
>
> 2012-04-05  Kai Tietz  
>
>        * gcc.dg/fold-compare-1.c: Adjust matching rule
>        for a == b without argument swap.
>        * gcc.dg/fold-compare-7.c: New test.
>
> Regession tested for x86_64-unknown-linux-gnu for all languages
> (including Ada and Obj-C++).  Ok for apply?
>
> Regards,
> Kai
>
> Index: gcc/gcc/fold-const.c
> ===
> --- gcc.orig/gcc/fold-const.c
> +++ gcc/gcc/fold-const.c
> @@ -8739,6 +8739,241 @@ pointer_may_wrap_p (tree base, tree offs
>   return total_low > (unsigned HOST_WIDE_INT) size;
>  }
>
> +/* Sub-routine of fold_comparison.  Folding of EQ_EXPR/NE_EXPR
> +   comparisons with integral typed arguments.  */
> +
> +static tree
> +fold_comparison_1 (location_t loc, enum tree_code code, tree type,
> +                  tree arg0, tree arg1)
> +{
> +  enum tree_code c1, c2;
> +  tree optype, op0, op1, opr0, opr1, tem;
> +
> +  if (code != NE_EXPR && code != EQ_EXPR)
> +    return NULL_TREE;
> +
> +  optype = TREE_TYPE (arg0);
> +  if (!INTEGRAL_TYPE_P (optype))
> +    return NULL_TREE;
> +
> +  c1 = TREE_CODE (arg0);
> +  c2 = TREE_CODE (arg1);
> +
> +  /* Integer constant is on right-hand side.  */
> +  if (c1 == INTEGER_CST
> +      && c2 != c1)
> +    return fold_build2_loc (loc, code, type, arg1, arg0);
> +
> +  if (!TREE_SIDE_EFFECTS (arg0)
> +      && operand_equal_p (arg0, arg1, 0))
> +    {
> +      if (code == EQ_EXPR)
> +        return build_one_cst (type);
> +      return build_zero_cst (type);
> +    }
> +
> +
> +  if (c1 == NEGATE_EXPR)
> +    {
> +      op0 = TREE_OPERAND (arg0, 0);
> +      /* -X ==/!= -Y -> X ==/!= Y.  */
> +      if (c2 == c1)
> +        return fold_build2_loc (loc, code, type,
> +                               op0,
> +                               TREE_OPERAND (arg1, 0));
> +      /* -X ==/!= CST -> X ==/!= CST' with CST'= -CST.  */
> +      else if (c2 == INTEGER_CST)
> +        return fold_build2_loc (loc, code, type, op0,
> +                               fold_build1_loc (loc, NEGATE_EXPR,
> +                                                optype, arg1));
> +     }
> +  else if (c1 == BIT_NOT_EXPR)
> +    {
> +      op0 = TREE_OPERAND (arg0, 0);
> +      /* ~X ==/!= ~Y -> X ==/!= Y.  */
> +      if (c2 == c1)
> +        return fold_build2_loc (loc, code, type, op0,
> +                               TREE_OPERAND (arg1, 0));
> +      /* ~X ==/!= CST -> X ==/!= CST' with CST'= ~CST.  */
> +      else if (c2 == INTEGER_CST)
> +        return fold_build2_loc (loc, code, type, op0,
> +                               fold_build1_loc (loc, BIT_NOT_EXPR,
> +                                                optype, arg1));
> +    }
> +
> +  /* See if we can simplify case X == (Y +|-|^ Z).  */
> +  if (c1 != PLUS_EXPR && c1 != MINUS_EXPR && c1 != BIT_XOR_EXPR)
> +    {
> +      if ((c2 != PLUS_EXPR && c2 != MINUS_EXPR
> +           && c2 != BIT_XOR_EXPR)
> +          || TREE_SIDE_EFFECTS (arg0))
> +        return NULL_TREE;
> +
> +      op0 = TREE_OPERAND (arg1, 0);
> +      op1 = TREE_OPERAND (arg1, 1);
> +
> +      /* Convert temporary X - Y to X + (-Y).  */
> +      if (c2 == MINUS_EXPR)
> +        op1 = fold_build1_loc (loc, NEGATE_EXPR, optype, op1);
> +
> +      /* Check if we can simplify X ==/!= (X ^ Y) to Y ==/!= 0,
> +         or X ==/!= (X +|- Y) to Y ==/!= 0.  */
> +      tem = fold_build2_loc (loc, (c2 == BIT_XOR_EXPR ? c2 : MINUS_EXPR),
> +                            optype, arg0, op0);
> +      if (TREE_CODE (tem) == INTEGER_CST
> +         && (integer_zerop (tem) || TYPE_UNSIGNED (optype)
> +             || c2 == BIT_XOR_EXPR))
> +       return fold_build2_loc (loc, code, type, op1, tem);
> +
> +      /* Check if we can simplify X ==/!= (Y ^ X) to Y ==/!= 0,
> +         or X ==/!= (Y + X) to Y ==/!= 0.  */
> +      tem = fold_build2_loc (loc, (c2 == BIT_XOR_EXPR ? c2 : MINUS_EXPR),
> +                            optype, arg0, op1);
> +      if (TREE_CODE (tem) == INTEGER_CST
> +         && (integer_zerop (tem) || TYPE_UNSIGNED (optype)
> +             || c2 == BIT_XOR_EXPR))
> +       return fold_build2_loc (loc, code, type, op0, tem);
> +    }
> +  else if (c2 != PLUS_EXPR && c2 != MINUS_EXPR && c2 != BIT_XOR_EXPR)
> +    {
> +      if ((c1 != PLUS_EXPR && c1 != MINUS_EXPR
> +           && c1 != BIT_XOR_EXPR)
> +          || TREE_SIDE_EFFECTS (arg1))
> +        return NULL_TREE;
> +
> +      op0 = TREE_OPERAND (arg0, 0);
> +      op1 = TREE_OPERAND (arg0, 1);
> +
> +      /* Convert temporary X - Y to X + (-Y).  */
> +      if (c1 == MINUS_EXPR)
> +        op1 = fold_build1_loc (loc, NEGATE_EXPR, optype, op1);
> +
> +      /* Check if we can 

Re: [PATCH 08/11] Make conversion warnings work on NULL with -ftrack-macro-expansion

[Gabriel Dos Reis]

On Wed, Apr 11, 2012 at 3:46 AM, Dodji Seketeli  wrote:
> There are various conversion related warnings that trigger on
> potentially dangerous uses of NULL (or __null).  NULL is defined as a
> macro in a system header, so calling warning or warning_at on a virtual
> location of NULL yields no diagnostic.  So the test accompanying this
> patch (as well as others), was failling when run with
> -ftrack-macro-expansion.
>
> I think it's necessary to use the location of NULL that is in the main
> source code (instead of, e.g, the spelling location that is in the
> system header where the macro is defined) in those cases.  Note that for
> __null, we don't have the issue.

I like the idea.  However, you should write a separate function
(get_null_ptr_cst_location?) that computes the location of the null
pointer constant token and call it from where you need the location.

> @@ -5538,12 +5538,26 @@ conversion_null_warnings (tree totype, tree expr, 
> tree fn, int argnum)
>   if (expr == null_node && TREE_CODE (totype) != BOOLEAN_TYPE
>       && ARITHMETIC_TYPE_P (totype))
>     {
> +      source_location loc = input_location;
> +      /* The location of the warning here is most certainly the one for
> +        the token that represented null_node in the source code.
> +        That is either NULL or __null.  If it is NULL, then that
> +        macro is defined in a system header and, as a consequence,
> +        warning_at won't emit any diagnostic for it.  In this case,
> +        we are going to resolve that location to the point in the
> +        source code where the expression that triggered this error
> +        message is, rather than the point where the NULL macro is
> +        defined.  */
> +      if (in_system_header_at (input_location))
> +       loc = linemap_resolve_location (line_table, loc,
> +                                       LRK_MACRO_EXPANSION_POINT,
> +                                       NULL);
>       if (fn)
> -       warning_at (input_location, OPT_Wconversion_null,
> +       warning_at (loc, OPT_Wconversion_null,
>                    "passing NULL to non-pointer argument %P of %qD",
>                    argnum, fn);
>       else
> -       warning_at (input_location, OPT_Wconversion_null,
> +       warning_at (loc, OPT_Wconversion_null,
>                    "converting to non-pointer type %qT from NULL", totype);
>     }
>
> diff --git a/gcc/cp/cvt.c b/gcc/cp/cvt.c
> index c411a47..73bdf71 100644
> --- a/gcc/cp/cvt.c
> +++ b/gcc/cp/cvt.c
> @@ -1468,8 +1468,22 @@ build_expr_type_conversion (int desires, tree expr, 
> bool complain)
>   if (expr == null_node
>       && (desires & WANT_INT)
>       && !(desires & WANT_NULL))
> -    warning_at (input_location, OPT_Wconversion_null,
> -               "converting NULL to non-pointer type");
> +    {
> +      source_location loc = input_location;
> +      /* The location of the warning here is the one for the
> +        (expansion of the) NULL macro, or for __null.  If it is for
> +        NULL, then, as that that macro is defined in a system header,
> +        warning_at won't emit any diagnostic.  In this case, we are
> +        going to resolve that location to the point in the source
> +        code where the expression that triggered this warning is,
> +        rather than the point where the NULL macro is defined.  */
> +      if (in_system_header_at (loc))
> +       loc = linemap_resolve_location (line_table, loc,
> +                                       LRK_MACRO_EXPANSION_POINT,
> +                                       NULL);
> +      warning_at (loc, OPT_Wconversion_null,
> +                 "converting NULL to non-pointer type");
> +    }
>
>   basetype = TREE_TYPE (expr);
>
> diff --git a/gcc/cp/typeck.c b/gcc/cp/typeck.c
> index d2ed940..d096f1e 100644
> --- a/gcc/cp/typeck.c
> +++ b/gcc/cp/typeck.c
> @@ -3798,9 +3798,23 @@ cp_build_binary_op (location_t location,
>          || (!null_ptr_cst_p (orig_op1)
>              && !TYPE_PTR_P (type1) && !TYPE_PTR_TO_MEMBER_P (type1)))
>       && (complain & tf_warning))
> -    /* Some sort of arithmetic operation involving NULL was
> -       performed.  */
> -    warning (OPT_Wpointer_arith, "NULL used in arithmetic");
> +    {
> +      source_location loc = input_location;
> +      /* Some sort of arithmetic operation involving NULL was
> +        performed.  The location of the warning here is the one for
> +        the (expansion of the) NULL macro, or for __null.  If it is
> +        for NULL, then, as that that macro is defined in a system
> +        header, warning_at won't emit any diagnostic.  In this case,
> +        we are going to resolve that location to the point in the
> +        source code where the expression that triggered this warning
> +        is, rather than the point where the NULL macro is
> +        defined.  */
> +      if (in_system_header_at (loc))
> +       loc = linemap_resolve_location (line_table, loc,
> +                                       LRK_MACR

Re: [PATCH] Atom: Enabling unroll at O2 optimization level

[Andi Kleen]

Richard Guenther  writes:
>
> 5% is not moderate.  Your patch does enable unrolling at -O2 but not -O3,
> why? Why do you disable register renaming?  check_imull requires a function
> comment.
>
> This completely looks like a hack for EEMBC2.0, so it's definitely not ok.
>
> -O2 is not supposed to give best benchmark results.

Besides it is against the Intel Optimization Manual recommendation
to prefer small code on Atom to avoid falling out of the predecode hints
in the cache.

So would need much more benchmarking on macro workloads first at least.

-Andi

-- 
a...@linux.intel.com -- Speaking for myself only

Re: [PATCH 09/11] Fix va_arg type location

[Gabriel Dos Reis]

On Wed, Apr 11, 2012 at 3:59 AM, Dodji Seketeli  wrote:
> Now that diagnostics first point to the spelling location of tokens
> coming from macro expansion, the test case
> gcc/testsuite/g++.old-deja/g++.other/vaarg3.C shows that when I write
> va_args (args, some_type), the location that is recorded for
> "some_type" is not correct.  We wrongly record a location that is in
> the system header where the va_args macro is defined.
>
> This patch changes that to correctly record the location for the type
> operand of the va_arg expression.
>
> With this patch applied, the
> gcc/testsuite/g++.old-deja/g++.other/vaarg3.C test PASSes with and
> without -ftrack-macro-expansion.
>
> Tested on x86_64-unknown-linux-gnu against trunk.
>
> Note that the bootstrap with -ftrack-macro-expansion exhibits other
> separate issues that are addressed in subsequent patches.  This patch
> just fixes one class of problems.
>
> The patch does pass bootstrap with -ftrack-macro-expansion turned off,
> though.

OK.

Re: [PATCH] Atom: Scheduler improvements for better imul placement

[Andi Kleen]

Igor Zamyatin  writes:

> Hi All!
>
> It is known that imul placement is rather critical for Atom processors
> and changes try to improve imul scheduling for Atom.
>
> This gives +5% performance on several tests from new OA 2.0 testsuite
> from EEMBC.
>
> Tested for i386 and x86-64, ok for trunk?

Did you measure how much this slows down the compiler when compiling
for Atom? The new pass looks rather slow.

-Andi

-- 
a...@linux.intel.com -- Speaking for myself only

Re: [PATCH 01/11] Fix cpp_sys_macro_p with -ftrack-macro-expansion

[Jason Merrill]

On 04/10/2012 10:55 AM, Dodji Seketeli wrote:

+  if (CPP_OPTION (pfile, track_macro_expansion))


I think this should check context->tokens_kind rather than the compiler 
flag.


Jason

Re: [PATCH 02/11] Fix token pasting with -ftrack-macro-expansion

[Jason Merrill]

On 04/10/2012 10:57 AM, Dodji Seketeli wrote:

+virt_loc = *(context->c.mc->cur_virt_loc - 1);


Style nit: I'd use [-1] here.  OK with that change.

Jason

Re: [SH] PR 50751 - add HImode displacement addressing support

[Oleg Endo]

On Wed, 2012-04-11 at 22:10 +0900, Kaz Kojima wrote:
> Oleg Endo  wrote:
> >> BTW, do you have the numbers of CSiBE with this?
> >> 
> > 
> > Only for "-m4-single -ml -O2 -mpretend-cmove" so far.
> > Not so spectacular :T
> > I'll also do a comparison of more variants to see if something went
> > really bad.  It's a bit difficult to isolate the degradations because
> > there's quite some code reordering happening after the patch... 
> 
> Thanks for numbers!  Looks good considering that HImode would be
> less frequently used than QImode in the usual working set.
> 
Sure, no problem.
I think there is some room for improvement in the
'sh_find_mov_disp_adjust' function.  If it was a bit smarter, all the
displacement move insns would instantly benefit from it.

Cheers,
Oleg

Re: [PATCH 04/11] Fix expansion point loc for macro-like tokens

[Jason Merrill]

On 04/10/2012 03:42 PM, Dodji Seketeli wrote:

In that case, besides returning NULL, enter_macro_context sets
pfile->context->c.macro to NULL, making cpp_get_token_1 forget to set
the location of the "vari" to the expansion point of A.


This seems like a bug that should be fixed rather than worked around; we 
are still expanding A.


Jason

Re: [PATCH 05/11] Make expand_location resolve to locus in main source file

[Jason Merrill]

On 04/10/2012 03:49 PM, Dodji Seketeli wrote:

Apparently, quite some places in the compiler (like the C/C++
preprocessor, the debug info machinery) expect expand_location to
resolve to locations that are in the main source file, even if the
token at stake comes from a macro that was defined in a header
somewhere.  Turning on -ftrack-macro-expansion by default was
triggering a lot of failures (not necessarily related to diagnostics)
because expand_location resolves to spelling locations instead.


Can you elaborate on these failures?  For debug info I would think that 
the spelling location would be useful information, though I suppose 
without any way to "unwind" to the expansion context it could be a bit 
confusing.  What is the problem for the preprocessor?


Jason

Re: [PATCH 06/11] Strip "" loc from displayed expansion context

[Jason Merrill]

Good thought.  OK.

Jason

Re: [PATCH 07/11] Fix -Wuninitialized for -ftrack-macro-expansion

[Jason Merrill]

OK.

Jason

intptr fixes for the testsuite

[Bernd Schmidt]

I'm working on a target where intptr_t and pointers are larger than
size_t and ptrdiff_t. The testsuite has problems in this area, since we
often use the latter two types for casting from/to pointers, leading to
unwanted warnings. In some cases I've checked the corresponding PRs and
found that the original testcases used something like plain int or long.

The following is a first pass to eliminate some of these problems.
Tested on i686-linux. Ok?


Bernd
* gcc.c-torture/execute/pr22098-1.c (uintptr_t): Likewise.
* gcc.c-torture/execute/pr22098-2.c (uintptr_t): Likewise.
* gcc.c-torture/execute/pr22098-3.c (uintptr_t): Likewise.
* gcc.dg/pr34856.c (uintptr_t): Likewise.
* gcc.dg/c99-const-expr-9.c (old_offsetof): Insert a cast to
__UINTPTR_TYPE__.
* gcc.c-torture/execute/pr15296.c (intptr_t): Likewise, with
__INTPTR_TYPE__.
* gcc.dg/pr14092-1.c (intptr_t): Likewise.
* gcc.dg/tree-ssa/foldcast-1.c (ssize_t): Likewise.
* gcc.dg/c90-const-expr-6.c (intptr_t): New typedef to replace ...
(ptrdiff_t): ... this.  All uses changed.
* gcc.dg/c99-const-expr-6.c (intptr_t, ptrdiff_t): Likewise.
* gcc.dg/torture/pta-escape-1.c (foo): Change arg type to
__INTPTR_TYPE__.
(main): Cast argument to __INTPTR_TYPE__.
* gcc.dg/20041106-1.c (main): Cast to __UINTPTR_TYPE__ rather than
size_t.
* gcc.dg/mallign.c (main): Likewise.
* gcc.dg/pr38700.c (foo): Likewise.
* gcc.dg/long-long-cst1.c (t): Likewise.
* gcc.dg/c99-const-expr-10.c (p, q, f, h, h2): Likewise.
* gcc.dg/array-10.c (c0, c1, c2, c3, c4, c5): Likewise.
* gcc.dg/pointer-arith-10.c (foo): Likewise.
* gcc.dg/pr25682.c (d, foo): Likewise.
* gcc.dg/format/cast-1.c (f): Likewise.
* gcc.dg/c90-const-expr-10.c
* gcc.dg/pr41551.c (uintptr_t): New typedef, replacing...
(size_t): ...this.  All uses changed.
* gcc.dg/sequence-pt-1.c: Likewise.
* gcc.dg/c90-const-expr-9.c (uintptr_t): Likewise.
* gcc.dg/max-1.c (intptr_t): Likewise, replacing ssize_t.
* gcc.dg/pr30744-1.c (my_intptr_t): New typedef.  Replace all uses
of ptrdiff_t with it.
* gcc.dg/inline-23.c (my_intptr_t): Likewise.
* gcc.dg/pr37561.c (p): Use __INTPTR_TYPE__.
* gcc.dg/vla-11.c (foo11b): Use __UINTPTR_TYPE__.

Index: gcc/testsuite/gcc.c-torture/execute/pr22098-1.c
===
--- gcc/testsuite/gcc.c-torture/execute/pr22098-1.c (revision 186270)
+++ gcc/testsuite/gcc.c-torture/execute/pr22098-1.c (working copy)
@@ -1,13 +1,13 @@
 extern void abort (void);
 extern void exit (int);
-typedef __SIZE_TYPE__ size_t;
+typedef __UINTPTR_TYPE__ uintptr_t;
 int
 main (void)
 {
   int a = 0;
   int *p;
-  size_t b;
-  b = (size_t)(p = &(int []){0, 1, 2}[++a]);
+  uintptr_t b;
+  b = (uintptr_t)(p = &(int []){0, 1, 2}[++a]);
   if (a != 1 || *p != 1 || *(int *)b != 1)
 abort ();
   exit (0);
Index: gcc/testsuite/gcc.c-torture/execute/pr22098-3.c
===
--- gcc/testsuite/gcc.c-torture/execute/pr22098-3.c (revision 186270)
+++ gcc/testsuite/gcc.c-torture/execute/pr22098-3.c (working copy)
@@ -1,6 +1,6 @@
 extern void abort (void);
 extern void exit (int);
-typedef __SIZE_TYPE__ size_t;
+typedef __UINTPTR_TYPE__ uintptr_t;
 int n = 0;
 int f (void) { return ++n; }
 int
@@ -8,8 +8,8 @@ main (void)
 {
   int a = 0;
   int *p;
-  size_t b;
-  b = (size_t)(p = &(int []){0, f(), 2}[1]);
+  uintptr_t b;
+  b = (uintptr_t)(p = &(int []){0, f(), 2}[1]);
   if (*p != 1 || *(int *)b != 1 || n != 1)
 abort ();
   exit (0);
Index: gcc/testsuite/gcc.c-torture/execute/pr15296.c
===
--- gcc/testsuite/gcc.c-torture/execute/pr15296.c   (revision 186270)
+++ gcc/testsuite/gcc.c-torture/execute/pr15296.c   (working copy)
@@ -3,7 +3,7 @@
fall-through code, while that register held a pointer used in code at
the branch target.  */
 
-typedef int __attribute__ ((mode (__pointer__))) intptr_t;
+typedef __INTPTR_TYPE__ intptr_t;
 typedef intptr_t W;
 union u0
 {
Index: gcc/testsuite/gcc.c-torture/execute/pr22098-2.c
===
--- gcc/testsuite/gcc.c-torture/execute/pr22098-2.c (revision 186270)
+++ gcc/testsuite/gcc.c-torture/execute/pr22098-2.c (working copy)
@@ -1,13 +1,13 @@
 extern void abort (void);
 extern void exit (int);
-typedef __SIZE_TYPE__ size_t;
+typedef __UINTPTR_TYPE__ uintptr_t;
 int
 main (void)
 {
   int a = 0;
   int *p;
-  size_t b;
-  b = (size_t)(p = &(int []){0, 1, 2}[1]);
+  uintptr_t b;
+  b = (uintptr_t)(p = &(int []){0, 1, 2}[1]);
   if (*p != 1 || *(int *)b != 1)
 abort ();
   exit (0);
Index: gcc/testsuite/gcc.dg/pr34856.c
==

Compare precisions with precisions in fold-const

[Bernd Schmidt]

This is another problem I found working on a new target. In fold-const,
when folding conversions, there are two instances where mode bitsizes
are compared to type precisions. This fails to do the right thing if
mode precision and bitsize differ (which I believe they currently don't
on any target).

Bootstrapped and regression tested on i686-linux. Ok?


Bernd
* fold-const.c (fold_unary_loc): Use GET_MODE_PRECISION for
comparisons against TYPE_PRECISION.
 
Index: gcc/fold-const.c
===
--- gcc/fold-const.c(revision 365109)
+++ gcc/fold-const.c(working copy)
@@ -8586,7 +8586,7 @@ fold_unary_loc (location_t loc, enum tre
  && inter_prec >= inside_prec
  && (inter_float || inter_vec
  || inter_unsignedp == inside_unsignedp)
- && ! (final_prec != GET_MODE_BITSIZE (TYPE_MODE (type))
+ && ! (final_prec != GET_MODE_PRECISION (TYPE_MODE (type))
&& TYPE_MODE (type) == TYPE_MODE (inter_type))
  && ! final_ptr
  && (! final_vec || inter_prec == inside_prec))
@@ -8620,7 +8620,7 @@ fold_unary_loc (location_t loc, enum tre
  == (final_unsignedp && final_prec > inter_prec))
  && ! (inside_ptr && inter_prec != final_prec)
  && ! (final_ptr && inside_prec != inter_prec)
- && ! (final_prec != GET_MODE_BITSIZE (TYPE_MODE (type))
+ && ! (final_prec != GET_MODE_PRECISION (TYPE_MODE (type))
&& TYPE_MODE (type) == TYPE_MODE (inter_type)))
return fold_build1_loc (loc, code, type, TREE_OPERAND (op0, 0));
}

Re: intptr fixes for the testsuite

[Tristan Gingold]

On Apr 11, 2012, at 3:55 PM, Bernd Schmidt wrote:

> I'm working on a target where intptr_t and pointers are larger than
> size_t and ptrdiff_t. The testsuite has problems in this area, since we
> often use the latter two types for casting from/to pointers, leading to
> unwanted warnings. In some cases I've checked the corresponding PRs and
> found that the original testcases used something like plain int or long.

Would this target be able to host gcc ?

Tristan.

Re: intptr fixes for the testsuite

[Bernd Schmidt]

On 04/11/2012 04:02 PM, Tristan Gingold wrote:
> 
> On Apr 11, 2012, at 3:55 PM, Bernd Schmidt wrote:
> 
>> I'm working on a target where intptr_t and pointers are larger than
>> size_t and ptrdiff_t. The testsuite has problems in this area, since we
>> often use the latter two types for casting from/to pointers, leading to
>> unwanted warnings. In some cases I've checked the corresponding PRs and
>> found that the original testcases used something like plain int or long.
> 
> Would this target be able to host gcc ?

I do not wish to think about this :) It's embedded, so hopefully no one
will try.

In principle, I'd think any target with enough memory can be made to
host gcc, with varying amounts of work.


Bernd

Re: [PATCH] Atom: Scheduler improvements for better imul placement

[Richard Guenther]

On Wed, Apr 11, 2012 at 3:38 PM, Andi Kleen  wrote:
> Igor Zamyatin  writes:
>
>> Hi All!
>>
>> It is known that imul placement is rather critical for Atom processors
>> and changes try to improve imul scheduling for Atom.
>>
>> This gives +5% performance on several tests from new OA 2.0 testsuite
>> from EEMBC.
>>
>> Tested for i386 and x86-64, ok for trunk?
>
> Did you measure how much this slows down the compiler when compiling
> for Atom? The new pass looks rather slow.

Also please explain why adjusting the automaton for Atom is not a way to
attack this issue.

Richard.

> -Andi
>
> --
> a...@linux.intel.com -- Speaking for myself only

Re: haifa-sched: Fix problems with cc0 in prune_ready_list

[Bernd Schmidt]

On 02/10/2012 08:01 PM, Vladimir Makarov wrote:
> On 02/08/2012 10:01 AM, Bernd Schmidt wrote:
>> We found a scheduler problem while testing Coldfire targets. The
>> prune_ready_list function I introduced doesn't take SCHED_GROUPs into
>> account, which can lead to a random insn being scheduled between a cc0
>> setter and user. The patch below fixes it, OK? (Bootstrapped&  tested
>> i686-linux).
>>
>>
> Ok. Thanks, Bernd.

It turns out that the previous fix was insufficient. If a cc0 user and
another insn are on the ready list, it can happen that the cc0 user is
delayed for longer than the other insn, and we will reenter
prune_ready_list with a new ready insn but with the cc0 user still
queued for later. In that case we'll do the wrong thing.

The following patch reworks the function to take care of this problem.
Bootstrapped and tested on i686-linux, and also tested with a m68k
multilib on our internal compiler (4.6 based but with scheduler patches
from 4.7). Ok?

I assume this should also go into 4.7 eventually.


Bernd
* haifa-sched.c (prune_ready_list): Rework handling of SHCED_GROUP_P
insns so that no other insn is queued for a time before them.

Index: gcc/haifa-sched.c
===
--- gcc/haifa-sched.c   (revision 186270)
+++ gcc/haifa-sched.c   (working copy)
@@ -3946,88 +3946,106 @@ static void
 prune_ready_list (state_t temp_state, bool first_cycle_insn_p,
  bool shadows_only_p, bool modulo_epilogue_p)
 {
-  int i;
+  int i, pass;
   bool sched_group_found = false;
+  int min_cost_group = 1;
 
- restart:
   for (i = 0; i < ready.n_ready; i++)
 {
   rtx insn = ready_element (&ready, i);
-  int cost = 0;
-  const char *reason = "resource conflict";
-
-  if (DEBUG_INSN_P (insn))
-   continue;
-
-  if (SCHED_GROUP_P (insn) && !sched_group_found)
+  if (SCHED_GROUP_P (insn))
{
  sched_group_found = true;
- if (i > 0)
-   goto restart;
+ break;
}
+}
 
-  if (sched_group_found && !SCHED_GROUP_P (insn))
-   {
- cost = 1;
- reason = "not in sched group";
-   }
-  else if (modulo_epilogue_p && INSN_EXACT_TICK (insn) == INVALID_TICK)
-   {
- cost = max_insn_queue_index;
- reason = "not an epilogue insn";
-   }
-  else if (shadows_only_p && !SHADOW_P (insn))
-   {
- cost = 1;
- reason = "not a shadow";
-   }
-  else if (recog_memoized (insn) < 0)
-   {
- if (!first_cycle_insn_p
- && (GET_CODE (PATTERN (insn)) == ASM_INPUT
- || asm_noperands (PATTERN (insn)) >= 0))
-   cost = 1;
- reason = "asm";
-   }
-  else if (sched_pressure_p)
-   cost = 0;
-  else
+  /* Make two passes if there's a SCHED_GROUP_P insn; make sure to handle
+ such an insn first and note its cost, then schedule all other insns
+ for one cycle later.  */
+  for (pass = sched_group_found ? 0 : 1; pass < 2; )
+{
+  int n = ready.n_ready;
+  for (i = 0; i < n; i++)
{
- int delay_cost = 0;
+ rtx insn = ready_element (&ready, i);
+ int cost = 0;
+ const char *reason = "resource conflict";
 
- if (delay_htab)
+ if (DEBUG_INSN_P (insn))
+   continue;
+
+ if (sched_group_found && !SCHED_GROUP_P (insn))
{
- struct delay_pair *delay_entry;
- delay_entry
-   = (struct delay_pair *)htab_find_with_hash (delay_htab, insn,
-   htab_hash_pointer 
(insn));
- while (delay_entry && delay_cost == 0)
+ if (pass == 0)
+   continue;
+ cost = min_cost_group;
+ reason = "not in sched group";
+   }
+ else if (modulo_epilogue_p
+  && INSN_EXACT_TICK (insn) == INVALID_TICK)
+   {
+ cost = max_insn_queue_index;
+ reason = "not an epilogue insn";
+   }
+ else if (shadows_only_p && !SHADOW_P (insn))
+   {
+ cost = 1;
+ reason = "not a shadow";
+   }
+ else if (recog_memoized (insn) < 0)
+   {
+ if (!first_cycle_insn_p
+ && (GET_CODE (PATTERN (insn)) == ASM_INPUT
+ || asm_noperands (PATTERN (insn)) >= 0))
+   cost = 1;
+ reason = "asm";
+   }
+ else if (sched_pressure_p)
+   cost = 0;
+ else
+   {
+ int delay_cost = 0;
+
+ if (delay_htab)
{
- delay_cost = estimate_shadow_tick (delay_entry);
- if (delay_cost > max_insn_queue_index)
-   delay_cost = max_insn_queue_index;
- delay_entry = delay_entry->next_same_i1;
+ struct delay_pair *del

Re: Compare precisions with precisions in fold-const

[Richard Guenther]

On Wed, Apr 11, 2012 at 3:59 PM, Bernd Schmidt  wrote:
> This is another problem I found working on a new target. In fold-const,
> when folding conversions, there are two instances where mode bitsizes
> are compared to type precisions. This fails to do the right thing if
> mode precision and bitsize differ (which I believe they currently don't
> on any target).
>
> Bootstrapped and regression tested on i686-linux. Ok?

Ok.  Please also adjust the corresponding duplicate code in tree-ssa-forwprop.c

Thanks,
Richard.

>
> Bernd

Change initialization order in sel-sched

[Bernd Schmidt]

The order of calls to sched_rgn_init and sched_init differs between
sched-rgn and sel-sched. This caused a scheduler patch I was working on
to segfault once sel-sched was enabled. The following patch swaps the
two function calls.

Bootstrapped & tested on i686-linux. Ok?


Bernd
* sel-sched.c (sel_global_init): Swap order of sched_rgn_init and
sched_init calls.

Index: gcc/sel-sched.c
===
--- gcc/sel-sched.c (revision 364953)
+++ gcc/sel-sched.c (working copy)
@@ -7616,8 +7616,8 @@ sel_global_init (void)
   sel_setup_sched_infos ();
   setup_sched_dump ();
 
-  sched_rgn_init (false);
   sched_init ();
+  sched_rgn_init (false);
 
   sched_init_bbs ();
   /* Reset AFTER_RECOVERY if it has been set by the 1st scheduler pass.  */

Re: RFC: PR rtl-optimization/52876: Sign extend 32 to 64bit then clear upper 32bits fails O1 or higher

[Richard Sandiford]

"H.J. Lu"  writes:
> Hi,
>
> CSE turns (reg:DI 64)
>
> (insn 6 3 7 2 (set (reg:DI 64)
> (sign_extend:DI (subreg/u:SI (reg/v/f:DI 63 [ addr ]) 0))) x.i:6 122
> {*extendsidi2_rex64} (nil))
>
> into (reg/f:DI 64 [ addr ]).  But nonzero_bits1 in rtlanal.c has
>
> #if defined(POINTERS_EXTEND_UNSIGNED) && !defined(HAVE_ptr_extend)
>   /* If pointers extend unsigned and this is a pointer in Pmode, say that
>  all the bits above ptr_mode are known to be zero.  */
>   /* As we do not know which address space the pointer is refering to,
>  we can do this only if the target does not support different pointer
>  or address modes depending on the address space.  */
>   if (target_default_pointer_address_modes_p ()
>   && POINTERS_EXTEND_UNSIGNED && GET_MODE (x) == Pmode
>   && REG_POINTER (x))
> nonzero &= GET_MODE_MASK (ptr_mode);
> #endif
>
> Setting REG_POINTER with incompatible pointer sign extension is wrong.
> This patch adds a bool parameter to set_reg_attrs_from_value to
> indicate if a register can be marked as a pointer.  Does it look OK?
>
> Thanks.
>
>
> H.J.
> ---
> gcc/
>
> 2012-04-05  H.J. Lu  
>
>   PR rtl-optimization/52876
>   * emit-rtl.c (set_reg_attrs_from_value): Add a bool parameter
>   to indicate if a register can be a pointer.
>   (gen_reg_rtx_and_attrs): Pass true to set_reg_attrs_from_value.
>   (set_reg_attrs_for_parm): Likewise.
>
>   * emit-rtl.h (set_reg_attrs_from_value): Add a bool parameter.
>
>   * reginfo.c (reg_scan_mark_refs): Pass false to
>   set_reg_attrs_from_value with incompatible pointer sign
>   extension.

Regardless of how it is currently used, I think gen_reg_rtx_and_attrs
(another caller to set_reg_attrs_from_value) is supposed to be a fairly
general function.  So rather than apply a fix specific to regscan,
I think it would be cleaner to redefine set_reg_attrs_from_value as
taking an arbitrary value.  The whole while loop:

  while (GET_CODE (src) == SIGN_EXTEND
 || GET_CODE (src) == ZERO_EXTEND
 || GET_CODE (src) == TRUNCATE
 || (GET_CODE (src) == SUBREG && subreg_lowpart_p (src)))
src = XEXP (src, 0);

would then move to set_reg_attrs_from_value, and the "can be pointer"
thing hidden there.  The regscan code would just be:

  if (REG_P (dest) && !REG_ATTRS (dest))
set_reg_attrs_from_value (dest, src);

Richard

Re: Change initialization order in sel-sched

[Richard Guenther]

On Wed, Apr 11, 2012 at 4:16 PM, Bernd Schmidt  wrote:
> The order of calls to sched_rgn_init and sched_init differs between
> sched-rgn and sel-sched. This caused a scheduler patch I was working on
> to segfault once sel-sched was enabled. The following patch swaps the
> two function calls.
>
> Bootstrapped & tested on i686-linux. Ok?

Ok.

Thanks,
Richard.

>
> Bernd

[PATCH] Cleanup estimated/max-niter API

[Richard Guenther]

I stumbled over the following hunk in one of my pending patches

Index: gcc/tree-ssa-loop-prefetch.c
===
--- gcc/tree-ssa-loop-prefetch.c.orig   2011-10-12 13:14:10.0 
+0200
+++ gcc/tree-ssa-loop-prefetch.c2012-02-23 15:05:45.0 
+0100
@@ -1801,6 +1801,8 @@ loop_prefetch_arrays (struct loop *loop)

   ahead = (PREFETCH_LATENCY + time - 1) / time;
   est_niter = max_stmt_executions_int (loop, false);
+  if (est_niter == -1)
+est_niter = max_stmt_executions_int (loop, true);

   /* Prefetching is not likely to be profitable if the trip count to 
ahead
  ratio is too small.  */

which confused me.  Then I looked at the existing API which
confused me more ;)  So the following ditches the 'conservative'
parameter in all of the functions and explicitely calls them
estimated_* and max_*.  Still way too many, but - oh well.

The other question is whether estimated_* should return max_*
if we have a maximum recorded but no estimate (the above hunk
would make us use the recorded maximum if available and no
estimate is available).  Or if that should be done in the callers
depending on their behavior in the case no estimate is available.

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

Richard.

2012-04-11  Richard Guenther  

* cfgloop.h (estimated_loop_iterations_int): Ditch
'conservative' parameter.
(max_stmt_executions_int): Likewise.
(estimated_loop_iterations): Likewise.
(max_stmt_executions): Likewise.
(max_loop_iterations): Declare.
(max_loop_iterations_int): Likewise.
(estimated_stmt_executions): Likewise.
(estimated_stmt_executions_int): Likewise.
* tree-ssa-loop-niter.c (estimated_loop_iterations):
Split parts to ...
(max_loop_iterations): ... this.
(estimated_loop_iterations_int): Split parts to ...
(max_loop_iterations_int): ... this.
(max_stmt_executions_int): Split parts to ...
(estimated_stmt_executions_int): ... this.
(max_stmt_executions): Split parts to ...
(estimated_stmt_executions): ... this.
* graphite-sese-to-poly.c (build_loop_iteration_domains): Adjust.
* predict.c (predict_loops): Likewise.
* tree-data-ref.c (max_stmt_executions_tree): Likewise.
(analyze_siv_subscript_cst_affine): Likewise.
(compute_overlap_steps_for_affine_1_2): Likewise.
(analyze_subscript_affine_affine): Likewise.
(init_omega_for_ddr_1): Likewise.
* tree-parloops.c (parallelize_loops): Likewise.
* tree-ssa-loop-ivopts.c (avg_loop_niter): Likewise.
(may_eliminate_iv): Likewise.
* tree-ssa-loop-prefetch.c (determine_loop_nest_reuse): Likewise.
(loop_prefetch_arrays): Likewise.
* tree-vrp.c (adjust_range_with_scev): Likewise.

Index: gcc/cfgloop.h
===
*** gcc/cfgloop.h.orig  2012-04-11 15:31:56.0 +0200
--- gcc/cfgloop.h   2012-04-11 15:41:05.688414649 +0200
*** extern unsigned expected_loop_iterations
*** 279,288 
  extern rtx doloop_condition_get (rtx);
  
  void estimate_numbers_of_iterations_loop (struct loop *, bool);
! HOST_WIDE_INT estimated_loop_iterations_int (struct loop *, bool);
! HOST_WIDE_INT max_stmt_executions_int (struct loop *, bool);
! bool estimated_loop_iterations (struct loop *, bool, double_int *);
! bool max_stmt_executions (struct loop *, bool, double_int *);
  
  /* Loop manipulation.  */
  extern bool can_duplicate_loop_p (const struct loop *loop);
--- 279,292 
  extern rtx doloop_condition_get (rtx);
  
  void estimate_numbers_of_iterations_loop (struct loop *, bool);
! bool estimated_loop_iterations (struct loop *, double_int *);
! bool max_loop_iterations (struct loop *, double_int *);
! HOST_WIDE_INT estimated_loop_iterations_int (struct loop *);
! HOST_WIDE_INT max_loop_iterations_int (struct loop *);
! bool max_stmt_executions (struct loop *, double_int *);
! bool estimated_stmt_executions (struct loop *, double_int *);
! HOST_WIDE_INT max_stmt_executions_int (struct loop *);
! HOST_WIDE_INT estimated_stmt_executions_int (struct loop *);
  
  /* Loop manipulation.  */
  extern bool can_duplicate_loop_p (const struct loop *loop);
Index: gcc/tree-ssa-loop-niter.c
===
*** gcc/tree-ssa-loop-niter.c.orig  2012-04-11 15:31:56.0 +0200
--- gcc/tree-ssa-loop-niter.c   2012-04-11 15:44:38.888401936 +0200
*** estimate_numbers_of_iterations_loop (str
*** 3052,3076 
 the function returns false, otherwise returns true.  */
  
  bool
! estimated_loop_iterations (struct loop *loop, bool conservative,
!  double_int *nit)
  {
estimate_numbers_of_iterations_loop (loop, true);
!   if (conservative)
! {
!   if (!loop->any_upper_bound)
! 

Re: RFC: IRA patch to reduce lifetimes

[Bernd Schmidt]

On 12/23/2011 05:31 PM, Vladimir Makarov wrote:
> On 12/21/2011 09:09 AM, Bernd Schmidt wrote:
>> This patch was an experiment to see if we can get the same improvement
>> with modifications to IRA, making it more tolerant to over-aggressive
>> scheduling. THe idea is that if an instruction sets a register A, and
>> all its inputs are live and unmodified for the lifetime of A, then
>> moving the instruction downwards towards its first use is going to be
>> beneficial from a register pressure point of view.
>>
>> That alone, however, turns out to be too aggressive, performance drops
>> presumably because we undo too many scheduling decisions. So, the patch
>> detects such situations, and splits the pseudo; a new pseudo is
>> introduced in the original setting instruction, and a copy is added
>> before the first use. If the new pseudo does not get a hard register, it
>> is removed again and instead the setting instruction is moved to the
>> point of the copy.
>>
>> This gets up to 6.5% on 456.hmmer on the mips target I was working on;
>> an embedded benchmark suite also seems to have a (small) geomean
>> improvement. On x86_64, I've tested spec2k, where specint is unchanged
>> and specfp has a tiny performance regression. All these tests were done
>> with a gcc-4.6 based tree.
>>
>> Thoughts? Currently the patch feels somewhat bolted on to the side of
>> IRA, maybe there's a nicer way to achieve this?
>>
> I think that is an excellent idea.  I used analogous approach for
> splitting pseudo in IRA on loop bounds even if it gets hard register
> inside and outside loops.  The copies are removed if the live ranges
> were not spilled in reload.
> 
> I have no problem with this patch.  It is just a small change in IRA.

Sounds like you're happier with the patch than I am, so who am I to argue.

Here's an updated version against current trunk, with some cc0 bugfixes
that I've since discovered to be necessary. Bootstrapped and tested (but
not benchmarked again) on i686-linux. Ok?


Bernd
* dbgcnt.def (ira_move): New counter.
* ira-int.h (ira_create_new_reg): Declare function.
(first_moveable_pseudo, last_moveable_pseudo): Declare variables.
* ira-emit.c (ira_create_new_reg): Renamed from craete_new_reg and
no longer static.  All callers changed.
* ira.c: Include "dbgcnt.h".
(rtx_moveable_p, insn_dominated_by_p, find_moveable_pseudos,
move_unallocated_pseudos): New static functions.
(first_moveable_pseudo, last_moveable_pseudo): New global variables.
(pseudo_replaced_reg, pseudo_move_insn): New static variables.
(ira): Call find_moveable_pseudos and move_unallocated_pseudos.
* ira-costs.c (find_costs_and_classes): Assign a memory cost of zero
to the pseudos generated in find_moveable_pseudos.
* Makefile.in (ira.o): Add $(DBGCNT_H).

Index: gcc/dbgcnt.def
===
--- gcc/dbgcnt.def  (revision 186270)
+++ gcc/dbgcnt.def  (working copy)
@@ -184,3 +184,4 @@ DEBUG_COUNTER (sms_sched_loop)
 DEBUG_COUNTER (store_motion)
 DEBUG_COUNTER (split_for_sched2)
 DEBUG_COUNTER (tail_call)
+DEBUG_COUNTER (ira_move)
Index: gcc/ira-int.h
===
--- gcc/ira-int.h   (revision 186270)
+++ gcc/ira-int.h   (working copy)
@@ -1416,3 +1416,6 @@ ira_allocate_and_set_or_copy_costs (int
reg_costs[i] = val;
 }
 }
+
+extern rtx ira_create_new_reg (rtx);
+extern int first_moveable_pseudo, last_moveable_pseudo;
Index: gcc/ira-emit.c
===
--- gcc/ira-emit.c  (revision 186270)
+++ gcc/ira-emit.c  (working copy)
@@ -330,8 +330,8 @@ add_to_edge_list (edge e, move_t move, b
 
 /* Create and return new pseudo-register with the same attributes as
ORIGINAL_REG.  */
-static rtx
-create_new_reg (rtx original_reg)
+rtx
+ira_create_new_reg (rtx original_reg)
 {
   rtx new_reg;
 
@@ -625,7 +625,7 @@ change_loop (ira_loop_tree_node_t node)
fprintf (ira_dump_file, "  %i vs parent %i:",
 ALLOCNO_HARD_REGNO (allocno),
 ALLOCNO_HARD_REGNO (parent_allocno));
- set_allocno_reg (allocno, create_new_reg (original_reg));
+ set_allocno_reg (allocno, ira_create_new_reg (original_reg));
}
}
 }
@@ -646,7 +646,7 @@ change_loop (ira_loop_tree_node_t node)
   if (! used_p)
continue;
   bitmap_set_bit (renamed_regno_bitmap, regno);
-  set_allocno_reg (allocno, create_new_reg (allocno_emit_reg (allocno)));
+  set_allocno_reg (allocno, ira_create_new_reg (allocno_emit_reg 
(allocno)));
 }
 }
 
@@ -852,7 +852,7 @@ modify_move_list (move_t list)
ALLOCNO_ASSIGNED_P (new_allocno) = true;
ALLOCNO_HARD_REGNO (new_allocno) = -1;
ALLOCNO_EMIT_DATA (new_allocno)->reg
-

Re: haifa-sched: Fix problems with cc0 in prune_ready_list

[Vladimir Makarov]

On 04/11/2012 10:08 AM, Bernd Schmidt wrote:

On 02/10/2012 08:01 PM, Vladimir Makarov wrote:

On 02/08/2012 10:01 AM, Bernd Schmidt wrote:

We found a scheduler problem while testing Coldfire targets. The
prune_ready_list function I introduced doesn't take SCHED_GROUPs into
account, which can lead to a random insn being scheduled between a cc0
setter and user. The patch below fixes it, OK? (Bootstrapped&   tested
i686-linux).



Ok. Thanks, Bernd.

It turns out that the previous fix was insufficient. If a cc0 user and
another insn are on the ready list, it can happen that the cc0 user is
delayed for longer than the other insn, and we will reenter
prune_ready_list with a new ready insn but with the cc0 user still
queued for later. In that case we'll do the wrong thing.
What a coincidence :)  Yesterday I found the same bug on m68k on lra 
branch and just started to work on it.

The following patch reworks the function to take care of this problem.
Bootstrapped and tested on i686-linux, and also tested with a m68k
multilib on our internal compiler (4.6 based but with scheduler patches
from 4.7). Ok?

Ok.

I assume this should also go into 4.7 eventually.


Yes.  It is a serious bug for cc0 targets.

Thanks, Bernd.

fix ppc-aix build failures with spaces in CC (internal) variable

[Olivier Hainque]

We sometimes get to invoke Makefile targets with a CC variable value containing
spaces (for extra options, typically). This causes failure at some stages on
powerpc-aix from mh-ppc-aix which has

  LDFLAGS = `case $(CC) in *gcc*) echo -Wl,-bbigtoc ;; esac;`

The problem is the expansion of spaces as part of the case controlling value,
triggering shell syntax errors.

This patch fixes this by adding quotes around.

OK to commit ?

Bootstrapped and regtested on powerpc-aix-5.2.

Thanks in adavnce,

Olivier

2012-04-11  Olivier Hainque  

* config/mh-ppc-aix (LDFLAGS): Quote $(CC).



aix-quotecc.dif
Description: video/dv

C6X fix in load_got_gotoff

[Bernd Schmidt]

This pattern is of type load, but the operands don't match the pattern
found in other load insns, so we must explicitly set op_pattern to
unknown. Committed.


Bernd
Index: gcc/ChangeLog
===
--- gcc/ChangeLog   (revision 186325)
+++ gcc/ChangeLog   (working copy)
@@ -6,6 +6,9 @@
* haifa-sched.c (prune_ready_list): Rework handling of SCHED_GROUP_P
insns so that no other insn is queued for a time before them.
 
+   * config/c6x/c6x.md (load_got_gotoff): Set op_pattern attribute to
+   unknown.
+
 2012-04-11  Richard Guenther  
 
PR middle-end/52621
Index: gcc/config/c6x/c6x.md
===
--- gcc/config/c6x/c6x.md   (revision 186270)
+++ gcc/config/c6x/c6x.md   (working copy)
@@ -433,6 +433,7 @@ (define_insn "load_got_gotoff"
   "%|%.\\tldw\\t%$\\t*+%1[%2], %0"
   [(set_attr "type" "load")
(set_attr "units" "d_addr")
+   (set_attr "op_pattern" "unknown")
(set_attr "dest_regfile" "a,b")
(set_attr "addr_regfile" "b")])
 

Re: intptr fixes for the testsuite

[Mike Stump]

On Apr 11, 2012, at 7:04 AM, Bernd Schmidt wrote:
> On 04/11/2012 04:02 PM, Tristan Gingold wrote:
>> 
>> On Apr 11, 2012, at 3:55 PM, Bernd Schmidt wrote:
>>> I'm working on a target where intptr_t and pointers are larger than
>>> size_t and ptrdiff_t. The testsuite has problems in this area, since we
>>> often use the latter two types for casting from/to pointers, leading to
>>> unwanted warnings. In some cases I've checked the corresponding PRs and
>>> found that the original testcases used something like plain int or long.
>> 
>> Would this target be able to host gcc ?
> 
> I do not wish to think about this :) It's embedded, so hopefully no one
> will try.
> 
> In principle, I'd think any target with enough memory can be made to
> host gcc, with varying amounts of work.

I've hosted gcc on mine, mainly as a code generation correctness check...  It's 
nice having a simulator and enough address bits, you can just plop down yet 
more memory and presto, everything just works.  The more annoying aspect is 
having to wire up stat and readdir for sim.  Fork and exec, are more trivial by 
comparison.  Some gcc ports might not have enough address bits, that might be 
the only hard requirement that one cannot fudge.

Re: intptr fixes for the testsuite

[Mike Stump]

On Apr 11, 2012, at 6:55 AM, Bernd Schmidt wrote:
> I'm working on a target where intptr_t and pointers are larger than
> size_t and ptrdiff_t.

Hum, we question your sanity  :-)

> Ok?

Ok.  I hope you tested it on your target too!

Re: intptr fixes for the testsuite

[Tristan Gingold]

On Apr 11, 2012, at 4:52 PM, Mike Stump wrote:

> On Apr 11, 2012, at 7:04 AM, Bernd Schmidt wrote:
>> On 04/11/2012 04:02 PM, Tristan Gingold wrote:
>>> 
>>> On Apr 11, 2012, at 3:55 PM, Bernd Schmidt wrote:
 I'm working on a target where intptr_t and pointers are larger than
 size_t and ptrdiff_t. The testsuite has problems in this area, since we
 often use the latter two types for casting from/to pointers, leading to
 unwanted warnings. In some cases I've checked the corresponding PRs and
 found that the original testcases used something like plain int or long.
>>> 
>>> Would this target be able to host gcc ?
>> 
>> I do not wish to think about this :) It's embedded, so hopefully no one
>> will try.
>> 
>> In principle, I'd think any target with enough memory can be made to
>> host gcc, with varying amounts of work.
> 
> I've hosted gcc on mine, mainly as a code generation correctness check...  
> It's nice having a simulator and enough address bits, you can just plop down 
> yet more memory and presto, everything just works.  The more annoying aspect 
> is having to wire up stat and readdir for sim.  Fork and exec, are more 
> trivial by comparison.  Some gcc ports might not have enough address bits, 
> that might be the only hard requirement that one cannot fudge.

VMS is an host/target where pointers (64 bits) can be larger than size_t and 
ptrdiff_t.
We can run gcc on it, but we also still have a very few patches to submit to 
achieve that!

Tristan.

Re: Compare precisions with precisions in fold-const

[Mike Stump]

On Apr 11, 2012, at 6:59 AM, Bernd Schmidt wrote:
> This is another problem I found working on a new target. In fold-const,
> when folding conversions, there are two instances where mode bitsizes
> are compared to type precisions. This fails to do the right thing if
> mode precision and bitsize differ (which I believe they currently don't
> on any target).

They do on mine...  In my genmodes patch, it would make it true on two existing 
gcc ports as I recall.

Re: [i386, patch, RFC] HLE support in GCC

[Kirill Yukhin]

Yet another iteration :)

>> > Do you really imply ACQUIRE/RELEASE with HLE_ACQUIRE/RELEASE now? I don't
Sorry, Andi. Added. So, at the moment you can do smth like
  __atomic_compare_exchange_n (p, &oldv, newv, 0,
__ATOMIC_HLE_ACQUIRE, __ATOMIC_ACQUIRE);
And will get __ATOMIC_ACQUIRE model as well for success model.

I've also reoved few defines (like __HLE__), made HLE defines
uncondtinioanl, extended autoconf to check if assembler can generate
HLE, added hook to make HLE acquire/release imply standard.
I am also made bits upper 16-th of memmodel enum to be target dependant.

ChangeLog entry:
2012-04-11  Kirill Yukhin  

* builtins.c (get_memmodel): Remove check of upper bound,
imply HLE to use standard ACQUIRE/RELEASE.
(expand_builtin_atomic_compare_exchange): Mask memmodel values.
* config/i386/cpuid.h (bit_HLE): New.
* config/i386/driver-i386.c (host_detect_local_cpu): Detect
HLE support.
* config/i386/i386-protos.h (ix86_generate_hle_prefix): New.
* config/i386/i386-c.c (ix86_target_macros_internal): Set
HLE defines.
(ix86_target_string)<-mhle>: New.
(ix86_option_override_internal): Ditto.
(ix86_valid_target_attribute_inner_p): Ditto.
* config/i386/i386.c (ix86_target_string):
New.
(ix86_valid_target_attribute_inner_p): Ditto.
(ix86_generate_hle_prefix): Ditto.
(ix86_extend_hle_macro): Ditto.
(TARGET_EXTEND_HLE_MACRO): Ditto.
* config/i386/i386.h (OPTION_ISA_HLE): Ditto.
(IX86_HLE_ACQUIRE): Ditto.
(IX86_HLE_RELEASE): Ditto.
* config/i386/i386.h (ix86_generate_hle_prefix): Ditto.
* config/i386/i386.opt (mhle): Ditto.
* config/i386/sync.md(atomic_compare_and_swap): Pass
success model to instruction emitter.
(atomic_compare_and_swap_single): Define and use argument
for success model.
(atomic_compare_and_swap_double): Ditto.
* doc/tm.texi.in (TARGET_EXTEND_HLE_MACRO): Describe.
* hooks.h (hook_uhwi_uhwi_unchange): Declare.
* hooks.c (hook_uhwi_uhwi_unchange): ... and define.
* target.def (extend_hle_macro): New hook.
* configure.ac: Check if assembler support HLE prefixies.
* configure: Regenerate.
* config.in: Ditto.

Patch attached.

Thanks, K


hle-rfc-4.gcc.patch
Description: Binary data

Re: jcf-reader: support for JSR 292 classfile extensions

[Rainer Orth]

Andrew Haley  writes:

> On 04/11/2012 01:43 PM, Richard Guenther wrote:
>> This breaks bootstrap for me:
>>
>> In file included from
>> /space/rguenther/src/svn/trunk/gcc/java/jcf-parse.c:1009:0:
>> /space/rguenther/src/svn/trunk/gcc/java/jcf-reader.c:550:1: error:
>> 'int jcf_parse_bootstrap_methods(JCF*, int)' defined but not used
>> [-Werror=unused-function]
>>  jcf_parse_bootstrap_methods (JCF* jcf, int attribute_length 
>> ATTRIBUTE_UNUSED)
>>  ^
>> cc1plus: all warnings being treated as errors
>> make[3]: *** [java/jcf-parse.o] Error 1
>> make[3]: *** Waiting for unfinished jobs
>>
>
> Sorry.

It also broke Java bootstrap on 32-bit targets:

/vol/gcc/src/hg/trunk/solaris/gcc/java/jcf-dump.c: In function 'void 
print_constant(std::FILE*, JCF*, int, int)':
/vol/gcc/src/hg/trunk/solaris/gcc/java/jcf-dump.c:929:64: error: format '%ld' 
expects argument of type 'long int', but argument 3 has type 'uint32 {aka 
unsigned int}' [-Werror=format]
  fprintf (out, "Fieldref: %ld=", JPOOL_USHORT2 (jcf, index));
^
/vol/gcc/src/hg/trunk/solaris/gcc/java/jcf-dump.c:936:65: error: format '%ld' 
expects argument of type 'long int', but argument 3 has type 'uint32 {aka 
unsigned int}' [-Werror=format]
  fprintf (out, "Methodref: %ld=", JPOOL_USHORT2 (jcf, index));
 ^
/vol/gcc/src/hg/trunk/solaris/gcc/java/jcf-dump.c:941:74: error: format '%ld' 
expects argument of type 'long int', but argument 3 has type 'uint32 {aka 
unsigned int}' [-Werror=format]
  fprintf (out, "InterfaceMethodref: %ld=", JPOOL_USHORT2 (jcf, index));
  ^
/vol/gcc/src/hg/trunk/solaris/gcc/java/jcf-dump.c:949:62: error: format '%ld' 
expects argument of type 'long int', but argument 3 has type 'uint32 {aka 
unsigned int}' [-Werror=format]
  fprintf (out, "MethodType %ld: ", JPOOL_USHORT1 (jcf, index));
  ^
/vol/gcc/src/hg/trunk/solaris/gcc/java/jcf-dump.c:957:68: error: format '%ld' 
expects argument of type 'long int', but argument 3 has type 'uint32 {aka 
unsigned int}' [-Werror=format]
  fprintf (out, "bootstrap_method: %ld ", JPOOL_USHORT1 (jcf, index));
^
The following patch got me into stage3 on i386-pc-solaris2.10 and
amd64-pc-solaris2.10.

Ok for mainline?

Rainer


2012-04-11  Rainer Orth  

* jcf-dump.c (print_constant): Cast JPOOL_USHORT2, JPOOL_USHORT1
results to long to match formats.

# HG changeset patch
# Parent 94918a528698bab552dc2f8be5c1666444afca67
Fix java bootstrap on 32-bit targets

diff --git a/gcc/java/jcf-dump.c b/gcc/java/jcf-dump.c
--- a/gcc/java/jcf-dump.c
+++ b/gcc/java/jcf-dump.c
@@ -926,19 +926,20 @@ print_constant (FILE *out, JCF *jcf, int
 	case 3:
 	case 4:
 	  if (verbosity > 0)
-	fprintf (out, "Fieldref: %ld=", JPOOL_USHORT2 (jcf, index));
+	fprintf (out, "Fieldref: %ld=", (long) JPOOL_USHORT2 (jcf, index));
 	  print_constant (out, jcf, JPOOL_USHORT2 (jcf, index), 0);
 	case 5:
 	case 6:
 	case 7:
 	case 8:
 	  if (verbosity > 0)
-	fprintf (out, "Methodref: %ld=", JPOOL_USHORT2 (jcf, index));
+	fprintf (out, "Methodref: %ld=", (long) JPOOL_USHORT2 (jcf, index));
 	  print_constant (out, jcf, JPOOL_USHORT2 (jcf, index), 0);
 	  break;
 	case 9:
 	  if (verbosity > 0)
-	fprintf (out, "InterfaceMethodref: %ld=", JPOOL_USHORT2 (jcf, index));
+	fprintf (out, "InterfaceMethodref: %ld=",
+		 (long) JPOOL_USHORT2 (jcf, index));
 	  print_constant (out, jcf, JPOOL_USHORT2 (jcf, index), 0);
 	  break;
 	}
@@ -946,7 +947,7 @@ print_constant (FILE *out, JCF *jcf, int
   }
 case CONSTANT_MethodType:
   if (verbosity > 0)
-	fprintf (out, "MethodType %ld: ", JPOOL_USHORT1 (jcf, index));
+	fprintf (out, "MethodType %ld: ", (long) JPOOL_USHORT1 (jcf, index));
   print_signature (out, jcf, JPOOL_USHORT1 (jcf, index), 0);
   break;
 case CONSTANT_InvokeDynamic:
@@ -954,7 +955,8 @@ print_constant (FILE *out, JCF *jcf, int
 	uint16 name_and_type = JPOOL_USHORT2 (jcf, index);
 	if (verbosity > 0)
 	  fprintf (out, "InvokeDynamic: ");
-	fprintf (out, "bootstrap_method: %ld ", JPOOL_USHORT1 (jcf, index));
+	fprintf (out, "bootstrap_method: %ld ",
+		 (long) JPOOL_USHORT1 (jcf, index));
 	if (verbosity == 2)
 	  fprintf (out, " name_and_type: %d=<", name_and_type);
 	print_constant_terse (out, jcf, name_and_type, CONSTANT_NameAndType);


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

Re: [i386, patch, RFC] HLE support in GCC

[Andi Kleen]

On Wed, Apr 11, 2012 at 07:52:59PM +0400, Kirill Yukhin wrote:
> Yet another iteration :)
> 
> >> > Do you really imply ACQUIRE/RELEASE with HLE_ACQUIRE/RELEASE now? I don't
> Sorry, Andi. Added. So, at the moment you can do smth like
>   __atomic_compare_exchange_n (p, &oldv, newv, 0,
> __ATOMIC_HLE_ACQUIRE, __ATOMIC_ACQUIRE);
> And will get __ATOMIC_ACQUIRE model as well for success model.
> 
> I've also reoved few defines (like __HLE__), made HLE defines
> uncondtinioanl, extended autoconf to check if assembler can generate
> HLE, added hook to make HLE acquire/release imply standard.
> I am also made bits upper 16-th of memmodel enum to be target dependant.

+static unsigned HOST_WIDE_INT
+ix86_extend_hle_macro (unsigned HOST_WIDE_INT memmodel)
+{
+  unsigned HOST_WIDE_INT result = memmodel;
+
+  if (memmodel & IX86_HLE_ACQUIRE)
+result |= MEMMODEL_ACQUIRE;
+
+  if (memmodel & IX86_HLE_RELEASE)
+result |= MEMMODEL_RELEASE;
+   
+  return result;
+}

This needs to check whether no existing model is already set
Multiple MEMMODEL_* do not or together.

Also I would not call the target hook "hle", it could be used
for other things too.

+mhle
+Target Report Mask(ISA_HLE) Var(ix86_isa_flags) Save
+Support Hardware Lock Elision prefixies

Typo

Also the new flags (plus the implied barrier semantics) 
need to be described in the manual too.

+  static char buf[128], hle[16];

The hle buffer does not need to be static.
BTW I'm surprised there is no better way to do this in machine descriptions
than to use static buffers.

Other than that it looks good to me. Thanks.

-Andi

Re: [i386, patch, RFC] HLE support in GCC

[Jakub Jelinek]

On Wed, Apr 11, 2012 at 06:06:58PM +0200, Andi Kleen wrote:
> +static unsigned HOST_WIDE_INT
> +ix86_extend_hle_macro (unsigned HOST_WIDE_INT memmodel)
> +{
> +  unsigned HOST_WIDE_INT result = memmodel;
> +
> +  if (memmodel & IX86_HLE_ACQUIRE)
> +result |= MEMMODEL_ACQUIRE;
> +
> +  if (memmodel & IX86_HLE_RELEASE)
> +result |= MEMMODEL_RELEASE;
> +   
> +  return result;
> +}

I actually think it is a bad idea to imply any memory model
from the HLE bits.  If anything, we should warn for memmodel
+ hle bit combinations that are unlikely to DTRT.
Let the developers really use the model they want.

Jakub

Re: [i386, patch, RFC] HLE support in GCC

[Andi Kleen]

> I actually think it is a bad idea to imply any memory model
> from the HLE bits.  If anything, we should warn for memmodel
> + hle bit combinations that are unlikely to DTRT.

This would be a warning with _RELAXED/_CONSUME, but there may be very 
obscure situations where someone really wants that (but then there
would be no way to get rid of the warning). So if you do that you would
need another flag to disable the warning.

The "default to ACQUIRE/RELEASE but allow override with no warning" model seems
more user friendly to me.

> Let the developers really use the model they want.

You assume they really want one :-)

-Andi

-- 
a...@linux.intel.com -- Speaking for myself only.

Re: [i386, patch, RFC] HLE support in GCC

[Jakub Jelinek]

On Wed, Apr 11, 2012 at 06:18:56PM +0200, Andi Kleen wrote:
> > I actually think it is a bad idea to imply any memory model
> > from the HLE bits.  If anything, we should warn for memmodel
> > + hle bit combinations that are unlikely to DTRT.
> 
> This would be a warning with _RELAXED/_CONSUME, but there may be very 
> obscure situations where someone really wants that (but then there
> would be no way to get rid of the warning). So if you do that you would
> need another flag to disable the warning.
> 
> The "default to ACQUIRE/RELEASE but allow override with no warning" model 
> seems
> more user friendly to me.

But such a model isn't possible.  The HLE bits are just some high bits
ored into the memory model enum.  So, if you use
__ATOMIC_HLE_ACQUIRE, it is the same thing as
__ATOMIC_HLE_ACQUIRE | __ATOMIC_RELAXED and thus it is a relaxed xacquire,
not xacquire with default memory model.
__atomic_* builtins were introduced already in GCC 4.7, so we need to do
a compatible extension...

Jakub

Re: [PATCH, i386, Android] -mandroid support for i386 target

[H.J. Lu]

On Tue, Apr 3, 2012 at 2:02 PM, Ilya Enkovich  wrote:
>> On Tue, Apr 3, 2012 at 3:49 AM, Ilya Enkovich  wrote:
 On 3/04/2012, at 2:16 AM, Ilya Enkovich wrote:

>>
>> The point is that one can build a toolchain for i686-linux-gnu that will 
>> support both 32-bit and 64-bit multilibs.  The 32-bit multilib will be 
>> used by default, and compilation for 64-bit user-space can be requested 
>> with -m64 option.  Even though Android is not supported for -m64, such a 
>> toolchain can support Android as a additional "-m32 -mandroid" multilib. 
>>  I.e., the toolchain will have three multilibs in total: "-m32" 
>> (default), "-m64" and "-m32 -mandroid".  I386/linux64.h will be picked 
>> up for such a toolchain, even though by default it would compile for 
>> 32-bit target.  Does this clear up things?
>>
>
> I think I see your point. And it seems to make all this work I'll also
> have to rename i386/gnu-user.h into i386/gnu-user32.h and create
> i386/gnu-user.h with common definitions to be included by
> gnu-user[32|64].h. Otherwise I wont be able to use some definitions
> (i.e. GNU_USER_TARGET_LINK_SPEC and GNU_USER_TARGET_MATHFILE_SPEC) in
> linux64.h. Right?

 It's simpler that you think.  The target headers ($tm_file in config.gcc 
 -- gnu-user.h, linux*.h, etc. in this case) are all included into tm.h, 
 which serves as proxy to all those headers.  All definitions made in 
 preceding headers are available in subsequent headers.  So, given that 
 i386/gnu-user*.h precedes i386/linux*.h in config.gcc's $tm_file, you only 
 need to touch linux*.h.

 Thanks,

 --
 Maxim Kuvyrkov
 CodeSourcery / Mentor Graphics

>>>
>>>
>>> Hi,
>>>
>>> I prepared version with common linux.h and gnu-user.h. Does it look OK?
>>>
>>> Bootstrapped and checked on linux-x86_64.
>>>
>>
>> There are so many duplicates in gnu-user64.h and gnu-user32.h.
>> Please move all of them to gnu-user.h.
>>
>> Thanks.
>>
>> --
>> H.J.
>
> Hi,
>
> Here is a new version with all gnu-user32.h and gnu-user64.h common
> definitions moved to gnu-user.h.
>
> Bootstrapped and checked on linux-x86_64.
>
> Thanks,
> Ilya
> ---
> 2012-04-04  Enkovich Ilya  
>
>        * config/i386/linux.h: Renamed to ...
>        * config/i386/linux32.h: ... this.
>
>        * config/i386/gnu-user.h: Renamed to ...
>        * config/i386/gnu-user32.h: ... this.
>        (CPP_SPEC): Removed.
>        (CC1_SPEC): Removed.
>        (ENDFILE_SPEC): Removed.
>        (DEFAULT_PCC_STRUCT_RETURN): Removed.
>        (TARGET_TLS_DIRECT_SEG_REFS_DEFAULT): Removed.
>        (TARGET_OS_CPP_BUILTINS): Removed.
>        (LIBGCC2_HAS_TF_MODE): Removed.
>        (LIBGCC2_TF_CEXT): Removed.
>        (TF_SIZE): Removed.
>        (TARGET_ASM_FILE_END): Removed.
>        (STACK_CHECK_MOVING_SP): Removed.
>        (STACK_CHECK_STATIC_BUILTIN): Removed.
>        (TARGET_THREAD_SSP_OFFSET): Removed.
>        (TARGET_CAN_SPLIT_STACK): Removed.
>        (TARGET_THREAD_SPLIT_STACK_OFFSET): Removed.
>        (GNU_USER_TARGET_LINK_SPEC): New.
>        (LINK_SPEC): Use GNU_USER_TARGET_LINK_SPEC.
>
>        * config.gcc: Rename i386/linux.h to i386/linux32.h and
>        i386/gnu-user.h to i386/gnu-user32.h.
>
>        * config/i386/linux.h: New.
>
>        * config/i386/gnu-user.h: New.
>
>        * config/i386/linux64.h: Include i386/linux.h.
>
>        * config/i386/gnu-user64.h: Include i386/gnu-user.h
>        (CPP_SPEC): Removed.
>        (CC1_SPEC): Removed.
>        (ENDFILE_SPEC): Removed.
>        (DEFAULT_PCC_STRUCT_RETURN): Removed.
>        (TARGET_TLS_DIRECT_SEG_REFS_DEFAULT): Removed.
>        (TARGET_OS_CPP_BUILTINS): Removed.
>        (LIBGCC2_HAS_TF_MODE): Removed.
>        (LIBGCC2_TF_CEXT): Removed.
>        (TF_SIZE): Removed.
>        (TARGET_ASM_FILE_END): Removed.
>        (STACK_CHECK_MOVING_SP): Removed.
>        (STACK_CHECK_STATIC_BUILTIN): Removed.
>        (TARGET_THREAD_SSP_OFFSET): Removed.
>        (TARGET_CAN_SPLIT_STACK): Removed.
>        (TARGET_THREAD_SPLIT_STACK_OFFSET): Removed.
>        (GNU_USER_TARGET_LINK_SPEC): New.
>        (LINK_SPEC): Use GNU_USER_TARGET_LINK_SPEC.

This is a big change.  Maybe it is better to break it into 2
parts:

1. Introduce gnu-user32.h only, which can be reviewed by x86 backend
maintainers.   Another possibility is to add gnu-user-common.h instead of
gnu-user32.h so that no changes to config.gcc are needed.
2. Add Android support, which can reviewed by Android maintainer.

Thanks.

-- 
H.J.

[cxx-conversion] Switch default to build in C++

[Diego Novillo]

This patch makes the branch to build in C++ mode by default.

Tested on x86_64.  Committed.


ChangeLog.cxx-conversion
* configure.ac (ENABLE_BUILD_WITH_CXX): Default to 'yes'.
* configure: Regenerate.

gcc/ChangeLog.cxx-conversion
* configure.ac (ENABLE_BUILD_WITH_CXX): Default to 'yes'.
* configure: Regenerate.

libcpp/ChangeLog.cxx-conversion
* configure.ac (ENABLE_BUILD_WITH_CXX): Default to 'yes'.
* configure: Regenerate.

Index: configure.ac
===
--- configure.ac(revision 186326)
+++ configure.ac(working copy)
@@ -1191,7 +1191,7 @@
 [AS_HELP_STRING([--enable-build-with-cxx],
[build with C++ compiler instead of C compiler])],
 ENABLE_BUILD_WITH_CXX=$enableval,
-ENABLE_BUILD_WITH_CXX=no)
+ENABLE_BUILD_WITH_CXX=yes)
 
 # Build stage1 with C and build stages 2 and 3 with C++.
 AC_ARG_ENABLE(build-poststage1-with-cxx,
Index: gcc/configure.ac
===
--- gcc/configure.ac(revision 186326)
+++ gcc/configure.ac(working copy)
@@ -608,7 +608,7 @@
 [AS_HELP_STRING([--enable-build-with-cxx],
[build with C++ compiler instead of C compiler])],
 ENABLE_BUILD_WITH_CXX=$enableval,
-ENABLE_BUILD_WITH_CXX=no)
+ENABLE_BUILD_WITH_CXX=yes)
 AC_SUBST(ENABLE_BUILD_WITH_CXX)
 if test "$ENABLE_BUILD_WITH_CXX" = "yes"; then
   AC_DEFINE(ENABLE_BUILD_WITH_CXX, 1,
Index: libcpp/configure.ac
===
--- libcpp/configure.ac (revision 186326)
+++ libcpp/configure.ac (working copy)
@@ -22,7 +22,7 @@
 AC_ARG_ENABLE(build-with-cxx,
 [  --enable-build-with-cxx build with C++ compiler instead of C compiler],
 ENABLE_BUILD_WITH_CXX=$enableval,
-ENABLE_BUILD_WITH_CXX=no)
+ENABLE_BUILD_WITH_CXX=yes)
 AC_SUBST(ENABLE_BUILD_WITH_CXX)
 
 MISSING=`cd $ac_aux_dir && ${PWDCMD-pwd}`/missing

Re: [i386, patch, RFC] HLE support in GCC

[Andi Kleen]

> But such a model isn't possible.  The HLE bits are just some high bits
> ored into the memory model enum.  So, if you use
> __ATOMIC_HLE_ACQUIRE, it is the same thing as
> __ATOMIC_HLE_ACQUIRE | __ATOMIC_RELAXED and thus it is a relaxed xacquire,
> not xacquire with default memory model.
> __atomic_* builtins were introduced already in GCC 4.7, so we need to do
> a compatible extension...

That's true. Actually I see the values are defined by the compiler
at compile time, so it would be possible to move all one up?

For compatibility just would need to make sure that 0 still means relaxed
without HLE.

-Andi

-- 
a...@linux.intel.com -- Speaking for myself only.

Re: [PATCH] Caret diagnostics

[H.J. Lu]

On Tue, Apr 10, 2012 at 1:33 PM, Manuel López-Ibáñez
 wrote:
> On 10 April 2012 21:41, Manuel López-Ibáñez  wrote:
>> On 10 April 2012 21:31, Jason Merrill  wrote:
>>> On 04/10/2012 12:46 PM, Manuel López-Ibáñez wrote:

 +  max_width = context->caret_max_width;
 +  if (max_width<= 0)
 +    max_width = INT_MAX;
>>>
>>>
>>> I don't think we need the test here; diagnostic_set_caret_max_width should
>>> make sure caret_max_width is set sensibly.  Otherwise, yes, thanks.
>>
>> It was just a bit of defensive programming, since nothing stops anyone
>> to set the value directly. But I will remove it.
>>
>>> On 04/10/2012 02:52 PM, Gabriel Dos Reis wrote:

 There is a novelty in this new version that I don't think we discussed
 before: automatic expansion of tabs to 8 hard space characters.  That
 number should not be hardcoded as there is no reason to believe a tab
 character always expands to 8 space characters.  You should check
 the environment first; if not present the default expansion number should
 be a symbolic constant as opposed to a magic number sprinkled all over the
 places.
>>>
>>>
>>> Hmm.  I don't know if there's any reliable way to query tab stops; the "it"
>>> termcap/terminfo capability tells you what it was originally (presumably 8),
>>> but it might have changed.
>>
>> No idea either, but it is in fact easier to print tabs a single
>> spaces. This simplifies the code a lot, as pointed by Gabriel. So if
>> you also prefer the simpler version, I am fine with committing that
>> one (it also saves space in the output).
>
> A new version of the patch. It removes the special handling of tabs.
> And abstracts out the adjusting of the line as Gabriel suggested. I am
> not sure what else could be abstracted out. The function is much
> shorter than other functions in diagnostic.c.
>
> This patch builds and I am running a full boostrap+check now.
>
> OK if it passes?
>
> Cheers,
>
> Manuel.
>
>
> 2012-04-05  Manuel López-Ibáñez  
>
>        PR 24985
> libstdc++-v3/
>        * testsuite/lib/prune.exp: Handle caret.
> libmudflap/
>        * testsuite/lib/libmudflap.exp: Handle caret.
> gcc/
>        * diagnostic.h (show_caret): Declare.
>        (caret_max_width): Declare.
>        (diagnostic_show_locus): Declare.
>        * diagnostic.c (diagnostic_initialize): Initialize to false.
>        (diagnostic_show_locus): New.
>        (diagnostic_report_diagnostic): Call it.
>        (getenv_columns): New.
>        (adjust_line): New.
>        (diagnostic_set_caret_max_width): New.
>        * input.c (read_line): New.
>        (location_get_source_line): New.
>        * input.h (location_get_source_line): Declare.
>        * toplev.c (general_init): Initialize show_caret from options.
>        * dwarf2out.c (gen_producer_string): Handle fdiagnostics-show-caret.
>        * opts.c (common_handle_option): Likewise.
>        * pretty-print.h (pp_get_prefix): New.
>        (pp_base_get_prefix): New.
>        * common.opt (fdiagnostics-show-caret): New option.
>        * doc/invoke.texi (fdiagnostics-show-caret): Document it.
> testsuite/
>        * lib/prune.exp: Add -fno-diagnostics-show-caret.

It breaks library tests:

ERROR: tcl error sourcing
../../../../src-trunk/boehm-gc/testsuite/../../gcc/testsuite/lib/prune.exp.
ERROR: tcl error sourcing
../../../../src-trunk/libgomp/testsuite/../../gcc/testsuite/lib/prune.exp.
ERROR: tcl error sourcing
../../../../src-trunk/libitm/testsuite/../../gcc/testsuite/lib/prune.exp.

RROR: tcl error sourcing
../../../../src-trunk/libitm/testsuite/../../gcc/testsuite/lib/prune.exp.
can't read "TEST_ALWAYS_FLAGS": no such variable
while executing
"set TEST_ALWAYS_FLAGS "-fno-diagnostics-show-caret $TEST_ALWAYS_FLAGS""
(file 
"../../../../src-trunk/libitm/testsuite/../../gcc/testsuite/lib/prune.exp"
line 20)
invoked from within
"source 
../../../../src-trunk/libitm/testsuite/../../gcc/testsuite/lib/prune.exp"
("uplevel" body line 1)
invoked from within
"uplevel #0 source
../../../../src-trunk/libitm/testsuite/../../gcc/testsuite/lib/prune.exp"
invoked from within
"catch "uplevel #0 source $file""
make[8]: *** [check-DEJAGNU] Error 1

-- 
H.J.

Re: jcf-reader: support for JSR 292 classfile extensions

[Andrew Haley]

On 04/11/2012 04:57 PM, Rainer Orth wrote:
> Ok for mainline?
> 
>   Rainer
> 
> 
> 2012-04-11  Rainer Orth  
> 
>   * jcf-dump.c (print_constant): Cast JPOOL_USHORT2, JPOOL_USHORT1
>   results to long to match formats.

Sure.  Sorry for the noise.

I wonder what we're supposed to do about warnings that only trigger
on 32-bit systems.  Just wait for reports, or do we really have to
boostrap with both?

Andrew.

PATCH: Check [SUB]SUBTARGET_OVERRIDE_OPTIONS after TARGET_64BIT

[H.J. Lu]

Hi,

SUBTARGET_OVERRIDE_OPTIONS and SUBSUBTARGET_OVERRIDE_OPTIONS may depend
on TARGET_64BIT.  This patch moves their handling after TARGET_64BIT
is updated.  Tested on Linux/x86-64. OK for trunk?

Thanks.


H.J.
---
2012-04-10  H.J. Lu  

* config/i386/i386.c (ix86_option_override_internal): Check
SUBTARGET_OVERRIDE_OPTIONS and SUBSUBTARGET_OVERRIDE_OPTIONS
after TARGET_64BIT is updated.

diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 8974ddc..af4af7c 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -3113,14 +3113,6 @@ ix86_option_override_internal (bool main_args_p)
   sw = "attribute";
 }
 
-#ifdef SUBTARGET_OVERRIDE_OPTIONS
-  SUBTARGET_OVERRIDE_OPTIONS;
-#endif
-
-#ifdef SUBSUBTARGET_OVERRIDE_OPTIONS
-  SUBSUBTARGET_OVERRIDE_OPTIONS;
-#endif
-
   /* Turn off both OPTION_MASK_ABI_64 and OPTION_MASK_ABI_X32 if
  TARGET_64BIT_DEFAULT is true and TARGET_64BIT is false.  */
   if (TARGET_64BIT_DEFAULT && !TARGET_64BIT)
@@ -3161,6 +3153,14 @@ ix86_option_override_internal (bool main_args_p)
   ix86_isa_flags &= ~OPTION_MASK_ABI_X32;
 }
 
+#ifdef SUBTARGET_OVERRIDE_OPTIONS
+  SUBTARGET_OVERRIDE_OPTIONS;
+#endif
+
+#ifdef SUBSUBTARGET_OVERRIDE_OPTIONS
+  SUBSUBTARGET_OVERRIDE_OPTIONS;
+#endif
+
   /* -fPIC is the default for x86_64.  */
   if (TARGET_MACHO && TARGET_64BIT)
 flag_pic = 2;

Re: [Patch, Fortran, F03] PR52909: Procedure pointers not private to modules

[Andrew Benson]

Hi Janus:

> I would surely appreciate some input from others, also from users (in
> particular from Andrew as the bug reporter). In general: Is ABI
> compatibility of different gfortran versions important to gfortran
> users? (For me personally, as a user, not so much. I usually don't
> link my own code with pre-compiled Fortran libraries).

Right now, ABI compatibility of gfortran versions isn't very important to me, 
for the following reasons:

* The main code I'm compiling with gfortran links against three libraries 
which all generate .mod files (HDF5, FGSL and FoX). I have to recompile those 
when the module format changes anyway, so recompiling if the ABI changes isn't 
a big problem.

* I don't link to any libraries that I haven't compiled myself, so if the ABI 
changes I can just recompile them. (Although I should say that this isn't 
really by choice - I'm compiling them myself because they either weren't 
available on some of the HPC systems I'm using, or else the installed versions 
were too old.)

* Since I'm using the development version of gfortran I'm expecting there to 
be changes, and I'm happy to see them if they are a result of new 
functionality being added of bugs being fixed.

However, I think the above reasons are quite specific to me, and might not be 
true for the majority of gfortran users. Also, I certainly agree with Tobias 
that ABI (and .mod) compatibility are very important in general - if 
compatibility can be maintained without stifling progress on implementation of 
new features and bug fixing then I'm all for it. My knowledge of compiler 
development is far too limited to judge how difficult maintaining ABI/.mod 
compatibility is in any specific situation though!

-Andrew

-- 

* Andrew Benson: http://www.tapir.caltech.edu/~abenson/contact.html

* Galacticus: http://sites.google.com/site/galacticusmodel

Re: RFC: PR rtl-optimization/52876: Sign extend 32 to 64bit then clear upper 32bits fails O1 or higher

[H.J. Lu]

On Wed, Apr 11, 2012 at 7:21 AM, Richard Sandiford
 wrote:
> "H.J. Lu"  writes:
>> Hi,
>>
>> CSE turns (reg:DI 64)
>>
>> (insn 6 3 7 2 (set (reg:DI 64)
>>         (sign_extend:DI (subreg/u:SI (reg/v/f:DI 63 [ addr ]) 0))) x.i:6 122
>> {*extendsidi2_rex64} (nil))
>>
>> into (reg/f:DI 64 [ addr ]).  But nonzero_bits1 in rtlanal.c has
>>
>> #if defined(POINTERS_EXTEND_UNSIGNED) && !defined(HAVE_ptr_extend)
>>       /* If pointers extend unsigned and this is a pointer in Pmode, say that
>>          all the bits above ptr_mode are known to be zero.  */
>>       /* As we do not know which address space the pointer is refering to,
>>          we can do this only if the target does not support different pointer
>>          or address modes depending on the address space.  */
>>       if (target_default_pointer_address_modes_p ()
>>           && POINTERS_EXTEND_UNSIGNED && GET_MODE (x) == Pmode
>>           && REG_POINTER (x))
>>         nonzero &= GET_MODE_MASK (ptr_mode);
>> #endif
>>
>> Setting REG_POINTER with incompatible pointer sign extension is wrong.
>> This patch adds a bool parameter to set_reg_attrs_from_value to
>> indicate if a register can be marked as a pointer.  Does it look OK?
>>
>> Thanks.
>>
>>
>> H.J.
>> ---
>> gcc/
>>
>> 2012-04-05  H.J. Lu  
>>
>>       PR rtl-optimization/52876
>>       * emit-rtl.c (set_reg_attrs_from_value): Add a bool parameter
>>       to indicate if a register can be a pointer.
>>       (gen_reg_rtx_and_attrs): Pass true to set_reg_attrs_from_value.
>>       (set_reg_attrs_for_parm): Likewise.
>>
>>       * emit-rtl.h (set_reg_attrs_from_value): Add a bool parameter.
>>
>>       * reginfo.c (reg_scan_mark_refs): Pass false to
>>       set_reg_attrs_from_value with incompatible pointer sign
>>       extension.
>
> Regardless of how it is currently used, I think gen_reg_rtx_and_attrs
> (another caller to set_reg_attrs_from_value) is supposed to be a fairly
> general function.  So rather than apply a fix specific to regscan,
> I think it would be cleaner to redefine set_reg_attrs_from_value as
> taking an arbitrary value.  The whole while loop:
>
>          while (GET_CODE (src) == SIGN_EXTEND
>                 || GET_CODE (src) == ZERO_EXTEND
>                 || GET_CODE (src) == TRUNCATE
>                 || (GET_CODE (src) == SUBREG && subreg_lowpart_p (src)))
>            src = XEXP (src, 0);
>
> would then move to set_reg_attrs_from_value, and the "can be pointer"
> thing hidden there.  The regscan code would just be:
>
>      if (REG_P (dest) && !REG_ATTRS (dest))
>        set_reg_attrs_from_value (dest, src);
>
> Richard

Here is the updated patch to change set_reg_attrs_from_value to
take arbitrary value and check incompatible pointer sign
extension.  OK for trunk if there are no regressions on Linux/x86-64?

Thanks.


-- 
H.J.
---
gcc/

2012-04-10  H.J. Lu  

PR rtl-optimization/52876
* emit-rtl.c (set_reg_attrs_from_value): Handle arbitrary value.
Don't call mark_reg_pointer for incompatible pointer sign
extension.

* reginfo.c (reg_scan_mark_refs): Call set_reg_attrs_from_value
directly.

gcc/testsuite

2012-04-10  H.J. Lu  

PR rtl-optimization/52876
* gcc.target/i386/pr52876.c: New.


gcc-pr52876-2.patch
Description: Binary data

Re: [PATCH] ARM: Use different linker path for hardfloat ABI

[Michael K. Edwards]

On Tue, Apr 10, 2012 at 8:15 PM, Mike Frysinger  wrote:
> On Tuesday 10 April 2012 12:46:49 Michael Edwards wrote:
>> That way I can grandfather in binaries with ABI-ignorant
>> hard-coded library paths, and still handle ISA variants.  The
>> "extranoise" might be "neon", or "ssse3"
>
> aren't ISA variants handled already by glibc ?  that's what the hwcaps stuff
> does -- you can put optimized versions in ISA-specific subdirs of the normal
> lib paths.  glibc will look for those first before falling back to the common
> libs.
> -mike

I stand corrected with regard to non-ABI-altering ISA variations --
except for the nightmare that is Bionic libc, which is out of scope
for the present discussion.  Googling reminds me that Ulrich covered
all this ground in his original document for Linaro (which appears to
have moved onto the Debian wiki as
http://wiki.debian.org/Multiarch/LibraryPathOverview).

So this really is about nothing but freezing the full ABI name (vs. a
two-character suffix) into the path to ld.so.  And, of course, the
implied commitment to resolve any residual ambiguities in the ABI
(__cxa_pure_virtual(), anyone?) and to prioritize spec conformance
over bug-for-bug compatibility
(https://bugs.launchpad.net/gcc-linaro/+bug/952565).  When you give
something a detailed name, people are more likely to assume that it
has a detailed spec, interchangeable among distros and over time.  For
better or for worse, perpetuating the /lib?? kludge doesn't give that
impression.

Cheers,
- Michael

Re: PATCH: Check [SUB]SUBTARGET_OVERRIDE_OPTIONS after TARGET_64BIT

[Uros Bizjak]

On Wed, Apr 11, 2012 at 7:00 PM, H.J. Lu  wrote:

> SUBTARGET_OVERRIDE_OPTIONS and SUBSUBTARGET_OVERRIDE_OPTIONS may depend
> on TARGET_64BIT.  This patch moves their handling after TARGET_64BIT
> is updated.  Tested on Linux/x86-64. OK for trunk?
>
> 2012-04-10  H.J. Lu  
>
>        * config/i386/i386.c (ix86_option_override_internal): Check
>        SUBTARGET_OVERRIDE_OPTIONS and SUBSUBTARGET_OVERRIDE_OPTIONS
>        after TARGET_64BIT is updated.

OK.

Thanks,
Uros.

C++ PATCH to c++/45088 (injected-class-name in dwarf output)

[Jason Merrill]

Dodji's final patch for 45088 fixed the GDB regression, but as Jakub 
recently pointed out to me, we still end up with redundant 
DW_TAG_pointer_types in some cases, with one for pointer-to-class and 
the other for pointer-to-injected-class-name.  We strip the 
injected-class-name in dwarf2out so that both pointers point to the same 
target type.  To avoid this, let's strip the injected-class-name earlier 
in the front end.


Of course, this is what Dodji first proposed to do for this issue, and I 
steered him wrong...


Tested x86_64-pc-linux-gnu, applying to trunk.

commit 9a2db2e62c441147007f520a3983f6bc12a7385f
Author: Jason Merrill 
Date:   Wed Apr 11 11:05:28 2012 -0400

	* decl.c (grokdeclarator): Strip the injected-class-name typedef
	if we are building a declaration or compound type.

diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index 8b22192..711ceef 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -8943,6 +8943,17 @@ grokdeclarator (const cp_declarator *declarator,
 error ("qualifiers are not allowed on declaration of %",
 	   ctor_return_type);
 
+  /* If we're using the injected-class-name to form a compound type or a
+ declaration, replace it with the underlying class so we don't get
+ redundant typedefs in the debug output.  But if we are returning the
+ type unchanged, leave it alone so that it's available to
+ maybe_get_template_decl_from_type_decl.  */
+  if (CLASS_TYPE_P (type)
+  && DECL_SELF_REFERENCE_P (TYPE_NAME (type))
+  && type == TREE_TYPE (TYPE_NAME (type))
+  && (declarator || type_quals))
+type = DECL_ORIGINAL_TYPE (TYPE_NAME (type));
+
   type_quals |= cp_type_quals (type);
   type = cp_build_qualified_type_real
 (type, type_quals, ((typedef_decl && !DECL_ARTIFICIAL (typedef_decl)
diff --git a/gcc/testsuite/g++.dg/debug/dwarf2/self-ref-1.C b/gcc/testsuite/g++.dg/debug/dwarf2/self-ref-1.C
index 81bcb27..06db9dc 100644
--- a/gcc/testsuite/g++.dg/debug/dwarf2/self-ref-1.C
+++ b/gcc/testsuite/g++.dg/debug/dwarf2/self-ref-1.C
@@ -5,7 +5,7 @@
 
 struct A
 {
-virtual ~A();
+virtual ~A(){}
 };
 
 struct B : public A
diff --git a/gcc/testsuite/g++.dg/debug/dwarf2/self-ref-2.C b/gcc/testsuite/g++.dg/debug/dwarf2/self-ref-2.C
index b1c5401..d5463c0 100644
--- a/gcc/testsuite/g++.dg/debug/dwarf2/self-ref-2.C
+++ b/gcc/testsuite/g++.dg/debug/dwarf2/self-ref-2.C
@@ -6,7 +6,7 @@
 template
 struct A
 {
-virtual ~A();
+virtual ~A(){}
 };
 
 struct B : public A

C++ PATCH for c++/52906 (ICE with attribute by itself)

[Jason Merrill]

We can't talk about the type if there is no type.

Tested x86_64-pc-linux-gnu, applying to trunk.
commit bc94f519583cdfc705c1bde750a06bbd42537193
Author: Jason Merrill 
Date:   Wed Apr 11 10:08:37 2012 -0400

	PR c++/52906
	* decl.c (check_tag_decl): Don't complain about attributes if we
	don't even have a type.

diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index e2f01d5..8b22192 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -4224,7 +4224,7 @@ check_tag_decl (cp_decl_specifier_seq *declspecs)
 error ("% cannot be used for type declarations");
 }
 
-  if (declspecs->attributes && warn_attributes)
+  if (declspecs->attributes && warn_attributes && declared_type)
 {
   location_t loc;
   if (!CLASS_TYPE_P (declared_type)
diff --git a/gcc/testsuite/g++.dg/ext/attrib45.C b/gcc/testsuite/g++.dg/ext/attrib45.C
new file mode 100644
index 000..0be1322
--- /dev/null
+++ b/gcc/testsuite/g++.dg/ext/attrib45.C
@@ -0,0 +1,3 @@
+// PR c++/52906
+
+__attribute__ ((__deprecated__)); // { dg-error "does not declare anything" }

Re: C++ PATCH for c++/52906 (ICE with attribute by itself)

[Jakub Jelinek]

On Wed, Apr 11, 2012 at 01:48:57PM -0400, Jason Merrill wrote:
> We can't talk about the type if there is no type.
> 
> Tested x86_64-pc-linux-gnu, applying to trunk.

Shouldn't this go to 4.7 too?

> commit bc94f519583cdfc705c1bde750a06bbd42537193
> Author: Jason Merrill 
> Date:   Wed Apr 11 10:08:37 2012 -0400
> 
>   PR c++/52906
>   * decl.c (check_tag_decl): Don't complain about attributes if we
>   don't even have a type.
> 
> diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
> index e2f01d5..8b22192 100644
> --- a/gcc/cp/decl.c
> +++ b/gcc/cp/decl.c
> @@ -4224,7 +4224,7 @@ check_tag_decl (cp_decl_specifier_seq *declspecs)
>  error ("% cannot be used for type declarations");
>  }
>  
> -  if (declspecs->attributes && warn_attributes)
> +  if (declspecs->attributes && warn_attributes && declared_type)
>  {
>location_t loc;
>if (!CLASS_TYPE_P (declared_type)
> diff --git a/gcc/testsuite/g++.dg/ext/attrib45.C 
> b/gcc/testsuite/g++.dg/ext/attrib45.C
> new file mode 100644
> index 000..0be1322
> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/ext/attrib45.C
> @@ -0,0 +1,3 @@
> +// PR c++/52906
> +
> +__attribute__ ((__deprecated__)); // { dg-error "does not declare anything" }


Jakub

Re: Setting precision for a PSImode type

[Bernd Schmidt]

On 04/11/2012 07:31 PM, Peter Bigot wrote:
> The biggest one is that widening from 20-bit to 32-bit is an extremely
> expensive operation: it was a 16-bit ISA, but some newer MCUs support
> an extension with 20 bits in each register and a set of new
> instructions that must be used to preserve the upper 4 bits.  Getting
> bits 19..16 of a 20-bit register down into the low bits of a 16 bit
> register requires a five-position rotate-through-carry.  The 20-bit
> enhancement to the ISA was really intended only to support a larger
> address space; to simplify validation of the machine description I've
> chosen to allow it to be used for any integer operation, but I have no
> reason to think that'll be common.

Ok. So these are pointer modes, essentially? For the target I'm working
on, I'm using the following patch, see if that helps you any. It seems
to apply to trunk, so I might as well ask for an OK if it bootstraps and
tests ok (but it has little use while these ports remain out-of-tree).


Bernd
* mode-classes.def (MODE_POINTER): New.
* machmode.h (POINTER_MODE_P): New macro.
* genopinit.c (gen_insn): Allow MODE_POINTER for some modifiers.
* expr.c (convert_move): Handle MODE_POINTER like MODE_PARTIAL_INT.
* recog.c (general_operand, immediate_operand): Allow MODE_POINTER.
* stor-layout.c (int_mode_for_mode): Likwise.
* genmodes.c (complete_mode): Likewise.
(POINTER_MODE): New macro.
(make_pointer_mode): New static function.
* emit-rtl.c (immed_double_const): Allow MODE_POINTER.
* simplify-rtx.c (simplify_immed_subreg): Likewise.
* explow.c (trunc_int_for_mode): Likewise.

Index: gcc/machmode.h
===
--- gcc/machmode.h  (revision 365245)
+++ gcc/machmode.h  (working copy)
@@ -76,6 +76,9 @@ extern const unsigned char mode_class[NU
   (GET_MODE_CLASS (MODE) == MODE_INT   \
|| GET_MODE_CLASS (MODE) == MODE_PARTIAL_INT)
 
+/* True if MODE is a pointer mode.  */
+#define POINTER_MODE_P(MODE) (GET_MODE_CLASS (MODE) == MODE_POINTER)
+
 /* Nonzero if MODE is a scalar floating point mode.  */
 #define SCALAR_FLOAT_MODE_P(MODE)  \
   (GET_MODE_CLASS (MODE) == MODE_FLOAT \
Index: gcc/genopinit.c
===
--- gcc/genopinit.c (revision 365109)
+++ gcc/genopinit.c (working copy)
@@ -368,11 +368,13 @@ gen_insn (rtx insn)
 
if (*p == 0
&& (! force_int || mode_class[i] == MODE_INT
-   || mode_class[i] == MODE_VECTOR_INT)
+   || mode_class[i] == MODE_VECTOR_INT
+   || mode_class[i] == MODE_POINTER)
&& (! force_partial_int
 || mode_class[i] == MODE_INT
 || mode_class[i] == MODE_PARTIAL_INT
-   || mode_class[i] == MODE_VECTOR_INT)
+   || mode_class[i] == MODE_VECTOR_INT
+   || mode_class[i] == MODE_POINTER)
&& (! force_float
|| mode_class[i] == MODE_FLOAT
|| mode_class[i] == MODE_DECIMAL_FLOAT
Index: gcc/mode-classes.def
===
--- gcc/mode-classes.def(revision 365109)
+++ gcc/mode-classes.def(working copy)
@@ -23,6 +23,7 @@ along with GCC; see the file COPYING3.
   DEF_MODE_CLASS (MODE_CC),/* condition code in a register */ \
   DEF_MODE_CLASS (MODE_INT),   /* integer */  \
   DEF_MODE_CLASS (MODE_PARTIAL_INT),   /* integer with padding bits */\
+  DEF_MODE_CLASS (MODE_POINTER),   /* pointer */  \
   DEF_MODE_CLASS (MODE_FRACT), /* signed fractional number */ \
   DEF_MODE_CLASS (MODE_UFRACT),/* unsigned fractional number 
*/   \
   DEF_MODE_CLASS (MODE_ACCUM), /* signed accumulator */   \
Index: gcc/expr.c
===
--- gcc/expr.c  (revision 365245)
+++ gcc/expr.c  (working copy)
@@ -481,7 +481,8 @@ convert_move (rtx to, rtx from, int unsi
   /* Handle pointer conversion.  *//* SPEE 900220.  */
   /* Targets are expected to provide conversion insns between PxImode and
  xImode for all MODE_PARTIAL_INT modes they use, but no others.  */
-  if (GET_MODE_CLASS (to_mode) == MODE_PARTIAL_INT)
+  if (GET_MODE_CLASS (to_mode) == MODE_PARTIAL_INT
+  || GET_MODE_CLASS (to_mode) == MODE_POINTER)
 {
   enum machine_mode full_mode
= smallest_mode_for_size (GET_MODE_BITSIZE (to_mode), MODE_INT);
@@ -495,7 +496,8 @@ convert_move (rtx to, rtx from, int unsi
  to, from, UNKNOWN);
   return;
 }
-  if (GET_MODE_CLASS (from_mode)

Re: [PATCH] Caret diagnostics

[Manuel López-Ibáñez]

In 11 April 2012 18:40, H.J. Lu  wrote:
>
> It breaks library tests:
>
> ERROR: tcl error sourcing
> ../../../../src-trunk/boehm-gc/testsuite/../../gcc/testsuite/lib/prune.exp.
> ERROR: tcl error sourcing
> ../../../../src-trunk/libgomp/testsuite/../../gcc/testsuite/lib/prune.exp.
> ERROR: tcl error sourcing
> ../../../../src-trunk/libitm/testsuite/../../gcc/testsuite/lib/prune.exp.
>
> RROR: tcl error sourcing
> ../../../../src-trunk/libitm/testsuite/../../gcc/testsuite/lib/prune.exp.
> can't read "TEST_ALWAYS_FLAGS": no such variable
>    while executing
> "set TEST_ALWAYS_FLAGS "-fno-diagnostics-show-caret $TEST_ALWAYS_FLAGS""
>    (file 
> "../../../../src-trunk/libitm/testsuite/../../gcc/testsuite/lib/prune.exp"
> line 20)
>    invoked from within
> "source 
> ../../../../src-trunk/libitm/testsuite/../../gcc/testsuite/lib/prune.exp"
>    ("uplevel" body line 1)
>    invoked from within
> "uplevel #0 source
> ../../../../src-trunk/libitm/testsuite/../../gcc/testsuite/lib/prune.exp"
>    invoked from within
> "catch "uplevel #0 source $file""
> make[8]: *** [check-DEJAGNU] Error 1

contrib/compare_tests does not seem to detect this :-(

So how can I say in tcl "if not defined VAR then set VAR ""?

Cheers,

Manuel.

Re: [PATCH] Caret diagnostics

[Andrew Pinski]

On Wed, Apr 11, 2012 at 11:15 AM, Manuel López-Ibáñez
 wrote:
> So how can I say in tcl "if not defined VAR then set VAR ""?

if ![info exists VAR] {
  set VAR XXX
}

Thanks,
Andrew Pinski

Re: [i386, patch, RFC] HLE support in GCC

[Jakub Jelinek]

On Wed, Apr 11, 2012 at 06:40:03PM +0200, Andi Kleen wrote:
> > But such a model isn't possible.  The HLE bits are just some high bits
> > ored into the memory model enum.  So, if you use
> > __ATOMIC_HLE_ACQUIRE, it is the same thing as
> > __ATOMIC_HLE_ACQUIRE | __ATOMIC_RELAXED and thus it is a relaxed xacquire,
> > not xacquire with default memory model.
> > __atomic_* builtins were introduced already in GCC 4.7, so we need to do
> > a compatible extension...
> 
> That's true. Actually I see the values are defined by the compiler
> at compile time, so it would be possible to move all one up?

No, that is IMHO not possible.  They need to match the enum values that are
part of libstdc++ ABI already, and not everybody is going to use the
__ATOMIC_* macros anyway.

Jakub