On Thu, Mar 24, 2011 at 12:15 AM, H.J. Lu wrote:
> On Wed, Mar 23, 2011 at 12:22 PM, Ulrich Weigand wrote:
>> Richard Henderson wrote:
>>> Because, really, if we consider the structure truly public, we can't even
>>> change the number of registers for a given port to support new features of
>>> t
On Sat, 9 Apr 2011, Gerald Pfeifer wrote:
> -NEW
> -A maintainer has verified that this is indeed a bug in GCC. Every
> -once in a while, old reports will need to be rechecked, to find out
> -whether the bug still exists.
I think this text is superior for GCC to that on the generic page and so
w
On Sat, 25 Sep 2010, Manuel López-Ibáñez wrote:
> All the status have well-defined meanings:
>
> http://gcc.gnu.org/bugs/management.html
>
> Unfortunately, there is some duplication:
>
> http://gcc.gnu.org/bugzilla/page.cgi?id=fields.html
Quite some duplication, in fact. By virtue of the patch
SPEC06 build with FDO is ok with the patch -- no abnormality was found.
David
On Fri, Apr 8, 2011 at 2:42 PM, Xinliang David Li wrote:
> Please review this patch. Regression test is ok. I will do more
> application testing to make sure the check is not too strict
> (filtering out legal ic target
On 09/04/11 17:45, Richard Guenther wrote:
On Sat, Apr 9, 2011 at 1:22 PM, Duncan Sands wrote:
I recently changed the dragonegg plugin to use array_type_nelts, and just
got
sent a Fortran testcase that shows that array_type_nelts can crash on array
types coming from Fortran. The array type in
On Sat, Apr 9, 2011 at 1:22 PM, Duncan Sands wrote:
> I recently changed the dragonegg plugin to use array_type_nelts, and just
> got
> sent a Fortran testcase that shows that array_type_nelts can crash on array
> types coming from Fortran. The array type in question has TYPE_DOMAIN set,
> with T
On Sat, Apr 9, 2011 at 12:08 AM, Xinliang David Li wrote:
> Hi, this patch fixes the test failure. OK after bootstrap and regression test?
Ok.
Thanks,
Richard.
> Thanks,
>
> David
>
>
> 2011-04-08 Xinliang David Li
>
> PR tree-optimization/PR48484
> * tree-ssa-uninit.c (convert
On Sat, 9 Apr 2011, Ralf Wildenhues wrote:
>> 4) Will there be someone like a mentor who I could ask such
>>questions or get useful hints?
> I'm not aware of a special mentor program for new contributors
I would say, however, that the one approving the request for a
gcc.gnu.org account should
I've been unable to get to this for months, if not years, not even from
gcc.gnu.org itself (so it cannot be a reasonable IP block restriction or
something).
Gerald
Index: mirrors.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/mirrors.h
n Thu, Apr 7, 2011 at 2:32 PM, Jason Merrill wrote:
> People have been finding other places where we haven't been handling SFINAE
> properly. In many cases, there are two patches for each fix; the first one
> fixes the bug conservatively (for possible application to 4.6), and the
> second one reo
2011/4/8 Richard Henderson :
>> + /* Special case regparm/sseregparm, which are either cdecl or stdcall. */
>> + if ((ret & (IX86_CALLCVT_REGPARM | IX86_CALLCVT_SSEREGPARM)) != 0)
>> + return (ret | ((TARGET_RTD && !stdarg_p (type)) ? IX86_CALLCVT_STDCALL
>> +
Dear Dominique and Michael,
I find that both nf.f90 and capacita.f90 segfault in runtime for any stack size.
Cheers
Paul
On Sat, Apr 9, 2011 at 12:08 PM, Dominique Dhumieres wrote:
> Michael,
>
> I have applied your patch on top of revision 172217 on
> x86_64-apple-darwin10.7.0.
> So far I ha
As explained in http://gcc.gnu.org/ml/gcc/2011-04/msg00167.html, this patch
extends the TYPE_DECL_IS_STUB trick in dwarf2out.c to all types.
Tested on x86_64-suse-linux (GCC + GDB), OK for the mainline?
2011-04-09 Eric Botcazou
* dwarf2out.c (TYPE_DECL_IS_STUB): Extend mechanism to
I recently changed the dragonegg plugin to use array_type_nelts, and just got
sent a Fortran testcase that shows that array_type_nelts can crash on array
types coming from Fortran. The array type in question has TYPE_DOMAIN set,
with TYPE_MIN_VALUE equal to 1 (because the array is indexed from 1)
On Fri, Apr 8, 2011 at 4:36 PM, Jeff Law wrote:
>>> Perhaps a third, per-translation-unit obstack is necessary?
>>
>> Perhaps. After I finish with permanent rtl obstack, I will measure how
>> large it gets and if it's worthwhile to split out
>> per-translation-obstack out of it.
> And then you'll
Michael,
I have applied your patch on top of revision 172217 on
x86_64-apple-darwin10.7.0.
So far I have only limited tests on the polyhedron test suite.
The test nf.f90 (containing an automatic array) executes in less than 20s,
compares
to ~28s without the patch. However capacita.f90 is miscomp
On Apr 9 2011, Magnus Fromreide wrote:
There is actually a much better approach, which was done in Algol 68
and seems now to be done only in Ada. As far as the compiler
implementation goes, it is a trivial variation on what you have done,
but there is a little more work in the run-time system.
> There is actually a much better approach, which was done in Algol 68
> and seems now to be done only in Ada. As far as the compiler
> implementation goes, it is a trivial variation on what you have done,
> but there is a little more work in the run-time system.
Obviously this depends on the com
On Sat, 2011-04-09 at 09:21 +0100, N.M. Maclaren wrote:
> On Apr 8 2011, Michael Matz wrote:
> >
> >It adds a new option -fstack-arrays which makes the frontend put
> >all local arrays on stack memory. ...
>
> Excellent!
>
> >I haven't rechecked performance now, but four months ago this was the
On Apr 8 2011, Michael Matz wrote:
It adds a new option -fstack-arrays which makes the frontend put
all local arrays on stack memory. ...
Excellent!
I haven't rechecked performance now, but four months ago this was the
result for the fortran benchmarks in cpu2006:
There is actually a muc
* Georg-Johann Lay wrote on Fri, Apr 08, 2011 at 11:30:29AM CEST:
> Gerald Pfeifer schrieb:
> > Nope. All you need is a maintainer (Eric, Denis and Anatoly all
> > qualifying) to sponsor your request. Obviously that mostly makes
> > sense if you expect to contribute more than a handfull of patche
21 matches
Mail list logo
