"Bingfeng Mei" wrote on 05/02/2009 12:45:20:
> Ayal,
> OOPs, your mail skipped my inbox and I missed it for several days.
>
I'm chasing after my mail as well..
> Using testsuite/gcc.dg/sms-6.c as an example and compiling it for
PowerPC,
> node 18 (see attachment) is in a SCC and cannot be sched
Jeff Law wrote:
What purpose does changed_allocation_pseudos serve? AFAICT we
set/clear the bitmap, but never use it for anything. It was added as
part of the IRA integration. Did you have some purpose in mind for
this bitmap? If not can we just remove it?
As I remember, it was used in an
Jeff Law wrote:
Ian Lance Taylor wrote:
Jeff Law writes:
Ian Lance Taylor wrote:
I see no reason for those to stay in reload (especially since I think
reload should disappear entirely). It is reasonable to pick the total
maximum size of the stack frame, and thus resolve all displaceme
Jeff Law wrote:
Vladimir Makarov wrote:
Jeff Law wrote:
I've been thinking further about instruction alternative selection
prior to allocation and one of the questions in my mind is how this
interacts with IRA.
We select an alternative for each insn based on some "best guess"
heuristic -- t
Ian Lance Taylor wrote:
> No, that makes no sense. What I'm suggesting is that we fix the stack
> offsets of all local variables before register allocation, based on a
> conservative assessment of how many registers will be saved on the
> stack.
The conservative assessment is that all pseudos go
Ian Lance Taylor wrote:
Jeff Law writes:
I would agree that careful relaxation of displacements is no longer as
important as it once was, I don't think we can just hand wave away
the displacement issues
1. The stack frames don't have to be that big to bump up against
these problems.
2.
Vladimir Makarov wrote:
IMHO, another important optimization what reload does for such
processors is usage of already calculated displacement whose value is
in hard register to calculate an new displacement (that was
implemented by Joern for SH).
ISTM this optimization could be done with a pr
Is it intended that the GCC C compiler support nested functions?
I would like to know so that I can determine whether to file bug reports
against other projects for nested function use.
Begin Nested Function example
void foo(void) {
void bar(void) {
puts("Bar");
}
> Is it intended that the GCC C compiler support nested functions?
Yes, it's an extension provided by GNU C, not part of ISO C.
Arno
On Tue, Feb 17, 2009 at 9:55 AM, Arnaud Charlet wrote:
>> Is it intended that the GCC C compiler support nested functions?
>
> Yes, it's an extension provided by GNU C, not part of ISO C.
>
Although nested functions should be avoided for portability,
but sometimes nested functions are very useful
However, a proportion of code written for Visual C++
makes use of
propriatery runtimes such as MFC, the runtime EULA of which 'currently'
prevents the use of MFC
based applications with a 'free' OS like ReactOS or GNU based toolchains...
And even if it were permitted, it wou
H.J. Lu wrote:
On Tue, Feb 17, 2009 at 9:55 AM, Arnaud Charlet wrote:
Is it intended that the GCC C compiler support nested functions?
Yes, it's an extension provided by GNU C, not part of ISO C.
Although nested functions should be avoided for portability,
but sometimes nested functions are
On Tue, Feb 17, 2009 at 5:51 PM, Bernd Schmidt wrote:
> The conservative assessment is that all pseudos go on the stack.
> However, this way you'll generate terrible code.
Yes. So make a not-too-optimistic estimate. And if it turns out your
estimate is too small, then you roll back, update the es
Jeff Law writes:
>> No, that makes no sense. What I'm suggesting is that we fix the stack
>> offsets of all local variables before register allocation, based on a
>> conservative assessment of how many registers will be saved on the
>> stack. Then we know during register allocation whether the
Bernd Schmidt writes:
> Ian Lance Taylor wrote:
>
>> No, that makes no sense. What I'm suggesting is that we fix the stack
>> offsets of all local variables before register allocation, based on a
>> conservative assessment of how many registers will be saved on the
>> stack.
>
> The conservative
On Mon, 2009-02-16 at 10:09 -0800, Janis Johnson wrote:
> On Fri, 2009-02-13 at 12:28 -0800, Joe Buck wrote:
> > On Fri, Feb 13, 2009 at 11:03:51AM -0800, Anthony Newnam wrote:
> > > Thanks Joe.
> > >
> > > As far as I know the problem I'm seeing isn't a regression but perhaps
> > > this script co
Hi Robert,
Since there's only one ACATS FAIL on mipsel-linux I investigated it
and it looks like a-teioed.adb code is wrong in some case:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39221
<<
,.,. CXF3A01 ACATS 2.5 09-02-17 22:07:04
CXF3A01 Check that the Valid function from package
Laurent GUERBY wrote:
Two obvious solutions: use Unsupress locally since there's already a others
handler or add explicit length checks.
analysis looks right, an explicit length check is more appropriate,
better to avoid the exception.
To reach quickly the interesting point under gdb:
break
On Tue, 2009-02-17 at 16:05 -0500, Robert Dewar wrote:
> Laurent GUERBY wrote:
>
> > Two obvious solutions: use Unsupress locally since there's already a others
> > handler or add explicit length checks.
>
> analysis looks right, an explicit length check is more appropriate,
> better to avoid the
Laurent GUERBY wrote:
On Tue, 2009-02-17 at 16:05 -0500, Robert Dewar wrote:
Laurent GUERBY wrote:
Two obvious solutions: use Unsupress locally since there's already a others
handler or add explicit length checks.
analysis looks right, an explicit length check is more appropriate,
better to a
Hi Grigori and Zbigniew,
I just took a look at the wiki page you guys put together. While I
have some reservations about categorizing the plugin APIs into
"production", "research", and "new pass", I totally agreed with you
that the plugin support should be implemented in layers, starting from
the
Grigori Fursin wrote:
Dear all,
Zbigniew and I prepared a page on GCC Wiki comparing several current plugin
mechanisms (some parts should be updated) with some suggestions to move forward:
http://gcc.gnu.org/wiki/GCC_PluginComparison
In case we mixed up or misunderstood something about other plu
Hi Le-chun and Taras,
You are right that instead of categorizing the plugin API
into "production", "research", etc, we can just introduce
several layers of abstraction that will be useful for different
purposes such as quick prototyping or tightly coupled plugins, etc.
We will update the Wiki to r
> Is the following okay to commit if it passes testing?
OK for stage 1 (GCC 4.5), currently pretty much everything is frozen on
mainline, except regressions (I hope stage 1 will open soon, since we have
monthes of backlog of various fixes and new development blocked right now
which will be painful
> OK for stage 1 (GCC 4.5), currently pretty much everything is frozen on
> mainline, except regressions (I hope stage 1 will open soon, since we have
> monthes of backlog of various fixes and new development blocked right now
> which will be painful to merge).
If the ACATS test fails on ia64-linu
> > OK for stage 1 (GCC 4.5), currently pretty much everything is frozen on
> > mainline, except regressions (I hope stage 1 will open soon, since we have
> > monthes of backlog of various fixes and new development blocked right now
> > which will be painful to merge).
>
> If the ACATS test fails
26 matches
Mail list logo
