[patch, fortran] Fix regression with inline matmul

2017-08-26 Thread Thomas Koenig

Hello world,

to relieve the boredom on the fortran mailing list and to fix
a regression I thought I'd submit a patch :-)

Apparently, a call to CONJG wasn't picking up the right
typespec, which led to an ICE with gimplification later.

Regression-tested.  OK for trunk?

Regards

Thomas

2017-08-26  Thomas Koenig  

PR fortran/81974
* frontend-passes (inline_matumul_assign):  Explicity
set typespec for call to CONJG.

2017-08-26  Thomas Koenig  

PR fortran/81974
* gfortran.dg/inline_matmul_19.f90:  New test
Index: frontend-passes.c
===
--- frontend-passes.c	(Revision 251125)
+++ frontend-passes.c	(Arbeitskopie)
@@ -3837,14 +3837,25 @@ inline_matmul_assign (gfc_code **c, int *walk_subt
   gcc_unreachable();
 }
 
+  /* Build the conjg call around the variables.  Set the typespec manually
+ because gfc_build_intrinsic_call sometimes gets this wrong.  */
   if (conjg_a)
-ascalar = gfc_build_intrinsic_call (ns, GFC_ISYM_CONJG, "conjg",
-	matrix_a->where, 1, ascalar);
+{
+  gfc_typespec ts;
+  ts = matrix_a->ts;
+  ascalar = gfc_build_intrinsic_call (ns, GFC_ISYM_CONJG, "conjg",
+	  matrix_a->where, 1, ascalar);
+  ascalar->ts = ts;
+}
 
   if (conjg_b)
-bscalar = gfc_build_intrinsic_call (ns, GFC_ISYM_CONJG, "conjg",
-	matrix_b->where, 1, bscalar);
-
+{
+  gfc_typespec ts;
+  ts = matrix_b->ts;
+  bscalar = gfc_build_intrinsic_call (ns, GFC_ISYM_CONJG, "conjg",
+	  matrix_b->where, 1, bscalar);
+  bscalar->ts = ts;
+}
   /* First loop comes after the zero assignment.  */
   assign_zero->next = do_1;
 
  ! { dg-do  run }
  ! { dg-options "-ffrontend-optimize" }
  ! PR 81974 - this used to cause an ICE.
  
  implicit none
  COMPLEX(kind=kind(0d0)), DIMENSION(3, 3) :: R
  REAL(kind=kind(0d0)), DIMENSION(3, 3):: M,a,b
  complex(8), dimension(3,3) :: res, c
  integer :: i, j, k
  c = 0
  call random_number(m)
  call random_number(a)
  call random_number(b)
  r = cmplx(a, b, 8)
  do k=1,3
 do j=1,3
do i=1,3
   c(k,j) = c(k,j) + conjg(r(i,k)) * m(i,j)
end do
 end do
  end do
  res = MATMUL(TRANSPOSE(CONJG(R)), M)
  if (any(abs(res-c) >= 1e-6)) call abort
  c = 0
  do k=1,3
 do j=1,3
do i=1,3
   c(i,k) = c(i,k) + m(i,j) * conjg(r(k,j))
end do
 end do
  end do
  res = matmul(m, transpose(conjg(r)))
  if (any(abs(res-c) >= 1e-6)) call abort
  END


Re: [patch, fortran] Fix regression with inline matmul

2017-08-26 Thread Jerry DeLisle
On 08/26/2017 11:24 AM, Thomas Koenig wrote:
> Hello world,
> 
> to relieve the boredom on the fortran mailing list and to fix
> a regression I thought I'd submit a patch :-)
> 
> Apparently, a call to CONJG wasn't picking up the right
> typespec, which led to an ICE with gimplification later.
> 
> Regression-tested.  OK for trunk?
> 

OK for Trunk, and backport to 7.3 if the bug is there.

Thanks,

Jerry


Re: [patch, libgfortran] PR78387 OpenMP segfault/stack size exceeded writing to internal file

2017-08-26 Thread Jerry DeLisle
ping - I will commit if I hear no objections.

Jerry

On 08/19/2017 10:12 PM, Jerry DeLisle wrote:
> Hi all,
> 
> I have decided to simply delete the internal unit stack altogether.
> 
> The original intent was to save time with internal unit I/O by avoiding
> reallocating a gfc_unit structure every time an internal unit (aka string) is
> used for I/O.
> 
> After deleting and testing it appears no significant change in performance.
> 
> Regression tested on x86_64-linux. No new test case.
> 
> OK for trunk and then I think this should be backported to 7.
> 
> Regards,
> 
> Jerry
> 
> 2017-08-20  Jerry DeLisle  
> 
> PR libgfortran/78387
> * io/list_read.c (nml_read_obj): Remove use of stash.
> * io/transfer.c (st_read_done, st_write_done): Likewise.
> * io/unit.c (stash_internal_unit): Delete function.
> (get_unit): Remove use of stash.
> (init_units): Likewise.
> (close_units): Likewise.
> * io/write.c (nml_write_obj): Likewise:



Re: [PATCH, i386]: Use btr/bts/btc some more (PR target/46091)

2017-08-26 Thread Gerald Pfeifer
On Mon, 21 Aug 2017, Uros Bizjak wrote:
> 2017-08-21  Uros Bizjak  
> 
> PR target/46091
> * config/i386/i386.md (*btsq_imm): Rename from *btsq.
> (*btrq_imm): Rename from *btrq.
> (*btcq_imm): Rename from *btcq.
> (btsc): New code attribute.
> (*): New insn pattern.
> (*btr): Ditto.
> (*_mask): New insn_and_split pattern.
> (*btr_mask): Ditto.

According to a binary search I did this is responsible for bootstrap 
failing on 32-bit x86 (i586-unknown-freebsd10.3):

  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81995

Revision 251234 still builds, and revision 251235 fails for me.

Gerald


Re: [PATCH, i386]: Use btr/bts/btc some more (PR target/46091)

2017-08-26 Thread Gerald Pfeifer
On Sun, 27 Aug 2017, Gerald Pfeifer wrote:
>> 2017-08-21  Uros Bizjak  
>> 
>> PR target/46091
>> * config/i386/i386.md (*btsq_imm): Rename from *btsq.
>> (*btrq_imm): Rename from *btrq.
>> (*btcq_imm): Rename from *btcq.
>> (btsc): New code attribute.
>> (*): New insn pattern.
>> (*btr): Ditto.
>> (*_mask): New insn_and_split pattern.
>> (*btr_mask): Ditto.
> According to a binary search I did this is responsible for bootstrap 
> failing on 32-bit x86 (i586-unknown-freebsd10.3):
> 
>   https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81995
> 
> Revision 251234 still builds, and revision 251235 fails for me.

And indeed just reverting this patch in HEAD gets that to build
again, too.

Gerald