The GNU Compiler Collection version 4.7.4 has been released.
GCC 4.7.4 is the last bug-fix release from the GCC 4.7 branch
containing important fixes for regressions and serious bugs in
GCC 4.7.3 with more than 134 bugs fixed since the previous release.
This release is available from the FTP serv
On Thu, Jun 12, 2014 at 7:59 PM, Zdenek Dvorak wrote:
> Hi,
>
>> > I noticed there is below code/comments about may_be_zero field in loop
>> > niter desc:
>> >
>> > tree may_be_zero;/* The boolean expression. If it evaluates to true,
>> >the loop will exit in the first itera
On Fri, Jun 13, 2014 at 9:43 AM, Bin.Cheng wrote:
> On Thu, Jun 12, 2014 at 7:59 PM, Zdenek Dvorak
> wrote:
>> Hi,
>>
>>> > I noticed there is below code/comments about may_be_zero field in loop
>>> > niter desc:
>>> >
>>> > tree may_be_zero;/* The boolean expression. If it evaluates to
I just realised that all our source files still say -2013 on the
4.8 branch, because the branch was created last year and the script to
update all the files in January only gets run on trunk.
Is that a problem, or is it OK for files on the branches to only have
copyright dates up to the point
Hi!
Hacking on Fortran target support now, I ran into an issue with
Fortran array pointers or other types using array descriptors.
The problem is that right now for OpenMP (I think OpenACC has it different)
we have only the OpenMP mandates kinds (alloc, to, from, tofrom),
which have address, size,
On 06/13/14 03:57, Jonathan Wakely wrote:
I just realised that all our source files still say -2013 on the
4.8 branch, because the branch was created last year and the script to
update all the files in January only gets run on trunk.
Is that a problem, or is it OK for files on the branches t
> If a release is made, then the copyright dates ought to be updated in
> files that have changed, at least that's always been my understanding.
Yes, but that update should have been done *when the file was changed*.
Or am I missing something here? Because anybody can take any of the
files at an
This email is probably a bit premature as the OpenMPv4.0 and OpenACC
2.0a specs do not seem to handle Fortran 2003's polymorphic variables.
However, as I am currently thinking how to handle a similar problem for
Fortran's coarray, I want to raise the issue for OpenMP/OpenACC to see
whether some
Hi
I am trying to build a native GNAT from the head on Fedora 20. It has
makeinfo 5.1 which is causing gnat_rm.texi a lot of problems. This
is just the beginning of almost 200 error messages.
../../gcc/gcc/ada/gnat_rm.texi:4107: warning: @itemize has text but no @item
../../gcc/gcc/ada/gnat_rm.te
pr61505
Dominique
On Thu, Jun 12, 2014 at 4:26 PM, Richard Biener
wrote:
> On Wed, Jun 11, 2014 at 4:09 PM, Prathamesh Kulkarni
> wrote:
>> On 6/11/14, Richard Biener wrote:
>>> On Wed, Jun 11, 2014 at 12:53 PM, Richard Biener
>>> wrote:
On Wed, Jun 11, 2014 at 10:51 AM, Richard Biener
wrote:
> On
On June 13, 2014 11:48:13 PM CEST, Prathamesh Kulkarni
wrote:
>On Thu, Jun 12, 2014 at 4:26 PM, Richard Biener
> wrote:
>> On Wed, Jun 11, 2014 at 4:09 PM, Prathamesh Kulkarni
>> wrote:
>>> On 6/11/14, Richard Biener wrote:
On Wed, Jun 11, 2014 at 12:53 PM, Richard Biener
wrote:
> cc'ing Eric B since I remember him mentioning that they autogenerated
> texinfo from Sphinx and I am wondering if this is manual or autogenerated.
No, that was me, mentioning that we were planning to do that in the future,
but not yet.
> Other than fixing the manual or downgrading makeinfo, any
13 matches
Mail list logo
