[SH][committed] Fix PR 70416

Hi, The attached patch fixes PR 70416. For details, please see the PR audit trail. Tested on sh-elf with make -k check RUNTESTFLAGS="--target_board=sh-sim\{-m2/-ml,-m2/-mb, -m2a/-mb,-m4/-ml,-m4/-mb,-m4a/-ml,-m4a/-mb}" and no new failures. Committed to trunk as r234702. Backport to GCC 5 branch

[Fortran, Patch, pr65795, v1] Segfault (invalid write) for ALLOCATE statement involving COARRAYS

Hi all, attached patch fixes a segfault when allocating a coarray of a type that has allocatable components. Before the patch the compiler tried to ref the component to nullify from the coarray's base address and not from its .data component. The proposed patch fixes this by preventing the nullify

[Fortran, Patch, pr66911, gcc-5, v1] ICE on allocate character with source as a derived type component

Hi all, attached patch fixes the ICE when using a deferred length char array as source= expression in an allocate for complicated source= expressions. Before the patch the compiler was relying on having the string length available in the ts of the expression, but when the expression is sufficientl

[Fortran, Patch, pr67538, v1] ICE with invalid source allocation

Hi all, the attached patch checks that for F2008-style allocate(arr1, source=s) the expression in s is array valued, when arr1 has no array spec and emits an error message saying: Array specification or array-valued SOURCE= expression required in ALLOCATE statement at (1) This fixes the ICE. B

Re: [Fortran, Patch, pr65795, v1] Segfault (invalid write) for ALLOCATE statement involving COARRAYS

On 04/03/2016 06:35 AM, Andre Vehreschild wrote: > Hi all, > > attached patch fixes a segfault when allocating a coarray of a type > that has allocatable components. Before the patch the compiler tried > to ref the component to nullify from the coarray's base address and not > from its .data compo

Re: [Fortran, Patch, pr67538, v1] ICE with invalid source allocation

On 04/03/2016 09:13 AM, Andre Vehreschild wrote: > Hi all, > > the attached patch checks that for F2008-style allocate(arr1, source=s) > the expression in s is array valued, when arr1 has no array spec and > emits an error message saying: > > Array specification or array-valued SOURCE= expression

Re: [Fortran, Patch, pr66911, gcc-5, v1] ICE on allocate character with source as a derived type component

On 04/03/2016 08:33 AM, Andre Vehreschild wrote: > Hi all, > > attached patch fixes the ICE when using a deferred length char array as > source= expression in an allocate for complicated source= expressions. > Before the patch the compiler was relying on having the string length > available in the

Optimize weakrefs

Hi, this patch fixes failure in lto/attr-weakref-1 with plugin disabled setup. The issue is that currently gas rejects .weakref referring to symbol defined in the same translation unit. /tmp/cc0Zk0UZ.s: Assembler messages: /tmp/cc0Zk0UZ.s:121: Error: symbol definition loop encountered at `callmea

Re: [Fortran, Patch, pr65795, v1] Segfault (invalid write) for ALLOCATE statement involving COARRAYS

Andre, Does not the test gfortran.dg/coarray_allocate_6.f08 require a -fdump-tree-original in the dg-options list? Thanks for the patch, Dominique

Re: [Fortran, Patch, pr65795, v1] Segfault (invalid write) for ALLOCATE statement involving COARRAYS

> Le 3 avr. 2016 à 23:38, Andre Vehreschild a écrit : > > Hi Dominique, > > I thought that was implicit, isn't it? I don’t think so and I see in the log files gcc/testsuite/gfortran4/gfortran.sum:UNRESOLVED: gfortran.dg/coarray_allocate_6.f08 -O0 scan-tree-dump-not original "c.caf.x = 0

Re: [Fortran, Patch, pr65795, v1] Segfault (invalid write) for ALLOCATE statement involving COARRAYS

Hi Andre, Thanks for submitting this patch . What can a program do with the object after it has been allocated? Below is a simplified version of the code submitted in pr65795 and the compile-time error that results from attempting accessing the co-indexed component of the allocated object. D

Re: [PATCH] Fix PR c++/70452 (regression in C++ parsing performance)

On Sat, Apr 2, 2016 at 11:57 PM, Trevor Saunders wrote: > On Sat, Apr 02, 2016 at 05:18:31PM -0400, Patrick Palka wrote: >> On Fri, 1 Apr 2016, Jason Merrill wrote: >> >> > I like this approach a lot. One thing, though: >> > >> > On 04/01/2016 03:13 PM, Patrick Palka wrote: >> > > +struct GTY((ch

Re: [Fortran, Patch, pr65795, v1] Segfault (invalid write) for ALLOCATE statement involving COARRAYS

> On Apr 3, 2016, at 3:04 PM, Andre Vehreschild wrote: > > Hi Damian, > > To say it quite bluntly, I don't know. I took care of the ICE only, but I > don't have a deeper understanding of the coarray usage, therefore I can't > answer your question. Hi Andre, No problem. Thanks for the quick

[PATCH] Fix PR70457 (ICE on incompatible call to built-in pow)

Hi, PR70457 shows that we ICE if a call to pow() has only one argument, or more generally doesn't match its expected signature. This can happen both during the widen-mult phase and the tree-inline phase. As suggested by Jakub, this patch uses gimple_call_combined_fn to test for this, similarly t

Re: [patch, fortran] PR68566 ICE on using unusable array in reshape

On 04/02/2016 07:40 AM, Jerry DeLisle wrote: > On 04/02/2016 05:42 AM, Dominique d'Humières wrote: >> >>> Le 2 avr. 2016 à 11:44, Dominique d'Humières a écrit : >>> >>> Hi Jerry, >>> ... I will add an additional test case for the original posted problem in the PR. Two existing

Re: [PATCH] Fix PR70457 (ICE on incompatible call to built-in pow)

On Sun, 2016-04-03 at 18:43 -0500, Bill Schmidt wrote: > Hi, > > PR70457 shows that we ICE if a call to pow() has only one argument, or > more generally doesn't match its expected signature. This can happen > both during the widen-mult phase and the tree-inline phase. As > suggested by Jakub, th

Re: [PATCH] Fix PR70457 (ICE on incompatible call to built-in pow)

On Sun, Apr 03, 2016 at 06:43:47PM -0500, Bill Schmidt wrote: > --- tree-inline.c (revision 234702) > +++ tree-inline.c (working copy) > @@ -57,8 +57,8 @@ along with GCC; see the file COPYING3. If not see > #include "cfgloop.h" > #include "builtins.h" > #include "tree-chkp.h" > +#includ