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
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
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
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
> 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
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
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
> 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
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
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
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
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
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
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
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
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
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
17 matches
Mail list logo
