[Bug ipa/90891] lto-bootstrap with ada enabled broken on x86_64

2019-06-15 Thread dimhen at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90891

Dmitry G. Dyachenko  changed:

   What|Removed |Added

 CC||dimhen at gmail dot com

--- Comment #1 from Dmitry G. Dyachenko  ---
PR90889 dup?

[Bug fortran/90890] segfault on LHS memory reallocation

2019-06-15 Thread sgk at troutmask dot apl.washington.edu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90890

--- Comment #3 from Steve Kargl  ---
On Sat, Jun 15, 2019 at 11:08:43PM +, bharat.mahajan at hotmail dot com
wrote:
> 
> I forgot to mention that code runs with no issues with ifort. Second, then why
> the following code works with gfortran?

The Fortran standard does not require a Fortran processor (i.e., 
the compiler) to detect and report that you are using an undefined
entity.

> program test
> implicit  none
> real, dimension(:), allocatable :: a
> integer :: b
> a = [a, 2.0]

What value does 'a' have on the right side of the above
expression?

The correct way to write the above would have either
been to assign something to 'a' prior to using on the
RHS above or writing

   if (allocated(a)) a = [a, 2.0]

> !b = -100
> end program test
> ---
> 
> I am not sure I would say 'a' is not defined.

The Fortran standard decides what is defined and undefined.

From F2018

   19.6.2 Variables that are always defined

   Zero-sized arrays and zero-length strings are always defined.

   19.6.3 Variables that are initially defined

   The following variables are initially defined:

 (1) variables specified to have initial values by DATA statements;
 (2) variables specified to have initial values by type declaration
 statements;
 (3) nonpointer default-initialized subcomponents of saved variables
 that do not have the ALLOCATABLE or POINTER attribute;
 (4) pointers specified to be initially associated with a variable
 that is initially defined;
 (5) variables that are always defined;
 (6) variables with the BIND attribute that are initialized by means
other than Fortran.

   19.6.4 Variables that are initially undefined

   Variables that are not initially defined are initially undefined.

Your 'a' is undefined.

[Bug fortran/90890] segfault on LHS memory reallocation

2019-06-15 Thread bharat.mahajan at hotmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90890

--- Comment #2 from Bharat Mahajan  ---
(In reply to kargl from comment #1)
> (In reply to Bharat Mahajan from comment #0)
> > The following program fails with segfault:
> > 
> > program test
> > implicit  none
> > real, dimension(:), allocatable :: a
> > integer :: b
> > 
> > a = [a, 2.0]
> > b = -100
> > end program test
> > 
> > Compiled it without any option to gfortran on MingW (Win10). If you comment
> > out the line "b=-100" then it works! gfortran version:
> > 
> > GNU Fortran (x86_64-posix-seh-rev0, Built by MinGW-W64 project) 8.1.0
> 
> The code is invalid.  In the expression 'a = [a, 2.0]'
> you reference 'a' on the RHS when it is undefined.

I forgot to mention that code runs with no issues with ifort. Second, then why
the following code works with gfortran?

---
program test
implicit  none
real, dimension(:), allocatable :: a
integer :: b
a = [a, 2.0]
!b = -100
end program test
---

I am not sure I would say 'a' is not defined. It is not allocated yet, that is
what the code is trying to do. I have not checked the standards so not sure
that the code is trying to do something outside of that, but it works with
ifort without their extensions.

[Bug fortran/90890] segfault on LHS memory reallocation

2019-06-15 Thread kargl at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90890

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||kargl at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #1 from kargl at gcc dot gnu.org ---
(In reply to Bharat Mahajan from comment #0)
> The following program fails with segfault:
> 
> program test
> implicit  none
> real, dimension(:), allocatable :: a
> integer :: b
> 
> a = [a, 2.0]
> b = -100
> end program test
> 
> Compiled it without any option to gfortran on MingW (Win10). If you comment
> out the line "b=-100" then it works! gfortran version:
> 
> GNU Fortran (x86_64-posix-seh-rev0, Built by MinGW-W64 project) 8.1.0

The code is invalid.  In the expression 'a = [a, 2.0]'
you reference 'a' on the RHS when it is undefined.

[Bug ipa/90891] New: lto-bootstrap with ada enabled broken on x86_64

2019-06-15 Thread hubicka at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90891

Bug ID: 90891
   Summary: lto-bootstrap with ada enabled broken on x86_64
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hubicka at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Hi,
configuring with  --enable-languages=ada,obj-c++,d,go,all --disable-multilib
--with-build-config=bootstrap-lto

I get the following ice linking gnatbind

during IPA pass: cp
   
   lto1: internal compiler error: in ipcp_verify_propagated_values,
at ipa-cp.c:1446   
  0x5d1647 ipcp_verify_propagated_values() 
   
 ../../gcc/ipa-cp.c:1446   
   
0xa7f9de
ipcp_propagate_stage   
   
  ../../gcc/ipa-cp.c:3314  
   
 0xa6757b ipcp_driver  
   
../../gcc/ipa-cp.c:5096
   
   0xa6757b execute
   
 
../../gcc/ipa-cp.c:5189
   
   Please submit a full bug report,
   
  with preprocessed source if appropriate. 
   
 Please include the complete backtrace with
any bug report.
See
 for instructions.  
   
   lto-wrapper: fatal error:
/aux/hubicka/trunk5/build-all/./prev-gcc/xg++ returned 1 exit status   

compilation terminated.

[Bug fortran/90890] New: segfault on LHS memory reallocation

2019-06-15 Thread bharat.mahajan at hotmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90890

Bug ID: 90890
   Summary: segfault on LHS memory reallocation
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bharat.mahajan at hotmail dot com
  Target Milestone: ---

The following program fails with segfault:

program test
implicit  none
real, dimension(:), allocatable :: a
integer :: b

a = [a, 2.0]
b = -100
end program test

Compiled it without any option to gfortran on MingW (Win10). If you comment out
the line "b=-100" then it works! gfortran version:

GNU Fortran (x86_64-posix-seh-rev0, Built by MinGW-W64 project) 8.1.0

[Bug other/43748] build machinery insufficient for installing target specific .def files as plugin headers

2019-06-15 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43748

Eric Gallager  changed:

   What|Removed |Added

 CC||iains at gcc dot gnu.org

--- Comment #3 from Eric Gallager  ---
since this is at least somewhat Darwin-related, cc-ing Iain...

[Bug tree-optimization/46029] -ftree-loop-if-convert-stores causes FAIL: libstdc++-v3/testsuite/ext/pb_ds/example/tree_intervals.cc

2019-06-15 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46029

--- Comment #7 from Eric Gallager  ---
the pb_ds directory might be removed in the future; might want to retitle this
to clarify that the underlying issue is actually in the compiler and the pb_ds
testcase only happens to expose it, so that this bug doesn't get closed when
the removal happens...
(assuming my read of the issue is right)

[Bug lto/90889] snapshot 20190614 fails to build Ada with LTO

2019-06-15 Thread ebotcazou at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90889

Eric Botcazou  changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
  Component|ada |lto
Summary|ada: snapshot 20190614  |snapshot 20190614 fails to
   |fails to build with LTO |build Ada with LTO

--- Comment #1 from Eric Botcazou  ---
Wrong component.

[Bug middle-end/64242] Longjmp expansion incorrect

2019-06-15 Thread dave.anglin at bell dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64242

--- Comment #28 from dave.anglin at bell dot net ---
On 2019-06-14 10:13 a.m., wilco at gcc dot gnu.org wrote:
> Given there are many possible stack layouts, the easiest option would be to
> clear the input buffer so it will jump to a null pointer. Eg.
>
> __attribute ((noinline)) void
> broken_longjmp (void *p)
> {
>   void *buf[32];
>   __builtin_memcpy (buf, p, 5 * sizeof (void*));
>   __builtin_memset (p, 0, 5 * sizeof (void*));
>   /* Corrupts stack pointer...  */
>   __builtin_longjmp (buf, 1);
> }
Yes, the above fixes test.  I think I have a fix for the pa longjmp and
nonlocal_goto expanders.

[Bug c++/60364] [[noreturn]] specified for second declaration but not first doesn't result in a diagnostic

2019-06-15 Thread mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60364

Marek Polacek  changed:

   What|Removed |Added

   Keywords||patch
 Status|NEW |ASSIGNED
 CC||mpolacek at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org

--- Comment #5 from Marek Polacek  ---
Patch posted:
https://gcc.gnu.org/ml/gcc-patches/2019-06/msg00880.html

[Bug objc/90709] [meta-bug] GNU Objective C (C++) cannot consume current headers on Darwin platforms.

2019-06-15 Thread iains at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90709

--- Comment #5 from Iain Sandoe  ---
Author: iains
Date: Sat Jun 15 14:03:44 2019
New Revision: 272327

URL: https://gcc.gnu.org/viewcvs?rev=272327&root=gcc&view=rev
Log:
[objective-c/c++, testsuite, 3/3] Workaround for PR90709.

Use the CF-CFString.h, F-NS*.h proxy headers where needed in the objective-c++
testsuite.  Make minor adjustments to tests as required, providing that those
do not alter the test intent.

2019-06-15  Iain Sandoe  

PR objc/90709
* obj-c++.dg/proto-lossage-7.mm: Use proxy headers.
* obj-c++.dg/strings/const-cfstring-2.mm: Likewise.
* obj-c++.dg/strings/const-cfstring-5.mm: Likewise
* obj-c++.dg/strings/const-str-12.mm: Likewise.
* obj-c++.dg/syntax-error-1.mm: Likewise.
* obj-c++.dg/torture/strings/const-cfstring-1.mm: Likewise.
* obj-c++.dg/torture/strings/const-str-10.mm: Likewise.
* obj-c++.dg/torture/strings/const-str-11.mm: Likewise.
* obj-c++.dg/torture/strings/const-str-9.mm: Likewise.
* obj-c++.dg/cxx-ivars-3.mm: Skip on later Darwin, where the 10.4 API
in no longer supported, also on m64 where there's no meaning to it.
* obj-c++.dg/isa-field-1.mm: Suppress unwanted warning, add comment
why.
* obj-c++.dg/objc-gc-3.mm: Skip for Darwin > 16, the API use is an
error
there.
* obj-c++.dg/qual-types-1.mm: Prune a spurious l64 warning.
* obj-c++.dg/stubify-1.mm: Tidy up after better compiler warnings.
* obj-c++.dg/stubify-2.mm: Likewise.
* obj-c++.dg/try-catch-1.mm: Likewise.
* obj-c++.dg/try-catch-3.mm: Likewise.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/obj-c++.dg/cxx-ivars-3.mm
trunk/gcc/testsuite/obj-c++.dg/isa-field-1.mm
trunk/gcc/testsuite/obj-c++.dg/objc-gc-3.mm
trunk/gcc/testsuite/obj-c++.dg/proto-lossage-7.mm
trunk/gcc/testsuite/obj-c++.dg/qual-types-1.mm
trunk/gcc/testsuite/obj-c++.dg/strings/const-cfstring-2.mm
trunk/gcc/testsuite/obj-c++.dg/strings/const-cfstring-5.mm
trunk/gcc/testsuite/obj-c++.dg/strings/const-str-12.mm
trunk/gcc/testsuite/obj-c++.dg/stubify-1.mm
trunk/gcc/testsuite/obj-c++.dg/stubify-2.mm
trunk/gcc/testsuite/obj-c++.dg/syntax-error-1.mm
trunk/gcc/testsuite/obj-c++.dg/torture/strings/const-cfstring-1.mm
trunk/gcc/testsuite/obj-c++.dg/torture/strings/const-str-10.mm
trunk/gcc/testsuite/obj-c++.dg/torture/strings/const-str-11.mm
trunk/gcc/testsuite/obj-c++.dg/torture/strings/const-str-9.mm
trunk/gcc/testsuite/obj-c++.dg/try-catch-1.mm
trunk/gcc/testsuite/obj-c++.dg/try-catch-3.mm

[Bug objc/90709] [meta-bug] GNU Objective C (C++) cannot consume current headers on Darwin platforms.

2019-06-15 Thread iains at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90709

--- Comment #4 from Iain Sandoe  ---
Author: iains
Date: Sat Jun 15 14:00:24 2019
New Revision: 272326

URL: https://gcc.gnu.org/viewcvs?rev=272326&root=gcc&view=rev
Log:
[objective-c/c++, testsuite, 2/3] Workaround for PR90709.

Use the CF-CFString.h, F-NS*.h proxy headers where needed in the objective-c
testsuite.  Make minor adjustments to tests as required, providing that those
do not alter the test intent.

2019-06-15  Iain Sandoe  

PR objc/90709
* objc.dg/encode-7-next-64bit.m: Use proxy headers.
* objc.dg/image-info.m: Likewise.
* objc.dg/method-6.m: Likewise.
* objc.dg/no-extra-load.m: Likewise.
* objc.dg/objc-foreach-4.m: Likewise.
* objc.dg/objc-foreach-5.m: Likewise.
* objc.dg/proto-lossage-7.m: Likewise.
* objc.dg/strings/const-cfstring-2.m: Likewise.
* objc.dg/strings/const-cfstring-5.m: Likewise.
* objc.dg/strings/const-str-12b.m: Likewise.
* objc.dg/symtab-1.m: Likewise.
* objc.dg/torture/strings/const-cfstring-1.m: Likewise.
* objc.dg/torture/strings/const-str-10.m: Likewise.
* objc.dg/torture/strings/const-str-11.m: Likewise.
* objc.dg/torture/strings/const-str-9.m: Likewise.
* objc.dg/zero-link-1.m: Likewise.
* objc.dg/zero-link-2.m: Likewise.
* objc.dg/zero-link-3.m: Likewise.
* objc.dg/isa-field-1.m: Suppress unwanted warning, add comment why.
* objc.dg/headers.m: XFAIL for Darwin14-19.
* objc.dg/objc-gc-4.m: Skip for Darwin > 16, the API use is an error
there.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/objc.dg/encode-7-next-64bit.m
trunk/gcc/testsuite/objc.dg/headers.m
trunk/gcc/testsuite/objc.dg/image-info.m
trunk/gcc/testsuite/objc.dg/isa-field-1.m
trunk/gcc/testsuite/objc.dg/method-6.m
trunk/gcc/testsuite/objc.dg/no-extra-load.m
trunk/gcc/testsuite/objc.dg/objc-foreach-4.m
trunk/gcc/testsuite/objc.dg/objc-foreach-5.m
trunk/gcc/testsuite/objc.dg/objc-gc-4.m
trunk/gcc/testsuite/objc.dg/proto-lossage-7.m
trunk/gcc/testsuite/objc.dg/strings/const-cfstring-2.m
trunk/gcc/testsuite/objc.dg/strings/const-cfstring-5.m
trunk/gcc/testsuite/objc.dg/strings/const-str-12b.m
trunk/gcc/testsuite/objc.dg/symtab-1.m
trunk/gcc/testsuite/objc.dg/torture/strings/const-cfstring-1.m
trunk/gcc/testsuite/objc.dg/torture/strings/const-str-10.m
trunk/gcc/testsuite/objc.dg/torture/strings/const-str-11.m
trunk/gcc/testsuite/objc.dg/torture/strings/const-str-9.m
trunk/gcc/testsuite/objc.dg/zero-link-1.m
trunk/gcc/testsuite/objc.dg/zero-link-2.m
trunk/gcc/testsuite/objc.dg/zero-link-3.m

[Bug objc/90709] [meta-bug] GNU Objective C (C++) cannot consume current headers on Darwin platforms.

2019-06-15 Thread iains at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90709

--- Comment #3 from Iain Sandoe  ---
Author: iains
Date: Sat Jun 15 13:54:36 2019
New Revision: 272325

URL: https://gcc.gnu.org/viewcvs?rev=272325&root=gcc&view=rev
Log:
[objective-c/c++, testsuite, 1/3] Workaround for PR90709.

Since we cannot parse the current NeXT headers, because of PR90709 and its
dependents, we have a large amount of testsuite noise for Darwin platforms.
In order to restore the usefulness of the testsuite, we are going add headers
without the modern syntax elements that trigger the bug, and use these for
test runs on newer Darwin.

The headers are imported from GNUStep, with some local modifications to make
sure that __BLOCKS__ is honoured as a gate for Apple-style blocks closures.

CF-CFString.h, F-NS*.h are proxy headers that use the installed CoreFoundation
or Foundation headers on systems <= Darwin12 and the GNUStep headers for newer.

2019-06-15  Iain Sandoe  

PR objc/90709
* objc-obj-c++-shared/CF-CFString.h: New.
* objc-obj-c++-shared/F-NSArray.h: New.
* objc-obj-c++-shared/F-NSAutoreleasePool.h: New.
* objc-obj-c++-shared/F-NSObject.h: New.
* objc-obj-c++-shared/F-NSString.h: New.
* objc-obj-c++-shared/F-NSValue.h: New.
* objc-obj-c++-shared/GNUStep/CoreFoundation/CFArray.h: New.
* objc-obj-c++-shared/GNUStep/CoreFoundation/CFAvailability.h: New.
* objc-obj-c++-shared/GNUStep/CoreFoundation/CFBase.h: New.
* objc-obj-c++-shared/GNUStep/CoreFoundation/CFCharacterSet.h: New.
* objc-obj-c++-shared/GNUStep/CoreFoundation/CFData.h: New.
* objc-obj-c++-shared/GNUStep/CoreFoundation/CFDictionary.h: New.
* objc-obj-c++-shared/GNUStep/CoreFoundation/CFLocale.h: New.
* objc-obj-c++-shared/GNUStep/CoreFoundation/CFString.h: New.
* objc-obj-c++-shared/GNUStep/Foundation/NSArray.h: New.
* objc-obj-c++-shared/GNUStep/Foundation/NSAutoreleasePool.h: New.
* objc-obj-c++-shared/GNUStep/Foundation/NSDate.h: New.
* objc-obj-c++-shared/GNUStep/Foundation/NSEnumerator.h: New.
* objc-obj-c++-shared/GNUStep/Foundation/NSGeometry.h: New.
* objc-obj-c++-shared/GNUStep/Foundation/NSObjCRuntime.h: New.
* objc-obj-c++-shared/GNUStep/Foundation/NSObject.h: New.
* objc-obj-c++-shared/GNUStep/Foundation/NSRange.h: New.
* objc-obj-c++-shared/GNUStep/Foundation/NSString.h: New.
* objc-obj-c++-shared/GNUStep/Foundation/NSValue.h: New.
* objc-obj-c++-shared/GNUStep/Foundation/NSZone.h: New.
* objc-obj-c++-shared/GNUStep/GNUstepBase/GNUstep.h: New.
* objc-obj-c++-shared/GNUStep/GNUstepBase/GSBlocks.h: New.
* objc-obj-c++-shared/GNUStep/GNUstepBase/GSConfig.h: New.
* objc-obj-c++-shared/GNUStep/GNUstepBase/GSObjCRuntime.h: New.
* objc-obj-c++-shared/GNUStep/GNUstepBase/GSVersionMacros.h: New.
* objc-obj-c++-shared/GNUStep/GNUstepBase/NSArray+GNUstepBase.h: New.
*
objc-obj-c++-shared/GNUStep/GNUstepBase/NSMutableString+GNUstepBase.h:
New.
* objc-obj-c++-shared/GNUStep/GNUstepBase/NSNumber+GNUstepBase.h: New.
* objc-obj-c++-shared/GNUStep/GNUstepBase/NSObject+GNUstepBase.h: New.
* objc-obj-c++-shared/GNUStep/GNUstepBase/NSString+GNUstepBase.h: New.


Added:
trunk/gcc/testsuite/objc-obj-c++-shared/CF-CFString.h
trunk/gcc/testsuite/objc-obj-c++-shared/F-NSArray.h
trunk/gcc/testsuite/objc-obj-c++-shared/F-NSAutoreleasePool.h
trunk/gcc/testsuite/objc-obj-c++-shared/F-NSObject.h
trunk/gcc/testsuite/objc-obj-c++-shared/F-NSString.h
trunk/gcc/testsuite/objc-obj-c++-shared/F-NSValue.h
trunk/gcc/testsuite/objc-obj-c++-shared/GNUStep/
trunk/gcc/testsuite/objc-obj-c++-shared/GNUStep/CoreFoundation/
trunk/gcc/testsuite/objc-obj-c++-shared/GNUStep/CoreFoundation/CFArray.h
   
trunk/gcc/testsuite/objc-obj-c++-shared/GNUStep/CoreFoundation/CFAvailability.h
trunk/gcc/testsuite/objc-obj-c++-shared/GNUStep/CoreFoundation/CFBase.h
   
trunk/gcc/testsuite/objc-obj-c++-shared/GNUStep/CoreFoundation/CFCharacterSet.h
trunk/gcc/testsuite/objc-obj-c++-shared/GNUStep/CoreFoundation/CFData.h
   
trunk/gcc/testsuite/objc-obj-c++-shared/GNUStep/CoreFoundation/CFDictionary.h
trunk/gcc/testsuite/objc-obj-c++-shared/GNUStep/CoreFoundation/CFLocale.h
trunk/gcc/testsuite/objc-obj-c++-shared/GNUStep/CoreFoundation/CFString.h
trunk/gcc/testsuite/objc-obj-c++-shared/GNUStep/Foundation/
trunk/gcc/testsuite/objc-obj-c++-shared/GNUStep/Foundation/NSArray.h
   
trunk/gcc/testsuite/objc-obj-c++-shared/GNUStep/Foundation/NSAutoreleasePool.h
trunk/gcc/testsuite/objc-obj-c++-shared/GNUStep/Foundation/NSDate.h
trunk/gcc/testsuite/objc-obj-c++-shared/GNUStep/Foundation/NSEnumerator.h
trunk/gcc/testsuite/objc-obj-c++-shared/GNUStep/Foundation/NSGeometry.h
trunk/gcc/testsuite/objc-obj-c++-shared/GNUStep/Foundation/NSObjCRuntime.h
trunk/gcc/t

[Bug c++/63149] wrong auto deduction from braced-init-list

2019-06-15 Thread mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63149

Marek Polacek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #8 from Marek Polacek  ---
Fixed.

[Bug tree-optimization/89713] Optimize away an empty loop whose finiteness can not be analytically determined

2019-06-15 Thread vries at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89713

--- Comment #7 from Tom de Vries  ---
Author: vries
Date: Sat Jun 15 12:01:30 2019
New Revision: 272324

URL: https://gcc.gnu.org/viewcvs?rev=272324&root=gcc&view=rev
Log:
[nvptx, libgomp] Update pr85381-{2,4}.c test-cases

After the fix for "PR tree-optimization/89713 - Assume loop with an exit is
finite" ( r272234 ) empty oacc loops are removed before expand.

Update pr85381-{2,4}.c accordingly.

2019-06-15  Tom de Vries  

PR tree-optimization/89713
* testsuite/libgomp.oacc-c-c++-common/pr85381-2.c: Expect no bar.sync.
* testsuite/libgomp.oacc-c-c++-common/pr85381-4.c: Same.

Modified:
trunk/libgomp/ChangeLog
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/pr85381-2.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/pr85381-4.c

[Bug middle-end/90779] Fortran array initialization in offload regions

2019-06-15 Thread vries at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90779

--- Comment #12 from Tom de Vries  ---
*** Bug 84592 has been marked as a duplicate of this bug. ***

[Bug lto/84592] [openacc,openmp] lto1: ICE in input_varpool_node, at lto-cgraph.c:1424: for function static var

2019-06-15 Thread vries at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84592

Tom de Vries  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #13 from Tom de Vries  ---
Marking duplicate.

*** This bug has been marked as a duplicate of bug 90779 ***

[Bug middle-end/90577] [9/10 Regression] FAIL: gfortran.dg/lrshift_1.f90 with -O(2|3) and -flto

2019-06-15 Thread dominiq at lps dot ens.fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90577

--- Comment #7 from Dominique d'Humieres  ---
> Fixed on trunk for the invalid testcase.  Can someone please check/confirm
> that it solves the LTO issues?

Confirmed. It would be nice to understand why revision r268992 exposed the
problem.

It would be nice to have a runtime diagnostic.

[Bug fortran/68544] ICE trying to pass derived type constructor as a function

2019-06-15 Thread dominiq at lps dot ens.fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68544

--- Comment #13 from Dominique d'Humieres  ---
Note that the test z4.f90 in comment 6 is still accepted.

[Bug middle-end/90779] Fortran array initialization in offload regions

2019-06-15 Thread vries at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90779

--- Comment #11 from Tom de Vries  ---
(In reply to Thomas Schwinge from comment #1)
> Same for OpenACC ('!$acc parallel copyout(v)').
> 
> 
> Thsi sounds similar to PR85063,
>  com> "[PATCH, PR85063] Fix switch conversion in offloading functions".

There is a certain difference.  There, switch conversion introduces a static
var, while there is none in the source.

This is similar to the test-case in PR84592 comment 5 (where there is a static
var in the source).  The patch from comment 10 makes that test-case pass.

[Bug middle-end/84992] [openacc] function static var in parallel

2019-06-15 Thread vries at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84992

--- Comment #2 from Tom de Vries  ---
(In reply to Tom de Vries from comment #0)
> When compiling this openacc testcase:
> 
> #include 
> 
> int
> main (void)
> {
>   int n[1];
>   n[0] = 3;
> #pragma acc parallel copy(n)
>   {
> static const int test[] = {1,2,3,4};
> n[0] = test[n[0]];
>   }
>   printf ("n: %d\n", n[0]);
> 
>   return 0;
> }
> ...
> 
> we run into an ICE:
> ...
> lto1: internal compiler error: in input_varpool_node, at lto-cgraph.c:1424^M
> ...
> 
> We've reported the ICE at PR84592, where we use a slightly more complicated
> example.
> 
> But the first question here is: is this a valid openacc program?
> 
> Given that function static variables are not supported in functions to which
> a routine directive applies, are function static variables supported in
> parallel regions, or not?
> 
> If not, we should emit a proper error message.
> 
> If so, we should implement the required semantics.

Thomas,

can you get this clarified with the OpenACC standard people?

Thanks,
- Tom

[Bug target/88952] The asm operator modifiers for rs6000 should be documented like they are for x86

2019-06-15 Thread segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88952

Segher Boessenkool  changed:

   What|Removed |Added

 CC||segher at gcc dot gnu.org

--- Comment #12 from Segher Boessenkool  ---
How old is your GCC?  I don't have anything older than 4.6 handy, and
that uses even-odd register pairs already (in big-endian mode, and the
other way around in little-endian mode) .  4.2 is over ten years old;
the oldest GCC still supported is GCC 7.

Being able to pass double-integer values to inline asm is a useful
feature.  There are many other much more surprising gotchas when you
make errors or typos in asm stuff.

But yup, we should document the output modifiers that we want people
to use, just like those constraints that we want people to use.  Those
that are for GCC internal use only should not be documented.

[Bug lto/84592] [openacc,openmp] lto1: ICE in input_varpool_node, at lto-cgraph.c:1424: for function static var

2019-06-15 Thread vries at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84592

Tom de Vries  changed:

   What|Removed |Added

 CC||jakub at redhat dot com

--- Comment #12 from Tom de Vries  ---
(In reply to Tom de Vries from comment #11)
> Remaining to be handled here is the example from comment 5. Updating summary
> to reflect that.

That example passes now on trunk, presumably because of r272322 ( PR90779
comment 10).

[Bug tree-optimization/90009] [nvptx] ICE when OpenACC region has num_workers>1

2019-06-15 Thread vries at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90009

Tom de Vries  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from Tom de Vries  ---
Patch with test-case committed, marking resolved-fixed.

[Bug middle-end/90779] Fortran array initialization in offload regions

2019-06-15 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90779

--- Comment #10 from Jakub Jelinek  ---
Author: jakub
Date: Sat Jun 15 07:09:04 2019
New Revision: 272322

URL: https://gcc.gnu.org/viewcvs?rev=272322&root=gcc&view=rev
Log:
PR middle-end/90779
* gimplify.c: Include omp-offload.h and context.h.
(gimplify_bind_expr): Add "omp declare target" attributes
to static block scope variables inside of target region or target
functions.

* c-c++-common/goacc/routine-5.c (func2): Don't expect error for
static block scope variable in #pragma acc routine.

* testsuite/libgomp.c/pr90779.c: New test.
* testsuite/libgomp.fortran/pr90779.f90: New test.

Added:
trunk/libgomp/testsuite/libgomp.c/pr90779.c
trunk/libgomp/testsuite/libgomp.fortran/pr90779.f90
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimplify.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/c-c++-common/goacc/routine-5.c
trunk/libgomp/ChangeLog

[Bug tree-optimization/90009] [nvptx] ICE when OpenACC region has num_workers>1

2019-06-15 Thread vries at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90009

--- Comment #5 from Tom de Vries  ---
Author: vries
Date: Sat Jun 15 07:06:19 2019
New Revision: 272321

URL: https://gcc.gnu.org/viewcvs?rev=272321&root=gcc&view=rev
Log:
[openacc] Disable pass_thread_jumps for IFN_UNIQUE

If we compile the openacc testcase with -fopenacc -O2, we run into a SIGSEGV
or assert.  The root cause for this is that pass_thread_jumps breaks the
invariant that OACC_FORK and OACC_JOIN mark the start and end of a
single-entry-single-exit region.

Fix this by bailing out when encountering an IFN_UNIQUE in
thread_jumps::profitable_jump_thread_path.

Bootstrapped and reg-tested on x86_64.
Build and reg-tested libgomp on x86_64 with nvptx accelerator.

2019-06-15  Tom de Vries  

PR tree-optimization/90009
* tree-ssa-threadbackward.c
(thread_jumps::profitable_jump_thread_path):
Return NULL if bb contains IFN_UNIQUE.

* testsuite/libgomp.oacc-c-c++-common/pr90009.c: New test.

Added:
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/pr90009.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-ssa-threadbackward.c
trunk/libgomp/ChangeLog