*ping* Re: [PATCH, PR preprocessor/42014] Added LAST_SOURCE_COLUMN in while loop

[Shakthi Kannan]

Hi,

Is the following patch okay for trunk?

SK

- Original Message -
From: "Shakthi Kannan" 
To: gcc-patches@gcc.gnu.org
Sent: Friday, May 10, 2013 12:25:07 PM
Subject: [PATCH, PR preprocessor/42014] Added LAST_SOURCE_COLUMN in while loop

Hi,

The attached patch adds LAST_SOURCE_COLUMN to pp_verbatim
function in the while loop present in
diagnostic_report_current_module(). This makes the output
consistent for any error parsing program as stated in the bug.

2013-05-10 Shakthi Kannan 

PR preprocessor/42014
* gcc/diagnostic.c: Added LAST_SOURCE_COLUMN in while loop.

---
 gcc/diagnostic.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/gcc/diagnostic.c b/gcc/diagnostic.c
index f9a236b..2addbf0 100644
--- a/gcc/diagnostic.c
+++ b/gcc/diagnostic.c
@@ -528,8 +528,9 @@ diagnostic_report_current_module (diagnostic_context 
*context, location_t where)
{
  map = INCLUDED_FROM (line_table, map);
  pp_verbatim (context->printer,
-  ",\n from %s:%d",
-  LINEMAP_FILE (map), LAST_SOURCE_LINE (map));
+  ",\n from %s:%d:%d",
+  LINEMAP_FILE (map),
+  LAST_SOURCE_LINE (map), LAST_SOURCE_COLUMN (map));
}
  pp_verbatim (context->printer, ":");
  pp_newline (context->printer);
-- 
1.7.11.7

-- 
Shakthi Kannan 
skannan at redhat dot com

Re: [patch, mips] Patch for mips generic scheduler

[Richard Sandiford]

Steve Ellcey  writes:
>> It might be worth having a new "generic" scheduler that's supposed to be
>> a good compromise for modern cores though.  Or, more simply, we could just
>> change:
>> 
>> MIPS_CPU ("mips32", PROCESSOR_4KC, 32, PTF_AVOID_BRANCHLIKELY)
>> MIPS_CPU ("mips32r2", PROCESSOR_M4K, 33, PTF_AVOID_BRANCHLIKELY)
>> MIPS_CPU ("mips64", PROCESSOR_5KC, 64, PTF_AVOID_BRANCHLIKELY)
>> /* ??? For now just tune the generic MIPS64r2 for 5KC as well.   */
>> MIPS_CPU ("mips64r2", PROCESSOR_5KC, 65, PTF_AVOID_BRANCHLIKELY)
>> 
>> to tune for other processors instead, if you don't think 4kc, etc. are
>> representative enough.
>
> Hm, I think the problem may be that mips32r2 defaults to PROCESSOR_M4K
> and mips32 defaults to PROCESSOR_4KC.  I don't see any special scheduler
> for m4k.  Is there supposed to be a scheduler for m4k?

Oops -- only if someone submitted one :-)  So we should definitely
change the mips32r2 entry.  I'd suggest one of PROCESSOR_24KF* or
PROCESSOR_74KF*, so that we get the FPU scheduling, but I don't know
which would be more representative of the general case.  TUNE_74*
has quite a lot of special code associated with it, whereas TUNE_24*
sets TUNE_MACC_CHAINS, which might overemphasise the use of MADD
for 74k targets when -mimadd is used.

But any choice is going to be a compromise.  A patch to do either
is preapproved.

Thanks,
Richard

*ping* Re: [PATCH, wwwdocs] Fix PR 50642

[Shakthi Kannan]

Hi,

Is the following patch okay for trunk?

SK

- Original Message -
From: "Shakthi Kannan" 
To: "Joseph S. Myers" 
Cc: gcc-patches@gcc.gnu.org
Sent: Monday, May 6, 2013 4:00:06 PM
Subject: Re: [PATCH, wwwdocs] Fix PR 50642

Hi,

I am re-submitting the patch to use html.css from the update_web_docs_svn 
script present in the maintainer-scripts folder. The smallexample attributes 
are defined to use a medium font size with a light blue background for 
readability and clarity.

2013-05-06 Shakthi Kannan 

PR wwwdocs/50642
* maintainer-scripts/update_web_docs_svn: Use --css-include with makeinfo.
* gcc/doc/include/html.css: New CSS file for HTML docs.

---
 gcc/doc/include/html.css   | 6 ++
 maintainer-scripts/update_web_docs_svn | 4 +++-
 2 files changed, 9 insertions(+), 1 deletion(-)
 create mode 100644 gcc/doc/include/html.css

diff --git a/gcc/doc/include/html.css b/gcc/doc/include/html.css
new file mode 100644
index 000..6cc0284
--- /dev/null
+++ b/gcc/doc/include/html.css
@@ -0,0 +1,6 @@
+pre.smallexample { 
+font-family: sans-serif; 
+font-size: medium; 
+padding: 4px; 
+background: #f2f2f9 
+}
\ No newline at end of file
diff --git a/maintainer-scripts/update_web_docs_svn 
b/maintainer-scripts/update_web_docs_svn
index cfc33c4..2cea078 100755
--- a/maintainer-scripts/update_web_docs_svn
+++ b/maintainer-scripts/update_web_docs_svn
@@ -36,6 +36,8 @@ WWWBASE=/www/gcc/htdocs
 WWWBASE_PREFORMATTED=/www/gcc/htdocs-preformatted
 WWWPREPROCESS='/www/gcc/bin/preprocess -r'
 
+HTMLCSS=gcc/doc/include/html.css
+
 # Process options -rrelease and -ddirectory
 RELEASE=""
 SUBDIR=""
@@ -164,7 +166,7 @@ for file in $MANUALS; do
 if [ "$file" = "gnat_ugn_unw" ]; then
   includes="$includes -I gcc/gcc/ada"
 fi
-makeinfo --html $includes -o ${file} ${filename}
+makeinfo --css-include=../$HTMLCSS --html $includes -o ${file} ${filename}
 tar cf ${file}-html.tar ${file}/*.html
 texi2dvi $includes -o ${file}.dvi ${filename} /dev/null && 
dvips -o ${file}.ps ${file}.dvi
 texi2pdf $includes -o ${file}.pdf ${filename} 

Re: [PING]RE: [patch] cilkplus: Array notation for C patch

[Jakub Jelinek]

On Tue, May 21, 2013 at 07:57:10PM -0700, Richard Henderson wrote:
> >+  /* This will create the if statement label.  */
> >+  if_stmt_label[ii] = build_decl (location, LABEL_DECL, NULL_TREE,
> >+ void_type_node);
> >+  DECL_CONTEXT (if_stmt_label[ii]) = current_function_decl;
> >+  DECL_ARTIFICIAL (if_stmt_label[ii]) = 0;
> >+  DECL_IGNORED_P (if_stmt_label[ii]) = 1;
> >+
> >+  /* This label statement will point to the loop body.  */
> >+  body_label[ii] = build_decl (location, LABEL_DECL, NULL_TREE,
> >+  void_type_node);
> >+  DECL_CONTEXT (body_label[ii]) = current_function_decl;
> >+  DECL_ARTIFICIAL (body_label[ii]) = 0;
> >+  DECL_IGNORED_P (body_label[ii]) = 1;
> >+  body_label_expr[ii] = build1 (LABEL_EXPR, void_type_node, 
> >body_label[ii])
> >;
> >+
> >+  /* This will create the exit label, i.e. where the while loop will 
> >branch
> >+out of.  */
> >+  exit_label[ii] = build_decl (location, LABEL_DECL, NULL_TREE,
> >+  void_type_node);
> >+  DECL_CONTEXT (exit_label[ii]) = current_function_decl;
> >+  DECL_ARTIFICIAL (exit_label[ii]) = 0;
> >+  DECL_IGNORED_P (exit_label[ii]) = 1;
> >+  exit_label_expr[ii] = build1 (LABEL_EXPR, void_type_node, 
> >exit_label[ii]);
> >+}
> 
> Is there any particular reason why you're open-coding the loop
> expansion instead of using existing infrastructure like
> c_finish_loop?
> 
> Yes, the specific example of c_finish_loop goes against the c++
> sharing, but it's fairly easy to add new interfaces to c-common.h
> that are implemented in the two front ends.

Furthermore, do you want to generate just normal loop out of it, or
shouldn't we generate a #pragma omp simd loop out of it instead?
Haven't read the spec if array notation guarantees lack of forward/backward
loop dependencies and what are the restrictions on the calls you can do
inside of array notation.  Perhaps the lowering to normal vs. simd loop
could depend on whether all called functions in the expression are
elemental.

Jakub

Re: Fix PR 53743 and other -freorder-blocks-and-partition failures

[Teresa Johnson]

On Mon, May 20, 2013 at 3:42 PM, Steven Bosscher  wrote:
> On Mon, May 20, 2013 at 4:55 AM, Teresa Johnson wrote:
>
>> * ifcvt.c (find_if_case_1): Replace BB_COPY_PARTITION with assert
>> as this is now done by redirect_edge_and_branch_force.
>> * function.c (thread_prologue_and_epilogue_insns): Insert new bb 
>> after
>> barriers, and fix interaction with splitting.
>> * emit-rtl.c (try_split): Copy REG_CROSSING_JUMP notes.
>> * cfgcleanup.c (try_forward_edges): Fix early return value to 
>> properly
>> reflect changes made in the routine.
>> * bb-reorder.c (emit_barrier_after_bb): Handle insertion in
>> non-cfglayout mode.
>> (fix_up_fall_thru_edges): Remove incorrect check for bb layout order
>> since this is called in cfglayout mode, and replace partition fixup
>> with assert as that is now done by force_nonfallthru_and_redirect.
>> (add_reg_crossing_jump_notes): Handle the fact that some jumps may
>> already be marked with region crossing note.
>> (insert_section_boundary_note): Make non-static, gate on flag
>> has_bb_partition, rewrite to also check for multiple partitions.
>> (rest_of_handle_reorder_blocks): Remove call to
>> insert_section_boundary_note, now done later during free_cfg.
>> * bb-reorder.h: Declare insert_section_boundary_note and
>> emit_barrier_after_bb, which are no longer static.
>> * Makefile.in (cfgrtl.o): Depend on bb-reorder.h
>> * cfgrtl.c (rest_of_pass_free_cfg): If partitions exist
>> invoke insert_section_boundary_note.
>> (try_redirect_by_replacing_jump): Remove unnecessary
>> check for region crossing note.
>> (fixup_partition_crossing): New function.
>> (rtl_redirect_edge_and_branch): Fixup partition boundaries.
>> (force_nonfallthru_and_redirect): Fixup partition boundaries,
>> remove old code that tried to do this. Emit barrier correctly
>> when we are in cfglayout mode.
>> (rtl_split_edge): Correctly fixup partition boundaries.
>> (commit_one_edge_insertion): Remove old code that tried to
>> fixup region crossing edge since this is now handled in
>> split_block, and set up insertion point correctly since
>> block may now end in a jump.
>> (rtl_verify_edges): Add checks for incorrect/missing 
>> REG_CROSSING_JUMP
>> notes.
>> (fixup_reorder_chain): Remove old code that attempted to fixup region
>> crossing note as this is now handled in 
>> force_nonfallthru_and_redirect.
>> (duplicate_insn_chain): Don't duplicate switch section notes.
>> (rtl_can_remove_branch_p): Remove unnecessary check for region 
>> crossing
>> note.
>>
>> Index: ifcvt.c
>> ===
>> --- ifcvt.c (revision 199014)
>> +++ ifcvt.c (working copy)
>> @@ -3905,10 +3905,9 @@ find_if_case_1 (basic_block test_bb, edge then_edg
>>if (new_bb)
>>  {
>>df_bb_replace (then_bb_index, new_bb);
>> -  /* Since the fallthru edge was redirected from test_bb to new_bb,
>> - we need to ensure that new_bb is in the same partition as
>> - test bb (you can not fall through across section boundaries).  */
>> -  BB_COPY_PARTITION (new_bb, test_bb);
>> +  /* This should have been done above via force_nonfallthru_and_redirect
>> + (possibly called from redirect_edge_and_branch_force).  */
>> +  gcc_assert (BB_PARTITION (new_bb) == BB_PARTITION (test_bb));
>>  }
>
> Nit: gcc_checking_assert() ?

ok.

>
>
>> Index: function.c
>> ===
>> --- function.c  (revision 199014)
>> +++ function.c  (working copy)
>> @@ -6270,8 +6270,10 @@ thread_prologue_and_epilogue_insns (void)
>> break;
>> if (e)
>>   {
>> -   copy_bb = create_basic_block (NEXT_INSN (BB_END 
>> (e->src)),
>> - NULL_RTX, e->src);
>> +/* Make sure we insert after any barriers.  */
>> +rtx end = get_last_bb_insn (e->src);
>> +copy_bb = create_basic_block (NEXT_INSN (end),
>> +  NULL_RTX, e->src);
>> BB_COPY_PARTITION (copy_bb, e->src);
>>   }
>> else
>
> This is a nice catch. The change at first glance looks unrelated to
> the profiling fixes, but apparently you have a test case where e is
> not an EDGE_FALLTHRU edge? Otherwise there can't be a barrier. The
> change looks OK to me.

Yes, according to my notes this fix was from a case in hmmer where the
edge was a crossing edge.

>
>
>> Index: bb-reorder.c
>> ===
>> ---

Re: [PATCH, rs6000] power8 patches, patch #2, add crypto builtins

[David Edelsohn]

On Mon, May 20, 2013 at 7:13 PM, Michael Meissner
 wrote:
> This patch adds the builtins for the new ISA 2.07 crypto instructions.  It
> bootstraps and causes no regressions, is it ok to install after patch #1 has
> been applied?
>
> [gcc]
> 2013-05-20  Michael Meissner  
>
> * doc/extend.texi (PowerPC AltiVec/VSX Built-in Functions): Add
> documentation for the power8 crypto builtins.
>
> * config/rs6000/t-rs6000 (MD_INCLUDES): Add crypto.md.
>
> * config/rs6000/rs6000-builtin.def (BU_P8V_AV_1): Add support
> macros for defining power8 builtin functions.
> (BU_P8V_AV_2): Likewise.
> (BU_P8V_AV_P): Likewise.
> (BU_P8V_VSX_1): Likewise.
> (BU_P8V_OVERLOAD_1): Likewise.
> (BU_P8V_OVERLOAD_2): Likewise.
> (BU_CRYPTO_1): Likewise.
> (BU_CRYPTO_2): Likewise.
> (BU_CRYPTO_3): Likewise.
> (BU_CRYPTO_OVERLOAD_1): Likewise.
> (BU_CRYPTO_OVERLOAD_2): Likewise.
> (XSCVSPDP): Fix typo, point to the correct instruction.
> (VCIPHER): Add power8 crypto builtins.
> (VCIPHERLAST): Likewise.
> (VNCIPHER): Likewise.
> (VNCIPHERLAST): Likewise.
> (VPMSUMB): Likewise.
> (VPMSUMH): Likewise.
> (VPMSUMW): Likewise.
> (VPERMXOR_V2DI): Likewise.
> (VPERMXOR_V4SI: Likewise.
> (VPERMXOR_V8HI: Likewise.
> (VPERMXOR_V16QI: Likewise.
> (VSHASIGMAW): Likewise.
> (VSHASIGMAD): Likewise.
> (VPMSUM): Likewise.
> (VPERMXOR): Likewise.
> (VSHASIGMA): Likewise.
>
> * config/rs6000/rs6000-c.c (rs6000_target_modify_macros): Define
> __CRYPTO__ if the crypto instructions are available.
> (altivec_overloaded_builtins): Add support for overloaded power8
> builtins.
>
> * config/rs6000/rs6000.c (rs6000_expand_ternop_builtin): Add
> support for power8 crypto builtins.
> (builtin_function_type): Likewise.
> (altivec_init_builtins): Add support for builtins that take vector
> long long (V2DI) arguments.
>
> * config/rs6000/crypto.md: New file, define power8 crypto
> instructions.
>
> [gcc/testsuite]
> 2013-05-20  Michael Meissner  
>
> * gcc.target/powerpc/crypto-builtin-1.c: New file, test for power8
> crypto builtins.

Patch #2 is okay.

Thanks, David

Re: [PATCH, rs6000] power8 patch #1, infrastructure changes (revised patch)

[David Edelsohn]

On Mon, May 20, 2013 at 5:34 PM, Michael Meissner
 wrote:
> After submitting the patch, I realized I had submitted a previous version of
> the patch, that had the wq constraint that was initially for the quad memory
> operations, and also had the changes for ChangeLog.ibm, that I keep on the
> branch.  However, the wq constraint was always equal to the r constraint, do I
> have removed it, and used the 'r' constraint once again.
>
> I have also done bootstraps and make check with the patches submitted, with no
> regressions found.  Can I check in the revised patch?

Patch #1 is okay.

Thanks, David

Re: [C++ Patch] PR 57211

[Jason Merrill]

OK.

Jason

Re: [patch, powerpc] increase array alignment for Altivec

[David Edelsohn]

On Tue, May 21, 2013 at 10:16 PM, Bill Schmidt
 wrote:

> I can take a look at this tomorrow.  I think I should probably commit
> the other pending patch I have first.  There was some discussion on my
> patch whether it was the right approach, but given the behavior of
> existing allocators I think it's still the right way to handle it for
> now.  David, do you agree?

The concern about the malloc patch was whether one could assert the
alignment for malloc on all PPC systems or whether it should be
limited to GNU/Linux and AIX.

It seems that any system that supports VMX, VSX or even SPE should
have the correct malloc alignment.

Thanks, David

Re: [PING]RE: [patch] cilkplus: Array notation for C patch

[Richard Henderson]

Let me start by saying that I think the patch is generally ok, especially 
considering the advice that's already been given.  That said...



+++ b/gcc/c/c-array-notation.c
@@ -0,0 +1,3121 @@


So, like, are we going to need to replicate 3000 lines to add array notation to 
c++ too?  How much of this are we going to be able to share?


While I don't think we should make the array notation global, we might be able 
to share the code via c-family/.  The Ideal way I think would be via 
c-gimplify, in which we don't expand the array notation until later.  But even 
if delaying the expansion causes other problems that I havn't thought about, 
just placing the common expansion logic in the shared directory would be better.



+  for (ii = 0; ii < rank ; ii++)
+{
+  /* This will create the if statement label.  */
+  if_stmt_label[ii] = build_decl (location, LABEL_DECL, NULL_TREE,
+ void_type_node);
+  DECL_CONTEXT (if_stmt_label[ii]) = current_function_decl;
+  DECL_ARTIFICIAL (if_stmt_label[ii]) = 0;
+  DECL_IGNORED_P (if_stmt_label[ii]) = 1;
+
+  /* This label statement will point to the loop body.  */
+  body_label[ii] = build_decl (location, LABEL_DECL, NULL_TREE,
+  void_type_node);
+  DECL_CONTEXT (body_label[ii]) = current_function_decl;
+  DECL_ARTIFICIAL (body_label[ii]) = 0;
+  DECL_IGNORED_P (body_label[ii]) = 1;
+  body_label_expr[ii] = build1 (LABEL_EXPR, void_type_node, body_label[ii])
;
+
+  /* This will create the exit label, i.e. where the while loop will branch
+out of.  */
+  exit_label[ii] = build_decl (location, LABEL_DECL, NULL_TREE,
+  void_type_node);
+  DECL_CONTEXT (exit_label[ii]) = current_function_decl;
+  DECL_ARTIFICIAL (exit_label[ii]) = 0;
+  DECL_IGNORED_P (exit_label[ii]) = 1;
+  exit_label_expr[ii] = build1 (LABEL_EXPR, void_type_node, 
exit_label[ii]);
+}


Is there any particular reason why you're open-coding the loop expansion 
instead of using existing infrastructure like c_finish_loop?


Yes, the specific example of c_finish_loop goes against the c++ sharing, but 
it's fairly easy to add new interfaces to c-common.h that are implemented in 
the two front ends.




r~

Re: [patch, powerpc] increase array alignment for Altivec

[Bill Schmidt]

On Tue, 2013-05-21 at 21:57 -0400, David Edelsohn wrote:
> On Tue, May 21, 2013 at 7:13 PM, Sandra Loosemore
>  wrote:
> > On 05/21/2013 04:04 PM, David Edelsohn wrote:
> >>
> >>
> >> There are three issues here:
> >>
> >> 1) Someone in the LTC toolchain team needs to benchmark this patch on
> >> POWER7.
> >
> >
> > That would be great if somebody else could help with that.
> >
> >
> >> 2) We need to clarify how the patch affects the ABI because it cannot
> >> break the ABI.
> >
> >
> > I understand this.
> >
> >
> >> 3) Please stop saying that you cannot justify trying to get the patch
> >> in mainline.  Other developers have pointed out how the patch may be
> >> incorrect. Do you want to deliver a broken compiler to CodeSourcery's
> >> customers? The comment sets a bad tone for engaging with the GCC
> >> community.
> >
> >
> > I think you've misunderstood my position, here.  Delivering a broken
> > compiler is just what I want to avoid!  We've had the original
> > local-arrays-only patch in our local tree for a couple of years now, but we
> > no longer have a customer for it.  I thought the comments from the previous
> > review would be straightforward to address and it would be worth making one
> > more attempt to revise and resubmit the patch, but if the feedback we get
> > from the community is that this is still broken in other ways and is going
> > to need a lot more work before it's acceptable, we're going to give up on it
> > and revert the previous version of the patch locally too.  We have a lot of
> > higher-priority patches in our local tree that we'd like to get on mainline,
> > and limited resources for working on it, so we need to pick our battles.
> > That's all.  :-)
> 
> I think the local arrays patch makes sense, if it does not hurt
> performance. We had another recent case where increasing GCC's
> knowledge about the alignment of memory returned by malloc allowed
> additional vectorization opportunities, but hurt performance because
> of bad spilling choices by GCC RA.  This alignment patch may expose
> similar RA problems.  We may need to apply the patch with the
> optimization disabled until the RA spilling problem is fixed.
> 
> Increasing the alignment of arrays within structs and unions would be
> nice, but that probably will change the ABI. I think that they best we
> may be able to do is increase the alignment if the array is the first
> element of the struct or union, see ROUND_TYPE_ALIGN for AIX.
> Although this might be more trouble than it is worth.
> 
> Pat or Bill, can you test the performance of the array alignment patch?

I can take a look at this tomorrow.  I think I should probably commit
the other pending patch I have first.  There was some discussion on my
patch whether it was the right approach, but given the behavior of
existing allocators I think it's still the right way to handle it for
now.  David, do you agree?

Thanks,
Bill

> 
> Thanks, David
> 

Re: [patch, powerpc] increase array alignment for Altivec

[David Edelsohn]

On Tue, May 21, 2013 at 7:13 PM, Sandra Loosemore
 wrote:
> On 05/21/2013 04:04 PM, David Edelsohn wrote:
>>
>>
>> There are three issues here:
>>
>> 1) Someone in the LTC toolchain team needs to benchmark this patch on
>> POWER7.
>
>
> That would be great if somebody else could help with that.
>
>
>> 2) We need to clarify how the patch affects the ABI because it cannot
>> break the ABI.
>
>
> I understand this.
>
>
>> 3) Please stop saying that you cannot justify trying to get the patch
>> in mainline.  Other developers have pointed out how the patch may be
>> incorrect. Do you want to deliver a broken compiler to CodeSourcery's
>> customers? The comment sets a bad tone for engaging with the GCC
>> community.
>
>
> I think you've misunderstood my position, here.  Delivering a broken
> compiler is just what I want to avoid!  We've had the original
> local-arrays-only patch in our local tree for a couple of years now, but we
> no longer have a customer for it.  I thought the comments from the previous
> review would be straightforward to address and it would be worth making one
> more attempt to revise and resubmit the patch, but if the feedback we get
> from the community is that this is still broken in other ways and is going
> to need a lot more work before it's acceptable, we're going to give up on it
> and revert the previous version of the patch locally too.  We have a lot of
> higher-priority patches in our local tree that we'd like to get on mainline,
> and limited resources for working on it, so we need to pick our battles.
> That's all.  :-)

I think the local arrays patch makes sense, if it does not hurt
performance. We had another recent case where increasing GCC's
knowledge about the alignment of memory returned by malloc allowed
additional vectorization opportunities, but hurt performance because
of bad spilling choices by GCC RA.  This alignment patch may expose
similar RA problems.  We may need to apply the patch with the
optimization disabled until the RA spilling problem is fixed.

Increasing the alignment of arrays within structs and unions would be
nice, but that probably will change the ABI. I think that they best we
may be able to do is increase the alignment if the array is the first
element of the struct or union, see ROUND_TYPE_ALIGN for AIX.
Although this might be more trouble than it is worth.

Pat or Bill, can you test the performance of the array alignment patch?

Thanks, David

[C++ Patch] PR 57211

[Paolo Carlini]

Hi,

I think submitters have a point that it doesn't make much sense to warn 
about unused parameters of defaulted functions: evidently those exist 
only for documentation purposes. The actual warning is produced by 
do_warn_unused_parameter, which belongs to gcc/function.c, thus the 
simplest solution I have been able to figure out for our front-end issue 
is setting the TREE_NO_WARNING bit, in defaultable_fn_check. I don't 
think we risk suppressing any other warnings.


Tested x86_64-linux.

Thanks,
Paolo.

/
/cp
2013-05-22  Paolo Carlini  

PR c++/57211
* method.c (defaultable_fn_check): Avoid do_warn_unused_parameter
warnings about defaulted functions.

/testsuite
2013-05-22  Paolo Carlini  

PR c++/57211
* g++.dg/cpp0x/Wunused-parm.C: New.
Index: cp/method.c
===
--- cp/method.c (revision 199164)
+++ cp/method.c (working copy)
@@ -1864,13 +1864,19 @@ defaultable_fn_check (tree fn)
 }
   else
 {
-  tree t = FUNCTION_FIRST_USER_PARMTYPE (fn);
-  for (; t && t != void_list_node; t = TREE_CHAIN (t))
+  for (tree t = FUNCTION_FIRST_USER_PARMTYPE (fn);
+  t && t != void_list_node; t = TREE_CHAIN (t))
if (TREE_PURPOSE (t))
  {
error ("defaulted function %q+D with default argument", fn);
break;
  }
+
+  /* Avoid do_warn_unused_parameter warnings.  */
+  for (tree p = FUNCTION_FIRST_USER_PARM (fn); p; p = DECL_CHAIN (p))
+   if (DECL_NAME (p))
+ TREE_NO_WARNING (p) = 1;
+
   if (TYPE_BEING_DEFINED (DECL_CONTEXT (fn)))
/* Defer checking.  */;
   else if (!processing_template_decl)
Index: testsuite/g++.dg/cpp0x/Wunused-parm.C
===
--- testsuite/g++.dg/cpp0x/Wunused-parm.C   (revision 0)
+++ testsuite/g++.dg/cpp0x/Wunused-parm.C   (working copy)
@@ -0,0 +1,23 @@
+// PR c++/57211
+// { dg-options "-std=c++11 -Wunused-parameter" }
+
+template  T&& move(T&);
+
+struct A
+{
+  struct B
+  {
+B& operator=(B&&);
+  };
+
+  B f;
+
+  A& operator=(A&& p) = default;
+};
+
+int main()
+{
+  A a;
+  A b;
+  b = move(a);
+}

Re: [PATCH, rs6000] power8 patches, patch #5, new vector tests

[Michael Meissner]

This patch provides the tests for the new vector instructions added in patches
3 and 4.  In addition, it provides the target support for power8 systems.

Is this patch acceptable to be checked in once the previous 4 patches have been
applied?

2013-05-21  Michael Meissner  

* gcc.target/powerpc/p8vector-builtin-1.c: New test to test
power8 builtin functions.
* gcc/testsuite/gcc.target/powerpc/p8vector-builtin-2.c: Likewise.
* gcc/testsuite/gcc.target/powerpc/p8vector-builtin-3.c: Likewise.
* gcc/testsuite/gcc.target/powerpc/p8vector-builtin-4.c: Likewise.
* gcc/testsuite/gcc.target/powerpc/p8vector-builtin-5.c: Likewise.
* gcc/testsuite/gcc.target/powerpc/p8vector-builtin-6.c: Likewise.
* gcc/testsuite/gcc.target/powerpc/p8vector-builtin-7.c: Likewise.
* gcc/testsuite/gcc.target/powerpc/p8vector-vectorize-1.c: New
tests to test power8 auto-vectorization.
* gcc/testsuite/gcc.target/powerpc/p8vector-vectorize-2.c: Likewise.
* gcc/testsuite/gcc.target/powerpc/p8vector-vectorize-3.c: Likewise.
* gcc/testsuite/gcc.target/powerpc/p8vector-vectorize-4.c: Likewise.
* gcc/testsuite/gcc.target/powerpc/p8vector-vectorize-5.c: Likewise.

* lib/target-supports.exp (check_p8vector_hw_available): New
function, check if we are running on a power8.
(check_effective_target_powerpc_p8vector_ok): New function, check
if target can compile for power8.
(is-effective-target): Add power8 support.
(is-effective-target-keyword): Likewise.
(check_vect_support_and_set_flags): Likewise.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460, USA
email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797
Index: gcc/testsuite/gcc.target/powerpc/p8vector-builtin-1.c
===
--- gcc/testsuite/gcc.target/powerpc/p8vector-builtin-1.c   (revision 0)
+++ gcc/testsuite/gcc.target/powerpc/p8vector-builtin-1.c   (revision 0)
@@ -0,0 +1,65 @@
+/* { dg-do compile { target { powerpc*-*-* } } } */
+/* { dg-skip-if "" { powerpc*-*-darwin* } { "*" } { "" } } */
+/* { dg-require-effective-target powerpc_p8vector_ok } */
+/* { dg-options "-mcpu=power8 -O2 -ftree-vectorize -fvect-cost-model 
-fno-unroll-loops -fno-unroll-all-loops" } */
+
+#ifndef TYPE
+#define TYPE long long
+#endif
+
+#ifndef SIGN_TYPE
+#define SIGN_TYPE signed TYPE
+#endif
+
+#ifndef UNS_TYPE
+#define UNS_TYPE unsigned TYPE
+#endif
+
+typedef vector SIGN_TYPE v_sign;
+typedef vector UNS_TYPE  v_uns;
+
+v_sign sign_add (v_sign a, v_sign b)
+{
+  return a + b;
+}
+
+v_sign sign_sub (v_sign a, v_sign b)
+{
+  return a - b;
+}
+
+v_sign sign_shift_left (v_sign a, v_sign b)
+{
+  return a << b;
+}
+
+v_sign sign_shift_right (v_sign a, v_sign b)
+{
+  return a >> b;
+}
+
+v_uns uns_add (v_uns a, v_uns b)
+{
+  return a + b;
+}
+
+v_uns uns_sub (v_uns a, v_uns b)
+{
+  return a - b;
+}
+
+v_uns uns_shift_left (v_uns a, v_uns b)
+{
+  return a << b;
+}
+
+v_uns uns_shift_right (v_uns a, v_uns b)
+{
+  return a >> b;
+}
+
+/* { dg-final { scan-assembler-times "vaddudm" 2 } } */
+/* { dg-final { scan-assembler-times "vsubudm" 2 } } */
+/* { dg-final { scan-assembler-times "vsld"2 } } */
+/* { dg-final { scan-assembler-times "vsrad"   1 } } */
+/* { dg-final { scan-assembler-times "vsrd"1 } } */
Index: gcc/testsuite/gcc.target/powerpc/p8vector-vectorize-1.c
===
--- gcc/testsuite/gcc.target/powerpc/p8vector-vectorize-1.c (revision 0)
+++ gcc/testsuite/gcc.target/powerpc/p8vector-vectorize-1.c (revision 0)
@@ -0,0 +1,200 @@
+/* { dg-do compile { target { powerpc*-*-* } } } */
+/* { dg-skip-if "" { powerpc*-*-darwin* } { "*" } { "" } } */
+/* { dg-require-effective-target powerpc_p8vector_ok } */
+/* { dg-options "-mcpu=power8 -O2 -ftree-vectorize -fvect-cost-model 
-fno-unroll-loops -fno-unroll-all-loops" } */
+
+#ifndef SIZE
+#define SIZE 1024
+#endif
+
+#ifndef ALIGN
+#define ALIGN 32
+#endif
+
+#ifndef TYPE
+#define TYPE long long
+#endif
+
+#ifndef SIGN_TYPE
+#define SIGN_TYPE signed TYPE
+#endif
+
+#ifndef UNS_TYPE
+#define UNS_TYPE unsigned TYPE
+#endif
+
+#define ALIGN_ATTR __attribute__((__aligned__(ALIGN)))
+
+SIGN_TYPE  sa[SIZE] ALIGN_ATTR;
+SIGN_TYPE  sb[SIZE] ALIGN_ATTR;
+SIGN_TYPE  sc[SIZE] ALIGN_ATTR;
+
+UNS_TYPE   ua[SIZE] ALIGN_ATTR;
+UNS_TYPE   ub[SIZE] ALIGN_ATTR;
+UNS_TYPE   uc[SIZE] ALIGN_ATTR;
+
+void
+sign_add (void)
+{
+  unsigned long i;
+
+  for (i = 0; i < SIZE; i++)
+sa[i] = sb[i] + sc[i];
+}
+
+void
+sign_sub (void)
+{
+  unsigned long i;
+
+  for (i = 0; i < SIZE; i++)
+sa[i] = sb[i] - sc[i];
+}
+
+void
+sign_shift_left (void)
+{
+  unsigned long i;
+
+  for (i = 0; i < SIZE; i++)
+sa[i] = sb[i] << sc[i];
+}
+
+void
+sign_shift_right (void)
+{
+  unsigned long i;
+
+  for (i = 0; i < SIZE; i++)
+ 

Re: [patch, powerpc] increase array alignment for Altivec

[Sandra Loosemore]

On 05/21/2013 04:04 PM, David Edelsohn wrote:


There are three issues here:

1) Someone in the LTC toolchain team needs to benchmark this patch on POWER7.


That would be great if somebody else could help with that.


2) We need to clarify how the patch affects the ABI because it cannot
break the ABI.


I understand this.


3) Please stop saying that you cannot justify trying to get the patch
in mainline.  Other developers have pointed out how the patch may be
incorrect. Do you want to deliver a broken compiler to CodeSourcery's
customers? The comment sets a bad tone for engaging with the GCC
community.


I think you've misunderstood my position, here.  Delivering a broken 
compiler is just what I want to avoid!  We've had the original 
local-arrays-only patch in our local tree for a couple of years now, but 
we no longer have a customer for it.  I thought the comments from the 
previous review would be straightforward to address and it would be 
worth making one more attempt to revise and resubmit the patch, but if 
the feedback we get from the community is that this is still broken in 
other ways and is going to need a lot more work before it's acceptable, 
we're going to give up on it and revert the previous version of the 
patch locally too.  We have a lot of higher-priority patches in our 
local tree that we'd like to get on mainline, and limited resources for 
working on it, so we need to pick our battles.  That's all.  :-)


-Sandra

[google gcc-4_7] coverage callback instrumentation (issue9630043)

[Rong Xu]

This patch is to be used with customized coverage reduction.

The functionalities are under two parameter options:
--param=COVERAGE-CALLBACK={0|1}
when enabled with 1, it injects a callback function for
each arc counter. Default off.
--param=COVERAGE-CALLONCE={0|1}
when enabled with 1, it stops incrementing the arc counter
when they flip to 1. Default off. Even with an extra condition
check, this is drastically faster than the normal coverage test
for highly threaded applications.

It also fixes a bug in profile sampling where some counters
(like those after the call stmt) are not sampled.

It disables the may-uninit check if the warning will not be
emitted.

Tested with bootstrap, regressions test and google internal
benchmarks.

Thanks,

-Rong

2013-05-21  Rong Xu  

* gcc/tree-ssa-uninit.c (gate_warn_uninitialized): Disable if
may-uninit warning will not emitted.
* gcc/params.def : (PARAM_COVERAGE_CALLBACK) New.
(PARAM_COVERAGE_CALLONCE): NEW.
* gcc/profile.c (branch_prob): Not increment edge counter after
first update.
(tree_init_instrumentation_sampling): Ditto.
(COVERAGE_CALLBACK_FUNC_NAME): New.
(COVERAGE_INSERT_CALL): New.
(insert_if_then): Update branch probability.
(add_sampling_wrapper): Ditto.
(add_callback_wrapper): New.
(add_sampling_to_edge_counters): Make predicate insertion
complete.
(gimple_gen_edge_profiler): Add coverage callback function.
(gimple_gen_ic_profiler): Fix trailing space.
(gimple_gen_ic_func_topn_profiler): Ditto.
(gimple_gen_dc_profiler): Ditto.
* libgcc/libgcov.c (__coverage_callback): Add an empty callback
function.

Index: libgcc/libgcov.c
===
--- libgcc/libgcov.c(revision 198952)
+++ libgcc/libgcov.c(working copy)
@@ -135,6 +135,14 @@ extern int gcov_dump_complete ATTRIBUTE_HIDDEN;
these symbols will always need to be resolved.  */
 void (*__gcov_dummy_ref1)() = &__gcov_reset;
 void (*__gcov_dummy_ref2)() = &__gcov_dump;
+
+__attribute__((weak)) void
+__coverage_callback (gcov_type funcdef_no __attribute__ ((unused)),
+ int edge_no __attribute__ ((unused)))
+{
+   /* nothing */
+}
+
 #endif /* __GCOV_KERNEL__ */
 
 /* Utility function for outputing errors.  */
Index: gcc/profile.c
===
--- gcc/profile.c   (revision 198952)
+++ gcc/profile.c   (working copy)
@@ -69,6 +69,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "timevar.h"
 #include "cfgloop.h"
 #include "tree-pass.h"
+#include "params.h"
 
 #include "profile.h"
 
@@ -1480,7 +1481,8 @@ branch_prob (void)
   /* Commit changes done by instrumentation.  */
   gsi_commit_edge_inserts ();
 
-  if (flag_profile_generate_sampling)
+  if (flag_profile_generate_sampling
+  || PARAM_VALUE (PARAM_COVERAGE_CALLONCE))
 add_sampling_to_edge_counters ();
 }
 
Index: gcc/params.def
===
--- gcc/params.def  (revision 198952)
+++ gcc/params.def  (working copy)
@@ -1060,6 +1060,16 @@ DEFPARAM (PARAM_PROFILE_GENERATE_SAMPLING_PERIOD,
  "sampling rate with -fprofile-generate-sampling",
  100, 0, 20)
 
+DEFPARAM (PARAM_COVERAGE_CALLBACK,
+ "coverage-callback",
+ "callback a user-define function when for arc counter increments.",
+ 0, 0, 1)
+
+DEFPARAM (PARAM_COVERAGE_CALLONCE,
+ "coverage-callonce",
+ "Stop increment coverage counts once they become 1.",
+ 0, 0, 1)
+
 /* Used for debugging purpose. Tell the compiler to find
the gcda file in the current directory.  */
 DEFPARAM (PARAM_GCOV_DEBUG,
Index: gcc/tree-profile.c
===
--- gcc/tree-profile.c  (revision 198952)
+++ gcc/tree-profile.c  (working copy)
@@ -54,6 +54,15 @@ along with GCC; see the file COPYING3.  If not see
 #include "target.h"
 #include "output.h"
 
+/* Default name for coverage callback function.  */
+#define COVERAGE_CALLBACK_FUNC_NAME "__coverage_callback"
+
+/* If we insert a callback to edge instrumentation code. Avoid this
+   for the callback function itself.  */
+#define COVERAGE_INSERT_CALL   ((PARAM_VALUE (PARAM_COVERAGE_CALLBACK) == 1) \
+ && strcmp (get_name (current_function_decl), \
+COVERAGE_CALLBACK_FUNC_NAME))
+
 /* Number of statements inserted for each edge counter increment.  */
 #define EDGE_COUNTER_STMT_COUNT 3
 
@@ -202,14 +211,16 @@ static tree GTY(()) gcov_lipo_merge_modu_edges = N
 static tree GTY(()) gcov_lipo_strict_inclusion = NULL_TREE;
 
 /* Insert STMT_IF around given sequence of consecutive statements in the
-   same basic block starting with STMT_START, ending with STMT_END.  */
+   

Re: [patch, powerpc] increase array alignment for Altivec

[David Edelsohn]

On Tue, May 21, 2013 at 5:49 PM, Sandra Loosemore
 wrote:
> On 05/20/2013 03:20 PM, David Edelsohn wrote:
>>
>> This seems like a reasonable change and *should* improve performance,
>> but what is the actual effect on performance, especially recent POWER
>> processors?  We have had some recent cases where increased alignment
>> hurt performance because of secondary effects on spilling.
>
>
> I've poked around a bit.  We seem to have no suitable Altivec hardware for
> bare-metal benchmarking (we do simulator testing for -te600 instead), but we
> have a Freescale 8641D board available for GNU/Linux. It's about 5 years old
> so I don't know if it qualifies as a sufficiently recent processor?  (Like I
> said before, we can't justify spending a lot of time trying to get this
> patch on mainline, and I especially don't want to waste time setting up
> benchmarking that would not be useful anyway.)

There are three issues here:

1) Someone in the LTC toolchain team needs to benchmark this patch on POWER7.

2) We need to clarify how the patch affects the ABI because it cannot
break the ABI.

3) Please stop saying that you cannot justify trying to get the patch
in mainline.  Other developers have pointed out how the patch may be
incorrect. Do you want to deliver a broken compiler to CodeSourcery's
customers? The comment sets a bad tone for engaging with the GCC
community.

Thanks, David

Re: [patch, powerpc] increase array alignment for Altivec

[Sandra Loosemore]

On 05/20/2013 03:20 PM, David Edelsohn wrote:

This seems like a reasonable change and *should* improve performance,
but what is the actual effect on performance, especially recent POWER
processors?  We have had some recent cases where increased alignment
hurt performance because of secondary effects on spilling.


I've poked around a bit.  We seem to have no suitable Altivec hardware 
for bare-metal benchmarking (we do simulator testing for -te600 
instead), but we have a Freescale 8641D board available for GNU/Linux. 
It's about 5 years old so I don't know if it qualifies as a sufficiently 
recent processor?  (Like I said before, we can't justify spending a lot 
of time trying to get this patch on mainline, and I especially don't 
want to waste time setting up benchmarking that would not be useful anyway.)


-Sandra

Re: [patch, mips] Patch for mips generic scheduler

[Steve Ellcey]

On Tue, 2013-05-21 at 19:55 +0100, Richard Sandiford wrote:

> Hmm, but generic.md is very much legacy and shouldn't be used for
> vaguely modern cores.  Even something like -mips32 is supposed to avoid
> the generic scheduler; it should use the 4k scheduler instead.
> What options were you using to trigger it?

I am just doing a default compilation of my mips-mti-linux-gnu target.
This defaults to mips32r2.  I just tried adding -mtune=mips32r2 and that
made no difference, -mtune=4k also makes no difference, but -mtune=4kc
does affect the output.

> It might be worth having a new "generic" scheduler that's supposed to be
> a good compromise for modern cores though.  Or, more simply, we could just
> change:
> 
> MIPS_CPU ("mips32", PROCESSOR_4KC, 32, PTF_AVOID_BRANCHLIKELY)
> MIPS_CPU ("mips32r2", PROCESSOR_M4K, 33, PTF_AVOID_BRANCHLIKELY)
> MIPS_CPU ("mips64", PROCESSOR_5KC, 64, PTF_AVOID_BRANCHLIKELY)
> /* ??? For now just tune the generic MIPS64r2 for 5KC as well.   */
> MIPS_CPU ("mips64r2", PROCESSOR_5KC, 65, PTF_AVOID_BRANCHLIKELY)
> 
> to tune for other processors instead, if you don't think 4kc, etc. are
> representative enough.

Hm, I think the problem may be that mips32r2 defaults to PROCESSOR_M4K
and mips32 defaults to PROCESSOR_4KC.  I don't see any special scheduler
for m4k.  Is there supposed to be a scheduler for m4k?

Steve Ellcey

Re: [google] Disable RDRAND bits when building with Clang

[Diego Novillo]

On 2013-05-20 09:15 , Evgeniy Stepanov wrote:

Is it OK for google/gcc-4_8 and google/main (or google/integration?) ?


OK for google branches.


Thanks.  Diego.

Re: [google/gcc-4_8] Fix libatomic testsuite for when GCC_UNDER_TEST is not plain xgcc

[Richard Henderson]

On 05/21/2013 12:28 PM, Diego Novillo wrote:
> This is OK for google branches.  I'm tempted to say it's fine for trunk, but I
> would like to know what maintainers think.  Richard?

Looks plausible.

Irritating that we need another config file, rather than simply an environment
variable passed down from make, but tcl is irritating already so I won't
quibble.  If a testsuite maintainer can suggest something else, please do.
Otherwise fine by me.


r~

Re: [google/gcc-4_8] Fix libatomic testsuite for when GCC_UNDER_TEST is not plain xgcc

[Diego Novillo]

On 2013-05-21 15:00 , Simon Baldwin wrote:

Ping.  Also, any thoughts on suitability of this (or otherwise) for trunk?


On 1 May 2013 16:04, Simon Baldwin  wrote:

Fix libatomic testsuite for when GCC_UNDER_TEST is not plain xgcc.

Libatomic tests fail if GCC_UNDER_TEST is set to something other than a plain
xgcc invocation (for example, when $CC requires a special -sysroot).  Fix
testsuite files so that it uniformly uses CC_UNDER_TEST rather than any result
from libgloss find_gcc.

Okay for google/gcc-4_8?  google/main?

2013-05-01

 * libatomic/configure: Regenerate.
 * libatomic/configure.ac: Add testsuite/atomicconfig.exp config file.
 * libatomic/testsuite/atomicconfig.exp.in: New.
 * libatomic/testsuite/config/default.exp: Load atomicconfig.exp.
 * libatomic/testsuite/lib/libatomic.exp: Print multi-lib using
 the full value of $GCC_UNDER_TEST.


Index: libatomic/configure
===
--- libatomic/configure (revision 198464)
+++ libatomic/configure (working copy)
@@ -655,6 +655,7 @@ CCAS
  am__fastdepCC_FALSE
  am__fastdepCC_TRUE
  CCDEPMODE
+am__nodep
  AMDEPBACKSLASH
  AMDEP_FALSE
  AMDEP_TRUE
@@ -3044,11 +3045,11 @@ MAKEINFO=${MAKEINFO-"${am_missing_run}ma

  # We need awk for the "check" target.  The system "awk" is bad on
  # some platforms.
-# Always define AMTAR for backward compatibility.
+# Always define AMTAR for backward compatibility.  Yes, it's still used
+# in the wild :-(  We should find a proper way to deprecate it ...
+AMTAR='$${TAR-tar}'

-AMTAR=${AMTAR-"${am_missing_run}tar"}
-
-am__tar='${AMTAR} chof - "$$tardir"'; am__untar='${AMTAR} xf -'
+am__tar='$${TAR-tar} chof - "$$tardir"' am__untar='$${TAR-tar} xf -'



@@ -3946,6 +3947,7 @@ fi
  if test "x$enable_dependency_tracking" != xno; then
am_depcomp="$ac_aux_dir/depcomp"
AMDEPBACKSLASH='\'
+  am__nodep='_no'
  fi
   if test "x$enable_dependency_tracking" != xno; then
AMDEP_TRUE=
@@ -3970,6 +3972,7 @@ else
# instance it was reported that on HP-UX the gcc test will end up
# making a dummy file named `D' -- because `-MD' means `put the output
# in D'.
+  rm -rf conftest.dir
mkdir conftest.dir
# Copy depcomp to subdir because otherwise we won't find it if we're
# using a relative directory.
@@ -4029,7 +4032,7 @@ else
 break
fi
;;
-msvisualcpp | msvcmsys)
+msvc7 | msvc7msys | msvisualcpp | msvcmsys)
# This compiler won't grok `-c -o', but also, the minuso test has
# not run yet.  These depmodes are late enough in the game, and
# so weak that their functioning should not be impacted.
@@ -4104,6 +4107,7 @@ else
# instance it was reported that on HP-UX the gcc test will end up
# making a dummy file named `D' -- because `-MD' means `put the output
# in D'.
+  rm -rf conftest.dir
mkdir conftest.dir
# Copy depcomp to subdir because otherwise we won't find it if we're
# using a relative directory.
@@ -4161,7 +4165,7 @@ else
 break
fi
;;
-msvisualcpp | msvcmsys)
+msvc7 | msvc7msys | msvisualcpp | msvcmsys)
# This compiler won't grok `-c -o', but also, the minuso test has
# not run yet.  These depmodes are late enough in the game, and
# so weak that their functioning should not be impacted.
@@ -7614,7 +7618,22 @@ fi

  # Check whether --with-pic was given.
  if test "${with_pic+set}" = set; then :
-  withval=$with_pic; pic_mode="$withval"
+  withval=$with_pic; p=${PACKAGE-default}
+case "$withval" in
+yes|no) pic_mode="$withval" ;;
+*)
+  pic_mode=default
+  # Look at the argument we got.  We use all the common list separators.
+  lt_save_ifs="$IFS"; IFS="${IFS}$PATH_SEPARATOR,"
+  for pkg in $withval; do
+   IFS="$lt_save_ifs"
+   if test "X$pkg" = "X$p"; then
+ pic_mode=yes
+   fi
+  done
+  IFS="$lt_save_ifs"
+  ;;
+esac
  else
pic_mode=default
  fi
@@ -11013,7 +11032,7 @@ else
lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
lt_status=$lt_dlunknown
cat > conftest.$ac_ext <<_LT_EOF
-#line 11016 "configure"
+#line 11035 "configure"
  #include "confdefs.h"

  #if HAVE_DLFCN_H
@@ -9,7 +11138,7 @@ else
lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
lt_status=$lt_dlunknown
cat > conftest.$ac_ext <<_LT_EOF
-#line 11122 "configure"
+#line 11141 "configure"
  #include "confdefs.h"

  #if HAVE_DLFCN_H
@@ -15125,6 +15144,8 @@ fi

  ac_config_files="$ac_config_files Makefile testsuite/Makefile"

+ac_config_files="$ac_config_files testsuite/atomicconfig.exp"
+
  cat >confcache <<\_ACEOF
  # This file is a shell script that caches the results of configure
  # tests run on this system so they can be shared between configure
@@ -16173,6 +16194,7 @@ do
  "gstdint.h") CONFIG_COMMANDS="$CONFIG_COMMANDS gstdint.h" ;;
  "Makefile") CONFIG_FILES="$CONFIG_FILES Makefile" ;;

Re: [google/gcc-4_8] Fix libatomic testsuite for when GCC_UNDER_TEST is not plain xgcc

[Simon Baldwin]

Ping.  Also, any thoughts on suitability of this (or otherwise) for trunk?


On 1 May 2013 16:04, Simon Baldwin  wrote:
> Fix libatomic testsuite for when GCC_UNDER_TEST is not plain xgcc.
>
> Libatomic tests fail if GCC_UNDER_TEST is set to something other than a plain
> xgcc invocation (for example, when $CC requires a special -sysroot).  Fix
> testsuite files so that it uniformly uses CC_UNDER_TEST rather than any result
> from libgloss find_gcc.
>
> Okay for google/gcc-4_8?  google/main?
>
> 2013-05-01
>
> * libatomic/configure: Regenerate.
> * libatomic/configure.ac: Add testsuite/atomicconfig.exp config file.
> * libatomic/testsuite/atomicconfig.exp.in: New.
> * libatomic/testsuite/config/default.exp: Load atomicconfig.exp.
> * libatomic/testsuite/lib/libatomic.exp: Print multi-lib using
> the full value of $GCC_UNDER_TEST.
>
>
> Index: libatomic/configure
> ===
> --- libatomic/configure (revision 198464)
> +++ libatomic/configure (working copy)
> @@ -655,6 +655,7 @@ CCAS
>  am__fastdepCC_FALSE
>  am__fastdepCC_TRUE
>  CCDEPMODE
> +am__nodep
>  AMDEPBACKSLASH
>  AMDEP_FALSE
>  AMDEP_TRUE
> @@ -3044,11 +3045,11 @@ MAKEINFO=${MAKEINFO-"${am_missing_run}ma
>
>  # We need awk for the "check" target.  The system "awk" is bad on
>  # some platforms.
> -# Always define AMTAR for backward compatibility.
> +# Always define AMTAR for backward compatibility.  Yes, it's still used
> +# in the wild :-(  We should find a proper way to deprecate it ...
> +AMTAR='$${TAR-tar}'
>
> -AMTAR=${AMTAR-"${am_missing_run}tar"}
> -
> -am__tar='${AMTAR} chof - "$$tardir"'; am__untar='${AMTAR} xf -'
> +am__tar='$${TAR-tar} chof - "$$tardir"' am__untar='$${TAR-tar} xf -'
>
>
>
> @@ -3946,6 +3947,7 @@ fi
>  if test "x$enable_dependency_tracking" != xno; then
>am_depcomp="$ac_aux_dir/depcomp"
>AMDEPBACKSLASH='\'
> +  am__nodep='_no'
>  fi
>   if test "x$enable_dependency_tracking" != xno; then
>AMDEP_TRUE=
> @@ -3970,6 +3972,7 @@ else
># instance it was reported that on HP-UX the gcc test will end up
># making a dummy file named `D' -- because `-MD' means `put the output
># in D'.
> +  rm -rf conftest.dir
>mkdir conftest.dir
># Copy depcomp to subdir because otherwise we won't find it if we're
># using a relative directory.
> @@ -4029,7 +4032,7 @@ else
> break
>fi
>;;
> -msvisualcpp | msvcmsys)
> +msvc7 | msvc7msys | msvisualcpp | msvcmsys)
># This compiler won't grok `-c -o', but also, the minuso test has
># not run yet.  These depmodes are late enough in the game, and
># so weak that their functioning should not be impacted.
> @@ -4104,6 +4107,7 @@ else
># instance it was reported that on HP-UX the gcc test will end up
># making a dummy file named `D' -- because `-MD' means `put the output
># in D'.
> +  rm -rf conftest.dir
>mkdir conftest.dir
># Copy depcomp to subdir because otherwise we won't find it if we're
># using a relative directory.
> @@ -4161,7 +4165,7 @@ else
> break
>fi
>;;
> -msvisualcpp | msvcmsys)
> +msvc7 | msvc7msys | msvisualcpp | msvcmsys)
># This compiler won't grok `-c -o', but also, the minuso test has
># not run yet.  These depmodes are late enough in the game, and
># so weak that their functioning should not be impacted.
> @@ -7614,7 +7618,22 @@ fi
>
>  # Check whether --with-pic was given.
>  if test "${with_pic+set}" = set; then :
> -  withval=$with_pic; pic_mode="$withval"
> +  withval=$with_pic; p=${PACKAGE-default}
> +case "$withval" in
> +yes|no) pic_mode="$withval" ;;
> +*)
> +  pic_mode=default
> +  # Look at the argument we got.  We use all the common list separators.
> +  lt_save_ifs="$IFS"; IFS="${IFS}$PATH_SEPARATOR,"
> +  for pkg in $withval; do
> +   IFS="$lt_save_ifs"
> +   if test "X$pkg" = "X$p"; then
> + pic_mode=yes
> +   fi
> +  done
> +  IFS="$lt_save_ifs"
> +  ;;
> +esac
>  else
>pic_mode=default
>  fi
> @@ -11013,7 +11032,7 @@ else
>lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
>lt_status=$lt_dlunknown
>cat > conftest.$ac_ext <<_LT_EOF
> -#line 11016 "configure"
> +#line 11035 "configure"
>  #include "confdefs.h"
>
>  #if HAVE_DLFCN_H
> @@ -9,7 +11138,7 @@ else
>lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
>lt_status=$lt_dlunknown
>cat > conftest.$ac_ext <<_LT_EOF
> -#line 11122 "configure"
> +#line 11141 "configure"
>  #include "confdefs.h"
>
>  #if HAVE_DLFCN_H
> @@ -15125,6 +15144,8 @@ fi
>
>  ac_config_files="$ac_config_files Makefile testsuite/Makefile"
>
> +ac_config_files="$ac_config_files testsuite/atomicconfig.exp"
> +
>  cat >confcache <<\_ACEOF
>  # This file is a shell script that caches the results of configure
>  # tests run on this system so they can be shared between configu

Re: [patch, mips] Patch for mips generic scheduler

[Richard Sandiford]

"Steve Ellcey "  writes:
> While looking at some matrix code I noticed that the generic mips scheduler
> was putting out a bunch of integer madd instructions in a row and that
> I got better performance (on 74kc and proAptiv) when they were spread out.
>
> I was wondering what folks thought of this change to specify that the
> integer madd instruction uses the alu and the imuldiv functional units?
>
> Tested on 74kc and proAptive with no regressions and better performance.

Hmm, but generic.md is very much legacy and shouldn't be used for
vaguely modern cores.  Even something like -mips32 is supposed to avoid
the generic scheduler; it should use the 4k scheduler instead.
What options were you using to trigger it?

generic.md is actually inherited by some of the very old, pre-DFA schedulers,
including those that were probably used with the old PMC cores.  I'm not
even sure how much generic.md was ever supposed to be a good "all-round"
scheduling description, akin to the modern -mtune=generic on x86 targets.
I'm a bit reluctant to change it at this stage.

It might be worth having a new "generic" scheduler that's supposed to be
a good compromise for modern cores though.  Or, more simply, we could just
change:

MIPS_CPU ("mips32", PROCESSOR_4KC, 32, PTF_AVOID_BRANCHLIKELY)
MIPS_CPU ("mips32r2", PROCESSOR_M4K, 33, PTF_AVOID_BRANCHLIKELY)
MIPS_CPU ("mips64", PROCESSOR_5KC, 64, PTF_AVOID_BRANCHLIKELY)
/* ??? For now just tune the generic MIPS64r2 for 5KC as well.   */
MIPS_CPU ("mips64r2", PROCESSOR_5KC, 65, PTF_AVOID_BRANCHLIKELY)

to tune for other processors instead, if you don't think 4kc, etc. are
representative enough.

Richard

Re: [PATCH,RFC] Make libbacktrace more standalone

[Ian Lance Taylor]

On Tue, May 21, 2013 at 9:52 AM, Alexander Monakov  wrote:
>
> 1. The documentation does not say whether reusing "state" objects is allowed.
> For instance, I'm using backtrace_simple, and then in the callback I'm
> invoking dladdr and backtrace_pcinfo to gather file-line info if available.
> Looks like at the moment it's fine, as no frame-specific information is stored
> there.

Yes, you can reuse backtrace_state objects.

> 2. The reason I'm invoking dladdr instead of backtrace_syminfo is the need to
> obtain the name of the module containing the symbol.  Is that intended?
> (IOW, would be nice if libbacktrace syminfo callback provided name and base
> address of the loaded module as well)

I'm fine with changing libbacktrace_syminfo so that it passes the
module name and the base address to the callback.

> 3. In libbacktrace/elf.c, elf_syminfo() does not seem to walk the chain of
> elf_syminfo_data (i.e. does not use edata->next).  Is that a bug?

Hmmm, yes, that does look like a bug.  Whoops.

Ian

Re: Testsuite MIPS libs/scanasm.exe allow mathing against (no)micromips/

[Richard Sandiford]

Graham Stott  writes:
> When micromips was added scanasm.exe wasn't updated this was causing a few 
> tests
> which scanned the assembler output to start failing such as
> dg.c++/debiug/dwarf2/lineno-simple1.C.
>  
> Fixed with the ollowing patch

Thanks.  I think we should only conditionally match the micromips part,
just in case anyone is testing with an older assembler.  Applied with
that tweak, as below.

Richard


gcc/testsuite/
2013-05-21  Graham Stott  

* lib/scanasm.exp (dg-function-on-line): Make MIPS targets match
.set (no)?micromips

Index: gcc/testsuite/lib/scanasm.exp
===
--- gcc/testsuite/lib/scanasm.exp   2013-01-10 20:30:57.257009075 +
+++ gcc/testsuite/lib/scanasm.exp   2013-05-21 19:22:55.618268581 +0100
@@ -493,7 +493,7 @@ proc dg-function-on-line { args } {
set pattern [format {\t;[^:]+:%d\n(\t[^\t]+\n)+%s:\n\t.PROC} \
  $line $symbol]
 } elseif { [istarget mips*-*-*] } {
-   set pattern [format {\t\.loc [0-9]+ %d 0( 
[^\n]*)?\n(\t.cfi_startproc[^\t]*\n)*\t\.set\t(no)?mips16\n\t\.ent\t%s\n\t\.type\t%s,
 @function\n%s:\n} \
+   set pattern [format {\t\.loc [0-9]+ %d 0( 
[^\n]*)?\n(\t.cfi_startproc[^\t]*\n)*\t\.set\t(no)?mips16\n\t(\.set\t(no)?micromips\n\t)?\.ent\t%s\n\t\.type\t%s,
 @function\n%s:\n} \
 $line $symbol $symbol $symbol]
 } else {
set pattern [format 
{%s:[^\t]*(\t.(fnstart|frame|mask|file)[^\t]*)*\t[^:]+:%d\n} \

[Patch, Fortran] PR57338 - add more missing constraint checks for assumed-rank

[Tobias Burnus]

That's a follow-up the just committed patch - which came too late in 
some cases.


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

Tobias
2013-05-21  Tobias Burnus  

	PR fortran/57338
	* intrinsic.c (do_check): Move some checks to ...
	(do_ts29113_check): ... this new function.
	(check_specific, gfc_intrinsic_sub_interface): Call it.

2013-05-21  Tobias Burnus  

	PR fortran/57338
	* gfortran.dg/assumed_type_6.f90: New.

diff --git a/gcc/fortran/intrinsic.c b/gcc/fortran/intrinsic.c
index ddf9d80..3251ebb 100644
--- a/gcc/fortran/intrinsic.c
+++ b/gcc/fortran/intrinsic.c
@@ -174,21 +174,14 @@ find_char_conv (gfc_typespec *from, gfc_typespec *to)
 }
 
 
-/* Interface to the check functions.  We break apart an argument list
-   and call the proper check function rather than forcing each
-   function to manipulate the argument list.  */
+/* Check TS29113, C407b for assumed type and C535b for assumed-rank,
+   and a likewise check for NO_ARG_CHECK.  */
 
 static bool
-do_check (gfc_intrinsic_sym *specific, gfc_actual_arglist *arg)
+do_ts29113_check (gfc_intrinsic_sym *specific, gfc_actual_arglist *arg)
 {
-  gfc_expr *a1, *a2, *a3, *a4, *a5;
   gfc_actual_arglist *a;
 
-  if (arg == NULL)
-return (*specific->check.f0) ();
-
-  /* Check TS29113, C407b for assumed type and C535b for assumed-rank,
- and a likewise check for NO_ARG_CHECK.  */
   for (a = arg; a; a = a->next)
 {
   if (!a->expr)
@@ -242,6 +235,22 @@ do_check (gfc_intrinsic_sym *specific, gfc_actual_arglist *arg)
 	}
 }
 
+  return true;
+}
+
+
+/* Interface to the check functions.  We break apart an argument list
+   and call the proper check function rather than forcing each
+   function to manipulate the argument list.  */
+
+static bool
+do_check (gfc_intrinsic_sym *specific, gfc_actual_arglist *arg)
+{
+  gfc_expr *a1, *a2, *a3, *a4, *a5;
+
+  if (arg == NULL)
+return (*specific->check.f0) ();
+
   a1 = arg->expr;
   arg = arg->next;
   if (arg == NULL)
@@ -4038,11 +4047,18 @@ check_specific (gfc_intrinsic_sym *specific, gfc_expr *expr, int error_flag)
   || specific->check.f1m == gfc_check_min_max_integer
   || specific->check.f1m == gfc_check_min_max_real
   || specific->check.f1m == gfc_check_min_max_double)
-return (*specific->check.f1m) (*ap);
+{
+  if (!do_ts29113_check (specific, *ap))
+	return false;
+  return (*specific->check.f1m) (*ap);
+}
 
   if (!sort_actual (specific->name, ap, specific->formal, &expr->where))
 return false;
 
+  if (!do_ts29113_check (specific, *ap))
+return false;
+
   if (specific->check.f3ml == gfc_check_minloc_maxloc)
 /* This is special because we might have to reorder the argument list.  */
 t = gfc_check_minloc_maxloc (*ap);
@@ -4352,6 +4368,9 @@ gfc_intrinsic_sub_interface (gfc_code *c, int error_flag)
   if (!sort_actual (name, &c->ext.actual, isym->formal, &c->loc))
 goto fail;
 
+  if (!do_ts29113_check (isym, c->ext.actual))
+goto fail;
+
   if (isym->check.f1 != NULL)
 {
   if (!do_check (isym, c->ext.actual))
diff --git a/gcc/testsuite/gfortran.dg/assumed_type_6.f90 b/gcc/testsuite/gfortran.dg/assumed_type_6.f90
new file mode 100644
index 000..78ff849
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/assumed_type_6.f90
@@ -0,0 +1,12 @@
+! { dg-do compile }
+!
+! PR fortran/
+!
+! Contributed by Vladimír Fuka
+!
+function avg(a)
+  integer :: avg
+  integer,intent(in) :: a(..)
+  
+  avg = sum(a)/size(a) ! { dg-error "Assumed-rank argument at .1. is only permitted as actual argument to intrinsic inquiry functions" }
+end function

Re: [Patch, Fortran] PR57035 - add constraint checks for type(*), dimension(..) and NO_ARG_CHECK

[Tobias Burnus]

I just realized that this patch wasn't committed - I did it now: Rev. 
199158.


Tobias

PS: Committed version attached, which honors the review comments.

On April 26,  2013 00:13, Mikael Morin wrote:

Hello,

Le 23/04/2013 09:58, Tobias Burnus a écrit :

The constraint checks for assumed-type and assumed-rank with regards to
intrinsics only worked very indirectly and, hence, was not strict
enough. That's now fixed with the attached patch - also for
NO_ARG_CHECK. For the latter, it also improves the wording a bit and
allows PRESENT as second permitted intrinsic. (That's the same as for
TYPE(*) minus the array intrinsics.)

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

diff --git a/gcc/fortran/gfortran.texi b/gcc/fortran/gfortran.texi
index f4bcdef..78ac0f7 100644
--- a/gcc/fortran/gfortran.texi
+++ b/gcc/fortran/gfortran.texi
@@ -2694,17 +2694,18 @@ with this attribute actual arguments of any type and 
kind (similar to
  @code{TYPE(*)}), scalars and arrays of any rank (no equivalent
  in Fortran standard) are accepted.  As with @code{TYPE(*)}, the argument
  is unlimited polymorphic and no type information is available.
-Additionally, the same restrictions apply, i.e. the argument may only be
-passed to dummy arguments with the @code{NO_ARG_CHECK} attribute and as
-argument to the @code{C_LOC} intrinsic function of the @code{ISO_C_BINDING}
-module.
+Additionally, the the argument may only be passed to dummy arguments

s/the the/the/


+with the @code{NO_ARG_CHECK} attribute and as argument to the
+@code{PRESENT} intrinsic function and to @code{C_LOC} of the
+@code{ISO_C_BINDING} module.
  
diff --git a/gcc/fortran/intrinsic.c b/gcc/fortran/intrinsic.c

index 688332f..cc62c6c 100644
--- a/gcc/fortran/intrinsic.c
+++ b/gcc/fortran/intrinsic.c
@@ -182,10 +182,65 @@ static bool

[...]

+  else if (a->expr->ts.type == BT_ASSUMED
+  && (a != arg
+  || (specific->id != GFC_ISYM_LBOUND
+  && specific->id != GFC_ISYM_PRESENT
+  && specific->id != GFC_ISYM_RANK
+  && specific->id != GFC_ISYM_SHAPE
+  && specific->id != GFC_ISYM_SIZE
+  && specific->id != GFC_ISYM_UBOUND
+  && specific->id != GFC_ISYM_C_LOC)))

I think that when both of the || conditions are true...


+   {
+ if (a != arg)
+   gfc_error ("Assumed-type argument at %L is only permitted as "
+  "first actual argument to the intrinsic %s",
+  &a->expr->where, gfc_current_intrinsic);
+ else
+   gfc_error ("Assumed-type argument at %L is not permitted as actual"
+  " argument to the intrinsic %s", &a->expr->where,
+  gfc_current_intrinsic);
+ return false;
+   }

... the second error should be preferred.
Testcase:

  subroutine thirteen(x, y)
type(*) :: x
integer, pointer :: y
print *, associated(y, x)
print *, associated(x)
  end subroutine thirteen


output:
test.f90:4.26:

print *, associated(y, x)
   1
Error: Assumed-type argument at (1) is only permitted as first actual
argument to the intrinsic associated
test.f90:5.23:

print *, associated(x)
1
Error: Assumed-type argument at (1) is not permitted as actual argument
to the intrinsic associated



Otherwise looks good.
Mikael





2013-05-21  Tobias Burnus  

	PR fortran/57035
	* intrinsic.c (do_check): Add contraint check for
	NO_ARG_CHECK, assumed rank and assumed type.
	* gfortran.texi (NO_ARG_CHECK): Minor wording change,
	allow PRESENT intrinsic.

2013-05-21  Tobias Burnus  

	PR fortran/57035
	* gfortran.dg/assumed_type_5.f90: New.
	* gfortran.dg/assumed_rank_1.f90: Comment invalid statement.
	* gfortran.dg/assumed_rank_2.f90: Ditto.
	* gfortran.dg/assumed_type_3.f90: Update dg-error.
	* gfortran.dg/no_arg_check_3.f90: Ditto.


diff --git a/gcc/fortran/gfortran.texi b/gcc/fortran/gfortran.texi
index f4bcdef..4a31a77 100644
--- a/gcc/fortran/gfortran.texi
+++ b/gcc/fortran/gfortran.texi
@@ -2694,17 +2694,18 @@ with this attribute actual arguments of any type and kind (similar to
 @code{TYPE(*)}), scalars and arrays of any rank (no equivalent
 in Fortran standard) are accepted.  As with @code{TYPE(*)}, the argument
 is unlimited polymorphic and no type information is available.
-Additionally, the same restrictions apply, i.e. the argument may only be
-passed to dummy arguments with the @code{NO_ARG_CHECK} attribute and as
-argument to the @code{C_LOC} intrinsic function of the @code{ISO_C_BINDING}
-module.
+Additionally, the argument may only be passed to dummy arguments
+with the @code{NO_ARG_CHECK} attribute and as argument to the
+@code{PRESENT} intrinsic function and to @code{C_LOC} of the
+@code{ISO_C_BINDING} module.
 
 Variables with @code{NO_ARG_CHECK} attribute shall be of assumed-type
-(@code{TYPE(*)}; recommended) or of an int

[4.8 PATCH, i386]: Fix PR 57356, SSE2 instructions generated with '-mno-sse2'

[Uros Bizjak]

Hello!

This patch avoids movdqu/movdqa when SSE2 is disabled. Although
-mno-sse2 is bordering on ABI violation for 64bit targets, the patch
is simple enough to fix movti_internal_rex64 pattern.

2013-05-21  Uros Bizjak  

PR target/57356
* config/i386/i386.md (*movti_internal_rex64): Emit movaps/movups
for non-sse2 targets.

Tested on x86_64-pc-linux-gnu {,-m32}. OK for 4.8 branch?

(The patch is also needed for 4.7 branch, but not for mainline, where
this problem is fixed by movti_internal/movti_internal_rex64 merge).

Uros.
Index: config/i386/i386.md
===
--- config/i386/i386.md (revision 199017)
+++ config/i386/i386.md (working copy)
@@ -1805,7 +1805,8 @@
 (const_string "V4SF")
   (match_test "TARGET_AVX")
 (const_string "TI")
-  (match_test "optimize_function_for_size_p (cfun)")
+  (ior (not (match_test "TARGET_SSE2"))
+   (match_test "optimize_function_for_size_p (cfun)"))
 (const_string "V4SF")
   ]
   (const_string "TI")))])

Re: [PATCH,RFC] Make libbacktrace more standalone

[Alexander Monakov]

On Mon, 20 May 2013, Ian Lance Taylor wrote:

> To be clear: are you withdrawing your earlier patch?

Yes; at this point I don't think it improves anything sufficiently to spend
more time on it.

Forgive me a digression, but having now actually used libbacktrace, I have
the following questions.

1. The documentation does not say whether reusing "state" objects is allowed.
For instance, I'm using backtrace_simple, and then in the callback I'm
invoking dladdr and backtrace_pcinfo to gather file-line info if available.
Looks like at the moment it's fine, as no frame-specific information is stored
there.

2. The reason I'm invoking dladdr instead of backtrace_syminfo is the need to
obtain the name of the module containing the symbol.  Is that intended?
(IOW, would be nice if libbacktrace syminfo callback provided name and base
address of the loaded module as well)

3. In libbacktrace/elf.c, elf_syminfo() does not seem to walk the chain of
elf_syminfo_data (i.e. does not use edata->next).  Is that a bug?

Thanks.

Alexander

Re: [GOOGLE] Back port discriminator patches to gcc-4_8

[Cary Coutant]

> Fixed the problem, and retested. New patch attached.

OK for the google/gcc-4_8 branch. Thanks!

-cary

[Fortran-Dev] Merge trunk into the branch

[Tobias Burnus]

I have merged the trunk into the branch: Rev. 199152

Tobias

Re: PATCH: PR plugins/56754 some missing plugin headers during installation in gcc 4.8

[Duncan Sands]

Hi Jakub, I actually committed this patch to mainline earlier today, as it is
trivial, enables my own plugin (dragonegg) to compile against gcc-4.8, and
according to the PR makes some other plugins work with gcc-4.8 too.  I will
backport it to the gcc-4.8 branch if no-one objects.  But maybe you are
objecting?

On 21/05/13 17:09, Jakub Jelinek wrote:

On Sat, Mar 30, 2013 at 03:17:59PM +0100, Magnus Granberg wrote:

This patch readd TARGET_H that was removed with revision 188166
IPA_PROP_H is in use by PLUGIN_HEADERS and did depend on GIMPLE_H that
did have TARGET_H before it was removed and it was not added to IPA_PROP_H or
PLUGIN_HEADERS. See the bug for more info.



2013-03-30  Magnus Granberg 


Two spaces before <, instead of just one.


I had corrected this one already in the version I committed.



PR plugins/56754
* Makefile.in (PLUGIN_HEADERS): Add TARGET_H


Missing dot at the end of line, plus it should be $(TARGET_H)
instead of TARGET_H.


I missed these however.  I will correct the changelog if you are otherwise
OK with the commit.



Where has it been tested?


In addition to what Jack mentioned, x86-64 ubuntu 13.04.

Ciao, Duncan.




--- a/gcc/Makefile.in   2013-02-08 10:07:49.0 +0100
+++ b/gcc/Makefile.in   2013-03-28 03:43:53.343390945 +0100
@@ -4597,7 +4597,7 @@ PLUGIN_HEADERS = $(TREE_H) $(CONFIG_H) $
$(C_PRAGMA_H)  $(CPPLIB_H)  $(FUNCTION_H) \
cppdefault.h flags.h $(MD5_H) params.def params.h prefix.h tree-inline.h \
$(GIMPLE_PRETTY_PRINT_H) realmpfr.h \
-  $(IPA_PROP_H) $(RTL_H) $(TM_P_H) $(CFGLOOP_H) $(EMIT_RTL_H) version.h
+  $(IPA_PROP_H) $(TARGET_H) $(RTL_H) $(TM_P_H) $(CFGLOOP_H) $(EMIT_RTL_H) 
version.h

  # generate the 'build fragment' b-header-vars
  s-header-vars: Makefile



Jakub

[rs6000] Add register save/restore routines for cross

[Eric Botcazou]

Hi,

this adds the register save/restore routines to libgcc for a couple of cross 
platforms that we use (powerpc-elf and powerpc-wrs-vxworks).  OK for mainline?


2013-05-20  Eric Botcazou  

libgcc/
* config.host (powerpc-*-elf*): Add rs6000/t-savresfgpr to tmake_file.
(powerpc-wrs-vxworks): Likewise.


-- 
Eric BotcazouIndex: config.host
===
--- config.host	(revision 199091)
+++ config.host	(working copy)
@@ -863,7 +863,7 @@ powerpc-*-eabisim*)
 	extra_parts="$extra_parts crtbegin.o crtend.o crtbeginS.o crtendS.o crtbeginT.o ecrti.o ecrtn.o ncrti.o ncrtn.o"
 	;;
 powerpc-*-elf*)
-	tmake_file="${tmake_file} rs6000/t-ppccomm rs6000/t-crtstuff t-crtstuff-pic t-fdpbit"
+	tmake_file="${tmake_file} rs6000/t-ppccomm rs6000/t-savresfgpr rs6000/t-crtstuff t-crtstuff-pic t-fdpbit"
 	extra_parts="$extra_parts crtbeginS.o crtendS.o crtbeginT.o ecrti.o ecrtn.o ncrti.o ncrtn.o"
 	;;
 powerpc-*-eabialtivec*)
@@ -888,7 +888,7 @@ powerpc*-*-linux*)
 	md_unwind_header=rs6000/linux-unwind.h
 	;;
 powerpc-wrs-vxworks|powerpc-wrs-vxworksae)
-	tmake_file="$tmake_file rs6000/t-ppccomm t-fdpbit"
+	tmake_file="$tmake_file rs6000/t-ppccomm rs6000/t-savresfgpr t-fdpbit"
 	;;
 powerpc-*-lynxos*)
 	tmake_file="$tmake_file rs6000/t-lynx t-fdpbit"

RE: [PATCH][gensupport] Add optional attributes field to define_cond_exec

[Kyrylo Tkachov]

Hi Richard,

> On 05/20/2013 09:55 AM, Kyrylo Tkachov wrote:
> > For example, a setup like:
> >
> > (define_attr "predicated" "yes,no" (const_string "no"))
> >
> > (define_attr "control_attr" "yes,no" (const_string "yes"))
> >
> >
> > (define_attr "enabled" "no,yes"
> >   (cond [(and (eq_attr "control_attr" "no")
> >   (and (eq_attr "predicated" "yes")
> >(eq_attr "TARGET_RESTRICT_CE" "no")))
> >  (const_string "no")]
> >  (const_string "yes"))
> >
> > (define_cond_exec
> >   [(match_operator 0 "arm_comparison_operator"
> > [(match_operand 1 "cc_register" "")
> >  (const_int 0)])]
> >   ""
> >   ""
> > [(set_attr "predicated" "yes")] //  New field
> > )
> >
> > (define_insn ...
> > [(set_attr "predicable" "yes")
> >  (set_attr "control_attr" "yes,no")]) //  disables predicated
> version of
> 
> We have a new define_subst which may help here.  I *think* that
> define_cond_exec is (or is nearly) a subset of define_subst.  On my
> medium term
> to-do list is to support define_cond_exec within gensupport via the
> define_subst infrastructure, removing everything except the actual
> parsing of
> define_cond_exec.

An clearer example of what I'm trying to achieve can be found here:
http://gcc.gnu.org/ml/gcc-patches/2013-05/msg01139.html

I've been trying to wrap my head around define_subst, and it was considered
initially, but from the online documentation
(http://gcc.gnu.org/onlinedocs/gccint/Define-Subst.html#Define-Subst)
I couldn't think of a way to use it.

What I want essentially, is to disable the cond_exec variant of an insn
based on some variable.
This stems from the fact that the "predicable" attribute cannot depend on
anything else
(has to be a compile-compile time constant).

> 
> Your "predicated" attribute could be mapped to a define_subst
> substitution.
> You could expose this via a true attribute, but I'm not 100% certain
> that you'd
> need to do so.
> 
> I havn't thought about all of the ramifications here, but I'd be
> interested to
> hear about your thoughts or experiments down this line.

Could you point me to any decent example of define_subst usage apart from
the documentation?
>From what I can see, define_subst performs RTL transformations, but doesn't
say anything about the attributes

Thanks,
Kyrill

> 
> 
> r~

[gomp4/cilk-in-gomp/cilkplus] C++ parsing for Cilk plus <#pragma simd>

[Iyer, Balaji V]

Hello Aldy et al.,  
Attached, please find a patch on top of gomp4 branch that implements 
Cilk's <#pragma simd> for C++. This is done in the same fashion as Aldy did in: 
http://gcc.gnu.org/ml/gcc-patches/2013-05/msg00678.html (It creates OMP_SIMD 
trees and let omp-low do the rest).

This patch should be applied on Aldy's branch aldyh/cilk-in-gomp. I have also 
included testsuite code that will catch several errors.

Aldy, is this OK for your branch?

Thanks,

Balaji V. Iyer.
diff --git gcc/ChangeLog.cilkplus gcc/ChangeLog.cilkplus
index 5e9fb79..8a7ed94 100644
--- gcc/ChangeLog.cilkplus
+++ gcc/ChangeLog.cilkplus
@@ -1,3 +1,8 @@
+2013-05-21  Balaji V. Iyer  
+
+testsuite/
+   * g++.dg/cilk-plus: New directory and associated infrastructure.
+
 2013-05-13  Aldy Hernandez  
 
* Makefile.in (C_COMMON_OBJS): Depend on c-family/c-cilkplus.o.
diff --git gcc/cp/ChangeLog.cilkplus gcc/cp/ChangeLog.cilkplus
new file mode 100755
index 000..7254b81
--- /dev/null
+++ gcc/cp/ChangeLog.cilkplus
@@ -0,0 +1,18 @@
+2013-05-21  Balaji V. Iyer  
+
+   * cp-tree.h (p_simd_valid_stmts_in_body_p): New prototype.
+   * parser.h (IN_CILK_P_SIMD_FOR): New #define.
+   * Make-lang.in (CXX_AND_OBJCXX_OBJS): Added new obj-file cp-cilkplus.o
+   * cp-cilkplus.c: New file.
+   * parser.c (cp_parser_pragma): Added a PRAGMA_CILK_SIMD case.
+   (cp_parser_cilk_simd_vectorlength): New function.
+   (cp_parser_cilk_simd_linear): Likewise.
+   (cp_parser_cilk_simd_clause_name): Likewise.
+   (cp_parser_cilk_simd_all_clauses): Likewise.
+   (cp_parser_cilk_simd_construct): Likewise.
+   (cp_parser_simd_for_init_statement): Likewise.
+   (cp_parser_cilk_for_expression_iterator): Likewise.
+   (cp_parser_cilk_for_condition): Likewise.
+   (cp_parser_cilk_for): Likewise.
+   (cp_parser_jump_statement): Added a IN_CILK_P_SIMD_FOR case.
+
diff --git gcc/cp/Make-lang.in gcc/cp/Make-lang.in
index cda4897..55ed6d4 100644
--- gcc/cp/Make-lang.in
+++ gcc/cp/Make-lang.in
@@ -80,7 +80,7 @@ CXX_AND_OBJCXX_OBJS = cp/call.o cp/decl.o cp/expr.o cp/pt.o 
cp/typeck2.o \
  cp/typeck.o cp/cvt.o cp/except.o cp/friend.o cp/init.o cp/method.o \
  cp/search.o cp/semantics.o cp/tree.o cp/repo.o cp/dump.o cp/optimize.o \
  cp/mangle.o cp/cp-objcp-common.o cp/name-lookup.o cp/cxx-pretty-print.o \
- cp/cp-gimplify.o $(CXX_C_OBJS)
+ cp/cp-gimplify.o cp/cp-cilkplus.o $(CXX_C_OBJS)
 
 # Language-specific object files for C++.
 CXX_OBJS = cp/cp-lang.o c-family/stub-objc.o $(CXX_AND_OBJCXX_OBJS)
@@ -345,3 +345,5 @@ cp/name-lookup.o: cp/name-lookup.c $(CONFIG_H) $(SYSTEM_H) 
coretypes.h \
 
 cp/cxx-pretty-print.o: cp/cxx-pretty-print.c $(CXX_PRETTY_PRINT_H) \
   $(CONFIG_H) $(SYSTEM_H) $(TM_H) coretypes.h $(CXX_TREE_H) tree-pretty-print.h
+cp/cp-cilkplus.o: cp/cp-cilkplus.c $(CONFIG_H) $(SYSTEM_H) coretypes.h \
+$(CXX_TREE_H) $(DIAGNOSTIC_CORE_H)
diff --git gcc/cp/cp-cilkplus.c gcc/cp/cp-cilkplus.c
new file mode 100755
index 000..118fd58
--- /dev/null
+++ gcc/cp/cp-cilkplus.c
@@ -0,0 +1,98 @@
+/* This file is part of the Intel(R) Cilk(TM) Plus support
+   This file contains routines to handle Cilk Plus specific
+   routines for the C++ Compiler.
+   Copyright (C) 2013  Free Software Foundation, Inc.
+   Contributed by Balaji V. Iyer ,
+ Aldy Hernandez .
+
+   This file is part of GCC.
+
+   GCC 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.
+
+   GCC 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 GCC; see the file COPYING3.  If not see
+   .  */
+
+#include "config.h"
+#include "system.h"
+#include "coretypes.h"
+#include "cp-tree.h"
+#include "diagnostic-core.h"
+
+
+/* This function is passed in as a function pointer to walk_tree.  *TP is
+   the current tree pointer, *WALK_SUBTREES is set to 0 by this function if
+   recursing into TP's subtrees is unnecessary. *DATA is a bool variable that
+   is set to false if an error has occured.  */
+
+static tree
+find_invalid_stmts (tree *tp, int *walk_subtrees, void *data)
+{
+  bool *valid = (bool *) data;
+  location_t loc = EXPR_HAS_LOCATION (*tp) ? EXPR_LOCATION (*tp) :
+UNKNOWN_LOCATION;
+  if (!tp || !*tp)
+return NULL_TREE;
+  else if (TREE_CODE (*tp) == GOTO_EXPR)
+{
+  error_at (loc, "goto statements are not allowed inside "
+   "loops marked with #pragma simd");
+  *valid = false;
+  *walk_subtrees = 0;
+}
+  else if (TREE_CODE (*tp) == THROW_EXPR)
+{
+  error_at (loc, "throw expressions are

Re: [PATCH] Allow nested use of attributes in MD-files

[Bernd Schmidt]

On 04/26/2013 05:17 PM, Michael Zolotukhin wrote:
> gcc/ChangeLog
> 2013-04-26  Michael Zolotukhin  
> 
> * read-rtl.c (copy_rtx_for_iterators): Continue applying iterators
> while it has any effect.

Ok.


Bernd

Re: PATCH: PR plugins/56754 some missing plugin headers during installation in gcc 4.8

[Jack Howarth]

On Tue, May 21, 2013 at 05:09:14PM +0200, Jakub Jelinek wrote:
> On Sat, Mar 30, 2013 at 03:17:59PM +0100, Magnus Granberg wrote:
> > This patch readd TARGET_H that was removed with revision 188166
> > IPA_PROP_H is in use by PLUGIN_HEADERS and did depend on GIMPLE_H that
> > did have TARGET_H before it was removed and it was not added to IPA_PROP_H 
> > or 
> > PLUGIN_HEADERS. See the bug for more info.
> 
> > 2013-03-30  Magnus Granberg 
> 
> Two spaces before <, instead of just one.
> > 
> > PR plugins/56754
> > * Makefile.in (PLUGIN_HEADERS): Add TARGET_H
> 
> Missing dot at the end of line, plus it should be $(TARGET_H)
> instead of TARGET_H.
> 
> Where has it been tested?

 This has been tested on i386-apple-darwin10, x86_64-apple-darwin10, 
x86_64-apple-darwin11 and
x86_64-apple-darwin12. The resulting gcc 4.8.1svn builds have been used to 
build dragonegg trunk
against gcc 4.8.1svn on x86_64-apple-darwin12.
> 
> > --- a/gcc/Makefile.in   2013-02-08 10:07:49.0 +0100
> > +++ b/gcc/Makefile.in   2013-03-28 03:43:53.343390945 +0100
> > @@ -4597,7 +4597,7 @@ PLUGIN_HEADERS = $(TREE_H) $(CONFIG_H) $
> >$(C_PRAGMA_H)  $(CPPLIB_H)  $(FUNCTION_H) \
> >cppdefault.h flags.h $(MD5_H) params.def params.h prefix.h tree-inline.h 
> > \
> >$(GIMPLE_PRETTY_PRINT_H) realmpfr.h \
> > -  $(IPA_PROP_H) $(RTL_H) $(TM_P_H) $(CFGLOOP_H) $(EMIT_RTL_H) version.h
> > +  $(IPA_PROP_H) $(TARGET_H) $(RTL_H) $(TM_P_H) $(CFGLOOP_H) $(EMIT_RTL_H) 
> > version.h
> >  
> >  # generate the 'build fragment' b-header-vars
> >  s-header-vars: Makefile
> 
> 
>   Jakub

Re: PATCH: PR plugins/56754 some missing plugin headers during installation in gcc 4.8

[Jakub Jelinek]

On Sat, Mar 30, 2013 at 03:17:59PM +0100, Magnus Granberg wrote:
> This patch readd TARGET_H that was removed with revision 188166
> IPA_PROP_H is in use by PLUGIN_HEADERS and did depend on GIMPLE_H that
> did have TARGET_H before it was removed and it was not added to IPA_PROP_H or 
> PLUGIN_HEADERS. See the bug for more info.

> 2013-03-30  Magnus Granberg 

Two spaces before <, instead of just one.
> 
>   PR plugins/56754
>   * Makefile.in (PLUGIN_HEADERS): Add TARGET_H

Missing dot at the end of line, plus it should be $(TARGET_H)
instead of TARGET_H.

Where has it been tested?

> --- a/gcc/Makefile.in 2013-02-08 10:07:49.0 +0100
> +++ b/gcc/Makefile.in 2013-03-28 03:43:53.343390945 +0100
> @@ -4597,7 +4597,7 @@ PLUGIN_HEADERS = $(TREE_H) $(CONFIG_H) $
>$(C_PRAGMA_H)  $(CPPLIB_H)  $(FUNCTION_H) \
>cppdefault.h flags.h $(MD5_H) params.def params.h prefix.h tree-inline.h \
>$(GIMPLE_PRETTY_PRINT_H) realmpfr.h \
> -  $(IPA_PROP_H) $(RTL_H) $(TM_P_H) $(CFGLOOP_H) $(EMIT_RTL_H) version.h
> +  $(IPA_PROP_H) $(TARGET_H) $(RTL_H) $(TM_P_H) $(CFGLOOP_H) $(EMIT_RTL_H) 
> version.h
>  
>  # generate the 'build fragment' b-header-vars
>  s-header-vars: Makefile


Jakub

Re: [PATCH] Fix simplify_cond_using_ranges ICE (PR tree-optimization/57331)

[Jeff Law]

On 05/21/2013 09:03 AM, Jakub Jelinek wrote:

Hi!

int_fits_type_p ICEs if the second argument is pointer type (those don't
have TYPE_MIN_VALUE/TYPE_MAX_VALUE).  Fixed thusly, bootstrapped/regtested
on x86_64-linux and i686-linux, ok for trunk?

2013-05-21  Jakub Jelinek  

PR tree-optimization/57331
* tree-vrp.c (simplify_cond_using_ranges): Don't optimize
comparison of conversion from pointer type to integral type
with integer.

* gcc.c-torture/compile/pr57331.c: New test.

Ok.  Sorry for the breakage.

jeff

[PATCH] Fix simplify_cond_using_ranges ICE (PR tree-optimization/57331)

[Jakub Jelinek]

Hi!

int_fits_type_p ICEs if the second argument is pointer type (those don't
have TYPE_MIN_VALUE/TYPE_MAX_VALUE).  Fixed thusly, bootstrapped/regtested
on x86_64-linux and i686-linux, ok for trunk?

2013-05-21  Jakub Jelinek  

PR tree-optimization/57331
* tree-vrp.c (simplify_cond_using_ranges): Don't optimize
comparison of conversion from pointer type to integral type
with integer.

* gcc.c-torture/compile/pr57331.c: New test.

--- gcc/tree-vrp.c.jj   2013-05-04 14:35:01.0 +0200
+++ gcc/tree-vrp.c  2013-05-21 12:07:33.382917422 +0200
@@ -8661,7 +8661,8 @@ simplify_cond_using_ranges (gimple stmt)
 
   innerop = gimple_assign_rhs1 (def_stmt);
 
-  if (TREE_CODE (innerop) == SSA_NAME)
+  if (TREE_CODE (innerop) == SSA_NAME
+ && !POINTER_TYPE_P (TREE_TYPE (innerop)))
{
  value_range_t *vr = get_value_range (innerop);
 
--- gcc/testsuite/gcc.c-torture/compile/pr57331.c.jj2013-05-21 
12:08:11.859697048 +0200
+++ gcc/testsuite/gcc.c-torture/compile/pr57331.c   2013-05-21 
12:06:27.0 +0200
@@ -0,0 +1,11 @@
+/* PR tree-optimization/57331 */
+
+int
+foo (int x)
+{
+  void *p = x ? (void *) 1 : (void *) 0;
+  __INTPTR_TYPE__ b = (__INTPTR_TYPE__) p;
+  if (b)
+return 0;
+  return 1;
+}

Jakub

Re: PATCH: contrib/repro_fail: filter out "-ignore SIGHUP" from spawn line

[David Malcolm]

On Tue, 2013-05-21 at 09:41 -0400, Diego Novillo wrote:
> On 2013-05-20 16:03 , David Malcolm wrote:
[...]
> >> BTW, I don't have commit rights to GCC (am reattaching the patch for
> >> convenience)
> > (I have svn rights now)
> Oh, that was it.  Sorry, it slipped my mind.  You can certainly commit 
> it now.

Thanks.  Committed to svn trunk as r199147.

Re: [patch] Preserve the CFG until after final

[Steven Bosscher]

On Tue, May 21, 2013 at 10:57 AM, Eric Botcazou wrote:
>> This patch allows targets to keep the CFG around until after final, by
>> skipping pass_free_cfg and CFG-destructive passes like dbr_schedule,
>> and by making insn splitting before 'final' use split_all_insns
>> instead of split_all_insns_noflow if pass_free_cfg was skipped.
>
> Well, you currently can't skip dbr_schedule if you have delay slots, c6x set
> aside, so I'm not sure whether we want to start another transition before even
> knowing if we can reasonably complete it.

That is only partially true. Currently the transition is already de
facto going on: Just look at how many back ends use
compute_bb_for_insn to re-initialize the BLOCK_FOR_INSN pointers right
after pass_free_cfg (it's usually the first thing they do in the
machine-reorg pass). Some ports never call free_bb_or_insn after that,
and expect BLOCK_FOR_INSN to be valid in 'final'. One of those ports
is i386, look at where BLOCK_FOR_INSN is used in i386.c (in functions
deciding what asm output templates to use).

Also, right now I'm stuck with a chicken-and-egg problem: dbr_schedule
is not CFG-aware, but my still slowly progressing work on a
replacement can't have a CFG because it has to run after machine-reorg
passes, and therefore after pass_free_cfg.


>> For the moment, only ix86 uses the CFG-aware version of the hook, but
>> there are a handful of targets that can be converted to do this also
>> (ia64, bfin, c6x, sparc, probably others).
>
> Not SPARC for sure.

Right, SPARC doesn't have a machine-reorg pass anymore. I was talking
about pass_work_around_errata, that runs after my CFG-aware
dbr_schedule,  properly maintaining the CFG.


>> I hope that maintainers will over time change their machine reorgs to
>> maintain the CFG, so that passes like pass_dwarf2_frame can use the
>> CFG instead of creating "a facsimile of one on the fly" (see
>> dwarf2cfi.c).
>
> I think that an incremental step would be to allow the machine reorg pass to
> use the CFG, even if it doesn't maintain it.

That is the current state of things already.


>  For the rest I'm not sure, as
> long as we have the dbr_schedule blocker.

But I need this exactly for that reason: To remove that blocker! :-)

Ciao!
Steven

Re: PATCH: contrib/repro_fail: filter out "-ignore SIGHUP" from spawn line

[Diego Novillo]

On 2013-05-20 16:03 , David Malcolm wrote:


Ping: OK if I commit this to trunk?


Absolutely.  I remembering approving this a while back.




BTW, I don't have commit rights to GCC (am reattaching the patch for
convenience)

(I have svn rights now)


Oh, that was it.  Sorry, it slipped my mind.  You can certainly commit 
it now.



Diego.

Re: [C++ Patch] More accurate location for conditional expressions

[Jason Merrill]

On 05/21/2013 06:13 AM, Paolo Carlini wrote:

@@ -2141,7 +2141,8 @@ rationalize_conditional_expr (enum tree_code code,
gcc_assert (!TREE_SIDE_EFFECTS (op0)
  && !TREE_SIDE_EFFECTS (op1));
return
-   build_conditional_expr (build_x_binary_op (input_location,
+   build_conditional_expr (input_location,
+   build_x_binary_op (input_location,
   (TREE_CODE (t) == MIN_EXPR
? LE_EXPR : GE_EXPR),
   op0, TREE_CODE (op0),
@@ -2154,7 +2155,7 @@ rationalize_conditional_expr (enum tree_code code,
  }

return
-build_conditional_expr (TREE_OPERAND (t, 0),
+build_conditional_expr (input_location, TREE_OPERAND (t, 0),


In rationalize_conditional_expr, it seems to me that we should be using 
EXPR_LOC_OR_HERE (t) rather than input_location.  OK with that change.


Jason

Re: RFA: Use gen_int_mode in plus_constant

[Andreas Krebbel]

On 21/05/13 11:26, Richard Sandiford wrote:
> Andreas Krebbel  writes:
>> On 21/05/13 10:39, Richard Sandiford wrote:
>>> Andreas Krebbel  writes:
 On 30/04/13 16:56, Richard Sandiford wrote:
> This patch fixes out the GEN_INT/gen_int_mode that Richard pointed out
> in the wide-int review.  It also passes "mode" rather than "VOIDmode"
> to immed_double_int_const.  (As discussed in that thread, the latter
> change shouldn't make any difference in practice, but is still more
> correct in principle.)
>
> Bootstrapped & regression-tested on x86_64-linux-gnu.  OK to install?
>
> Richard
>
> gcc/
>   * explow.c (plus_constant): Pass "mode" to immed_double_int_const.
>   Use gen_int_mode rather than GEN_INT.
>
> Index: gcc/explow.c
> ===
> --- gcc/explow.c  2013-02-25 09:41:58.0 +
> +++ gcc/explow.c  2013-04-30 15:52:57.270362112 +0100
> @@ -106,10 +106,10 @@ plus_constant (enum machine_mode mode, r
> if (overflow)
>   gcc_unreachable ();
>
> -   return immed_double_int_const (v, VOIDmode);
> +   return immed_double_int_const (v, mode);
>   }
>
> -  return GEN_INT (INTVAL (x) + c);
> +  return gen_int_mode (INTVAL (x) + c, mode);

 This calls trunc_int_for_mode which fails for mode == VOIDmode.
 On s390x gcc.c-torture/compile/20021008-1.c fails due to this.
>>>
>>> But it's invalid to pass mode == VOIDmode to plus_constant too.
>>> Which caller is causing trouble?
>>>
>>> Thanks,
>>> Richard
>>>
>>
>> Hi Richard,
>>
>> the call comes from reload when checking a const_int memory address.
> 
> Ah, thanks.  Could you give the patch below a go?
> 
> Richard
> 
> 
> gcc/
>   * recog.c (offsettable_address_addr_space_p): Fix calculation of
>   address mode.  Move pointer mode initialization to the same place.

Thanks! This fixed the failure (and others). Bootstrapped on s390x - no 
regressions:

< FAIL: gcc.c-torture/compile/20021008-1.c  -O1  (internal compiler error)
< FAIL: gcc.c-torture/compile/20021008-1.c  -O1  (test for excess errors)
< FAIL: gcc.c-torture/compile/20021008-1.c  -O2  (internal compiler error)
< FAIL: gcc.c-torture/compile/20021008-1.c  -O2  (test for excess errors)
< FAIL: gcc.c-torture/compile/20021008-1.c  -O3 -fomit-frame-pointer  (internal 
compiler error)
< FAIL: gcc.c-torture/compile/20021008-1.c  -O3 -fomit-frame-pointer  (test for 
excess errors)
< FAIL: gcc.c-torture/compile/20021008-1.c  -O3 -g  (internal compiler error)
< FAIL: gcc.c-torture/compile/20021008-1.c  -O3 -g  (test for excess errors)
< FAIL: gcc.c-torture/compile/20021008-1.c  -Os  (internal compiler error)
< FAIL: gcc.c-torture/compile/20021008-1.c  -Os  (test for excess errors)
< FAIL: gcc.c-torture/compile/20021008-1.c  -O2 -flto -fno-use-linker-plugin 
-flto-partition=none
(internal compiler error)
< FAIL: gcc.c-torture/compile/20021008-1.c  -O2 -flto -fno-use-linker-plugin 
-flto-partition=none
(test for excess errors)
< FAIL: gcc.c-torture/execute/pr31448-2.c compilation,  -O1  (internal compiler 
error)
< UNRESOLVED: gcc.c-torture/execute/pr31448-2.c execution,  -O1
< FAIL: gcc.c-torture/execute/pr31448-2.c compilation,  -O2  (internal compiler 
error)
< UNRESOLVED: gcc.c-torture/execute/pr31448-2.c execution,  -O2
< FAIL: gcc.c-torture/execute/pr31448-2.c compilation,  -O3 
-fomit-frame-pointer  (internal compiler
error)
< UNRESOLVED: gcc.c-torture/execute/pr31448-2.c execution,  -O3 
-fomit-frame-pointer
< FAIL: gcc.c-torture/execute/pr31448-2.c compilation,  -O3 -g  (internal 
compiler error)
< UNRESOLVED: gcc.c-torture/execute/pr31448-2.c execution,  -O3 -g
< FAIL: gcc.c-torture/execute/pr31448-2.c compilation,  -Os  (internal compiler 
error)
< UNRESOLVED: gcc.c-torture/execute/pr31448-2.c execution,  -Os
< FAIL: gcc.c-torture/execute/pr31448-2.c compilation,  -Og -g  (internal 
compiler error)
< UNRESOLVED: gcc.c-torture/execute/pr31448-2.c execution,  -Og -g
< FAIL: gcc.c-torture/execute/pr31448-2.c compilation,  -O2 -flto 
-fno-use-linker-plugin
-flto-partition=none  (internal compiler error)
< UNRESOLVED: gcc.c-torture/execute/pr31448-2.c execution,  -O2 -flto 
-fno-use-linker-plugin
-flto-partition=none
< FAIL: gcc.c-torture/execute/pr31448.c compilation,  -O1  (internal compiler 
error)
< UNRESOLVED: gcc.c-torture/execute/pr31448.c execution,  -O1
< FAIL: gcc.c-torture/execute/pr31448.c compilation,  -O2  (internal compiler 
error)
< UNRESOLVED: gcc.c-torture/execute/pr31448.c execution,  -O2
< FAIL: gcc.c-torture/execute/pr31448.c compilation,  -O3 -fomit-frame-pointer  
(internal compiler
error)
< UNRESOLVED: gcc.c-torture/execute/pr31448.c execution,  -O3 
-fomit-frame-pointer
< FAIL: gcc.c-torture/execute/pr31448.c compilation,  -O3 -g  (internal 
compiler error)
< UNRESOLVED: gcc.c-torture/execute/pr31448.c execution,  -O3 -g
< FAIL: gcc.c-torture/execute/pr31448.c compilation,

Testsuite MIPS libs/scanasm.exe allow mathing against (no)micromips/

[Graham Stott]

All,
 
When micromips was added scanasm.exe wasn't updated this was causing a few tests
which scanned the assembler output to start failing such as 
dg.c++/debiug/dwarf2/lineno-simple1.C.
 
Fixed with the ollowing patch
 
Graham

testuite/ChangeLog:
 
 21-05-2013   * graham stott  graham.st...@btinternet.com
* lib/scanasm.exp (dg-function-on-line) target mips-*-*-* allow matching 
aginst micromips
   directive
  
Index: scanasm.exp
===
--- scanasm.exp (revision 199093)
+++ scanasm.exp (working copy)
@@ -493,7 +493,7 @@
  set pattern [format {\t;[^:]+:%d\n(\t[^\t]+\n)+%s:\n\t.PROC} \
  $line $symbol]
 } elseif { [istarget mips*-*-*] } {
- set pattern [format {\t\.loc [0-9]+ %d 0( 
[^\n]*)?\n(\t.cfi_startproc[^\t]*\n)*\t\.set\t(no)?mips16\n\t\.ent\t%s\n\t\.type\t%s,
 @function\n%s:\n} \
+ set pattern [format {\t\.loc [0-9]+ %d 0( 
[^\n]*)?\n(\t.cfi_startproc[^\t]*\n)*\t\.set\t(no)?mips16\n\t\.set\t(no)?micromips\n\t\.ent\t%s\n\t\.type\t%s,
 @function\n%s:\n} \
    $line $symbol $symbol $symbol]
 } else {
  set pattern [format 
{%s:[^\t]*(\t.(fnstart|frame|mask|file)[^\t]*)*\t[^:]+:%d\n} \

RE: [gomp4/cilkplus] C parsing for Cilk Plus <#pragma simd>

[Iyer, Balaji V]

> -Original Message-
> From: Aldy Hernandez [mailto:al...@redhat.com]
> Sent: Tuesday, May 21, 2013 8:14 AM
> To: Iyer, Balaji V
> Cc: gcc-patches; Jakub Jelinek
> Subject: Re: [gomp4/cilkplus] C parsing for Cilk Plus <#pragma simd>
> 
> On 05/20/13 14:34, Iyer, Balaji V wrote:
> > Hello Aldy, I have moved a couple prototypes from c-tree.h to
> > c-family/c-common.h. This way I can use the same function for the C++
> > implementation. Here is a patch.
> >
> 
> OK for branch.
The patch is comitted.

Thanks,

Balaji V. Iyer.

Re: [PATCH] Fix incorrect discriminator assignment.

[Richard Biener]

On Fri, May 17, 2013 at 5:48 PM, Dehao Chen  wrote:
> On Fri, May 17, 2013 at 1:22 AM, Richard Biener
>  wrote:
>> On Wed, May 15, 2013 at 6:50 PM, Cary Coutant  wrote:
 gcc/ChangeLog:

 * tree-cfg.c (locus_descrim_hasher::hash): Only hash lineno.
 (locus_descrim_hasher::equal): Likewise.
 (next_discriminator_for_locus): Likewise.
 (assign_discriminator): Add return value.
 (make_edges): Assign more discriminator if necessary.
 (make_cond_expr_edges): Likewise.
 (make_goto_expr_edges): Likewise.

 gcc/testsuite/ChangeLog:

 * gcc.dg/debug/dwarf2/discriminator.c: New Test.
>>>
>>> Looks OK to me, but I can't approve patches for tree-cfg.c.
>>>
>>> Two comments:
>>>
>>> (1) In the C++ conversion, it looks like someone misspelled "discrim"
>>> in "locus_descrim_hasher".
>>>
>>> (2) Is this worth fixing in trunk when we'll eventually switch to a
>>> per-instruction discriminator?
>>
>>> This patch fixes a common case where one line is distributed to 3 BBs,
>>> but only 1 discriminator is assigned.
>>
>> As far as I can see the patch makes discriminators coarser (by hashing
>> and comparing on LOCATION_LINE and not on the location).  It also has
>> the changes like
>>
>> -  assign_discriminator (entry_locus, then_bb);
>> +  if (assign_discriminator (entry_locus, then_bb))
>> +assign_discriminator (entry_locus, bb);
>>
>> which is what the comment refers to?  I think those changes are short-sighted
>> because what happens if the 2nd assign_discriminator call has exactly the
>> same issue?  Especially with the make_goto_expr_edges change there
>> may be multiple predecessors where I cannot see how the change is
>> correct.  Yes, the change changes something and thus may fix the testcase
>> but it doesn't change things in a predictable way as far as I can see.
>>
>> So - the change to compare/hash LOCATION_LINE looks good to me,
>> but the assign_discriminator change needs more explaining.
>
> The new discriminator assignment algorithm is:
>
> 1 FOR_EACH_BB:
> 2   FOR_EACH_SUCC_EDGE:
> 3 if (same_line(bb, succ_bb))
> 4   if (succ_bb has no discriminator)
> 5  succ_bb->discriminator = new_discriminator
> 6   else if (bb has no discriminator)
> 7  bb->discriminator = new_discriminator
>
> Because there are so many places to handle SUCC_EDGE, thus the logic
> line #3, #4 is embedded within assign_discriminator function, and the
> logic in line #6 is encoded as the return value of
> assign_discriminator.

Hmm, as of current the code is hardly readable while the above makes sense
(well, apart from what happens if both succ and bb already have a
discriminator).

Can I make you refactor the current code to postpone discriminator assignment
until after make_edges completed, thus, do it in a postprocessing step done
exactly like outlined above?  That way also the whole thing, including
the currently global  discriminator_per_locus can be localized into a single
function.

Thanks,
Richard.


> Thanks,
> Dehao
>
>>
>> Richard.
>>
>>> -cary

Re: [PATCH, PR 57289] Fix streaming order in ipa_read_node_info

[Richard Biener]

On Tue, May 21, 2013 at 1:24 PM, Martin Jambor  wrote:
> Hi,
>
> PR 57289 is an LTO streaming issue.  We should process the bitpack
> before moving on to read other stuff in ipa_read_node_info because
> bp_unpack_value might read from the stream if there are many bits to
> read.  Fixed by the following patch which makes 454.calculix build
> with -flto again and also passes bootstrap and testing on
> x86_64-linux. OK for trunk?

Ok.

Thanks,
Richard.

> Thanks,
>
> Martin
>
>
> 2013-05-20  Martin Jambor  
>
> PR lto/57289
> * ipa-prop.c (ipa_read_node_info): Process param_used and
> controlled_uses in the same order as when writing.
>
> Index: src/gcc/ipa-prop.c
> ===
> --- src.orig/gcc/ipa-prop.c
> +++ src/gcc/ipa-prop.c
> @@ -3849,9 +3849,9 @@ ipa_read_node_info (struct lto_input_blo
>  info->uses_analysis_done = true;
>info->node_enqueued = false;
>for (k = 0; k < ipa_get_param_count (info); k++)
> -ipa_set_controlled_uses (info, k, streamer_read_hwi (ib));
> -  for (k = 0; k < ipa_get_param_count (info); k++)
>  ipa_set_param_used (info, k, bp_unpack_value (&bp, 1));
> +  for (k = 0; k < ipa_get_param_count (info); k++)
> +ipa_set_controlled_uses (info, k, streamer_read_hwi (ib));
>for (e = node->callees; e; e = e->next_callee)
>  {
>struct ipa_edge_args *args = IPA_EDGE_REF (e);

Re: [gomp4/cilkplus] C parsing for Cilk Plus <#pragma simd>

[Aldy Hernandez]

On 05/20/13 14:34, Iyer, Balaji V wrote:

Hello Aldy, I have moved a couple prototypes from c-tree.h to
c-family/c-common.h. This way I can use the same function for the C++
implementation. Here is a patch.



OK for branch.

Re: [PATCH] Fix PR57318

[Jakub Jelinek]

On Tue, May 21, 2013 at 01:58:54PM +0200, Richard Biener wrote:
> 
> The following fixes PR57318 where we estimate volatile loads to
> be eliminated.
> 
> Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
> 
> Ok for the branch?

Yes.

Jakub

[PATCH] Fix PR57318

[Richard Biener]

The following fixes PR57318 where we estimate volatile loads to
be eliminated.

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

Ok for the branch?

Thanks,
Richard.

2013-05-21  Richard Biener  

PR tree-optimization/57318
* tree-ssa-loop-ivcanon.c (tree_estimate_loop_size): Do not
estimate stmts with side-effects as likely eliminated.

Index: gcc/tree-ssa-loop-ivcanon.c
===
*** gcc/tree-ssa-loop-ivcanon.c (revision 199137)
--- gcc/tree-ssa-loop-ivcanon.c (working copy)
*** tree_estimate_loop_size (struct loop *lo
*** 257,264 
  
  /* Look for reasons why we might optimize this stmt away. */
  
  /* Exit conditional.  */
! if (exit && body[i] == exit->src
   && stmt == last_stmt (exit->src))
{
  if (dump_file && (dump_flags & TDF_DETAILS))
--- 257,266 
  
  /* Look for reasons why we might optimize this stmt away. */
  
+ if (gimple_has_side_effects (stmt))
+   ;
  /* Exit conditional.  */
! else if (exit && body[i] == exit->src
   && stmt == last_stmt (exit->src))
{
  if (dump_file && (dump_flags & TDF_DETAILS))

Re: [PATCH] Fix PR57330

[Jakub Jelinek]

On Tue, May 21, 2013 at 01:55:34PM +0200, Richard Biener wrote:
> 
> The following makes sure to preserve the call function type when
> redirecting edges.
> 
> Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
> 
> Ok for the branch?

Yes, we'll need to do rc2 most likely anyway.

> 2013-05-21  Richard Biener  
> 
>   PR tree-optimization/57330
>   * cgraph.c (cgraph_redirect_edge_call_stmt_to_callee): Properly
>   preserve the call stmts fntype.
> 
>   * gcc.dg/torture/pr57330.c: New testcase.

Jakub

[PATCH] Fix PR57330

[Richard Biener]

The following makes sure to preserve the call function type when
redirecting edges.

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

Ok for the branch?

Thanks,
Richard.

2013-05-21  Richard Biener  

PR tree-optimization/57330
* cgraph.c (cgraph_redirect_edge_call_stmt_to_callee): Properly
preserve the call stmts fntype.

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

Index: gcc/cgraph.c
===
*** gcc/cgraph.c(revision 199137)
--- gcc/cgraph.c(working copy)
*** cgraph_redirect_edge_call_stmt_to_callee
*** 1068,1073 
--- 1068,1074 
= gimple_call_copy_skip_args (e->call_stmt,
  e->callee->clone.combined_args_to_skip);
gimple_call_set_fndecl (new_stmt, e->callee->symbol.decl);
+   gimple_call_set_fntype (new_stmt, gimple_call_fntype (e->call_stmt));
  
if (gimple_vdef (new_stmt)
  && TREE_CODE (gimple_vdef (new_stmt)) == SSA_NAME)
Index: gcc/testsuite/gcc.dg/torture/pr57330.c
===
*** gcc/testsuite/gcc.dg/torture/pr57330.c  (revision 0)
--- gcc/testsuite/gcc.dg/torture/pr57330.c  (working copy)
***
*** 0 
--- 1,11 
+ /* { dg-do compile } */
+ 
+ void foo (int a)
+ {}
+ 
+ void *a;
+ void bar ()
+ {
+   void **( *b ) (  ) = (void**(*)()) foo;
+   a = b (0);
+ }

[PATCH, PR 57289] Fix streaming order in ipa_read_node_info

[Martin Jambor]

Hi,

PR 57289 is an LTO streaming issue.  We should process the bitpack
before moving on to read other stuff in ipa_read_node_info because
bp_unpack_value might read from the stream if there are many bits to
read.  Fixed by the following patch which makes 454.calculix build
with -flto again and also passes bootstrap and testing on
x86_64-linux. OK for trunk?

Thanks,

Martin


2013-05-20  Martin Jambor  

PR lto/57289
* ipa-prop.c (ipa_read_node_info): Process param_used and
controlled_uses in the same order as when writing.

Index: src/gcc/ipa-prop.c
===
--- src.orig/gcc/ipa-prop.c
+++ src/gcc/ipa-prop.c
@@ -3849,9 +3849,9 @@ ipa_read_node_info (struct lto_input_blo
 info->uses_analysis_done = true;
   info->node_enqueued = false;
   for (k = 0; k < ipa_get_param_count (info); k++)
-ipa_set_controlled_uses (info, k, streamer_read_hwi (ib));
-  for (k = 0; k < ipa_get_param_count (info); k++)
 ipa_set_param_used (info, k, bp_unpack_value (&bp, 1));
+  for (k = 0; k < ipa_get_param_count (info); k++)
+ipa_set_controlled_uses (info, k, streamer_read_hwi (ib));
   for (e = node->callees; e; e = e->next_callee)
 {
   struct ipa_edge_args *args = IPA_EDGE_REF (e);

[C++ Patch] More accurate location for conditional expressions

[Paolo Carlini]

Hi,

a little more work on locations. Yesterday, when I patched 
build_new_op_1 to propagate the incoming location to cp_build_binary_op 
I noticed that the locations for the conditional expressions in 
Wdouble-promotion.C where inaccurate, essentially always pointing to the 
end. We can improve the situation by adding a location_t parameter to 
build_conditional_expr and using it from build_x_conditional_expr. I'm 
also happy about the error message we get for cpp0x/explicit3.C: we used 
to also print spurious lines of code when printing notes about built-ins 
(eg, for line #44).


Tested x86_64-linux.

Thanks,
Paolo.

//


/cp
2013-05-21  Paolo Carlini  

* call.c (build_conditional_expr_1): Add location_t parameter.
(build_conditional_expr): Likewise.
* typeck.c (rationalize_conditional_expr, cp_build_array_ref,
get_member_function_from_ptrfunc, build_x_conditional_expr,
cp_build_modify_expr): Update.
* init.c (build_new_1): Likewise.
* cp-tree.h: Update declaration.

/testsuite
2013-05-21  Paolo Carlini  

* g++.dg/cpp0x/explicit3.C: Add column in dg-errors.
* g++.dg/warn/Wdouble-promotion.C: Likewise.
Index: cp/call.c
===
--- cp/call.c   (revision 199137)
+++ cp/call.c   (working copy)
@@ -4353,7 +4353,7 @@ conditional_conversion (tree e1, tree e2, tsubst_f
arguments to the conditional expression.  */
 
 static tree
-build_conditional_expr_1 (tree arg1, tree arg2, tree arg3,
+build_conditional_expr_1 (location_t loc, tree arg1, tree arg2, tree arg3,
   tsubst_flags_t complain)
 {
   tree arg2_type;
@@ -4373,7 +4373,7 @@ static tree
   if (!arg2)
 {
   if (complain & tf_error)
-   pedwarn (input_location, OPT_Wpedantic, 
+   pedwarn (loc, OPT_Wpedantic, 
 "ISO C++ forbids omitting the middle term of a ?: expression");
 
   /* Make sure that lvalues remain lvalues.  See g++.oliva/ext1.C.  */
@@ -4407,8 +4407,8 @@ static tree
  && TREE_CODE (arg3_type) != VECTOR_TYPE)
{
  if (complain & tf_error)
-   error ("at least one operand of a vector conditional operator "
-  "must be a vector");
+   error_at (loc, "at least one operand of a vector conditional "
+ "operator must be a vector");
  return error_mark_node;
}
 
@@ -4416,7 +4416,7 @@ static tree
  != (TREE_CODE (arg3_type) == VECTOR_TYPE))
{
  enum stv_conv convert_flag =
-   scalar_to_vector (input_location, VEC_COND_EXPR, arg2, arg3,
+   scalar_to_vector (loc, VEC_COND_EXPR, arg2, arg3,
  complain & tf_error);
 
  switch (convert_flag)
@@ -4448,9 +4448,10 @@ static tree
  || TYPE_SIZE (arg1_type) != TYPE_SIZE (arg2_type))
{
  if (complain & tf_error)
-   error ("incompatible vector types in conditional expression: "
-  "%qT, %qT and %qT", TREE_TYPE (arg1), TREE_TYPE (orig_arg2),
-  TREE_TYPE (orig_arg3));
+   error_at (loc,
+ "incompatible vector types in conditional expression: "
+ "%qT, %qT and %qT", TREE_TYPE (arg1),
+ TREE_TYPE (orig_arg2), TREE_TYPE (orig_arg3));
  return error_mark_node;
}
 
@@ -4535,15 +4536,15 @@ static tree
   if (complain & tf_error)
 {
   if (VOID_TYPE_P (arg2_type))
-error ("second operand to the conditional operator "
-   "is of type %, "
-   "but the third operand is neither a throw-expression "
-   "nor of type %");
+error_at (EXPR_LOC_OR_LOC (arg3, loc),
+ "second operand to the conditional operator "
+ "is of type %, but the third operand is "
+ "neither a throw-expression nor of type %");
   else
-error ("third operand to the conditional operator "
-   "is of type %, "
-   "but the second operand is neither a throw-expression "
-   "nor of type %");
+error_at (EXPR_LOC_OR_LOC (arg2, loc),
+ "third operand to the conditional operator "
+ "is of type %, but the second operand is "
+ "neither a throw-expression nor of type %");
 }
  return error_mark_node;
}
@@ -4583,8 +4584,8 @@ static tree
  || (conv3 && conv3->kind == ck_ambig))
{
  if (complain & tf_error)
-   error ("operands to ?: have different types %qT and %qT",
-  arg2_type, arg3_type);
+   error_at (loc, "operands to ?: have different types %qT and %qT",
+ arg2_

Re: RFA: Use gen_int_mode in plus_constant

[Richard Sandiford]

Andreas Krebbel  writes:
> On 21/05/13 10:39, Richard Sandiford wrote:
>> Andreas Krebbel  writes:
>>> On 30/04/13 16:56, Richard Sandiford wrote:
 This patch fixes out the GEN_INT/gen_int_mode that Richard pointed out
 in the wide-int review.  It also passes "mode" rather than "VOIDmode"
 to immed_double_int_const.  (As discussed in that thread, the latter
 change shouldn't make any difference in practice, but is still more
 correct in principle.)

 Bootstrapped & regression-tested on x86_64-linux-gnu.  OK to install?

 Richard

 gcc/
* explow.c (plus_constant): Pass "mode" to immed_double_int_const.
Use gen_int_mode rather than GEN_INT.

 Index: gcc/explow.c
 ===
 --- gcc/explow.c   2013-02-25 09:41:58.0 +
 +++ gcc/explow.c   2013-04-30 15:52:57.270362112 +0100
 @@ -106,10 +106,10 @@ plus_constant (enum machine_mode mode, r
  if (overflow)
gcc_unreachable ();

 -return immed_double_int_const (v, VOIDmode);
 +return immed_double_int_const (v, mode);
}

 -  return GEN_INT (INTVAL (x) + c);
 +  return gen_int_mode (INTVAL (x) + c, mode);
>>>
>>> This calls trunc_int_for_mode which fails for mode == VOIDmode.
>>> On s390x gcc.c-torture/compile/20021008-1.c fails due to this.
>> 
>> But it's invalid to pass mode == VOIDmode to plus_constant too.
>> Which caller is causing trouble?
>> 
>> Thanks,
>> Richard
>> 
>
> Hi Richard,
>
> the call comes from reload when checking a const_int memory address.

Ah, thanks.  Could you give the patch below a go?

Richard


gcc/
* recog.c (offsettable_address_addr_space_p): Fix calculation of
address mode.  Move pointer mode initialization to the same place.

Index: gcc/recog.c
===
--- gcc/recog.c 2013-04-29 12:38:00.0 +0100
+++ gcc/recog.c 2013-05-21 10:21:24.553671961 +0100
@@ -1953,9 +1953,6 @@ offsettable_address_addr_space_p (int st
 (strictp ? strict_memory_address_addr_space_p
 : memory_address_addr_space_p);
   unsigned int mode_sz = GET_MODE_SIZE (mode);
-#ifdef POINTERS_EXTEND_UNSIGNED
-  enum machine_mode pointer_mode = targetm.addr_space.pointer_mode (as);
-#endif
 
   if (CONSTANT_ADDRESS_P (y))
 return 1;
@@ -1966,6 +1963,13 @@ offsettable_address_addr_space_p (int st
   if (mode_dependent_address_p (y, as))
 return 0;
 
+  enum machine_mode address_mode = GET_MODE (y);
+  if (address_mode == VOIDmode)
+address_mode = targetm.addr_space.address_mode (as);
+#ifdef POINTERS_EXTEND_UNSIGNED
+  enum machine_mode pointer_mode = targetm.addr_space.pointer_mode (as);
+#endif
+
   /* ??? How much offset does an offsettable BLKmode reference need?
  Clearly that depends on the situation in which it's being used.
  However, the current situation in which we test 0x is
@@ -1981,7 +1985,7 @@ offsettable_address_addr_space_p (int st
   int good;
 
   y1 = *y2;
-  *y2 = plus_constant (GET_MODE (y), *y2, mode_sz - 1);
+  *y2 = plus_constant (address_mode, *y2, mode_sz - 1);
   /* Use QImode because an odd displacement may be automatically invalid
 for any wider mode.  But it should be valid for a single byte.  */
   good = (*addressp) (QImode, y, as);
@@ -2002,20 +2006,20 @@ offsettable_address_addr_space_p (int st
   if (GET_CODE (y) == LO_SUM
   && mode != BLKmode
   && mode_sz <= GET_MODE_ALIGNMENT (mode) / BITS_PER_UNIT)
-z = gen_rtx_LO_SUM (GET_MODE (y), XEXP (y, 0),
-   plus_constant (GET_MODE (y), XEXP (y, 1),
+z = gen_rtx_LO_SUM (address_mode, XEXP (y, 0),
+   plus_constant (address_mode, XEXP (y, 1),
   mode_sz - 1));
 #ifdef POINTERS_EXTEND_UNSIGNED
   /* Likewise for a ZERO_EXTEND from pointer_mode.  */
   else if (POINTERS_EXTEND_UNSIGNED > 0
   && GET_CODE (y) == ZERO_EXTEND
   && GET_MODE (XEXP (y, 0)) == pointer_mode)
-z = gen_rtx_ZERO_EXTEND (GET_MODE (y),
+z = gen_rtx_ZERO_EXTEND (address_mode,
 plus_constant (pointer_mode, XEXP (y, 0),
mode_sz - 1));
 #endif
   else
-z = plus_constant (GET_MODE (y), y, mode_sz - 1);
+z = plus_constant (address_mode, y, mode_sz - 1);
 
   /* Use QImode because an odd displacement may be automatically invalid
  for any wider mode.  But it should be valid for a single byte.  */

Re: RFA: Use gen_int_mode in plus_constant

[Andreas Krebbel]

On 21/05/13 10:39, Richard Sandiford wrote:
> Andreas Krebbel  writes:
>> On 30/04/13 16:56, Richard Sandiford wrote:
>>> This patch fixes out the GEN_INT/gen_int_mode that Richard pointed out
>>> in the wide-int review.  It also passes "mode" rather than "VOIDmode"
>>> to immed_double_int_const.  (As discussed in that thread, the latter
>>> change shouldn't make any difference in practice, but is still more
>>> correct in principle.)
>>>
>>> Bootstrapped & regression-tested on x86_64-linux-gnu.  OK to install?
>>>
>>> Richard
>>>
>>> gcc/
>>> * explow.c (plus_constant): Pass "mode" to immed_double_int_const.
>>> Use gen_int_mode rather than GEN_INT.
>>>
>>> Index: gcc/explow.c
>>> ===
>>> --- gcc/explow.c2013-02-25 09:41:58.0 +
>>> +++ gcc/explow.c2013-04-30 15:52:57.270362112 +0100
>>> @@ -106,10 +106,10 @@ plus_constant (enum machine_mode mode, r
>>>   if (overflow)
>>> gcc_unreachable ();
>>>
>>> - return immed_double_int_const (v, VOIDmode);
>>> + return immed_double_int_const (v, mode);
>>> }
>>>
>>> -  return GEN_INT (INTVAL (x) + c);
>>> +  return gen_int_mode (INTVAL (x) + c, mode);
>>
>> This calls trunc_int_for_mode which fails for mode == VOIDmode.
>> On s390x gcc.c-torture/compile/20021008-1.c fails due to this.
> 
> But it's invalid to pass mode == VOIDmode to plus_constant too.
> Which caller is causing trouble?
> 
> Thanks,
> Richard
> 

Hi Richard,

the call comes from reload when checking a const_int memory address.

Breakpoint 1, trunc_int_for_mode (c=16, mode=VOIDmode) at 
/home/andreas/clean/gcc-head/gcc/explow.c:55
55gcc_assert (SCALAR_INT_MODE_P (mode));
(gdb) bt
#0  trunc_int_for_mode (c=16, mode=VOIDmode) at 
/home/andreas/clean/gcc-head/gcc/explow.c:55
#1  0x802b23be in gen_int_mode (c=, mode=)
at /home/andreas/clean/gcc-head/gcc/emit-rtl.c:420
#2  0x802c4e6a in plus_constant (mode=, x=, c=15)
at /home/andreas/clean/gcc-head/gcc/explow.c:112
#3  0x804cfae6 in offsettable_address_addr_space_p 
(strictp=strictp@entry=0,
mode=, y=0x3fff7634480, as=)
at /home/andreas/clean/gcc-head/gcc/recog.c:2018
#4  0x804cfcb4 in offsettable_nonstrict_memref_p (op=)
at /home/andreas/clean/gcc-head/gcc/recog.c:1931
#5  0x804ec024 in find_reloads (insn=0x3fff7711708, replace=,
ind_levels=, live_known=, 
reload_reg_p=)
at /home/andreas/clean/gcc-head/gcc/reload.c:3395
#6  0x804f86de in calculate_needs_all_insns (global=)
at /home/andreas/clean/gcc-head/gcc/reload1.c:1520
#7  reload (first=0x3fff7722040, global=)
at /home/andreas/clean/gcc-head/gcc/reload1.c:941
#8  0x80405aa2 in do_reload () at 
/home/andreas/clean/gcc-head/gcc/ira.c:4653
#9  rest_of_handle_reload () at /home/andreas/clean/gcc-head/gcc/ira.c:4753
#10 0x804aa42a in execute_one_pass (pass=pass@entry=0x80c580e0 
)
at /home/andreas/clean/gcc-head/gcc/passes.c:2337
#11 0x804aa870 in execute_pass_list (pass=0x80c580e0 )
at /home/andreas/clean/gcc-head/gcc/passes.c:2389
#12 0x804aa88c in execute_pass_list (pass=0x80c587d0 
)
at /home/andreas/clean/gcc-head/gcc/passes.c:2390
#13 0x80224464 in expand_function (node=0x3fff7721000)
at /home/andreas/clean/gcc-head/gcc/cgraphunit.c:1648
#14 0x80226472 in expand_all_functions ()
at /home/andreas/clean/gcc-head/gcc/cgraphunit.c:1752
#15 compile () at /home/andreas/clean/gcc-head/gcc/cgraphunit.c:2050
#16 0x80226b98 in finalize_compilation_unit ()
at /home/andreas/clean/gcc-head/gcc/cgraphunit.c:2127
#17 0x800f2e1e in c_write_global_declarations ()
at /home/andreas/clean/gcc-head/gcc/c/c-decl.c:10118
#18 0x8055a990 in compile_file () at 
/home/andreas/clean/gcc-head/gcc/toplev.c:558
#19 0x8055caf0 in do_compile () at 
/home/andreas/clean/gcc-head/gcc/toplev.c:1872
#20 toplev_main (argc=18, argv=0x3fff148) at 
/home/andreas/clean/gcc-head/gcc/toplev.c:1948
#21 0x03fffdc99088 in __libc_start_main (main=0x800d4bbc ,
argc=, ubp_av=0x3fff148, init=,
fini=0x809e4a8c <__libc_csu_fini>, rtld_fini=0x3fffdfed8f4 <_dl_fini>, 
stack_end=0x3fff090)
at libc-start.c:226
#22 0x800d4c1e in _start ()
(gdb) frame 5
#5  0x804ec024 in find_reloads (insn=0x3fff7711708, replace=,
ind_levels=, live_known=, 
reload_reg_p=)
at /home/andreas/clean/gcc-head/gcc/reload.c:3395
3395  : offsettable_nonstrict_memref_p 
(operand))
(gdb) p debug_rtx(insn)
(insn 7 18 12 2 (set (mem/v/c:TF (plus:DI (reg/f:DI 15 %r15)
(const_int 160 [0xa0])) [0 val+0 S16 A64])
(mem:TF (const_int 1 [0x1]) [0 MEM[(long double *)buf_3(D) + 1B]+0 S16 
A64]))
/home/andreas/clean/gcc-head/gcc/testsuite/gcc.c-torture/compile/20021008-1.c:9 
78 {*movtf_64}
 (nil))

Bye,

-Andreas-

Re: [patch] Preserve the CFG until after final

[Eric Botcazou]

> This patch allows targets to keep the CFG around until after final, by
> skipping pass_free_cfg and CFG-destructive passes like dbr_schedule,
> and by making insn splitting before 'final' use split_all_insns
> instead of split_all_insns_noflow if pass_free_cfg was skipped.

Well, you currently can't skip dbr_schedule if you have delay slots, c6x set 
aside, so I'm not sure whether we want to start another transition before even 
knowing if we can reasonably complete it.

> For the moment, only ix86 uses the CFG-aware version of the hook, but
> there are a handful of targets that can be converted to do this also
> (ia64, bfin, c6x, sparc, probably others).

Not SPARC for sure.

> I hope that maintainers will over time change their machine reorgs to
> maintain the CFG, so that passes like pass_dwarf2_frame can use the
> CFG instead of creating "a facsimile of one on the fly" (see
> dwarf2cfi.c).

I think that an incremental step would be to allow the machine reorg pass to 
use the CFG, even if it doesn't maintain it.  For the rest I'm not sure, as 
long as we have the dbr_schedule blocker.

-- 
Eric Botcazou

Re: RFA: Use gen_int_mode in plus_constant

[Richard Sandiford]

Andreas Krebbel  writes:
> On 30/04/13 16:56, Richard Sandiford wrote:
>> This patch fixes out the GEN_INT/gen_int_mode that Richard pointed out
>> in the wide-int review.  It also passes "mode" rather than "VOIDmode"
>> to immed_double_int_const.  (As discussed in that thread, the latter
>> change shouldn't make any difference in practice, but is still more
>> correct in principle.)
>> 
>> Bootstrapped & regression-tested on x86_64-linux-gnu.  OK to install?
>> 
>> Richard
>> 
>> gcc/
>>  * explow.c (plus_constant): Pass "mode" to immed_double_int_const.
>>  Use gen_int_mode rather than GEN_INT.
>> 
>> Index: gcc/explow.c
>> ===
>> --- gcc/explow.c 2013-02-25 09:41:58.0 +
>> +++ gcc/explow.c 2013-04-30 15:52:57.270362112 +0100
>> @@ -106,10 +106,10 @@ plus_constant (enum machine_mode mode, r
>>if (overflow)
>>  gcc_unreachable ();
>> 
>> -  return immed_double_int_const (v, VOIDmode);
>> +  return immed_double_int_const (v, mode);
>>  }
>> 
>> -  return GEN_INT (INTVAL (x) + c);
>> +  return gen_int_mode (INTVAL (x) + c, mode);
>
> This calls trunc_int_for_mode which fails for mode == VOIDmode.
> On s390x gcc.c-torture/compile/20021008-1.c fails due to this.

But it's invalid to pass mode == VOIDmode to plus_constant too.
Which caller is causing trouble?

Thanks,
Richard

Re: [patch] fix libstdc++/57336

[Jonathan Wakely]

On 21 May 2013 09:24, Daniel Krügler wrote:
> 2013/5/21 Jonathan Wakely :
>> This broke due to some front end changes that disallow forming
>> function types that return abstract types.  std::reference_wrapper
>> always passes an lvalue reference to __invoke so it's correct to use
>> an lvalue reference as the result_of's template argument.
>
> I agree. This was
>
> http://cplusplus.github.io/LWG/lwg-defects.html#2017
>
> wasn't it?

Ah yes, thanks!  I'd fixed the signature in reference_wrapper but not
its __invoke() helper.

It's fixed on trunk and the 4.8 branch now.

>
> - Daniel

Re: Fix PR tree-optimization/57322

[Richard Biener]

On Mon, May 20, 2013 at 4:04 PM, Steven Bosscher  wrote:
> On Mon, May 20, 2013 at 4:00 PM, Easwaran Raman wrote:
>> If your suggestion is to use that
>> instead of 1 when BB == NULL, that would work (even though setting it
>> to 1 is sufficient.)
>
> That's what I suggest, yes. I understand that 1 is sufficient for now,
> but you never know if/when someone will use these uids for something
> else within the pass and expect them to be more-or-less unique (only
> non-unique for consecutive insns).
>
> But I have no strong preference either way, 1 or max+1.

It has to be 1 for correctness reason.

The patch is ok with the testcase included.

Thanks,
Richard.

> Ciao!
> Steven

RE: [PATCH][gensupport] Add optional attributes field to define_cond_exec

[Kyrylo Tkachov]

Hi Steven,

> >  This would allow us to, for example, disable the predicable variant
> of an
> > insn
> > based on a non-constant variable.
> 
> Is there a reason why you can't use attribute "enabled" for this?

The problem stems from the fact that the "predicable" attribute cannot have
a dynamic value.

Consider a pattern from the arm backend (config/arm/sync.md):

(define_insn "atomic_loaddi_1"
  [(set (match_operand:DI 0 "s_register_operand" "=r")
(unspec:DI [(match_operand:DI 1 "mem_noofs_operand" "Ua")]
   UNSPEC_LL))]
  "TARGET_HAVE_LDREXD && ARM_DOUBLEWORD_ALIGN"
  "ldrexd%?\t%0, %H0, %C1"
  [(set_attr "predicable" "yes")])

Now, say I want to disable the cond_exec variant of this when
TARGET_RESTRICT_CE is set.
If I wanted to do it with the "enabled" attribute I would have to do
something like

(define_insn "atomic_loaddi_1"
  [(set (match_operand:DI 0 "s_register_operand" "=r,r")
(unspec:DI [(match_operand:DI 1 "mem_noofs_operand" "Ua,Ua")]
   UNSPEC_LL))]
  "TARGET_HAVE_LDREXD && ARM_DOUBLEWORD_ALIGN"
  "ldrexd%?\t%0, %H0, %C1"
  [(set_attr "predicable" "yes,no")
   (set_attr_alternative "enabled" [(if_then_else (match_test
"TARGET_RESTRICT_CE")
  (const_string "no")
  (const_string "yes"))
(if_then_else (match_test
"TARGET_RESTRICT_CE")
  (const_string "yes")
  (const_string "no")) ])])

A slightly cleaner approach would be to define an extra attribute:

(define_attr "control_attr" "yes,no" (const_string "yes"))

(define_attr "enabled" "no,yes"
  (cond [(and (eq_attr "control_attr" "no")
  (match_test "TARGET_RESTRICT_CE"))
 (const_string "no")]
 (const_string "yes"))

(define_insn "atomic_loaddi_1"
  [(set (match_operand:DI 0 "s_register_operand" "=r,r")
(unspec:DI [(match_operand:DI 1 "mem_noofs_operand" "Ua,Ua")]
   UNSPEC_LL))]
  "TARGET_HAVE_LDREXD && ARM_DOUBLEWORD_ALIGN"
  "ldrexd%?\t%0, %H0, %C1"
  [(set_attr "predicable" "yes,no")
   (set_attr "control_attr" "no,yes")])

This helps, but still requires me to duplicate the constraint string, which
for more complicated patterns
(for example, the arm_addsi3 pattern in arm.md has 14 alternatives) would
create a big mess.

With my proposed scheme we would have the setup:

(define_attr "predicated" "yes,no" (const_string "no"))

(define_attr "control_attr" "yes,no" (const_string "yes"))


(define_attr "enabled" "no,yes"
  (cond [(and (eq_attr "control_attr" "no")
  (and (eq_attr "predicated" "yes")
   (match_test "TARGET_RESTRICT_CE")))
 (const_string "no")]
 (const_string "yes"))

(define_cond_exec
  [(match_operator 0 "arm_comparison_operator"
[(match_operand 1 "cc_register" "")
 (const_int 0)])]
  ""
  ""
[(set_attr "predicated" "yes")])

and the above pattern would now be:

(define_insn "atomic_loaddi_1"
  [(set (match_operand:DI 0 "s_register_operand" "=r")
(unspec:DI [(match_operand:DI 1 "mem_noofs_operand" "Ua")]
   UNSPEC_LL))]
  "TARGET_HAVE_LDREXD && ARM_DOUBLEWORD_ALIGN"
  "ldrexd%?\t%0, %H0, %C1"
  [(set_attr "predicable" "yes")
   (set_attr "control_var" "no")]) // <


We only add one attribute to the pattern.
Any other approach I may have missed?

Thanks,
Kyrill

Re: [patch] install host specific {bits,ext}/opt_random.h headers in host specific c++ incdir

[Matthias Klose]

Am 19.05.2013 11:40, schrieb Paolo Carlini:
> On 05/19/2013 11:35 AM, Andreas Schwab wrote:
>> Tests that now fail, but worked before:
> Thanks Andreas. Matthias, please revert ASAP, thanks.

you already did that.

Looks like ext/random includes opt_random.h, which is not on any include dir, so
make it ext/opt_random.h.  tests all pass, and check the include with an
installed version too.

  Matthias


# DP: Install host specific libstdc++ headers into the host include dir

2013-05-11  Matthias Klose  

* include/Makefile.am (bits_headers): Remove ${bits_host_headers}.
(ext_headers): Remove ${ext_host_headers}.
(stamp-${host_alias}): Create ${host_builddir}/../ext.
(stamp-host): Link ${bits_host_headers} and ${ext_host_headers}.
(install-headers): Install ${bits_host_headers} and ${ext_host_headers}.
* include/Makefile.in: Regenerate.
* include/ext/random: Include ext/opt_random.h.

Index: b/src/libstdc++-v3/include/Makefile.am
===
--- a/src/libstdc++-v3/include/Makefile.am  2013-05-12 17:29:35.231053893 
+
+++ b/src/libstdc++-v3/include/Makefile.am  2013-05-19 11:45:38.434218502 
+
@@ -172,8 +172,7 @@
${bits_srcdir}/valarray_array.tcc \
${bits_srcdir}/valarray_before.h \
${bits_srcdir}/valarray_after.h \
-   ${bits_srcdir}/vector.tcc \
-   ${bits_host_headers}
+   ${bits_srcdir}/vector.tcc
 
 bits_host_headers = \
${glibcxx_srcdir}/${CPU_OPT_BITS_RANDOM}
@@ -535,8 +534,7 @@
${ext_srcdir}/vstring.tcc \
${ext_srcdir}/vstring_fwd.h \
${ext_srcdir}/vstring_util.h \
-   ${ext_compat_headers} \
-   ${ext_host_headers}
+   ${ext_compat_headers}
 
 ext_compat_headers = \
${backward_srcdir}/hash_set \
@@ -1048,13 +1046,14 @@
 
 stamp-${host_alias}:
@-mkdir -p ${host_builddir}
+   @-mkdir -p ${host_builddir}/../ext
@$(STAMP) stamp-${host_alias}
 
 # Host includes static.
 # XXX Missing dependency info for {host_headers_extra}
-stamp-host: ${host_headers} ${host_headers_noinst} stamp-${host_alias}
+stamp-host: ${host_headers} ${bits_host_headers} ${ext_host_headers} 
${host_headers_noinst} stamp-${host_alias}
@cd ${host_builddir} && {\
- $(LN_S) ${host_headers} . || true ;\
+ $(LN_S) ${host_headers} ${bits_host_headers} . || true ;\
  $(LN_S) ${glibcxx_srcdir}/$(BASIC_FILE_H) basic_file.h || true ;\
  $(LN_S) ${glibcxx_srcdir}/$(ALLOCATOR_H) c++allocator.h || true ;\
  $(LN_S) ${glibcxx_srcdir}/$(CSTDIO_H) c++io.h || true ;\
@@ -1064,6 +1063,9 @@
  $(LN_S) ${glibcxx_srcdir}/$(CMESSAGES_H) messages_members.h || true ;\
  $(LN_S) ${glibcxx_srcdir}/$(CTIME_H) time_members.h || true;\
} 2>/dev/null
+   @cd ${host_builddir}/../ext && {\
+ $(LN_S) ${ext_host_headers} . || true ;\
+   } 2>/dev/null
$(STAMP) stamp-host
 
 # Host includes dynamic.
@@ -1290,9 +1292,12 @@
for file in ${profile_impl_headers}; do \
  $(INSTALL_DATA) $${file} 
$(DESTDIR)${gxx_include_dir}/${profile_impl_builddir}; done
$(mkinstalldirs) $(DESTDIR)${host_installdir}
-   for file in ${host_headers} ${host_headers_extra} \
+   for file in ${host_headers} ${bits_host_headers} ${host_headers_extra} \
 ${thread_host_headers}; do \
  $(INSTALL_DATA) $${file} $(DESTDIR)${host_installdir}; done
+   $(mkinstalldirs) $(DESTDIR)${host_installdir}/../ext
+   for file in ${ext_host_headers}; do \
+ $(INSTALL_DATA) $${file} $(DESTDIR)${host_installdir}/../ext; done
 
 # By adding these files here, automake will remove them for 'make clean'
 CLEANFILES = ${pch_output} ${pch_output_anchors} stamp-host
Index: b/src/libstdc++-v3/include/Makefile.in
===
--- a/src/libstdc++-v3/include/Makefile.in  2013-05-12 17:29:35.231053893 
+
+++ b/src/libstdc++-v3/include/Makefile.in  2013-05-19 11:46:14.778466710 
+
@@ -434,8 +434,7 @@
${bits_srcdir}/valarray_array.tcc \
${bits_srcdir}/valarray_before.h \
${bits_srcdir}/valarray_after.h \
-   ${bits_srcdir}/vector.tcc \
-   ${bits_host_headers}
+   ${bits_srcdir}/vector.tcc
 
 bits_host_headers = \
${glibcxx_srcdir}/${CPU_OPT_BITS_RANDOM}
@@ -795,8 +794,7 @@
${ext_srcdir}/vstring.tcc \
${ext_srcdir}/vstring_fwd.h \
${ext_srcdir}/vstring_util.h \
-   ${ext_compat_headers} \
-   ${ext_host_headers}
+   ${ext_compat_headers}
 
 ext_compat_headers = \
${backward_srcdir}/hash_set \
@@ -1461,13 +1459,14 @@
 
 stamp-${host_alias}:
@-mkdir -p ${host_builddir}
+   @-mkdir -p ${host_builddir}/../ext
@$(STAMP) stamp-${host_alias}
 
 # Host includes static.
 # XXX Missing dependency info for {host_headers_extra}
-stamp-host: ${host_headers} ${host_headers_noin

Re: [patch] fix libstdc++/57336

[Daniel Krügler]

2013/5/21 Jonathan Wakely :
> This broke due to some front end changes that disallow forming
> function types that return abstract types.  std::reference_wrapper
> always passes an lvalue reference to __invoke so it's correct to use
> an lvalue reference as the result_of's template argument.

I agree. This was

http://cplusplus.github.io/LWG/lwg-defects.html#2017

wasn't it?

- Daniel

Re: [PATCH] [tree-optimization/57124] Updated fix for 254.gap problems

[Richard Biener]

On Fri, May 17, 2013 at 5:51 PM, Jeff Law  wrote:
> As I believe I pointed out in a follow-up message, 254.gap is depending on
> signed overflow semantics.
>
> This patch avoids eliminating a cast feeding a conditional when the
> SSA_NAME's range has overflowed unless -fstrict-overflow is in effect. Thus
> 254.gap should be building with -fno-strict-overflow.
>
> This patch also introduces a warning when the optimization is applied and
> the ranges have overflowed.
>
> Bootstrapped and regression tested on x86-unknown-linux-gnu.
>
> OK for the trunk?
>
>
>
>
> commit 62bbaa8de0e8d929eb3c63331b47950e9b09d801
> Author: Jeff Law 
> Date:   Wed May 1 12:33:20 2013 -0600
>
> PR tree-optimization/57124
> * tree-vrp.c (simplify_cond_using_ranges): Only simplify a
> conversion feeding a condition if the range has an overflow
> if -fstrict-overflow.  Add warnings for when we do make the
> transformation.
>
> PR tree-optimization/57124
> * gcc.c-torture/execute/pr57124.c: New test.
> * gcc.c-torture/execute/pr57124.x: Set -fno-strict-overflow.
>
> diff --git a/gcc/ChangeLog b/gcc/ChangeLog
> index 8e92c44..9320f21 100644
> --- a/gcc/ChangeLog
> +++ b/gcc/ChangeLog
> @@ -1,3 +1,11 @@
> +2013-05-17  Jeff Law  
> +
> +   PR tree-optimization/57124
> +   * tree-vrp.c (simplify_cond_using_ranges): Only simplify a
> +   conversion feeding a condition if the range has an overflow
> +   if -fstrict-overflow.  Add warnings for when we do make the
> +   transformation.
> +
>  2013-05-16  Rainer Orth  
>
> * reorg.c (link_cc0_insns): Wrap in #ifdef HAVE_cc0.
> diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
> index 879b9bc..482151c 100644
> --- a/gcc/testsuite/ChangeLog
> +++ b/gcc/testsuite/ChangeLog
> @@ -1,3 +1,9 @@
> +2013-05-17  Jeff Law  
> +
> +   PR tree-optimization/57124
> +   * gcc.c-torture/execute/pr57124.c: New test.
> +   * gcc.c-torture/execute/pr57124.x: Set -fno-strict-overflow.
> +
>  2013-05-16  Greta Yorsh  
>
> * gcc.target/arm/unaligned-memcpy-2.c: Adjust expected output.
> diff --git a/gcc/testsuite/gcc.c-torture/execute/pr57124.c
> b/gcc/testsuite/gcc.c-torture/execute/pr57124.c
> new file mode 100644
> index 000..835d249
> --- /dev/null
> +++ b/gcc/testsuite/gcc.c-torture/execute/pr57124.c
> @@ -0,0 +1,27 @@
> +__attribute__ ((noinline))
> +foo(short unsigned int *p1, short unsigned int *p2)
> +{
> +  short unsigned int x1, x4;
> +  int x2, x3, x5, x6;
> +  unsigned int x7;
> +
> +  x1 = *p1;
> +  x2 = (int) x1;
> +  x3 = x2 * 65536;
> +  x4 = *p2;
> +  x5 = (int) x4;
> +  x6 = x3 + x4;
> +  x7 = (unsigned int) x6;
> +  if (x7 <= 268435455U)
> +abort ();
> +  exit (0);
> +}
> +
> +main()
> +{
> +  short unsigned int x, y;
> +  x = -5;
> +  y = -10;
> +  foo (&x, &y);
> +}
> +
> diff --git a/gcc/testsuite/gcc.c-torture/execute/pr57124.x
> b/gcc/testsuite/gcc.c-torture/execute/pr57124.x
> new file mode 100644
> index 000..d8cacbe
> --- /dev/null
> +++ b/gcc/testsuite/gcc.c-torture/execute/pr57124.x
> @@ -0,0 +1,2 @@
> +set additional_flags "-fno-strict-overflow"
> +return 0
> diff --git a/gcc/tree-vrp.c b/gcc/tree-vrp.c
> index b5de683..b3eccf0 100644
> --- a/gcc/tree-vrp.c
> +++ b/gcc/tree-vrp.c
> @@ -8669,8 +8669,32 @@ simplify_cond_using_ranges (gimple stmt)
>   && range_fits_type_p (vr,
> TYPE_PRECISION (TREE_TYPE (op0)),
> TYPE_UNSIGNED (TREE_TYPE (op0)))
> - && int_fits_type_p (op1, TREE_TYPE (innerop)))
> + && int_fits_type_p (op1, TREE_TYPE (innerop))
> + /* The range must not have overflowed, or if it did overflow
> +we must not be wrapping/trapping overflow and optimizing
> +with strict overflow semantics.  */
> + && ((!is_negative_overflow_infinity (vr->min)
> +  && !is_positive_overflow_infinity (vr->max))
> + || (!flag_wrapv && !flag_trapv && flag_strict_overflow)))

Ok with changing this to

   || TYPE_OVERFLOW_UNDEFINED (TREE_TYPE (innerop)))

> {
> + /* If the range overflowed and the user has asked for warnings
> +when strict overflow semantics were used to optimize code,
> +issue an appropriate warning.  */
> + if ((is_negative_overflow_infinity (vr->min)
> +  || is_positive_overflow_infinity (vr->max))
> + && issue_strict_overflow_warning
> (WARN_STRICT_OVERFLOW_CONDITIONAL))
> +   {
> + location_t location;
> +
> + if (!gimple_has_location (stmt))
> +   location = input_location;
> + else
> +   location = gimple_location (stmt);
> + warning_at (location, OPT_Wstrict_overflow,
> + "assuming signed overflow does n

Re: [patch] fix libstdc++/57336

[Jakub Jelinek]

On Tue, May 21, 2013 at 09:18:15AM +0100, Jonathan Wakely wrote:
> This broke due to some front end changes that disallow forming
> function types that return abstract types.  std::reference_wrapper
> always passes an lvalue reference to __invoke so it's correct to use
> an lvalue reference as the result_of's template argument.
> 
> PR libstdc++/57336
> * include/std/functional (__invoke): Do not form function types with
> abstract return type.
> * testsuite/20_util/reference_wrapper/invoke-3.cc: New.
> 
> Tested x86_64-linux, committed to trunk.
> 
> Jakub, this is a regression against 4.8.0, should it go on the branch too?
> The change is small and isolated to code used by std::reference_wrapper.

Ok.

Jakub

[patch] fix libstdc++/57336

[Jonathan Wakely]

This broke due to some front end changes that disallow forming
function types that return abstract types.  std::reference_wrapper
always passes an lvalue reference to __invoke so it's correct to use
an lvalue reference as the result_of's template argument.

PR libstdc++/57336
* include/std/functional (__invoke): Do not form function types with
abstract return type.
* testsuite/20_util/reference_wrapper/invoke-3.cc: New.

Tested x86_64-linux, committed to trunk.

Jakub, this is a regression against 4.8.0, should it go on the branch too?
The change is small and isolated to code used by std::reference_wrapper.
commit 4b5557d04acb37fed7686e720ba0af0ed3428c56
Author: Jonathan Wakely 
Date:   Tue May 21 08:52:16 2013 +0100

PR libstdc++/57336
* include/std/functional (__invoke): Do not form function types with
abstract return type.
* testsuite/20_util/reference_wrapper/invoke-3.cc: New.

diff --git a/libstdc++-v3/include/std/functional 
b/libstdc++-v3/include/std/functional
index 44d3fd5..63ba777 100644
--- a/libstdc++-v3/include/std/functional
+++ b/libstdc++-v3/include/std/functional
@@ -195,7 +195,7 @@ _GLIBCXX_HAS_NESTED_TYPE(result_type)
 (!is_member_pointer<_Functor>::value
  && !is_function<_Functor>::value
  && !is_function::type>::value),
-typename result_of<_Functor(_Args&&...)>::type
+typename result_of<_Functor&(_Args&&...)>::type
   >::type
 __invoke(_Functor& __f, _Args&&... __args)
 {
diff --git a/libstdc++-v3/testsuite/20_util/reference_wrapper/invoke-3.cc 
b/libstdc++-v3/testsuite/20_util/reference_wrapper/invoke-3.cc
new file mode 100644
index 000..4291a67
--- /dev/null
+++ b/libstdc++-v3/testsuite/20_util/reference_wrapper/invoke-3.cc
@@ -0,0 +1,37 @@
+// { dg-options "-std=gnu++11" }
+// { dg-do compile }
+
+// Copyright (C) 2013 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
+// .
+
+// 20.8.3.4 reference_wrapper invocation [refwrap.invoke]
+#include 
+
+struct ABC
+{
+virtual bool operator()() const = 0;
+};
+
+struct Concrete : ABC
+{
+virtual bool operator()() const { return true; }
+};
+
+Concrete c;
+ABC& abc = c;
+
+auto b = std::cref(abc)();

[PATCH] Fix PR57303

[Richard Biener]

The following patch fixes store sinking to properly account for
self-assignments in the same way DSE does (which means this patch
also enhances store-sinking).

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

Richard.

2013-05-21  Richard Biener  

PR tree-optimization/57303
* tree-ssa-sink.c (statement_sink_location): Improve killing
stmt detection and properly handle self-assignments.

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

Index: gcc/tree-ssa-sink.c
===
*** gcc/tree-ssa-sink.c (revision 199004)
--- gcc/tree-ssa-sink.c (working copy)
*** statement_sink_location (gimple stmt, ba
*** 331,341 
  gimple use_stmt = USE_STMT (use_p);
  
  /* A killing definition is not a use.  */
! if (gimple_assign_single_p (use_stmt)
! && gimple_vdef (use_stmt)
! && operand_equal_p (gimple_assign_lhs (stmt),
! gimple_assign_lhs (use_stmt), 0))
!   continue;
  
  if (gimple_code (use_stmt) != GIMPLE_PHI)
return false;
--- 331,349 
  gimple use_stmt = USE_STMT (use_p);
  
  /* A killing definition is not a use.  */
! if ((gimple_has_lhs (use_stmt)
!  && operand_equal_p (gimple_assign_lhs (stmt),
!  gimple_get_lhs (use_stmt), 0))
! || stmt_kills_ref_p (use_stmt, gimple_assign_lhs (stmt)))
!   {
! /* If use_stmt is or might be a nop assignment then USE_STMT
!acts as a use as well as definition.  */
! if (stmt != use_stmt
! && ref_maybe_used_by_stmt_p (use_stmt,
!  gimple_assign_lhs (stmt)))
!   return false;
! continue;
!   }
  
  if (gimple_code (use_stmt) != GIMPLE_PHI)
return false;
Index: gcc/testsuite/gcc.dg/torture/pr57303.c
===
*** gcc/testsuite/gcc.dg/torture/pr57303.c  (revision 0)
--- gcc/testsuite/gcc.dg/torture/pr57303.c  (working copy)
***
*** 0 
--- 1,33 
+ /* { dg-do run } */
+ 
+ void abort (void);
+ 
+ struct S0
+ {
+   int f0;
+ };
+ struct S1
+ {
+   struct S0 f0;
+ };
+ 
+ struct S1 x = { {0} };
+ struct S1 y = { {1} };
+ 
+ static void
+ foo (struct S0 p)
+ {
+   struct S0 *l = &y.f0;
+   *l = x.f0;
+   if (p.f0)
+ *l = *l;
+ }
+ 
+ int
+ main ()
+ {
+   foo(y.f0);
+   if (y.f0.f0 != 0)
+ abort ();
+   return 0;
+ }

[committed] Add testcase from PR57321

[Jakub Jelinek]

Hi!

This PR has been fixed recently by PR56988 fix, but adding the testcase
IMHO doesn't hurt.  Committed to trunk/4.8.

2013-05-21  Jakub Jelinek  

PR tree-optimization/57321
* gcc.c-torture/execute/pr57321.c: New test.

--- gcc/testsuite/gcc.c-torture/execute/pr57321.c.jj2013-05-21 
09:43:48.099364022 +0200
+++ gcc/testsuite/gcc.c-torture/execute/pr57321.c   2013-05-21 
09:43:30.0 +0200
@@ -0,0 +1,24 @@
+/* PR tree-optimization/57321 */
+
+int a = 1, *b, **c;
+
+static int
+foo (int *p)
+{
+  if (*p == a)
+{
+  int *i[7][5] = { { 0 } };
+  int **j[1][1];
+  j[0][0] = &i[0][0];
+  *b = &p != c;
+}
+  return 0;
+}
+
+int
+main ()
+{
+  int i = 0;
+  foo (&i);
+  return 0;
+}

Jakub

Re: [DWARF] Fix multiple register spanning location.

[Christian Bruel]

Yes, this looks good. OK for trunk, but please add a note about those
additional changes you made to the ChangeLog entry. Thanks!



Thanks, done with this entry:

2013-05-21  Christian Bruel  

* dwarf2out.c (multiple_reg_loc_descriptor): Use dbx_reg_number for
spanning registers. LEAF_REG_REMAP is supported only for contiguous
registers. Set register size out of the PARALLEL loop.

Cheers

Re: [Patch][gcc-4_7-branch] Backport trunk revision 187838 into gcc-4_7-branch

[Richard Biener]

On Sun, 19 May 2013, Chung-Ju Wu wrote:

> 2013/5/19 Ian Lance Taylor :
> > On Fri, May 17, 2013 at 7:29 PM, Chung-Ju Wu  wrote:
> >> Ping: http://gcc.gnu.org/ml/gcc-patches/2013-05/msg00429.html
> >>
> >> The patch is to fix dependency issue of libgcc Makefile.in
> >> by adding 'rm libgcc_tm.stamp' in the clean rule.
> >>
> >> That was fixed on main trunk (r187838) but not on gcc-4_7-branch.
> >> Since gcc-4_7-branch is still open, is it OK to backport r187838
> >> into gcc-4_7-branch?
> >
> > It's OK with me but in general I think the release managers need to
> > approve backports.
> >
> > Ian
> 
> Thanks Ian's approval for the libgcc part.
> 
> Hi, Richard, here is the mail for my patch:
>   http://gcc.gnu.org/ml/gcc-patches/2013-05/msg00429.html
> 
> The patch doesn't add any new feature to gcc-4_7-branch.
> It just fixes the dependency issue in libgcc Makefile.in.
> 
> Is it OK to do backport?

Ok.

Thanks,
Richard.

Re: RFA: Use gen_int_mode in plus_constant

[Andreas Krebbel]

On 30/04/13 16:56, Richard Sandiford wrote:
> This patch fixes out the GEN_INT/gen_int_mode that Richard pointed out
> in the wide-int review.  It also passes "mode" rather than "VOIDmode"
> to immed_double_int_const.  (As discussed in that thread, the latter
> change shouldn't make any difference in practice, but is still more
> correct in principle.)
> 
> Bootstrapped & regression-tested on x86_64-linux-gnu.  OK to install?
> 
> Richard
> 
> gcc/
>   * explow.c (plus_constant): Pass "mode" to immed_double_int_const.
>   Use gen_int_mode rather than GEN_INT.
> 
> Index: gcc/explow.c
> ===
> --- gcc/explow.c  2013-02-25 09:41:58.0 +
> +++ gcc/explow.c  2013-04-30 15:52:57.270362112 +0100
> @@ -106,10 +106,10 @@ plus_constant (enum machine_mode mode, r
> if (overflow)
>   gcc_unreachable ();
> 
> -   return immed_double_int_const (v, VOIDmode);
> +   return immed_double_int_const (v, mode);
>   }
> 
> -  return GEN_INT (INTVAL (x) + c);
> +  return gen_int_mode (INTVAL (x) + c, mode);

This calls trunc_int_for_mode which fails for mode == VOIDmode.
On s390x gcc.c-torture/compile/20021008-1.c fails due to this.

-Andreas-

> 
>  case CONST_DOUBLE:
>{
> @@ -124,7 +124,7 @@ plus_constant (enum machine_mode mode, r
>To fix, add constant support wider than CONST_DOUBLE.  */
> gcc_assert (GET_MODE_BITSIZE (mode) <= HOST_BITS_PER_DOUBLE_INT);
> 
> - return immed_double_int_const (v, VOIDmode);
> + return immed_double_int_const (v, mode);
>}
> 
>  case MEM:
>