date:20160619

Re: [PATCH] Use gfc_add_*_component defines where appropriate

2016-06-19 Thread Paul Richard Thomas

Hi Bernhard,

Thanks for doing some of this tidying up. The patch is OK to commit on
both trunk and 6-branch. It might be worth going back to 5-branch as
well, if you feel up to it.

Cheers

Paul

On 18 June 2016 at 21:47, Bernhard Reutner-Fischer
 wrote:
> Ping.
>
> On December 1, 2015 1:54:58 PM GMT+01:00, Bernhard Reutner-Fischer 
>  wrote:
>>A couple of places used gfc_add_component_ref(expr, "string") instead
>>of
>>the defines from gfortran.h
>>
>>Regstrapped without regressions, ok for trunk stage3 now / next stage1?
>>
>>gcc/fortran/ChangeLog
>>
>>2015-11-29  Bernhard Reutner-Fischer  
>>
>> * class.c (gfc_add_class_array_ref): Call gfc_add_data_component()
>>instead of gfc_add_component_ref().
>>   (gfc_get_len_component): Call gfc_add_len_component() instead of
>>gfc_add_component_ref().
>>* trans-intrinsic.c (gfc_conv_intrinsic_loc): Call
>>gfc_add_data_component() instead of gfc_add_component_ref().
>>* trans.c (gfc_add_finalizer_call): Call
>>gfc_add_final_component() and gfc_add_size_component() instead
>>of gfc_add_component_ref.
>>
>>Signed-off-by: Bernhard Reutner-Fischer 
>>---
>> gcc/fortran/class.c   | 4 ++--
>> gcc/fortran/trans-intrinsic.c | 2 +-
>> gcc/fortran/trans.c   | 4 ++--
>> 3 files changed, 5 insertions(+), 5 deletions(-)
>>
>>diff --git a/gcc/fortran/class.c b/gcc/fortran/class.c
>>index 8b49ae9..027cb89 100644
>>--- a/gcc/fortran/class.c
>>+++ b/gcc/fortran/class.c
>>@@ -258,7 +258,7 @@ gfc_add_class_array_ref (gfc_expr *e)
>>   int rank = CLASS_DATA (e)->as->rank;
>>   gfc_array_spec *as = CLASS_DATA (e)->as;
>>   gfc_ref *ref = NULL;
>>-  gfc_add_component_ref (e, "_data");
>>+  gfc_add_data_component (e);
>>   e->rank = rank;
>>   for (ref = e->ref; ref; ref = ref->next)
>> if (!ref->next)
>>@@ -584,7 +584,7 @@ gfc_get_len_component (gfc_expr *e)
>>   ref = ref->next;
>> }
>>   /* And replace if with a ref to the _len component.  */
>>-  gfc_add_component_ref (ptr, "_len");
>>+  gfc_add_len_component (ptr);
>>   return ptr;
>> }
>>
>>diff --git a/gcc/fortran/trans-intrinsic.c
>>b/gcc/fortran/trans-intrinsic.c
>>index 1dabc26..2ef0709 100644
>>--- a/gcc/fortran/trans-intrinsic.c
>>+++ b/gcc/fortran/trans-intrinsic.c
>>@@ -7112,7 +7112,7 @@ gfc_conv_intrinsic_loc (gfc_se * se, gfc_expr *
>>expr)
>>   if (arg_expr->rank == 0)
>> {
>>   if (arg_expr->ts.type == BT_CLASS)
>>-  gfc_add_component_ref (arg_expr, "_data");
>>+  gfc_add_data_component (arg_expr);
>>   gfc_conv_expr_reference (se, arg_expr);
>> }
>>   else
>>diff --git a/gcc/fortran/trans.c b/gcc/fortran/trans.c
>>index 2a91c35..14dad0f 100644
>>--- a/gcc/fortran/trans.c
>>+++ b/gcc/fortran/trans.c
>>@@ -1132,11 +1132,11 @@ gfc_add_finalizer_call (stmtblock_t *block,
>>gfc_expr *expr2)
>>
>>   final_expr = gfc_copy_expr (expr);
>>   gfc_add_vptr_component (final_expr);
>>-  gfc_add_component_ref (final_expr, "_final");
>>+  gfc_add_final_component (final_expr);
>>
>>   elem_size = gfc_copy_expr (expr);
>>   gfc_add_vptr_component (elem_size);
>>-  gfc_add_component_ref (elem_size, "_size");
>>+  gfc_add_size_component (elem_size);
>> }
>>
>>   gcc_assert (final_expr->expr_type == EXPR_VARIABLE);
>
>



-- 
The difference between genius and stupidity is; genius has its limits.

Albert Einstein

Re: [PATCH] Use gfc_add_*_component defines where appropriate

2016-06-19 Thread Bernhard Reutner-Fischer

On Sun, Jun 19, 2016 at 11:18:08AM +0200, Paul Richard Thomas wrote:
> Hi Bernhard,
> 
> Thanks for doing some of this tidying up. The patch is OK to commit on
> both trunk and 6-branch. It might be worth going back to 5-branch as
> well, if you feel up to it.

Applied to trunk as r237580 so far.

thanks,

[PING**2] [PATCH] Fix asm X constraint (PR inline-asm/59155)

2016-06-19 Thread Bernd Edlinger

Hi,

ping...

As this discussion did not make any progress, I just attached
the latest version of my patch with the the changes that
Vladimir proposed.

Boot-strapped and reg-tested again on x86_64-linux-gnu.
Is it OK for the trunk?


Thanks
Bernd.


On 06/10/16 16:13, Bernd Edlinger wrote:
> On 06/09/16 18:45, Jakub Jelinek wrote:
>> On Thu, Jun 09, 2016 at 06:43:04PM +0200, Jakub Jelinek wrote:
>>> Yes, I'm all in favor in disabling X constraint for inline asm.
>>> Especially if people actually try to print it as well, rather than
>>> make it
>>> unused.  That is a sure path to ICEs.
>>
>> Though, on the other side, even our documentation mentions
>> asm volatile ("mtfsf 255,%1" : "=X"(sum): "f"(fpenv));
>> So perhaps we need to error just in case such an argument is printed?
>
> note that "=X" is also introduced internally in this asm statement:
>
> asm ("cmpl  %2, 0" : "=@ccz"(z), "=@ccb"(b): "r"(i));
>
> see i386.c, ix86_md_asm_adjust.
>
> The first =@cc is replaced by "=Bf" constraint but any
> further =@cc are replaced by "=X" and scratch operand.
>
> Printing the "=X" scratch is harmless, but printing the "=Bf" causes
> another ICE, I shall submit a follow up patch for that:
> asm ("# %0" : "=@ccz"(z));
>
> test.c:6:1: internal compiler error: in print_reg, at
> config/i386/i386.c:17193
>   }
>   ^
> 0xedfc30 print_reg(rtx_def*, int, _IO_FILE*)
>  ../../gcc-trunk/gcc/config/i386/i386.c:17189
> 0xf048a4 ix86_print_operand(_IO_FILE*, rtx_def*, int)
>  ../../gcc-trunk/gcc/config/i386/i386.c:17867
> 0x8bf87c output_operand(rtx_def*, int)
>  ../../gcc-trunk/gcc/final.c:3847
> 0x8c00ee output_asm_insn(char const*, rtx_def**)
>  ../../gcc-trunk/gcc/final.c:3763
> 0x8c1f9c final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
>  ../../gcc-trunk/gcc/final.c:2628
> 0x8c25c9 final(rtx_insn*, _IO_FILE*, int)
>  ../../gcc-trunk/gcc/final.c:2045
> 0x8c2da9 rest_of_handle_final
>  ../../gcc-trunk/gcc/final.c:4445
> 0x8c2da9 execute
>  ../../gcc-trunk/gcc/final.c:4520
>
>
> Well, regarding the X constraint, I do think that
> it's definitely OK to use different rules if it is
> used in asms vs. when if it is used internally in .md files.
>
> The patch handles X in asms to be just a synonym to the g constraint,
> except that g allows only GENERAL_REGS and X allows ALL_REGS.
>
> What I am not sure of, is if X should allow more than g in terms of
> CONSTANT_P.  I think it should not, because probably the CONSTANT_P
> handling in general_operand is likely smarter than that of the i
> constraint.
>
>
> Bernd.
gcc:
2016-05-23  Bernd Edlinger  

PR inline-asm/59155
* lra-constraints.c (process_alt_operands): Allow ALL_REGS.
* recog.c (asm_operand_ok): Handle X constraint.

testsuite:
2016-05-23  Bernd Edlinger  

PR inline-asm/59155
* gcc.dg/torture/pr59155-1.c: New test.
* gcc.dg/torture/pr59155-2.c: New test.
* gcc.dg/torture/pr59155-3.c: New test.
Index: gcc/lra-constraints.c
===
--- gcc/lra-constraints.c	(revision 237133)
+++ gcc/lra-constraints.c	(working copy)
@@ -1854,8 +1854,9 @@ process_alt_operands (int only_alternative)
 	  if (curr_static_id->operand_alternative[opalt_num].anything_ok)
 	{
 	  /* Fast track for no constraints at all.	*/
-	  curr_alt[nop] = NO_REGS;
-	  CLEAR_HARD_REG_SET (curr_alt_set[nop]);
+	  curr_alt[nop] = ALL_REGS;
+	  COPY_HARD_REG_SET (curr_alt_set[nop],
+ reg_class_contents[ALL_REGS]);
 	  curr_alt_win[nop] = true;
 	  curr_alt_match_win[nop] = false;
 	  curr_alt_offmemok[nop] = false;
Index: gcc/recog.c
===
--- gcc/recog.c	(revision 237133)
+++ gcc/recog.c	(working copy)
@@ -1778,6 +1778,10 @@ asm_operand_ok (rtx op, const char *constraint, co
 	result = 1;
 	  break;
 
+	case 'X':
+	  if (scratch_operand (op, VOIDmode))
+	result = 1;
+	  /* ... fall through ...  */
 	case 'g':
 	  if (general_operand (op, VOIDmode))
 	result = 1;
Index: gcc/testsuite/gcc.dg/torture/pr59155-1.c
===
--- gcc/testsuite/gcc.dg/torture/pr59155-1.c	(revision 0)
+++ gcc/testsuite/gcc.dg/torture/pr59155-1.c	(working copy)
@@ -0,0 +1,8 @@
+/* { dg-do compile } */
+double f(double x){
+  asm volatile("":"+X"(x));
+  return x;
+}
+double g(double x,double y){
+  return f(f(x)+f(y));
+}
Index: gcc/testsuite/gcc.dg/torture/pr59155-2.c
===
--- gcc/testsuite/gcc.dg/torture/pr59155-2.c	(revision 0)
+++ gcc/testsuite/gcc.dg/torture/pr59155-2.c	(working copy)
@@ -0,0 +1,8 @@
+/* { dg-do compile } */
+double f(double x){
+  asm volatile("":"+X"(x));
+  return x;
+}
+double g(){
+  return f(1.);
+}
Index: gcc/testsuite/gcc.dg/torture/pr59155-3.c
===
--- gcc/testsuite/

Re: [wwwdocs] Buildstat update for 5.x

2016-06-19 Thread Gerald Pfeifer

On Thu, 16 Jun 2016, Tom G. Christensen wrote:
> On Thu, Jun 16, 2016 at 03:53:40PM +0200, Tom G. Christensen wrote:
>> Testresults for 5.4.0:
>>   i386-pc-solaris2.11 (2)
>>   i386-pc-solaris2.12 (2)
>>   sparc-sun-solaris2.11 (2)
>>   sparc-sun-solaris2.12 (2)
>> 
> Updated patch with new entries added in the right position.

Thank you, Tom!

Index: buildstat.html
===
 powerpc64-unknown-linux-gnu
  
 Test results:
-https://gcc.gnu.org/ml/gcc-testresults/2016-06/msg00324.html";>5.4.0
+https://gcc.gnu.org/ml/gcc-testresults/2016-06/msg00324.html";>5.4.0,

 powerpc64le-unknown-linux-gnu
  
 Test results:
-https://gcc.gnu.org/ml/gcc-testresults/2016-06/msg00322.html";>5.4.0
+https://gcc.gnu.org/ml/gcc-testresults/2016-06/msg00322.html";>5.4.0,

These two hunks were not mentioned in the changelog (but then they only
add a missing comma).

 
+sparc-sun-solaris2.12
+ 
+Test results:
+https://gcc.gnu.org/ml/gcc-testresults/2016-06/msg00377.html";>5.4.0,
+https://gcc.gnu.org/ml/gcc-testresults/2016-06/msg00376.html";>5.4.0
+
+
+
+
+sparc-sun-solaris2.12
+ 
+Test results:
+https://gcc.gnu.org/ml/gcc-testresults/2016-06/msg00377.html";>5.4.0,
+https://gcc.gnu.org/ml/gcc-testresults/2016-06/msg00376.html";>5.4.0
+
+

This looks like a duplication of the sparc-sun-solaris2.12 section,
and I committed an updated patch with only one of the two.

Gerald

Re: [PATCH] PR52665 do not let .ident confuse assembler scan tests

2016-06-19 Thread Mike Stump

On Jun 18, 2016, at 12:31 PM, Bernhard Reutner-Fischer  
wrote:
> 
> A branch with a name matching scan-assembler pattern triggers
> inappropriate FAIL.

> The patch below adds -fno-ident if a testcase contains one of
> scan-assembler, scan-assembler-not or scan-assembler-times.

Kinda gross.  I'd like to consensus build a little, as I don't know that I have 
a better solution than the solution you propose to fix the issue.  I'd love it 
if one or more of Jacob, Law and Richard can chime in on direction here.  I'll 
have to think about this some more and see if I can come up with something that 
I like better.

If no one has a better solution, I'll approve the proposed solution.  Let's 
give people a little time to chime in.

Re: [BUILDROBOT] Selftest failed for rs6000-ibm-aix4.3

2016-06-19 Thread David Edelsohn

On Sat, Jun 18, 2016 at 9:56 AM, David Malcolm  wrote:
> On Sat, 2016-06-18 at 15:06 +0200, Jan-Benedict Glaw wrote:
>> Hi David, Segher, Aldy!
>>
>> Davids new selftest code found something for the rs6000-ibm-aix4.3
>> target, maybe you're interested:
>>
>> /home/jbglaw/src/toolchain/build/./gcc/xgcc
>> -B/home/jbglaw/src/toolchain/build/./gcc/ -xc -S -c /dev/null -fself
>> -test
>> : internal compiler error: in altivec_init_builtins, at
>> config/rs6000/rs6000.c:16675
>> 0xe0ed04 altivec_init_builtins
>> ../../gcc/gcc/config/rs6000/rs6000.c:16675
>> 0xe0ed04 rs6000_init_builtins
>> ../../gcc/gcc/config/rs6000/rs6000.c:15935
>> 0x643c7e c_define_builtins
>> ../../gcc/gcc/c-family/c-common.c:5208
>> 0x643c7e c_common_nodes_and_builtins()
>> ../../gcc/gcc/c-family/c-common.c:5656
>> 0x590c49 c_init_decl_processing()
>> ../../gcc/gcc/c/c-decl.c:3934
>> 0x5dd7e8 c_objc_common_init()
>> ../../gcc/gcc/c/c-objc-common.c:58
>> 0x580cc1 lang_dependent_init
>> ../../gcc/gcc/toplev.c:1757
>> 0x580cc1 do_compile
>> ../../gcc/gcc/toplev.c:1975
>> Please submit a full bug report,
>> with preprocessed source if appropriate.
>> Please include the complete backtrace with any bug report.
>> See  for instructions.
>> make[1]: *** [s-selftest] Error 1
>>
>>
>>
>> See eg. build
>> http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=572874
>> ,
>> which is as simple as .../configure --enable-languages=c,c++
>> --target=rs6000-ibm-aix4.3 --without-headers --disable-threads
>>
>
> I looks like PR target/71375 ("Failure on startup on rs6000-ibm
> -aix{4.3|5.1.0}"), which I believe is a pre-existing issue, and
> unrelated to -fself-test.

I fixed this, but we probably should remove AIX 4.3 and AIX 5.1 from
config-list.mk.  And we should add AIX 7.1.

- David

Re: [PATCH] Use gfc_add_*_component defines where appropriate

Re: [PATCH] Use gfc_add_*_component defines where appropriate

[PING**2] [PATCH] Fix asm X constraint (PR inline-asm/59155)

Re: [wwwdocs] Buildstat update for 5.x

Re: [PATCH] PR52665 do not let .ident confuse assembler scan tests

Re: [BUILDROBOT] Selftest failed for rs6000-ibm-aix4.3

6 matches

Site Navigation

Mail list logo

Footer information