> On 15 Jan 2016, at 05:10, Patrick Palka wrote:
>
> On Thu, 14 Jan 2016, Ryan Burn wrote:
>
>> Also caused https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69091
>
> Thanks for the heads up, I was not aware I had caused this regression.
While looking at last few failures with GCC 6.0.0 in our so
I have committed the following patch for PR70573 (preapproved by Jakub Jelinek
in bugzilla)
Dominique
Index: gcc/testsuite/ChangeLog
===
--- gcc/testsuite/ChangeLog (revision 234847)
+++ gcc/testsuite/ChangeLog (working copy
>>> On Wed, Apr 06, 2016 at 05:44:55PM +0200, Dominique d'Humières wrote:
Is the following patch OK (regtested on x86_64-apple-darwin15)? Should it
be back ported to the gcc-5 branch?
>>>
>>> No and No.
> Le 7 avr. 2016 à 15:59, Steve Kargl a
> écrit :
>
> The latter is obvious as th
On April 8, 2016 10:00:58 PM GMT+02:00, Jakub Jelinek wrote:
>On Fri, Apr 08, 2016 at 09:14:33PM +0200, Richard Biener wrote:
>> Hmm, I think this means GIMPLE_has_side_effects is to be fixed then.
>
>> Note that honza had plans to compute things like 'uses FP' and
>'contains arith with undefined
On April 9, 2016 1:17:51 PM GMT+02:00, Richard Biener wrote:
>On April 8, 2016 10:00:58 PM GMT+02:00, Jakub Jelinek
> wrote:
>>On Fri, Apr 08, 2016 at 09:14:33PM +0200, Richard Biener wrote:
>>> Hmm, I think this means GIMPLE_has_side_effects is to be fixed then.
>>
>>> Note that honza had plans t
On April 9, 2016 6:07:19 AM GMT+02:00, Sebastian Pop wrote:
>On Fri, Apr 8, 2016 at 2:03 AM, Tom de Vries
>wrote:
>> pdr_0 (read
>> in gimple stmt: _9 = yu[_8][0];
>> data accesses: { S_4[i1, i2] -> [1, 0, 1 + i1] }
>
>data access should be { S_4[i1, i2] -> [1, 1 + i1, 0] }
>
>> subscript sizes:
On Sat, Apr 09, 2016 at 01:21:06PM +0200, Richard Biener wrote:
> To followup myself here - we can also make sure the function doesn't become
> pure/const.
>
> Similar issues exist with pure/const functions with ops with undefined
> overflow (and code gen taking advantage of that).
> So it's not
On April 9, 2016 1:29:51 PM GMT+02:00, Jakub Jelinek wrote:
>On Sat, Apr 09, 2016 at 01:21:06PM +0200, Richard Biener wrote:
>> To followup myself here - we can also make sure the function doesn't
>become pure/const.
>>
>> Similar issues exist with pure/const functions with ops with
>undefined ov
On Fri, 8 Apr 2016, Jake Hamby wrote:
> Thanks for the info! I've discovered a few additional clues which should
> help, namely the optimizer pass that's introducing the problem. Through
> process of elimination, I discovered that adding "-fno-tree-ter" will
> prevent the unrecognizable insn er
On 04/08/2016 08:54 PM, Martin Sebor wrote:
>> The name for new option "-Wduplicate-decl-specifier" and wording was
>> chosen to match the same option in Clang.
>
> My version of Clang also warns in C++ mode but if I'm reading
> the patch right, GCC would warn only C mode. I would find it
> surpr
As asked by Paul Richard Thomas on IRC I have committed the following patch to
trunk. I’ll commit it to the gcc-5 branch tomorrow.
Dominique
Index: gcc/testsuite/ChangeLog
===
--- gcc/testsuite/ChangeLog (revision 234849)
+++ gc
On Sat, Apr 09, 2016 at 12:28:12PM +0200, Dominique d'Humières wrote:
> >>> On Wed, Apr 06, 2016 at 05:44:55PM +0200, Dominique d'Humières wrote:
> Is the following patch OK (regtested on x86_64-apple-darwin15)? Should
> it be back ported to the gcc-5 branch?
> >>>
> >>> No and No.
> >
> (/ /) is valid Fortran 95 syntax
> ...
>
> program foo
> call bar((/ /))
> end program foo
>
> % gfc -c -std=f95 foo.f90
> foo.f90:2:17:
>
>call bar((/ /))
> 1
> Error: Empty array constructor at (1) is not allowed
>
> The above error is correct.
Well the two asserti
On 09/12/15 19:26, Sebastian Pop wrote:
we used to add the access functions in the wrong order, Fortran style, leading
to unprofitable interchanges.
---
gcc/graphite-sese-to-poly.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/graphite-sese-to-poly.c b/gcc/graphite-s
On Sat, Apr 09, 2016 at 05:56:12PM +0200, Dominique d'Humières wrote:
>
> > (/ /) is valid Fortran 95 syntax
> > ...
> >
> > program foo
> > call bar((/ /))
> > end program foo
> >
> > % gfc -c -std=f95 foo.f90
> > foo.f90:2:17:
> >
> >call bar((/ /))
> > 1
> > Error: Empt
>
> It is valid syntax because of
>
> "An empty sequence forms a zero-sized rank-one array."
>
> It seems that J3 saw the error in their ways as (/ /) is clearly
> an empty array constructor, and fixed the possibility of creating
> a typeless zero-sized, rank-one array.
This is exactly the po
On Sat, Apr 09, 2016 at 06:51:50PM +0200, Dominique d'Humières wrote:
>
> >
> > It is valid syntax because of
> >
> > "An empty sequence forms a zero-sized rank-one array."
> >
> > It seems that J3 saw the error in their ways as (/ /) is clearly
> > an empty array constructor, and fixed the po
Patch withdrawn, PR47040 closed as INVALID.
Dominique
Attached are a set of testsuite updates for hppa. The pr64434.c.d.txt,
ivopts-lt-2.c.d.txt and uninit-19.c.d.txt changes
were applied to both gcc-5 and trunk. The rest were applied to the trunk.
Tested on hppa2.0w-hp-hpux11.11 and hppa64-hp-hpux11.11.
Sorry, for batch update. Mail wasn't work
It turns out the stricter server settings also broke the /java
page on gcc.gnu.org.
This restores showing two columns on this page (though it still
uses non-standard CSS extensions).
That said, looking at the page, and how since 2005 nearly all changes
have been maintainance ones from me, is it
And here is the version for GCC 4.6.
Applied.
Gerald
Index: gcc-4.6/cxx0x_status.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.6/cxx0x_status.html,v
retrieving revision 1.11
diff -u -r1.11 cxx0x_status.html
--- gcc-4.6/cxx0x_stat
21 matches
Mail list logo
