Re: [PATCH] handle function pointers in __builtin_object_size (PR 88372)

2018-12-09 Thread Richard Biener
On December 8, 2018 6:42:48 PM GMT+01:00, Martin Sebor  wrote:
>On 12/7/18 1:06 AM, Richard Biener wrote:
>> On Thu, 6 Dec 2018, Martin Sebor wrote:
>> 
>>> On 12/6/18 2:26 PM, Jakub Jelinek wrote:
 On Thu, Dec 06, 2018 at 01:21:58PM -0700, Martin Sebor wrote:
> Bug 88372 - alloc_size attribute is ignored on function pointers
> points out that even though the alloc_size attribute is accepted
> on function pointers it doesn't have any effect on Object Size
> Checking.  The reporter, who is implementing the feature in Clang,
> wants to know if by exposing it under the same name they won't be
> causing incompatibilities with GCC.
>
> I don't think it's intentional that GCC doesn't take advantage of
> the attribute for Object Size Checking, and certainly not to
>detect
> the same kinds of issues as with other allocation functions (such
> as excessive or negative size arguments).  Rather, it's almost
> certainly an oversight since GCC does make use of function pointer
> attributes in other contexts (e.g., attributes alloc_align and
> noreturn).
>
> As an oversight, I think it's fair to consider it a bug rather
> than a request for an enhancement.  Since not handling
> the attribute in Object Size Checking has adverse security
> implications, I also think this bug should be addressed in GCC
> 9.  With that, I submit the attached patch to resolve both
> aspects of the problem.

 This is because alloc_object_size has been written before we had
>attributes
 like alloc_size.  The only thing I'm unsure about is whether we
>should
 prefer gimple_call_fntype or TREE_TYPE (gimple_call_fndecl ()) if
>it is a
 direct call or if we should try to look for alloc_size attribute on
>both
 of those if they are different types.  E.g. if somebody does

 #include 

 typedef void *(*allocfn) (size_t);

 static inline void *
 foo (allocfn fn, size_t sz)
 {
 return fn (sz);
 }

 static inline void *
 bar (size_t sz)
 {
 return foo (malloc, sz);
 }

 then I think this patch would no longer treat it as malloc.

 As this is security relevant, I'd probably look for alloc_size
 attribute in both gimple_call_fntype and, if gimple_call_fndecl is
>non-NULL,
 its TREE_TYPE.
>>>
>>> Thanks for the test case!  I wondered if using fntype would
>>> always work but couldn't think of when it wouldn't.  I've
>>> adjusted the function to use both and added the test case.
>>>
>>> While thinking about this it occurred to me that alloc_size
>>> is only documented as a function attribute but not one that
>>> applies to pointers or types.  I added documentation for
>>> these uses to the Common Type and Common Variable sections.
>> 
>> Please always _only_ use gimple_call_fntype when the decl
>> isn't visible.  As elsewhere the type of the function
>> pointer doesn't have any semantic meaning (it could be a
>> wrong one).
>
>I don't understand what you're asking me to do differently here:
>
>-  callee = gimple_call_fndecl (call);
>-  if (!callee)
>+  tree calltype;
>+  if (tree callfn = gimple_call_fndecl (call))
>+calltype = TREE_TYPE (callfn);
>+  else
>+calltype = gimple_call_fntype (call);
> ^^
>
>Can you show the change you're looking for?  (The change I had
>made originally was in response to this same request you made
>in Bugzilla, which Jakub then suggested may not be robust enough.)

I was replying to the discussion, not looking at the patch. The above snippet 
looks OK to me. 

>Btw., it should be straightforward to ask "give me the attribute
>if this is a call to an alloc_size-kind of a function?" (or one
>with whatever other attribute of interest).  Since it appears
>to be anything but straightforward, we should consider providing
>an API to make it so.  Maybe something like:
>
>   tree gimple_call_attribute (gcall *, tree attribute);

Maybe a char * instead of the tree argument to match lookup_attribute? But yes, 
sth like this looks indeed useful. 

Richard. 

>Martin
>
>> 
>> Richard.
>> 
>>> Martin
>>>
>>> PS Other function attributes that also apply to types and
>>> variables are only documented in the function section.  They
>>> should also be mentioned in the other sections.  Which, if
>>> done in the established style, will result in duplicating
>>> a lot of text in three places.  I think that suggests that
>>> we might want to think about structuring these sections of
>>> the manual differently to avoid the duplication.
>>>
>> 



[PATCH] [RFC] PR target/52813 and target/11807

2018-12-09 Thread Dimitar Dimitrov
I have tested this fix on x86_64 host, and found no regression in the C
and C++ testsuites.  I'm marking this patch as RFC simply because I don't
have experience with other architectures, and I don't have a setup to
test all architectures supported by GCC.

gcc/ChangeLog:

2018-12-07  Dimitar Dimitrov  

* cfgexpand.c (asm_clobber_reg_is_valid): Also produce
error when stack pointer is clobbered.
(expand_asm_stmt): Refactor clobber check in separate function.

gcc/testsuite/ChangeLog:

2018-12-07  Dimitar Dimitrov  

* gcc.target/i386/pr52813.c: New test.

Signed-off-by: Dimitar Dimitrov 
---
 gcc/cfgexpand.c | 42 ++---
 gcc/testsuite/gcc.target/i386/pr52813.c |  9 +++
 2 files changed, 43 insertions(+), 8 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/i386/pr52813.c

diff --git a/gcc/cfgexpand.c b/gcc/cfgexpand.c
index 5e23bc242b9..8474372a216 100644
--- a/gcc/cfgexpand.c
+++ b/gcc/cfgexpand.c
@@ -2845,6 +2845,38 @@ tree_conflicts_with_clobbers_p (tree t, HARD_REG_SET 
*clobbered_regs)
   return false;
 }
 
+/* Check that the given REGNO spanning NREGS is a valid
+   asm clobber operand.  Some HW registers cannot be
+   saved/restored, hence they should not be clobbered by
+   asm statements.  */
+static bool
+asm_clobber_reg_is_valid (int regno, int nregs, const char *regname)
+{
+  bool is_valid = true;
+  HARD_REG_SET regset;
+
+  CLEAR_HARD_REG_SET (regset);
+
+  add_range_to_hard_reg_set (®set, regno, nregs);
+
+  /* Clobbering the PIC register is an error.  */
+  if (PIC_OFFSET_TABLE_REGNUM != INVALID_REGNUM
+  && overlaps_hard_reg_set_p (regset, Pmode, PIC_OFFSET_TABLE_REGNUM))
+{
+  /* ??? Diagnose during gimplification?  */
+  error ("PIC register clobbered by %qs in %", regname);
+  is_valid = false;
+}
+  /* Clobbering the STACK POINTER register is an error.  */
+  if (overlaps_hard_reg_set_p (regset, Pmode, STACK_POINTER_REGNUM))
+{
+  error ("Stack Pointer register clobbered by %qs in %", regname);
+  is_valid = false;
+}
+
+  return is_valid;
+}
+
 /* Generate RTL for an asm statement with arguments.
STRING is the instruction template.
OUTPUTS is a list of output arguments (lvalues); INPUTS a list of inputs.
@@ -2977,14 +3009,8 @@ expand_asm_stmt (gasm *stmt)
  else
for (int reg = j; reg < j + nregs; reg++)
  {
-   /* Clobbering the PIC register is an error.  */
-   if (reg == (int) PIC_OFFSET_TABLE_REGNUM)
- {
-   /* ??? Diagnose during gimplification?  */
-   error ("PIC register clobbered by %qs in %",
-  regname);
-   return;
- }
+   if (!asm_clobber_reg_is_valid (reg, nregs, regname))
+ return;
 
SET_HARD_REG_BIT (clobbered_regs, reg);
rtx x = gen_rtx_REG (reg_raw_mode[reg], reg);
diff --git a/gcc/testsuite/gcc.target/i386/pr52813.c 
b/gcc/testsuite/gcc.target/i386/pr52813.c
new file mode 100644
index 000..154ebbfc423
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/pr52813.c
@@ -0,0 +1,9 @@
+/* Ensure that stack pointer cannot be an asm clobber.  */
+/* { dg-do compile { target { ! ia32 } } } */
+/* { dg-options "-O2" } */
+
+void
+test1 (void)
+{
+  asm volatile ("" : : : "%esp"); /* { dg-error "Stack Pointer register 
clobbered" } */
+}
-- 
2.11.0



[C++ PATCH] Fix ICE with offsetof-like initializer (PR c++/88410)

2018-12-09 Thread Jakub Jelinek
Hi!

The following testcase ICEs starting with my change to move offsetof-like
expression handling from the parsing to cp_fold - if the base expression
is not INTEGER_CST, but a constant VAR_DECL initialized with INTEGER_CST,
then we don't fold it as offsetof-like expression and as we use recursive
cp_fold only on functions, not initializers, we don't fold that VAR_DECL in
there into INTEGER_CST and the middle-end ICEs on it trying to fold it.

Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk?

2018-12-09  Jakub Jelinek  

PR c++/88410
* cp-gimplify.c (cp_fold) : For offsetof-like folding,
call maybe_constant_value on val to see if it is INTEGER_CST.

* g++.dg/cpp0x/pr88410.C: New test.

--- gcc/cp/cp-gimplify.c.jj 2018-11-23 20:00:26.603273556 +0100
+++ gcc/cp/cp-gimplify.c2018-12-08 11:39:03.983985326 +0100
@@ -2317,6 +2317,7 @@ cp_fold (tree x)
{
  val = TREE_OPERAND (val, 0);
  STRIP_NOPS (val);
+ val = maybe_constant_value (val);
  if (TREE_CODE (val) == INTEGER_CST)
return fold_offsetof (op0, TREE_TYPE (x));
}
--- gcc/testsuite/g++.dg/cpp0x/pr88410.C.jj 2018-12-08 11:41:10.946927148 
+0100
+++ gcc/testsuite/g++.dg/cpp0x/pr88410.C2018-12-08 11:40:48.476291414 
+0100
@@ -0,0 +1,7 @@
+// PR c++/88410
+// { dg-do compile { target c++11 } }
+
+typedef __UINTPTR_TYPE__ uintptr_t;
+const uintptr_t a = 32;
+struct C { int b; int c; };
+uintptr_t d { uintptr_t (&reinterpret_cast(a)->c) - a };

Jakub


Re: [RFC PATCH] Coalesce host to device transfers in libgomp

2018-12-09 Thread Thomas Schwinge
Hi!

On Thu, 6 Dec 2018 18:57:31 +0100, Jakub Jelinek  wrote:
> On Thu, Dec 06, 2018 at 06:54:20PM +0100, Thomas Schwinge wrote:
> > On Thu, 6 Dec 2018 18:18:56 +0100, Jakub Jelinek  wrote:
> > > On Thu, Dec 06, 2018 at 06:01:48PM +0100, Thomas Schwinge wrote:
> > > > While reviewing Chung-Lin's
> > > >  "[PATCH 4/6,
> > > > OpenACC, libgomp] Async re-work, libgomp/target.c changes", I noticed 
> > > > the
> > > > following unrelated hunk.  Is that intentional or just an oversight that
> > > > it hasn't been included in your "gomp_coalesce_buf" changes (quoted 
> > > > below
> > > > for reference)?
> > > 
> > > I believe it is intentional, the coalescing code coalesces only stuff
> > > allocated by the current gomp_map_vars call, for the link_key case we know
> > > that is not the case, it is a copy to a file scope data variable in the 
> > > PTX
> > > code.
> > 
> > Hmm, I thought this would just copy an address (as opposed to data) from
> > the host to the device, so that would be fine for coalescing.  But I'm
> > not familiar with that code, so it's certainly possible that I'm not
> > understanding this correctly.
> 
> The actual data transfer can be coalesced, just the address is copied into
> the offloaded file scope var and so that exact transfer can't be coalesced.

Ah, I see, thanks!

> > > Perhaps we could do the change but pass NULL instead
> > > of cbufp as the last argument?

Committed to trunk in r266919:

commit 9d5a0b9dbb3aa4493f6e20b711607a25783bcec3
Author: tschwinge 
Date:   Sun Dec 9 12:47:23 2018 +

Coalesce host to device transfers in libgomp: not for link pointer

libgomp/
* target.c (gomp_map_vars): Call gomp_copy_host2dev instead of
devicep->host2dev_func.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@266919 
138bc75d-0d04-0410-961f-82ee72b054a4
---
 libgomp/ChangeLog | 6 ++
 libgomp/target.c  | 7 ---
 2 files changed, 10 insertions(+), 3 deletions(-)

diff --git libgomp/ChangeLog libgomp/ChangeLog
index 7ce0cdb42e14..99417ef62cf0 100644
--- libgomp/ChangeLog
+++ libgomp/ChangeLog
@@ -1,3 +1,9 @@
+2018-12-09  Thomas Schwinge  
+   Jakub Jelinek  
+
+   * target.c (gomp_map_vars): Call gomp_copy_host2dev instead of
+   devicep->host2dev_func.
+
 2018-12-08  Jakub Jelinek  
 
PR libgomp/87995
diff --git libgomp/target.c libgomp/target.c
index 8ebc2a370a16..a62ae2c3e4b3 100644
--- libgomp/target.c
+++ libgomp/target.c
@@ -957,9 +957,10 @@ gomp_map_vars (struct gomp_device_descr *devicep, size_t 
mapnum,
/* Set link pointer on target to the device address of the
   mapped object.  */
void *tgt_addr = (void *) (tgt->tgt_start + k->tgt_offset);
-   devicep->host2dev_func (devicep->target_id,
-   (void *) n->tgt_offset,
-   &tgt_addr, sizeof (void *));
+   /* We intentionally do not use coalescing here, as it's not
+  data allocated by the current call to this function.  */
+   gomp_copy_host2dev (devicep, (void *) n->tgt_offset,
+   &tgt_addr, sizeof (void *), NULL);
  }
array++;
  }


Grüße
 Thomas


[PR88420] Fortran OpenACC "Clause SEQ conflicts with INDEPENDENT"

2018-12-09 Thread Thomas Schwinge
Hi!

Other release branches probably likewise affected; for now committed to
trunk in r266920:

commit 7e5550c06d7ce70887a5042d07f1d9a76706b582
Author: tschwinge 
Date:   Sun Dec 9 12:47:35 2018 +

[PR88420] Fortran OpenACC "Clause SEQ conflicts with INDEPENDENT"

The Fortran front end declares that the OpenACC "Clause SEQ conflicts with
INDEPENDENT".  While that combination doesn't make too much sense indeed, 
it's
still valid; these are orthogonal concepts.

gcc/fortran/
PR fortran/88420
* openmp.c (resolve_oacc_loop_blocks): Remove "Clause SEQ
conflicts with INDEPENDENT" diagnostic.
gcc/testsuite/
PR fortran/88420
* gfortran.dg/goacc/loop-1-2.f95: Update.
* gfortran.dg/goacc/loop-1.f95: Likewise.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@266920 
138bc75d-0d04-0410-961f-82ee72b054a4
---
 gcc/fortran/ChangeLog| 6 ++
 gcc/fortran/openmp.c | 2 --
 gcc/testsuite/ChangeLog  | 6 ++
 gcc/testsuite/gfortran.dg/goacc/loop-1-2.f95 | 3 +--
 gcc/testsuite/gfortran.dg/goacc/loop-1.f95   | 3 +--
 5 files changed, 14 insertions(+), 6 deletions(-)

diff --git gcc/fortran/ChangeLog gcc/fortran/ChangeLog
index 7ae21ac7d808..ae1871ec7f8d 100644
--- gcc/fortran/ChangeLog
+++ gcc/fortran/ChangeLog
@@ -1,3 +1,9 @@
+2018-12-09  Thomas Schwinge  
+
+   PR fortran/88420
+   * openmp.c (resolve_oacc_loop_blocks): Remove "Clause SEQ
+   conflicts with INDEPENDENT" diagnostic.
+
 2018-12-08  Steven G. Kargl  
 
PR fortran/88048
diff --git gcc/fortran/openmp.c gcc/fortran/openmp.c
index fb9c073ff779..d97b8bfbb142 100644
--- gcc/fortran/openmp.c
+++ gcc/fortran/openmp.c
@@ -5895,8 +5895,6 @@ resolve_oacc_loop_blocks (gfc_code *code)
 
   if (code->ext.omp_clauses->seq)
 {
-  if (code->ext.omp_clauses->independent)
-   gfc_error ("Clause SEQ conflicts with INDEPENDENT at %L", &code->loc);
   if (code->ext.omp_clauses->gang)
gfc_error ("Clause SEQ conflicts with GANG at %L", &code->loc);
   if (code->ext.omp_clauses->worker)
diff --git gcc/testsuite/ChangeLog gcc/testsuite/ChangeLog
index 0cbe4e26bb2e..5656259cbbad 100644
--- gcc/testsuite/ChangeLog
+++ gcc/testsuite/ChangeLog
@@ -1,3 +1,9 @@
+2018-12-09  Thomas Schwinge  
+
+   PR fortran/88420
+   * gfortran.dg/goacc/loop-1-2.f95: Update.
+   * gfortran.dg/goacc/loop-1.f95: Likewise.
+
 2018-12-08  Steven G. Kargl  
 
PR fortran/88048
diff --git gcc/testsuite/gfortran.dg/goacc/loop-1-2.f95 
gcc/testsuite/gfortran.dg/goacc/loop-1-2.f95
index f89687aab43b..e048205d2c38 100644
--- gcc/testsuite/gfortran.dg/goacc/loop-1-2.f95
+++ gcc/testsuite/gfortran.dg/goacc/loop-1-2.f95
@@ -152,8 +152,7 @@ subroutine test1
 ! { dg-error "ACC LOOP iteration variable must be of type integer" "" 
{ target *-*-* } 150 }
 end do
 
-! Both seq and independent are not allowed
-  !$acc loop independent seq ! { dg-error "SEQ conflicts with INDEPENDENT" }
+  !$acc loop independent seq
   do i = 1,10
   enddo
 
diff --git gcc/testsuite/gfortran.dg/goacc/loop-1.f95 
gcc/testsuite/gfortran.dg/goacc/loop-1.f95
index e51c9a40f923..776fa482af3c 100644
--- gcc/testsuite/gfortran.dg/goacc/loop-1.f95
+++ gcc/testsuite/gfortran.dg/goacc/loop-1.f95
@@ -152,8 +152,7 @@ subroutine test1
 ! { dg-error "ACC LOOP iteration variable must be of type integer" "" 
{ target *-*-* } 150 }
 end do
 
-! Both seq and independent are not allowed
-  !$acc loop independent seq ! { dg-error "SEQ conflicts with INDEPENDENT" }
+  !$acc loop independent seq
   do i = 1,10
   enddo
 


Grüße
 Thomas


Split up "gfortran.dg/goacc/loop-2.f95"

2018-12-09 Thread Thomas Schwinge
Hi!

Committed to trunk in r266921:

commit 8aa2f4ea84a86e2b600d41854a41c54b494cabb2
Author: tschwinge 
Date:   Sun Dec 9 12:47:47 2018 +

Split up "gfortran.dg/goacc/loop-2.f95"

gcc/testsuite/
* gfortran.dg/goacc/loop-2.f95: Split into...
* gfortran.dg/goacc/loop-2-kernels-nested.f95: ... this new
file...
* gfortran.dg/goacc/loop-2-kernels-tile.f95: ..., and this new
file...
* gfortran.dg/goacc/loop-2-kernels.f95: ..., and this new file...
* gfortran.dg/goacc/loop-2-parallel-3.f95: ..., and this new
file...
* gfortran.dg/goacc/loop-2-parallel-nested.f95: ..., and this new
file...
* gfortran.dg/goacc/loop-2-parallel-tile.f95: ..., and this new
file...
* gfortran.dg/goacc/loop-2-parallel.f95: ..., and this new file.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@266921 
138bc75d-0d04-0410-961f-82ee72b054a4
---
 gcc/testsuite/ChangeLog|  14 +
 gcc/testsuite/c-c++-common/goacc/loop-2-kernels.c  |   2 +
 gcc/testsuite/c-c++-common/goacc/loop-2-parallel.c |   2 +
 gcc/testsuite/c-c++-common/goacc/loop-3.c  |   2 +
 .../gfortran.dg/goacc/loop-2-kernels-nested.f95|  34 ++
 .../gfortran.dg/goacc/loop-2-kernels-tile.f95  | 119 
 gcc/testsuite/gfortran.dg/goacc/loop-2-kernels.f95 | 190 ++
 .../gfortran.dg/goacc/loop-2-parallel-3.f95|  56 ++
 .../gfortran.dg/goacc/loop-2-parallel-nested.f95   |  34 ++
 .../gfortran.dg/goacc/loop-2-parallel-tile.f95 | 110 
 .../gfortran.dg/goacc/loop-2-parallel.f95  | 154 +
 gcc/testsuite/gfortran.dg/goacc/loop-2.f95 | 649 -
 12 files changed, 717 insertions(+), 649 deletions(-)

diff --git gcc/testsuite/ChangeLog gcc/testsuite/ChangeLog
index 5656259cbbad..7bee068aabf3 100644
--- gcc/testsuite/ChangeLog
+++ gcc/testsuite/ChangeLog
@@ -1,5 +1,19 @@
 2018-12-09  Thomas Schwinge  
 
+   * gfortran.dg/goacc/loop-2.f95: Split into...
+   * gfortran.dg/goacc/loop-2-kernels-nested.f95: ... this new
+   file...
+   * gfortran.dg/goacc/loop-2-kernels-tile.f95: ..., and this new
+   file...
+   * gfortran.dg/goacc/loop-2-kernels.f95: ..., and this new file...
+   * gfortran.dg/goacc/loop-2-parallel-3.f95: ..., and this new
+   file...
+   * gfortran.dg/goacc/loop-2-parallel-nested.f95: ..., and this new
+   file...
+   * gfortran.dg/goacc/loop-2-parallel-tile.f95: ..., and this new
+   file...
+   * gfortran.dg/goacc/loop-2-parallel.f95: ..., and this new file.
+
PR fortran/88420
* gfortran.dg/goacc/loop-1-2.f95: Update.
* gfortran.dg/goacc/loop-1.f95: Likewise.
diff --git gcc/testsuite/c-c++-common/goacc/loop-2-kernels.c 
gcc/testsuite/c-c++-common/goacc/loop-2-kernels.c
index 01ad32d6eac6..93e1cece26b4 100644
--- gcc/testsuite/c-c++-common/goacc/loop-2-kernels.c
+++ gcc/testsuite/c-c++-common/goacc/loop-2-kernels.c
@@ -1,3 +1,5 @@
+/* See also "../../gfortran.dg/goacc/loop-2-kernels.f95".  */
+
 void K(void)
 {
   int i, j;
diff --git gcc/testsuite/c-c++-common/goacc/loop-2-parallel.c 
gcc/testsuite/c-c++-common/goacc/loop-2-parallel.c
index 0ef5741ca4bb..5b1e9d7ce87f 100644
--- gcc/testsuite/c-c++-common/goacc/loop-2-parallel.c
+++ gcc/testsuite/c-c++-common/goacc/loop-2-parallel.c
@@ -1,3 +1,5 @@
+/* See also "../../gfortran.dg/goacc/loop-2-parallel.f95".  */
+
 void P(void)
 {
   int i, j;
diff --git gcc/testsuite/c-c++-common/goacc/loop-3.c 
gcc/testsuite/c-c++-common/goacc/loop-3.c
index 44b65a8bf574..e6c3f18042e6 100644
--- gcc/testsuite/c-c++-common/goacc/loop-3.c
+++ gcc/testsuite/c-c++-common/goacc/loop-3.c
@@ -1,3 +1,5 @@
+/* See also "../../gfortran.dg/goacc/loop-2-parallel-3.f95".  */
+
 void par1 (void)
 {
   int i, j;
diff --git gcc/testsuite/gfortran.dg/goacc/loop-2-kernels-nested.f95 
gcc/testsuite/gfortran.dg/goacc/loop-2-kernels-nested.f95
new file mode 100644
index ..2c0c2ead28b6
--- /dev/null
+++ gcc/testsuite/gfortran.dg/goacc/loop-2-kernels-nested.f95
@@ -0,0 +1,34 @@
+program test
+  implicit none
+  integer :: i, j
+
+  !$acc kernels loop gang
+  DO i = 1,10
+!$acc kernels loop gang ! { dg-bogus "OpenACC construct inside of 
non-OpenACC region" "TODO" { xfail *-*-* } }
+DO j = 1,10
+ENDDO
+  ENDDO
+
+  !$acc kernels loop worker
+  DO i = 1,10
+!$acc kernels loop worker ! { dg-bogus "OpenACC construct inside of 
non-OpenACC region" "TODO" { xfail *-*-* } }
+DO j = 1,10
+ENDDO
+!$acc kernels loop gang ! { dg-bogus "OpenACC construct inside of 
non-OpenACC region" "TODO" { xfail *-*-* } }
+DO j = 1,10
+ENDDO
+  ENDDO
+
+  !$acc kernels loop vector
+  DO i = 1,10
+!$acc kernels loop vector ! { dg-bogus "OpenACC construct inside of 
non-OpenACC region" "TODO" { xfail *-*-* } }
+DO j = 1,10
+ENDDO
+!$acc kernels loop worker ! { dg-bogus "OpenA

Use existing middle end checking for Fortran OpenACC loop clauses

2018-12-09 Thread Thomas Schwinge
Hi!

Committed to trunk in r266922:

commit fd1f371dd476ba3e76fb62eb76f1c1e23bd77b33
Author: tschwinge 
Date:   Sun Dec 9 12:47:58 2018 +

Use existing middle end checking for Fortran OpenACC loop clauses

Don't duplicate in the Fortran front end what's generically being checked in
the middle end.

gcc/fortran/
* openmp.c (resolve_oacc_loop_blocks): Remove checking of OpenACC
loop clauses.
gcc/testsuite/
* gfortran.dg/goacc/loop-2-kernels.f95: Update.
* gfortran.dg/goacc/loop-2-parallel.f95: Likewise.
* gfortran.dg/goacc/nested-parallelism.f90: Likewise.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@266922 
138bc75d-0d04-0410-961f-82ee72b054a4
---
 gcc/fortran/ChangeLog  |  3 +
 gcc/fortran/openmp.c   | 70 --
 gcc/testsuite/ChangeLog|  4 ++
 gcc/testsuite/gfortran.dg/goacc/loop-2-kernels.f95 | 40 ++---
 .../gfortran.dg/goacc/loop-2-parallel.f95  | 40 ++---
 .../gfortran.dg/goacc/nested-parallelism.f90   | 12 ++--
 6 files changed, 53 insertions(+), 116 deletions(-)

diff --git gcc/fortran/ChangeLog gcc/fortran/ChangeLog
index ae1871ec7f8d..c6eb05174f69 100644
--- gcc/fortran/ChangeLog
+++ gcc/fortran/ChangeLog
@@ -1,5 +1,8 @@
 2018-12-09  Thomas Schwinge  
 
+   * openmp.c (resolve_oacc_loop_blocks): Remove checking of OpenACC
+   loop clauses.
+
PR fortran/88420
* openmp.c (resolve_oacc_loop_blocks): Remove "Clause SEQ
conflicts with INDEPENDENT" diagnostic.
diff --git gcc/fortran/openmp.c gcc/fortran/openmp.c
index d97b8bfbb142..261a54a6015e 100644
--- gcc/fortran/openmp.c
+++ gcc/fortran/openmp.c
@@ -5659,12 +5659,6 @@ oacc_is_parallel (gfc_code *code)
   return code->op == EXEC_OACC_PARALLEL || code->op == EXEC_OACC_PARALLEL_LOOP;
 }
 
-static bool
-oacc_is_kernels (gfc_code *code)
-{
-  return code->op == EXEC_OACC_KERNELS || code->op == EXEC_OACC_KERNELS_LOOP;
-}
-
 static gfc_statement
 omp_code_to_statement (gfc_code *code)
 {
@@ -5846,73 +5840,9 @@ resolve_oacc_params_in_parallel (gfc_code *code, const 
char *clause,
 static void
 resolve_oacc_loop_blocks (gfc_code *code)
 {
-  fortran_omp_context *c;
-
   if (!oacc_is_loop (code))
 return;
 
-  if (code->op == EXEC_OACC_LOOP)
-for (c = omp_current_ctx; c; c = c->previous)
-  {
-   if (oacc_is_loop (c->code))
- {
-   if (code->ext.omp_clauses->gang)
- {
-   if (c->code->ext.omp_clauses->gang)
- gfc_error ("Loop parallelized across gangs is not allowed "
-"inside another loop parallelized across gangs at 
%L",
-&code->loc);
-   if (c->code->ext.omp_clauses->worker)
- gfc_error ("Loop parallelized across gangs is not allowed "
-"inside loop parallelized across workers at %L",
-&code->loc);
-   if (c->code->ext.omp_clauses->vector)
- gfc_error ("Loop parallelized across gangs is not allowed "
-"inside loop parallelized across vectors at %L",
-&code->loc);
- }
-   if (code->ext.omp_clauses->worker)
- {
-   if (c->code->ext.omp_clauses->worker)
- gfc_error ("Loop parallelized across workers is not allowed "
-"inside another loop parallelized across workers 
at %L",
-&code->loc);
-   if (c->code->ext.omp_clauses->vector)
- gfc_error ("Loop parallelized across workers is not allowed "
-"inside another loop parallelized across vectors 
at %L",
-&code->loc);
- }
-   if (code->ext.omp_clauses->vector)
- if (c->code->ext.omp_clauses->vector)
-   gfc_error ("Loop parallelized across vectors is not allowed "
-  "inside another loop parallelized across vectors at 
%L",
-  &code->loc);
- }
-
-   if (oacc_is_parallel (c->code) || oacc_is_kernels (c->code))
- break;
-  }
-
-  if (code->ext.omp_clauses->seq)
-{
-  if (code->ext.omp_clauses->gang)
-   gfc_error ("Clause SEQ conflicts with GANG at %L", &code->loc);
-  if (code->ext.omp_clauses->worker)
-   gfc_error ("Clause SEQ conflicts with WORKER at %L", &code->loc);
-  if (code->ext.omp_clauses->vector)
-   gfc_error ("Clause SEQ conflicts with VECTOR at %L", &code->loc);
-  if (code->ext.omp_clauses->par_auto)
-   gfc_error ("Clause SEQ conflicts with AUTO at %L", &code->loc);
-}
-  if (code->ext.omp_clauses->par_auto)
-{
-  if (code->ext.omp_clauses->gang)
-   gfc_error ("Clause AU

Re: [PATCH 2/3] Correct the reported line number in c++ combined OpenACC directives

2018-12-09 Thread Thomas Schwinge
Hi!

On Wed, 25 Jul 2018 08:29:18 -0700, Cesar Philippidis  
wrote:
> Like the fortran FE, the C++ FE doesn't set the expr_location of the
> split acc loop in combined acc parallel/kernels loop directives. This
> only happens for with combined directives, otherwise
> cp_parser_omp_construct would be responsible for setting the
> location. After fixing this bug, I was able to resolve a couple of
> long standing diagnostics discrepancies between the c/c++ FEs in the
> test suite.
> 
> Is this patch OK for trunk? I bootstrapped and regtested using x86_64
> with nvptx offloading.

Thanks, committed to trunk in r266923:

commit 21fb940c5d500a1a8e850b59412fb506aa51181a
Author: tschwinge 
Date:   Sun Dec 9 12:48:26 2018 +

Correct the reported line number in C++ combined OpenACC directives

The C++ FE doesn't set the expr_location of the split acc loop in combined 
acc
parallel/kernels loop directives. This only happens for with combined
directives, otherwise cp_parser_omp_construct would be responsible for 
setting
the location. After fixing this bug, I was able to resolve a couple of long
standing diagnostics discrepancies between the C/C++ FEs in the test suite.

gcc/cp/
* parser.c (cp_parser_oacc_kernels_parallel): Adjust EXPR_LOCATION
on the combined acc loop.
gcc/testsuite/
* c-c++-common/goacc/combined-directives-3.c: New test.
* c-c++-common/goacc/loop-2-kernels.c (void K): Adjust test.
* c-c++-common/goacc/loop-2-parallel.c (void P): Adjust test.
* c-c++-common/goacc/loop-3.c (void p2): Adjust test.

Reviewed-by: Thomas Schwinge 

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@266923 
138bc75d-0d04-0410-961f-82ee72b054a4
---
 gcc/cp/ChangeLog   |  5 
 gcc/cp/parser.c|  5 ++--
 gcc/testsuite/ChangeLog|  7 ++
 .../c-c++-common/goacc/combined-directives-3.c | 24 +++
 gcc/testsuite/c-c++-common/goacc/loop-2-kernels.c  | 24 +--
 gcc/testsuite/c-c++-common/goacc/loop-2-parallel.c | 28 +++---
 gcc/testsuite/c-c++-common/goacc/loop-3.c  | 24 +--
 7 files changed, 77 insertions(+), 40 deletions(-)

diff --git gcc/cp/ChangeLog gcc/cp/ChangeLog
index fc22f206606b..672be2d072db 100644
--- gcc/cp/ChangeLog
+++ gcc/cp/ChangeLog
@@ -1,3 +1,8 @@
+2018-12-09  Cesar Philippidis  
+
+   * parser.c (cp_parser_oacc_kernels_parallel): Adjust EXPR_LOCATION
+   on the combined acc loop.
+
 2018-12-07  Paolo Carlini  
 
* decl2.c (grokbitfield): Use DECL_SOURCE_LOCATION in error messages
diff --git gcc/cp/parser.c gcc/cp/parser.c
index adfe09e494dc..8b669a82b147 100644
--- gcc/cp/parser.c
+++ gcc/cp/parser.c
@@ -38742,8 +38742,9 @@ cp_parser_oacc_kernels_parallel (cp_parser *parser, 
cp_token *pragma_tok,
  cp_lexer_consume_token (parser->lexer);
  tree block = begin_omp_parallel ();
  tree clauses;
- cp_parser_oacc_loop (parser, pragma_tok, p_name, mask, &clauses,
-  if_p);
+ tree stmt = cp_parser_oacc_loop (parser, pragma_tok, p_name, mask,
+  &clauses, if_p);
+ protected_set_expr_location (stmt, pragma_tok->location);
  return finish_omp_construct (code, block, clauses);
}
 }
diff --git gcc/testsuite/ChangeLog gcc/testsuite/ChangeLog
index 192a29ee971c..6b26f6f510db 100644
--- gcc/testsuite/ChangeLog
+++ gcc/testsuite/ChangeLog
@@ -1,3 +1,10 @@
+2018-12-09  Cesar Philippidis  
+
+   * c-c++-common/goacc/combined-directives-3.c: New test.
+   * c-c++-common/goacc/loop-2-kernels.c (void K): Adjust test.
+   * c-c++-common/goacc/loop-2-parallel.c (void P): Adjust test.
+   * c-c++-common/goacc/loop-3.c (void p2): Adjust test.
+
 2018-12-09  Thomas Schwinge  
 
* gfortran.dg/goacc/loop-2-kernels.f95: Update.
diff --git gcc/testsuite/c-c++-common/goacc/combined-directives-3.c 
gcc/testsuite/c-c++-common/goacc/combined-directives-3.c
new file mode 100644
index ..77d418262eac
--- /dev/null
+++ gcc/testsuite/c-c++-common/goacc/combined-directives-3.c
@@ -0,0 +1,24 @@
+/* Verify the accuracy of the line number associated with combined
+   constructs.  */
+
+int
+main ()
+{
+  int x, y, z;
+
+#pragma acc parallel loop seq auto /* { dg-error "'seq' overrides other 
OpenACC loop specifiers" } */
+  for (x = 0; x < 10; x++)
+#pragma acc loop
+for (y = 0; y < 10; y++)
+  ;
+
+#pragma acc parallel loop gang auto /* { dg-error "'auto' conflicts with other 
OpenACC loop specifiers" } */
+  for (x = 0; x < 10; x++)
+#pragma acc loop worker auto /* { dg-error "'auto' conflicts with other 
OpenACC loop specifiers" } */
+for (y = 0; y < 10; y++)
+#pragma acc loop vector
+  for (z = 0; z < 10; z++)
+   ;
+
+  return 0;
+

Re: [PATCH 1/3] Correct the reported line number in fortran combined OpenACC directives

2018-12-09 Thread Thomas Schwinge
Hi!

On Wed, 25 Jul 2018 08:53:35 -0700, Cesar Philippidis  
wrote:
> On 07/25/2018 08:32 AM, Marek Polacek wrote:
> > On Wed, Jul 25, 2018 at 08:29:17AM -0700, Cesar Philippidis wrote:
> >> The fortran FE incorrectly records the line locations of combined acc
> >> loop directives when it lowers the construct to gimple.

After a bit of preparational work to "use existing middle end checking
for Fortran OpenACC loop clauses"...

> >> Usually this
> >> isn't a problem because the fortran FE is able to report problems with
> >> acc loops itself.

..., the Fortran front end is no longer doing that, and...

> >> However, there will be inaccuracies if the ME tries
> >> to use those locations.
> >>
> >> Note that test cases are inconspicuously absent in this patch.

..., I've been able to verify your changes by translating your C++ test
case into Fortran.

> >> However, without this bug fix, -fopt-info-note-omp will report bogus
> >> line numbers. This code patch will be tested in a later patch in
> >> this series.

> >> +  if (CAN_HAVE_LOCATION_P (stmt))
> >> +SET_EXPR_LOCATION (stmt, loc);
> > 
> > This is protected_set_expr_location.
> 
> Neat, thanks! This patch includes that correction. Is it ok for trunk
> after bootstrapping and regression testing?

Thanks, committed to trunk in r266924:

commit a43ff24656fa8224b249e159ea81e629ffa32664
Author: tschwinge 
Date:   Sun Dec 9 12:49:20 2018 +

Correct the reported line number in Fortran combined OpenACC directives

gcc/fortran/
* trans-openmp.c (gfc_trans_oacc_combined_directive): Set the
location of combined acc loops.
gcc/testsuite/
* gfortran.dg/goacc/combined-directives-3.f90: New file.

Reviewed-by: Thomas Schwinge 

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@266924 
138bc75d-0d04-0410-961f-82ee72b054a4
---
 gcc/fortran/ChangeLog  |  5 +
 gcc/fortran/trans-openmp.c |  5 +++--
 gcc/testsuite/ChangeLog|  4 
 .../c-c++-common/goacc/combined-directives-3.c |  1 +
 .../gfortran.dg/goacc/combined-directives-3.f90| 26 ++
 5 files changed, 39 insertions(+), 2 deletions(-)

diff --git gcc/fortran/ChangeLog gcc/fortran/ChangeLog
index c6eb05174f69..e74bda7a1362 100644
--- gcc/fortran/ChangeLog
+++ gcc/fortran/ChangeLog
@@ -1,3 +1,8 @@
+2018-12-09  Cesar Philippidis  
+
+   * trans-openmp.c (gfc_trans_oacc_combined_directive): Set the
+   location of combined acc loops.
+
 2018-12-09  Thomas Schwinge  
 
* openmp.c (resolve_oacc_loop_blocks): Remove checking of OpenACC
diff --git gcc/fortran/trans-openmp.c gcc/fortran/trans-openmp.c
index c9fc4e49c450..bf3f46939e39 100644
--- gcc/fortran/trans-openmp.c
+++ gcc/fortran/trans-openmp.c
@@ -3878,6 +3878,7 @@ gfc_trans_oacc_combined_directive (gfc_code *code)
   gfc_omp_clauses construct_clauses, loop_clauses;
   tree stmt, oacc_clauses = NULL_TREE;
   enum tree_code construct_code;
+  location_t loc = input_location;
 
   switch (code->op)
 {
@@ -3939,12 +3940,12 @@ gfc_trans_oacc_combined_directive (gfc_code *code)
   else
 pushlevel ();
   stmt = gfc_trans_omp_do (code, EXEC_OACC_LOOP, pblock, &loop_clauses, NULL);
+  protected_set_expr_location (stmt, loc);
   if (TREE_CODE (stmt) != BIND_EXPR)
 stmt = build3_v (BIND_EXPR, NULL, stmt, poplevel (1, 0));
   else
 poplevel (0, 0);
-  stmt = build2_loc (input_location, construct_code, void_type_node, stmt,
-oacc_clauses);
+  stmt = build2_loc (loc, construct_code, void_type_node, stmt, oacc_clauses);
   gfc_add_expr_to_block (&block, stmt);
   return gfc_finish_block (&block);
 }
diff --git gcc/testsuite/ChangeLog gcc/testsuite/ChangeLog
index 6b26f6f510db..19bc532c9d57 100644
--- gcc/testsuite/ChangeLog
+++ gcc/testsuite/ChangeLog
@@ -1,3 +1,7 @@
+2018-12-09  Thomas Schwinge  
+
+   * gfortran.dg/goacc/combined-directives-3.f90: New file.
+
 2018-12-09  Cesar Philippidis  
 
* c-c++-common/goacc/combined-directives-3.c: New test.
diff --git gcc/testsuite/c-c++-common/goacc/combined-directives-3.c 
gcc/testsuite/c-c++-common/goacc/combined-directives-3.c
index 77d418262eac..c6e31c26a8f1 100644
--- gcc/testsuite/c-c++-common/goacc/combined-directives-3.c
+++ gcc/testsuite/c-c++-common/goacc/combined-directives-3.c
@@ -1,5 +1,6 @@
 /* Verify the accuracy of the line number associated with combined
constructs.  */
+/* See also "../../gfortran.dg/goacc/combined-directives-3.f90".  */
 
 int
 main ()
diff --git gcc/testsuite/gfortran.dg/goacc/combined-directives-3.f90 
gcc/testsuite/gfortran.dg/goacc/combined-directives-3.f90
new file mode 100644
index ..b138822827f6
--- /dev/null
+++ gcc/testsuite/gfortran.dg/goacc/combined-directives-3.f90
@@ -0,0 +1,26 @@
+! Verify the accuracy of the line number associated with combined constructs.
+! See "../../c-c++-common/goacc/combined-directives-3

[PATCH, d] Committd merge with upstream dmd

2018-12-09 Thread Iain Buclaw
Hi,

This patch merges the D front-end implementation with dmd upstream e2fe2687b.

Backports VRP fixes from the D front-end implementation to the C++
port, and  fixes errors reported by ubsan build where the conversion
from D didn't include adjusting integer suffixes from 'UL' to 'ULL',
fixing https://gcc.gnu.org/PR88366.

Bootstrapped and tested on x86_64-linux-gnu --with-build-config=bootstrap-ubsan

Committed to trunk as r266925.

-- 
Iain

---
diff --git a/gcc/d/dmd/MERGE b/gcc/d/dmd/MERGE
index 223ffbdc358..a1a1fa0efd1 100644
--- a/gcc/d/dmd/MERGE
+++ b/gcc/d/dmd/MERGE
@@ -1,4 +1,4 @@
-5220ad51eebe06754e6881d9bd5aab89dba2b065
+e2fe2687b817a201528abaa3aa882333e04db01b
 
 The first line of this file holds the git revision number of the last
 merge done from the dlang/dmd repository.
diff --git a/gcc/d/dmd/constfold.c b/gcc/d/dmd/constfold.c
index 4b5dceba62e..c3df013d802 100644
--- a/gcc/d/dmd/constfold.c
+++ b/gcc/d/dmd/constfold.c
@@ -446,13 +446,13 @@ UnionExp Div(Loc loc, Type *type, Expression *e1, Expression *e2)
 if (n2 == -1 && !type->isunsigned())
 {
 // Check for int.min / -1
-if ((dinteger_t)n1 == 0x8000UL && type->toBasetype()->ty != Tint64)
+if ((dinteger_t)n1 == 0x8000ULL && type->toBasetype()->ty != Tint64)
 {
 e2->error("integer overflow: int.min / -1");
 new(&ue) ErrorExp();
 return ue;
 }
-else if ((dinteger_t)n1 == 0x8000L) // long.min / -1
+else if ((dinteger_t)n1 == 0x8000LL) // long.min / -1
 {
 e2->error("integer overflow: long.min / -1");
 new(&ue) ErrorExp();
diff --git a/gcc/d/dmd/dcast.c b/gcc/d/dmd/dcast.c
index 39471665e4a..9606c994482 100644
--- a/gcc/d/dmd/dcast.c
+++ b/gcc/d/dmd/dcast.c
@@ -986,6 +986,19 @@ MATCH implicitConvTo(Expression *e, Type *t)
 visit((Expression *)e);
 }
 
+void visit(AndExp *e)
+{
+visit((Expression *)e);
+if (result != MATCHnomatch)
+return;
+
+MATCH m1 = e->e1->implicitConvTo(t);
+MATCH m2 = e->e2->implicitConvTo(t);
+
+// Pick the worst match
+result = (m1 < m2) ? m1 : m2;
+}
+
 void visit(OrExp *e)
 {
 visit((Expression *)e);
@@ -3381,74 +3394,6 @@ IntRange getIntRange(Expression *e)
 {
 class IntRangeVisitor : public Visitor
 {
-private:
-static uinteger_t getMask(uinteger_t v)
-{
-// Ref: http://graphics.stanford.edu/~seander/bithacks.html#RoundUpPowerOf2
-v |= v >> 1;
-v |= v >> 2;
-v |= v >> 4;
-v |= v >> 8;
-v |= v >> 16;
-v |= v >> 32;
-return v;
-}
-
-// The algorithms for &, |, ^ are not yet the best! Sometimes they will produce
-//  not the tightest bound. See
-//  https://github.com/D-Programming-Language/dmd/pull/116
-//  for detail.
-static IntRange unsignedBitwiseAnd(const IntRange& a, const IntRange& b)
-{
-// the DiffMasks stores the mask of bits which are variable in the range.
-uinteger_t aDiffMask = getMask(a.imin.value ^ a.imax.value);
-uinteger_t bDiffMask = getMask(b.imin.value ^ b.imax.value);
-// Since '&' computes the digitwise-minimum, the we could set all varying
-//  digits to 0 to get a lower bound, and set all varying digits to 1 to get
-//  an upper bound.
-IntRange result;
-result.imin.value = (a.imin.value & ~aDiffMask) & (b.imin.value & ~bDiffMask);
-result.imax.value = (a.imax.value | aDiffMask) & (b.imax.value | bDiffMask);
-// Sometimes the upper bound is overestimated. The upper bound will never
-//  exceed the input.
-if (result.imax.value > a.imax.value)
-result.imax.value = a.imax.value;
-if (result.imax.value > b.imax.value)
-result.imax.value = b.imax.value;
-result.imin.negative = result.imax.negative = a.imin.negative && b.imin.negative;
-return result;
-}
-static IntRange unsignedBitwiseOr(const IntRange& a, const IntRange& b)
-{
-// the DiffMasks stores the mask of bits which are variable in the range.
-uinteger_t aDiffMask = getMask(a.imin.value ^ a.imax.value);
-uinteger_t bDiffMask = getMask(b.imin.value ^ b.imax.value);
-// The imax algorithm by Adam D. Ruppe.
-// http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=digitalmars.D&artnum=108796
-IntRange result;
-result.imin.value = (a.imin.value & ~aDiffMask) | (b.imin.value & ~bDiffMask);
-result.imax.value = a.imax.valu

[patch, fortran] Fix PR 88411, wrong code with async I/O

2018-12-09 Thread Thomas Koenig

Hello world,

the attached patch fixes the wrong-code regression by changing the
way synchronous writes are handled on files using asynchronous I/O:
The are now handled synchronously.

This also means that two places where a wait instruction was
issued in such a case are no longer needed.

I tried to construct a failing test case for this new behavior,
but failed :-)

Regression-tested.

OK for trunk?

Regards

Thomas
Index: io/transfer.c
===
--- io/transfer.c	(Revision 266250)
+++ io/transfer.c	(Arbeitskopie)
@@ -3189,7 +3189,7 @@ data_transfer_init (st_parameter_dt *dtp, int read
 	}
 }
 
-  if (au)
+  if (au && dtp->u.p.async)
 {
   NOTE ("enqueue_data_transfer");
   enqueue_data_transfer_init (au, dtp, read_flag);
@@ -4313,11 +4313,8 @@ st_read_done (st_parameter_dt *dtp)
 	*dtp->id = enqueue_done_id (dtp->u.p.current_unit->au, AIO_READ_DONE);  
 	  else
 	{
-	  enqueue_done (dtp->u.p.current_unit->au, AIO_READ_DONE);
-	  /* An asynchronous unit without ASYNCHRONOUS="YES" - make this
-		 synchronous by performing a wait operation.  */
-	  if (!dtp->u.p.async)
-		async_wait (&dtp->common, dtp->u.p.current_unit->au);
+	  if (dtp->u.p.async)
+		enqueue_done (dtp->u.p.current_unit->au, AIO_READ_DONE);
 	}
 	}
   else
@@ -4401,7 +4398,7 @@ st_write_done (st_parameter_dt *dtp)
 {
   if (dtp->u.p.current_unit)
 {
-  if (dtp->u.p.current_unit->au)
+  if (dtp->u.p.current_unit->au && dtp->u.p.async)
 	{
 	  if (dtp->common.flags & IOPARM_DT_HAS_ID)
 	*dtp->id = enqueue_done_id (dtp->u.p.current_unit->au,
@@ -4408,11 +4405,10 @@ st_write_done (st_parameter_dt *dtp)
 	AIO_WRITE_DONE);
 	  else
 	{
-	  enqueue_done (dtp->u.p.current_unit->au, AIO_WRITE_DONE);
-	  /* An asynchronous unit without ASYNCHRONOUS="YES" - make this
-		 synchronous by performing a wait operation.  */
-	  if (!dtp->u.p.async)
-		async_wait (&dtp->common, dtp->u.p.current_unit->au);
+	  /* We perform synchronous I/O on an asynchronous unit, so no need
+		 to enqueue AIO_READ_DONE.  */
+	  if (dtp->u.p.async)
+		enqueue_done (dtp->u.p.current_unit->au, AIO_WRITE_DONE);
 	}
 	}
   else
! { dg-do run }
! PR libfortran/88411
! This used to generate errors due to a mixup of
! synchronous and asynchronous execution.
! Test case by Harald Anlauf.
program gfcbug153
  implicit none
  integer :: iu, irecl
  real:: a(100,20), b(1,3000)
  iu = 10
  a  = 0.
  b  = 0.
  inquire (iolength = irecl) a
  open (iu, file="file1.dat", access='direct', &
   asynchronous='yes', &
   recl=irecl)
  write(iu, rec=1) a(:,:)
  write(iu, rec=2) a(:,:)
  write(iu, rec=3) a(:,:)
  close (iu,status="delete")

  inquire (iolength = irecl) b
  open (iu, file="file2.dat", access='direct', &
   asynchronous='yes', &
   recl=irecl)
  write(iu, rec=1) b(:,:)
  write(iu, rec=2) b(:,:)
  write(iu, rec=3) b(:,:)
  close (iu,status="delete")
end program


Re: [patch, fortran] Fix PR 88411, wrong code with async I/O

2018-12-09 Thread Jerry DeLisle

On 12/9/18 8:11 AM, Thomas Koenig wrote:

Hello world,

the attached patch fixes the wrong-code regression by changing the
way synchronous writes are handled on files using asynchronous I/O:
The are now handled synchronously.

This also means that two places where a wait instruction was
issued in such a case are no longer needed.

I tried to construct a failing test case for this new behavior,
but failed :-)

Regression-tested.

OK for trunk?



Looks good Thomas, thanks for quick fix.

Jerry


[Committed] PR fortran/88228 -- ICE with -fdec and logical op on integers

2018-12-09 Thread Steve Kargl
I committed attached patch to trunk, branch-8, and branch-7.

2018-12-09  Fritz Reese  

PR fortran/88228
* resolve.c (resolve_operator):  Do not call resolve_function.
Break like other cases.

2018-12-09  Steven G. Kargl  

PR fortran/88228
* gfortran.dg/pr88228.f90: New test.

-- 
Steve
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c	(revision 266925)
+++ gcc/fortran/resolve.c	(working copy)
@@ -4004,7 +4004,7 @@ resolve_operator (gfc_expr *e)
 	  if (op2->ts.type != e->ts.type || op2->ts.kind != e->ts.kind)
 	gfc_convert_type (op2, &e->ts, 1);
 	  e = logical_to_bitwise (e);
-	  return resolve_function (e);
+	  break;
 	}
 
   sprintf (msg, _("Operands of logical operator %%<%s%%> at %%L are %s/%s"),
@@ -4020,7 +4020,7 @@ resolve_operator (gfc_expr *e)
 	  e->ts.type = BT_INTEGER;
 	  e->ts.kind = op1->ts.kind;
 	  e = logical_to_bitwise (e);
-	  return resolve_function (e);
+	  break;
 	}
 
   if (op1->ts.type == BT_LOGICAL)
Index: gcc/testsuite/gfortran.dg/pr88228.f90
===
--- gcc/testsuite/gfortran.dg/pr88228.f90	(nonexistent)
+++ gcc/testsuite/gfortran.dg/pr88228.f90	(working copy)
@@ -0,0 +1,8 @@
+! { dg-do compile }
+! { dg-options "-fdec" }
+! PR fortran/88228
+program p
+   integer :: n = .not. 1
+   integer :: j = .true. .or. 1
+end
+


[committed] hppa: Add target support infrastructure for D front end

2018-12-09 Thread John David Anglin
The attached change has been tested on hppa-unknown-linux-gnu with an
initial implementation
of libphobos.  Committed to trunk.

Dave

-- 
John David Anglin  dave.ang...@bell.net

2018-12-09  John David Anglin  

* config.gcc (hppa*-*-linux*): Add pa/t-pa to tmake_file.  Define
d_target_objs.
* config/pa/pa-protos.h (pa_d_target_versions): New prototype.
* config/pa/pa.h (TARGET_D_CPU_VERSIONS): Define.
* config/pa/pa-d.c: New file.
* config/pa/t-pa: New file.

Index: config.gcc
===
--- config.gcc  (revision 266405)
+++ config.gcc  (working copy)
@@ -1447,7 +1447,8 @@
target_cpu_default="MASK_PA_11|MASK_NO_SPACE_REGS|MASK_CALLER_COPIES"
tm_file="${tm_file} dbxelf.h elfos.h gnu-user.h linux.h glibc-stdint.h 
pa/pa-linux.h \
 pa/pa32-regs.h pa/pa32-linux.h"
-   tmake_file="${tmake_file} pa/t-linux"
+   tmake_file="${tmake_file} pa/t-pa pa/t-linux"
+   d_target_objs="${d_target_objs} pa-d.o"
;;
 hppa*-*-openbsd*)
target_cpu_default="MASK_PA_11"
Index: config/pa/pa-protos.h
===
--- config/pa/pa-protos.h   (revision 266405)
+++ config/pa/pa-protos.h   (working copy)
@@ -110,3 +110,6 @@
 extern HOST_WIDE_INT pa_function_arg_size (machine_mode, const_tree);
 
 extern const int pa_magic_milli[];
+
+/* Routines implemented in pa-d.c  */
+extern void pa_d_target_versions (void);
Index: config/pa/pa.h
===
--- config/pa/pa.h  (revision 266405)
+++ config/pa/pa.h  (working copy)
@@ -1302,3 +1302,6 @@
   (flag_pic ? (TARGET_HPUX ? 198164 : 221312) : 24)
 
 #define NEED_INDICATE_EXEC_STACK 0
+
+/* Target CPU versions for D.  */
+#define TARGET_D_CPU_VERSIONS pa_d_target_versions
--- /dev/null   2018-11-24 12:57:36.82000 -0500
+++ config/pa/pa-d.c2018-11-20 18:17:23.807892880 -0500
@@ -0,0 +1,39 @@
+/* Subroutines for the D front end on the HPPA architecture.
+   Copyright (C) 2018 Free Software Foundation, Inc.
+
+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 "target.h"
+#include "d/d-target.h"
+#include "d/d-target-def.h"
+
+/* Implement TARGET_D_CPU_VERSIONS for HPPA targets.  */
+
+void
+pa_d_target_versions (void)
+{
+  if (TARGET_64BIT)
+d_add_builtin_version ("HPPA64");
+  else
+d_add_builtin_version ("HPPA");
+
+  if (TARGET_SOFT_FLOAT)
+d_add_builtin_version ("D_SoftFloat");
+  else
+d_add_builtin_version ("D_HardFloat");
+}
--- /dev/null   2018-11-24 12:57:36.82000 -0500
+++ config/pa/t-pa  2018-11-20 07:45:53.982380350 -0500
@@ -0,0 +1,4 @@
+pa-d.o: $(srcdir)/config/pa/pa-d.c
+   $(COMPILE) $<
+   $(POSTCOMPILE)
+


Re: [testsuite] Require ucn support in gdc.test/compilable/ddoc12.d (PR d/88039)

2018-12-09 Thread Iain Buclaw
On Tue, 4 Dec 2018 at 14:49, Rainer Orth  wrote:
>
> Hi Iain,
>
> > On Sat, 1 Dec 2018 at 19:28, Iain Buclaw  wrote:
> >>
> >> On Thu, 29 Nov 2018 at 15:12, Rainer Orth  
> >> wrote:
> >> >
> >> > Hi Iain,
> >> >
> >> > > On Tue, 27 Nov 2018 at 20:32, Rainer Orth
> >> > >  wrote:
> >> > >>
> >> > >> Hi Mike,
> >> > >>
> >> > >> > On Nov 27, 2018, at 2:18 AM, Rainer Orth 
> >> > >> > 
> >> > >> > wrote:
> >> > >> >>
> >> > >> >> Some assemblers, including the Solaris one, don't support UTF-8
> >> > >> >> identifiers, which breaks the gdc.test/compilable/ddoc12.d 
> >> > >> >> testcase as
> >> > >> >> reported in the PR.
> >> > >> >
> >> > >> > So, another style of fix, would be to change the binding from the
> >> > >> > language
> >> > >> > front-end to encode unsupported symbols using a fixed, documented, 
> >> > >> > abi
> >> > >> > defined technique.
> >> > >>
> >> > >> there's been some discussion on this in the PR.  Joseph's suggestion 
> >> > >> was
> >> > >> to follow the system compilers if this were done, and indeed they do
> >> > >> encode UTF-8 identifiers in some way which could either be
> >> > >> reverse-engineered or a spec obtained.  However, given Iain's stance
> >> > >> towards UTF-8 identifiers in D, I very much doubt this is worth the
> >> > >> effort.  Ultimately, it's his call, of course.
> >> > >>
> >> > >
> >> > > Not only my stance, but as a whole just how those maintaining the core
> >> > > language generally agree on. Encoding UTF8 characters in symbols is
> >> > > not part of the D ABI, so that is something that needs convincing
> >> > > upstream.
> >> > >
> >> > > There is a third way however, all compilable/ddoc* tests don't
> >> > > actually require us to compile the module all the way down to object
> >> > > code, the only thing that really needs to be tested is the Ddoc
> >> > > generator itself.  Which would be setting 'dg-do-what compile' and
> >> > > build with the compiler option -fdoc, then dg-final checks for the
> >> > > presence of the file ddoc12.html is the minimum that needs to be done
> >> > > for these tests to be considered passed.
> >> > >
> >> > > I'll have a look into doing it that way tomorrow.
> >> >
> >> > that would be even better of course, also saving some testing time.
> >> >
> >>
> >> Hi Rainer,
> >>
> >> Attached patch for it, I've checked that and it does the right thing
> >> and passes on x86_64.
> >>
> >> There's a couple more changes than just testsuite files, as compiling
> >> with -fdoc unearthed bug fixes not backported from the D version of
> >> the compiler.  These I'll apply separately.
> >>
> >
> > D2 front-end and testsuite changes have been upstreamed/downstreamed.
> > If there's no complaint, I'll apply the dejagnu fix as well.
>
> not at all: I've checked it on i386-pc-solaris2.11/gas and
> sparc-sun-solaris2.12/as and compilable/ddoc12.d now PASSes on both, so
> the gdc-test.exp part is ok.  Please mention PR d/88039 in the
> ChangeLog.
>

Done, and committed in r266933.

-- 
Iain


[PATCH] hppa: Add libphobos support

2018-12-09 Thread John David Anglin
The attached change implements a first cut at libphobos support on
hppa/glibc/linux.  Test
results are here:
.

Okay?

Dave

-- 
John David Anglin  dave.ang...@bell.net

2018-12-09  John David Anglin  

* configure.tgt: Add hppa*-*-linux* target.
* libdruntime/core/stdc/errno.d: Define for hppa/glibc/linux.
* libdruntime/core/stdc/fenv.d: Likewise.
* libdruntime/core/stdc/math.d: Likewise.
* libdruntime/core/sys/linux/dlfcn.d: Likewise.
* libdruntime/core/sys/linux/epoll.d: Likewise.
* libdruntime/core/sys/linux/link.d: Likewise.
* libdruntime/core/sys/linux/sys/eventfd.d: Likewise.
* libdruntime/core/sys/linux/sys/inotify.d: Likewise.
* libdruntime/core/sys/posix/dlfcn.d: Likewise.
* libdruntime/core/sys/posix/fcntl.d: Likewise.
* libdruntime/core/sys/posix/setjmp.d: Likewise.
* libdruntime/core/sys/posix/signal.d: Likewise.
* libdruntime/core/sys/posix/sys/socket.d: Likewise.
* libdruntime/core/sys/posix/sys/stat.d: Likewise.
* libdruntime/core/sys/posix/sys/types.d: Likewise.
* libdruntime/core/sys/posix/ucontext.d: Likewise.
* libdruntime/rt/sections_elf_shared.d: Likewise.
* src/std/experimental/allocator/building_blocks/region.d: Likewise.
* src/std/math.d: Likewise.

Index: configure.tgt
===
--- configure.tgt   (revision 266930)
+++ configure.tgt   (working copy)
@@ -24,6 +24,8 @@
 case "${target}" in
   arm*-*-linux*)
;;
+  hppa*-*-linux*)
+   ;;
   mips*-*-linux*)
;;
   x86_64-*-kfreebsd*-gnu | i?86-*-kfreebsd*-gnu)
Index: libdruntime/core/stdc/errno.d
===
--- libdruntime/core/stdc/errno.d   (revision 266930)
+++ libdruntime/core/stdc/errno.d   (working copy)
@@ -25,6 +25,7 @@
 
 version (ARM) version = ARM_Any;
 version (AArch64) version = ARM_Any;
+version (HPPA)version = HPPA_Any;
 version (MIPS32)  version = MIPS_Any;
 version (MIPS64)  version = MIPS_Any;
 version (PPC) version = PPC_Any;
@@ -421,6 +422,112 @@
 enum ERFKILL= 132;///
 enum EHWPOISON  = 133;///
 }
+else version (HPPA_Any)
+{
+enum ENOMSG = 35; ///
+enum EIDRM  = 36; ///
+enum ECHRNG = 37; ///
+enum EL2NSYNC   = 38; ///
+enum EL3HLT = 39; ///
+enum EL3RST = 40; ///
+enum ELNRNG = 41; ///
+enum EUNATCH= 42; ///
+enum ENOCSI = 43; ///
+enum EL2HLT = 44; ///
+enum EDEADLK= 45; ///
+enum EDEADLOCK  = EDEADLK;///
+enum ENOLCK = 46; ///
+enum EILSEQ = 47; ///
+enum ENONET = 50; ///
+enum ENODATA= 51; ///
+enum ETIME  = 52; ///
+enum ENOSR  = 53; ///
+enum ENOSTR = 54; ///
+enum ENOPKG = 55; ///
+enum ENOLINK= 57; ///
+enum EADV   = 58; ///
+enum ESRMNT = 59; ///
+enum ECOMM  = 60; ///
+enum EPROTO = 61; ///
+enum EMULTIHOP  = 64; ///
+enum EDOTDOT= 66; ///
+enum EBADMSG= 67; ///
+enum EUSERS = 68; ///
+enum EDQUOT = 69; ///
+enum ESTALE = 70; ///
+enum EREMOTE= 71; ///
+enum EOVERFLOW  = 72; ///
+enum EBADE  = 160;///
+enum EBADR  = 161;///
+enum EXFULL = 162;///
+enum ENOANO = 163;///
+enum EBADRQC= 164;///
+enum EBADSLT= 165;///
+enum EBFONT = 166;///
+enum ENOTUNIQ   = 167;///
+enum EBADFD = 168;///
+enum EREMCHG= 169;///
+enum ELIBACC= 170;///
+enum ELIBBAD= 171;///
+enum ELIBSCN= 172;///
+enum ELIBMAX= 173;///
+enum ELIBEXEC   = 174;///
+enum ERESTART   = 175;///
+enum ESTRPIPE   = 176;///
+enum EUCLEAN= 177;///

[Committed] PR fortran/88206 -- Fix REAL issue with array constructor

2018-12-09 Thread Steve Kargl
The attach patch fixes an issue where REAL intrinsic can confuse
typespec rsolution in an array constructor.

2018-12-09  Steven G. Kargl  

PR fortran/88206
* match.c (gfc_match_type_spec): REAL can be an intrinsic function.

2018-12-09  Steven G. Kargl  

PR fortran/88206
* gfortran.dg/pr88206.f90: New test.

-- 
Steve
Index: gcc/fortran/match.c
===
--- gcc/fortran/match.c	(revision 266929)
+++ gcc/fortran/match.c	(working copy)
@@ -2225,6 +2225,9 @@ found:
 	  return MATCH_NO;
 	}
 
+	  if (e->expr_type != EXPR_CONSTANT)
+	goto ohno;
+
 	  gfc_next_char (); /* Burn the ')'. */
 	  ts->kind = (int) mpz_get_si (e->value.integer);
 	  if (gfc_validate_kind (ts->type, ts->kind , true) == -1)
@@ -2238,6 +2241,8 @@ found:
 	  return MATCH_YES;
 	}
 }
+
+ohno:
 
   /* If a type is not matched, simply return MATCH_NO.  */
   gfc_current_locus = old_locus;
Index: gcc/testsuite/gfortran.dg/pr88206.f90
===
--- gcc/testsuite/gfortran.dg/pr88206.f90	(nonexistent)
+++ gcc/testsuite/gfortran.dg/pr88206.f90	(working copy)
@@ -0,0 +1,8 @@
+! { dg-do compile }
+! PR fortran/88206
+program p
+   integer, parameter :: z(4) = [1,2,3,4]
+   integer :: k = 2
+   print *, [real(z(k))]
+end
+


Re: [committed] hppa: Add target support infrastructure for D front end

2018-12-09 Thread Iain Buclaw
On Sun, 9 Dec 2018 at 20:49, John David Anglin  wrote:
>
> The attached change has been tested on hppa-unknown-linux-gnu with an
> initial implementation
> of libphobos.  Committed to trunk.
>
> Dave
>

Thanks!  Shouldn't this be made available to all hppa* configurations
though?  Or just conservatively adding it for now.

--
Iain


Re: [PATCH] hppa: Add libphobos support

2018-12-09 Thread Iain Buclaw
On Sun, 9 Dec 2018 at 21:16, John David Anglin  wrote:
>
> The attached change implements a first cut at libphobos support on
> hppa/glibc/linux.  Test
> results are here:
> .
>
> Okay?
>

>From what I can see, everything is properly scoped and looks valid (no
accidental C-style syntax anywhere).  Looking at the test results,
seems like nothing runs, which may not be entirely unexpected from a
new port, but I would have expected a little better.  I've just tried
building a cross-compiler and running some small programs under qemu,
but it seems that nothing works under emulation, not even C programs.

Would you mind if I send this to the upstream druntime first?
Repository is here https://github.com/dlang/druntime

-- 
Iain


[PATCH, libphobos] Committed added druntime bindings for sparc/solaris

2018-12-09 Thread Iain Buclaw
Hi,

This patch is backported from druntime master, adding initial
libdruntime bindings support for SPARC/Solaris.  Though I suspect
there's still plenty that's been missed out.

Bootstrapped and tested on x86_64-linux-gnu, not that it checks
anything except all changes are properly scoped.

Committed to trunk as r266935.

-- 
Iain

---
diff --git a/libphobos/libdruntime/core/stdc/fenv.d b/libphobos/libdruntime/core/stdc/fenv.d
index 00b99af97a2..abfdcde5330 100644
--- a/libphobos/libdruntime/core/stdc/fenv.d
+++ b/libphobos/libdruntime/core/stdc/fenv.d
@@ -457,6 +457,54 @@ version (CRuntime_Microsoft)
 FE_TOWARDZERO   = 0x300, ///
 }
 }
+else version (Solaris)
+{
+version (SPARC_Any)
+{
+enum
+{
+FE_TONEAREST= 0,
+FE_TOWARDZERO   = 1,
+FE_UPWARD   = 2,
+FE_DOWNWARD = 3,
+}
+
+enum
+{
+FE_INEXACT  = 0x01,
+FE_DIVBYZERO= 0x02,
+FE_UNDERFLOW= 0x04,
+FE_OVERFLOW = 0x08,
+FE_INVALID  = 0x10,
+FE_ALL_EXCEPT   = 0x1f,
+}
+
+}
+else version (X86_Any)
+{
+enum
+{
+FE_TONEAREST= 0,
+FE_DOWNWARD = 1,
+FE_UPWARD   = 2,
+FE_TOWARDZERO   = 3,
+}
+
+enum
+{
+FE_INVALID  = 0x01,
+FE_DIVBYZERO= 0x04,
+FE_OVERFLOW = 0x08,
+FE_UNDERFLOW= 0x10,
+FE_INEXACT  = 0x20,
+FE_ALL_EXCEPT   = 0x3d,
+}
+}
+else
+{
+static assert(0, "Unimplemented architecture");
+}
+}
 else
 {
 version (X86)
diff --git a/libphobos/libdruntime/core/sys/posix/aio.d b/libphobos/libdruntime/core/sys/posix/aio.d
index 372152ab063..99bd0b3475b 100644
--- a/libphobos/libdruntime/core/sys/posix/aio.d
+++ b/libphobos/libdruntime/core/sys/posix/aio.d
@@ -123,15 +123,58 @@ else version (DragonFlyBSD)
 
 version = BSD_Posix;
 }
+else version (Solaris)
+{
+struct aio_result_t
+{
+ssize_t aio_return;
+int aio_errno;
+}
+
+struct aiocb
+{
+int aio_fildes;
+void* aio_buf;   // volatile
+size_t aio_nbytes;
+off_t aio_offset;
+int aio_reqprio;
+sigevent aio_sigevent;
+int aio_lio_opcode;
+aio_result_t aio_resultp;
+int aio_state;
+int[1] aio__pad;
+}
+}
 else
 static assert(false, "Unsupported platform");
 
 /* Return values of cancelation function.  */
-enum
+version (CRuntime_Glibc)
 {
-AIO_CANCELED,
-AIO_NOTCANCELED,
-AIO_ALLDONE
+enum
+{
+AIO_CANCELED,
+AIO_NOTCANCELED,
+AIO_ALLDONE
+}
+}
+else version (Solaris)
+{
+enum
+{
+AIO_CANCELED,
+AIO_ALLDONE,
+AIO_NOTCANCELED
+}
+}
+else version (BSD_Posix)
+{
+enum
+{
+AIO_CANCELED,
+AIO_NOTCANCELED,
+AIO_ALLDONE
+}
 }
 
 /* Operation codes for `aio_lio_opcode'.  */
@@ -144,6 +187,15 @@ version (CRuntime_Glibc)
 LIO_NOP
 }
 }
+else version (Solaris)
+{
+enum
+{
+LIO_NOP,
+LIO_READ,
+LIO_WRITE,
+}
+}
 else version (BSD_Posix)
 {
 enum
@@ -163,6 +215,14 @@ version (CRuntime_Glibc)
 LIO_NOWAIT
 }
 }
+else version (Solaris)
+{
+enum
+{
+LIO_NOWAIT,
+LIO_WAIT
+}
+}
 else version (BSD_Posix)
 {
 enum
diff --git a/libphobos/libdruntime/core/sys/posix/ucontext.d b/libphobos/libdruntime/core/sys/posix/ucontext.d
index 964b77cc50d..9e7d6436e7e 100644
--- a/libphobos/libdruntime/core/sys/posix/ucontext.d
+++ b/libphobos/libdruntime/core/sys/posix/ucontext.d
@@ -989,7 +989,17 @@ else version (Solaris)
 {
 alias uint[4] upad128_t;
 
-version (X86_64)
+version (SPARC64)
+{
+enum _NGREG = 21;
+alias long greg_t;
+}
+else version (SPARC)
+{
+enum _NGREG = 19;
+alias int greg_t;
+}
+else version (X86_64)
 {
 enum _NGREG = 28;
 alias long greg_t;
@@ -999,10 +1009,81 @@ else version (Solaris)
 enum _NGREG = 19;
 alias int greg_t;
 }
+else
+static assert(0, "unimplemented");
 
 alias greg_t[_NGREG] gregset_t;
 
-version (X86_64)
+version (SPARC64)
+{
+private
+{
+struct _fpq
+{
+uint *fpq_addr;
+uint fpq_instr;
+}
+
+struct fq
+{
+union
+{
+double whole;
+_fpq fpq;
+}
+}
+}
+
+struct fpregset_t
+{
+union
+{
+uint[32]   fpu_regs;
+double[32] fpu_dregs;
+real[16]   fpu_qregs;
+}
+fq*fpu_q;
+

Re: RFA: PATCH to add pp command to gdbinit.in

2018-12-09 Thread Eric Gallager
On 12/6/18, Jason Merrill  wrote:
> Since pvt was removed, it's bugged me that to pretty-print a vec I
> needed to write out "call debug($)".  So this patch adds a generic
> command "pp" to print anything handled by a debug overload.
>
> OK for trunk?
>

Why does it also change pbb to do the same thing as the new pp command
you're adding?


Re: RFA: PATCH to add pp command to gdbinit.in

2018-12-09 Thread Jason Merrill
On Sun, Dec 9, 2018, 7:42 PM Eric Gallager  On 12/6/18, Jason Merrill  wrote:
> > Since pvt was removed, it's bugged me that to pretty-print a vec I
> > needed to write out "call debug($)".  So this patch adds a generic
> > command "pp" to print anything handled by a debug overload.
> >
> > OK for trunk?
> >
>
> Why does it also change pbb to do the same thing as the new pp command
> you're adding?
>

I assumed that some people were used to using pbb for basic_blocks. But on
reflection, the command before my patch didn't work at all, so it's
unlikely anyone was relying on it, so it's probably better to remove it.

Jason

>


Re: RFC: libiberty PATCH to disable demangling of ancient mangling schemes

2018-12-09 Thread Eric Gallager
On 12/7/18, Jason Merrill  wrote:
> On 12/7/18 6:36 AM, Richard Biener wrote:
>> On Thu, Dec 6, 2018 at 10:22 PM Jason Merrill  wrote:
>>>
>>> On Thu, Dec 6, 2018 at 11:14 AM Jason Merrill  wrote:

 Looks good to me.  Independently, do you see a reason not to disable
 the
 old demangler entirely?
>>>
>>> Like so.  Does anyone object to this?  These mangling schemes haven't
>>> been relevant in decades.
>>
>> Why #ifdef the code?  Just rip it out?
>
> I was thinking as an intermediate measure in case some user wanted it
> for some reason, but I'd be fine with that as well.
>
> Jason
>

A compromise could be to do the #ifdef for GCC 9, see if anyone
complains, and then if no one complains, rip it out entirely for GCC
10.


[Committed] PR fortran/88205 -- Check NEWUNIT after STATUS

2018-12-09 Thread Steve Kargl
The attach patch moves the checks on NEWUNIT to 
after the checks on STATUS.

2018-12-09  Steven G. Kargl  

PR fortran/88205
* io.c (gfc_match_open): Move NEWUNIT checks to after STATUS checks.

2018-12-09  Steven G. Kargl  

PR fortran/88205
* gfortran.dg/pr88205.f90: New unit.

-- 
Steve
Index: gcc/fortran/io.c
===
--- gcc/fortran/io.c	(revision 266929)
+++ gcc/fortran/io.c	(working copy)
@@ -2150,33 +2150,6 @@ gfc_match_open (void)
 
   warn = (open->err || open->iostat) ? true : false;
 
-  /* Checks on NEWUNIT specifier.  */
-  if (open->newunit)
-{
-  if (open->unit)
-	{
-	  gfc_error ("UNIT specifier not allowed with NEWUNIT at %C");
-	  goto cleanup;
-	}
-
-  if (!open->file && open->status)
-{
-	  if (open->status->expr_type == EXPR_CONSTANT
-	 && gfc_wide_strncasecmp (open->status->value.character.string,
-   "scratch", 7) != 0)
-	   {
-	 gfc_error ("NEWUNIT specifier must have FILE= "
-			"or STATUS='scratch' at %C");
-	 goto cleanup;
-	   }
-	}
-}
-  else if (!open->unit)
-{
-  gfc_error ("OPEN statement at %C must have UNIT or NEWUNIT specified");
-  goto cleanup;
-}
-
   /* Checks on the ACCESS specifier.  */
   if (open->access && open->access->expr_type == EXPR_CONSTANT)
 {
@@ -2499,6 +2472,33 @@ gfc_match_open (void)
 			 "cannot have the value SCRATCH if a FILE specifier "
 			 "is present");
 	}
+}
+
+  /* Checks on NEWUNIT specifier.  */
+  if (open->newunit)
+{
+  if (open->unit)
+	{
+	  gfc_error ("UNIT specifier not allowed with NEWUNIT at %C");
+	  goto cleanup;
+	}
+
+  if (!open->file && open->status)
+{
+	  if (open->status->expr_type == EXPR_CONSTANT
+	 && gfc_wide_strncasecmp (open->status->value.character.string,
+   "scratch", 7) != 0)
+	   {
+	 gfc_error ("NEWUNIT specifier must have FILE= "
+			"or STATUS='scratch' at %C");
+	 goto cleanup;
+	   }
+	}
+}
+  else if (!open->unit)
+{
+  gfc_error ("OPEN statement at %C must have UNIT or NEWUNIT specified");
+  goto cleanup;
 }
 
   /* Things that are not allowed for unformatted I/O.  */
Index: gcc/testsuite/gfortran.dg/pr88205.f90
===
--- gcc/testsuite/gfortran.dg/pr88205.f90	(nonexistent)
+++ gcc/testsuite/gfortran.dg/pr88205.f90	(working copy)
@@ -0,0 +1,14 @@
+! { dg-do compile }
+! PR fortran/88205
+subroutine s1
+   real, parameter :: status = 0
+   open (newunit=n, status=status)! { dg-error "STATUS requires" }
+end
+subroutine s2
+   complex, parameter :: status = 0
+   open (newunit=n, status=status)! { dg-error "STATUS requires" }
+end
+program p
+  logical, parameter :: status = .false.
+  open (newunit=a, status=status) ! { dg-error "STATUS requires" }
+end


Re: [PATCH] Fix debuginfo in -fopenmp code (PR debug/87039)

2018-12-09 Thread Kevin Buettner
On Fri, 16 Nov 2018 22:10:00 +0100
Jakub Jelinek  wrote:

> Kevin, did you have some gdb testcases you were trying for the r253335
> change?  Can you try those with added another e.g. parallel around it (say
> #pragma omp parallel if (0) or num_threads (1), so that it doesn't spawn too
> many children and see if you can check variables not mentioned in the inner
> parallel inside of the outer parallel, or even outside of the outer
> parallel?

Hi Jakub,

Sorry for the delayed response - I had some issues on the GDB side of
things that needed to be addressed before I could properly test your
patch.

In the GDB test that I've written, I test four scenarios:

1) Simple parallel region with no additional lexical scopes.

2) Like the above, but with additional lexical scopes.

3) Parallel region within nested function.

4) Nested parallel regions.

With your patch in place, I see correct results for scenarios 1, 2,
and 3.  Scenario 4 works better than it ever did in the past, though
there are still some problems.  Here is that test case - just
scenario 4:

static int file_scope_var = 9876;

void
nested_parallel (void)
{
  int i = 1, j = 2;
  int l = -1;

  omp_set_nested (1);
  omp_set_dynamic (0);
#pragma omp parallel num_threads (2) private (l)
  {
int num = omp_get_thread_num ();
int nthr = omp_get_num_threads ();
int off = num * nthr;
int k = off + 101;
l = off + 102;
#pragma omp parallel num_threads (2) shared (num)
{
  #pragma omp critical
  printf ("nested_parallel (inner threads): outer thread num = %d, thread 
num = %d\n", num, omp_get_thread_num ());
}
#pragma omp critical
printf ("nested_parallel (outer threads) %d: k = %d, l = %d\n", num, k, l);
  }
}

Breakpoints are placed on both of the printfs and attempts are made to
print some of the variables that should be in scope at each stop.  For
the "inner threads" printf, there are four stops altogether.

At each stop for those inner threads, GDB is able to successfully print
file_scope_var, num, i, and j.

For all but one of the stops, GDB is able to print the values for l and k.

Here is the log output for the fourth stop in which GDB cannot print out
either l or k:

print l
No frame is currently executing in block nested_parallel._omp_fn.3.
(gdb) XFAIL: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 4th 
stop: print l
print k
No frame is currently executing in specified block
(gdb) XFAIL: gdb.threads/omp-par-scope.exp: nested_parallel: inner_threads: 4th 
stop: print k

These failures are not entirely unexpected due to the fact that GDB is
not always able to correctly determine the thread parent for the nested
parallel case.  (Additional support will be required from libgomp.)

I still need to do some investigation to find out whether the messages
being printed make sense.

Anyway... I'm all in favor of your patch.  It fixes a bunch of failures
that I had been seeing for quite a while.

Kevin


Re: libgo patch committed: Add precise stack scan support

2018-12-09 Thread Matthias Klose
On 06.12.18 00:09, Ian Lance Taylor wrote:
> This libgo patch by Cherry Zhang adds support for precise stack
> scanning to the Go runtime.  This uses per-function stack maps stored
> in the exception tables in the language-specific data area.  The
> compiler needs to generate these stack maps; currently this is only
> done by a version of LLVM, not by GCC.  Each safepoint in a function
> is associated with a (real or dummy) landing pad, and its "type info"
> in the exception table is a pointer to the stack map. When a stack is
> scanned, the stack map is found by the stack unwinding code.
> 
> For precise stack scan we need to unwind the stack. There are three cases:
> 
> - If a goroutine is scanning its own stack, it can unwind the stack
> and scan the frames.
> 
> - If a goroutine is scanning another, stopped, goroutine, it cannot
> directly unwind the target stack. We handle this by switching
> (runtime.gogo) to the target g, letting it unwind and scan the stack,
> and switch back.
> 
> - If we are scanning a goroutine that is blocked in a syscall, we send
> a signal to the target goroutine's thread, and let the signal handler
> unwind and scan the stack. Extra care is needed as this races with
> enter/exit syscall.
> 
> Currently this is only implemented on GNU/Linux.
> 
> Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu.  Committed
> to mainline.

this broke the libgo build on ARM32:

../../../src/libgo/runtime/go-unwind.c: In function 'scanstackwithmap_callback':
../../../src/libgo/runtime/go-unwind.c:754:18: error: '_URC_NORMAL_STOP'
undeclared (first use in this function)
  754 |   return _URC_NORMAL_STOP;
  |  ^~~~
../../../src/libgo/runtime/go-unwind.c:754:18: note: each undeclared identifier
is reported only once for each function i
t appears in
../../../src/libgo/runtime/go-unwind.c: In function 'probestackmaps_callback':
../../../src/libgo/runtime/go-unwind.c:802:10: error: '_URC_NORMAL_STOP'
undeclared (first use in this function)
  802 |   return _URC_NORMAL_STOP;
  |  ^~~~
../../../src/libgo/runtime/go-unwind.c:803:1: warning: control reaches end of
non-void function [-Wreturn-type]
  803 | }
  | ^
make[6]: *** [Makefile:1474: runtime/go-unwind.lo] Error 1
make[6]: Leaving directory '/<>/build/arm-linux-gnueabihf/libgo'