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
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
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
Patch withdrawn, PR47040 closed as INVALID.
Dominique
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
>
> 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 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
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
> (/ /) 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 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.
> >
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 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
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 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 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 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 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 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 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
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 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
21 matches
Mail list logo
