Hi!
If a non-static variable declared inside of #pragma {omp,} simd
body is addressable and we would still like to be able to vectorize
it, we must treat it like if it were private variable, i.e. create
omp simd array for it, otherwise all iterations might get address of
the same variable, rather
On Thu, Feb 06, 2014 at 10:04:00AM +0100, Richard Biener wrote:
> > PS, just looking at the patch now again, in the light of PR59594
> > the reordering of datarefs before goto again looks also wrong, we IMHO have
> > to perform a vector ordered remove in that case, ok to handle it as a
> > follow-u
Jeff Law writes:
> On 02/06/14 13:39, Benno Schulenberg wrote:
>>
>> [Oops, had a wrong bug number in the subject line.]
>>
>> Below patch fixes another miswording in an error message,
>> reported by Roland Stigge. Please apply.
>>
>>
>> 2014-02-06 Benno Schulenberg
>>
>> PR translation/
> Looks like I have to build a cross to a sjlj EH target ...
Let's clear a common misconception here: the SJLJ EH scheme implemented in C++
doesn't explicitly use __builtin_setjmp/__buitin_longjmp so it won't help to
understand how things work for the case at hand; it's instead a hybrid scheme,
> This is then combined into:
>
> newpat = (parallel [
> (set (pc)
> (pc))
> (set (reg/v/f:SI 34 [ stack ])
> (reg/f:SI 15 %sp))
> ])
>
> This isn't a recognized insn, and it needs to be split. Since it's just
> a parallel of independent sets, com
Hi Mikael,
thanks for your suggestions and the approval of the patch.
>> maybe add gcc_assert to
>> make it clear that fini->proc_tree should be set at this point.
> Or better: a comment ;-)
I'm going for the gcc_assert *plus* a comment ;)
The thusly updated patch in the attachment regtests cle
On Fri, Feb 7, 2014 at 6:15 PM, Xinliang David Li wrote:
> On Fri, Feb 7, 2014 at 1:22 AM, Richard Biener
> wrote:
>> On Thu, Feb 6, 2014 at 10:30 PM, Xinliang David Li
>> wrote:
>>> Hi the following patch removes the 'state' print for
>>> -ftree-tree-vectorize option which does not make sense
On Sat, Feb 8, 2014 at 1:37 AM, Richard Henderson wrote:
> On 02/07/2014 03:12 PM, Richard Biener wrote:
>> On February 7, 2014 8:35:16 PM GMT+01:00, Richard Henderson
>> wrote:
>>> In the testcases with the PR, we have a bit of type punning going on,
>>>
>>> *(int *) &s2.f = 0;
>>> s2 = s1;
>
On Sat, Feb 8, 2014 at 8:29 AM, dxq wrote:
> hi all,
>
> We found that gcc would run out of memory on Windows when compiling a *big*
> function (10 lines).
>
> More investigation shows that gcc crashes at the function *compute_avail*,
> in tree-fre pass. *compute_avail* collects information f
On Sat, Feb 8, 2014 at 10:25 AM, Jakub Jelinek wrote:
> On Thu, Feb 06, 2014 at 10:04:00AM +0100, Richard Biener wrote:
>> > PS, just looking at the patch now again, in the light of PR59594
>> > the reordering of datarefs before goto again looks also wrong, we IMHO have
>> > to perform a vector or
Dear All,
I am aware that we are in stage 4 but this wrong-code-on-valid PR is
confined to a corner of a corner and so I am certain that it can be
safely applied - OK, Richie?
This patch follows the same route as has been used for pointer array
assignment to components of derived type arrays by r
Hello,
using the -mcall-linux option on powerpc64le-linux (which should be a no-op)
currently causes the compiler driver to pass -mbig to the linker. Likewise,
using -mcall-aixdesc (which is allowed when also using -mabi=elfv1, like
certain versions of the Linux kernel do), causes the compiler dr
On 11/25/13 23:53, David Holsgrove wrote:
Add optimized lshrsi3 instruction, to be used when optimizing for size
with immediate values over 5
Changelog
2013-11-26 Nagaraju Mekala
* gcc/config/microblaze/microblaze.md: Add size optimized lshrsi3 insn.
David --
Please put the description
Hi,
On Fri, Feb 07, 2014 at 04:37:22PM -0800, Richard Henderson wrote:
> On 02/07/2014 03:12 PM, Richard Biener wrote:
> > On February 7, 2014 8:35:16 PM GMT+01:00, Richard Henderson
> > wrote:
> >> In the testcases with the PR, we have a bit of type punning going on,
> >>
> >> *(int *) &s2.f =
Dear All,
This is another corner of a corner case that is not a regression but
fixes a wrong-code-on-valid.
At present, an actual argument of an elemental procedure with the
VALUE attribute is not passed by value. The fix is obvious.
Bootstraps and regtests on FC17/x86_64 - OK for trunk, 4.8 an
Le 08/02/2014 18:48, Paul Richard Thomas a écrit :
> Dear All,
>
> This is another corner of a corner case that is not a regression but
> fixes a wrong-code-on-valid.
>
> At present, an actual argument of an elemental procedure with the
> VALUE attribute is not passed by value. The fix is obviou
Is the following patch OK?
Dominique
2014-02-08 Dominique d'Humieres
PR fortran/34928
* fortran/gfortran.texi: Document Volatile COMMON as not
suppoerted.
--- ../_clean/gcc/fortran/gfortran.texi 2014-01-04 15:51:42.0 +0100
+++ gcc/fortran/gfortran.texi 2014-
On Sat, Feb 08, 2014 at 10:07:23PM +0100, Dominique Dhumieres wrote:
> Is the following patch OK?
>
> Dominique
>
> 2014-02-08 Dominique d'Humieres
>
> PR fortran/34928
> * fortran/gfortran.texi: Document Volatile COMMON as not
> suppoerted.
s/suppoerted/supported
> --- ..
On Sat, Feb 8, 2014 at 11:44 AM, Ulrich Weigand wrote:
> Hello,
>
> using the -mcall-linux option on powerpc64le-linux (which should be a no-op)
> currently causes the compiler driver to pass -mbig to the linker. Likewise,
> using -mcall-aixdesc (which is allowed when also using -mabi=elfv1, like
> I can't remember. Do you have commit privilege?
No.
> If not, why?
Probably because I did not asked for it explicitly.
I have only hinted a couple time that I have the FSF papers
signed.
I'll do the changes.
Thanks for the quick review,
Dominique
On Sat, Feb 08, 2014 at 10:28:24PM +0100, Dominique Dhumieres wrote:
> > I can't remember. Do you have commit privilege?
>
> No.
>
> > If not, why?
>
> Probably because I did not asked for it explicitly.
> I have only hinted a couple time that I have the FSF papers
> signed.
>
I suppose we ca
2014-02-08 22:47 GMT+01:00 Steve Kargl :
> On Sat, Feb 08, 2014 at 10:28:24PM +0100, Dominique Dhumieres wrote:
>> > I can't remember. Do you have commit privilege?
>>
>> No.
>>
>> > If not, why?
>>
>> Probably because I did not asked for it explicitly.
>> I have only hinted a couple time that I h
All,
Here is a potentially contentious patch for PR fortran/52879.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52879
As demonstrated in that PR, it is possible to provide RANDOM_SEED
with sets of seeds that result in a very poor sequences of PRN.
Gfortran's RANDOM_NUMBER uses 3 independent KISS
23 matches
Mail list logo
