Ian Lance Taylor wrote :
Kai Ruottu <[EMAIL PROTECTED]> writes:
Ok, the traditional "evolutionary" method is to not reinvent the wheel
with the already tested target components but let then be as they are
and produce only the stuff required for the new $host, the GNU
binutils and the GCC s
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sat, Feb 10, 2007 at 03:09:41PM +0200, Robert Dewar wrote:
> Ian Lance Taylor wrote:
> > "Jie Zhang" <[EMAIL PROTECTED]> writes:
> >> But now gcc seems to optimize it away. For the following function:
> >>
> >> $ cat t.c
> >> #include
> >> void foo
On Sun, Feb 11, 2007 at 09:51:33PM -0800, Paul Eggert wrote:
> > Given that there is still discussion and work on GCC for this topic
> > anyway[1], I don't think Autoconf should be doing anything just yet.
Yeah, it is just too early.
> Both of the solutions that Bruno suggested seem too drastic t
Mark Mitchell writes:
> Kaveh R. GHAZI wrote:
>
> [Java folks: see below for check-in window for daylight savings time
> patches.]
>
> Therefore, if the Java folks have daylight savings time patches that
> they would like to check in, please do so before Monday evening,
> California time.
Kai Ruottu <[EMAIL PROTECTED]> writes:
> For which existing targets the prebuilt C libraries are missing? Or
> which are the
> targets which don't have any "suitable", "compatible" or something C library
> which could serve as that temporary bootstrap "target C library"
> during the GCC
> build?
On Sun, Feb 11, 2007 at 01:04:05PM -0800, H. J. Lu wrote:
> On Sun, Feb 11, 2007 at 01:00:41PM -0800, H. J. Lu wrote:
> > "make bootstrap" used to compare stage2 and stage3 after gcc was
> > bootstrapped. "make bootstrap" would abort if comparison was failed.
> > Now, compare stage2 and stage3 is n
On Mon, Feb 12, 2007 at 09:53:00AM -0800, Joe Buck wrote:
> On Sun, Feb 11, 2007 at 01:04:05PM -0800, H. J. Lu wrote:
> > On Sun, Feb 11, 2007 at 01:00:41PM -0800, H. J. Lu wrote:
> > > "make bootstrap" used to compare stage2 and stage3 after gcc was
> > > bootstrapped. "make bootstrap" would abort
Ian, Richard, Diego --
I've explicitly forwarded this to you, as folks who have done work on
middle-end optimization and have seen lots of real-world code.
(That's not to say that I'm not looking for comments from anyone and
everyone -- but I'm specifically trying to get at least some feedback,
s
Hi,
I am reading the code of autovect branch and curious about how to deal
with the dependencies of virtual defs/uses. In the function
vect_analyze_scalar_cycles( ), I found the statement "Skip virtual
phi's. The data dependences that are associated with virtual defs/uses
( i.e., memory accesses)
On 2/12/07, Jiahua He <[EMAIL PROTECTED]> wrote:
Hi,
I am reading the code of autovect branch and curious about how to deal
with the dependencies of virtual defs/uses. In the function
vect_analyze_scalar_cycles( ), I found the statement "Skip virtual
phi's. The data dependences that are associat
Thanks! In fact, I should ask how to deal with idiom (such as
reduction, induction) recognition for virtual defs/uses.
Jiahua
2007/2/12, Daniel Berlin <[EMAIL PROTECTED]>:
On 2/12/07, Jiahua He <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I am reading the code of autovect branch and curious about how
> On 2/12/07, Jiahua He <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > I am reading the code of autovect branch and curious about how to deal
> > with the dependencies of virtual defs/uses. In the function
> > vect_analyze_scalar_cycles( ), I found the statement "Skip virtual
> > phi's. The data depend
> Thanks! In fact, I should ask how to deal with idiom (such as
> reduction, induction) recognition for virtual defs/uses.
>
Just curious - what is this for? (are you interested in this in the context
of vectorization? is there a specific example you have in mind?)
dorit
> Jiahua
>
>
> 2007/2/12
On Sunday I had accidentally chat about the df infrastructure on
IIRC. I've got some thoughts which I'd like to share.
I like df infrastructure code from the day one for its clearness.
Unfortunately users don't see it and probably don't care about it.
With my point of view the df infrastructur
On Mon, Feb 12, 2007 at 10:06:11AM -0800, Mark Mitchell wrote:
> Does it seem overly aggressive to you to assume "f" cannot throw
> in "g", given:
>
> void f() {}
> void g() { f(); }
>
> where this code is in a shared library?
Yes.
If F is part of the exported (and overridable) interface of
On 2/12/07, Vladimir Makarov <[EMAIL PROTECTED]> wrote:
I like df infrastructure code from the day one for its clearness.
Unfortunately users don't see it and probably don't care about it.
With my point of view the df infrastructure has a design flaw. It
extracts a lot of information about RT
Oh, I see. For reduction and induction, you don't need to deal with
the condition with vdef. I am considering how to implement an idiom
with vdef, like SCAN (prefix sum). And by the way, do you support
idioms with vuses?
Jiahua
2007/2/12, Dorit Nuzman <[EMAIL PROTECTED]>:
> Thanks! In fact, I
Richard Henderson wrote:
> On Mon, Feb 12, 2007 at 10:06:11AM -0800, Mark Mitchell wrote:
>> Does it seem overly aggressive to you to assume "f" cannot throw
>> in "g", given:
>>
>> void f() {}
>> void g() { f(); }
>>
>> where this code is in a shared library?
>
> Yes.
>
> If F is part of the
Vladimir Makarov wrote:
> On Sunday I had accidentally chat about the df infrastructure on
> IIRC. I've got some thoughts which I'd like to share.
>
> I like df infrastructure code from the day one for its clearness.
> Unfortunately users don't see it and probably don't care about it.
You're r
Larry Evans wrote:
How does one dump the trees in pt.c:tsubst in some hunan readable
cp_dump_tree(&di, args);
cp_dump_tree is a hook for printing C++ specific trees. Try dump_node
in tree-dump.c instead. Or one of the other functions in this file.
I'm not sure if you can call dump_node di
Mark Mitchell <[EMAIL PROTECTED]> writes:
> But, aren't big C++ shared libraries rather different? Does KDE
> actually use throw() everywhere, or visibility attributes? But,
> presumably, most people don't replace the implementation of
> ScrollBar::ScrollUp or whatever. I'd be happy to know I'm
On 02/11/2007 05:59 PM, Gerald Pfeifer wrote:
On Sun, 11 Feb 2007, Larry Evans wrote:
[snip]
I can't comment on the contents, but that HTML file is generated from
our texinfo documentation; the master source for that is
gcc/doc/install.texi
in our SVN repository.
Gerald
THanks Gerald. C
> Vladimir Makarov writes:
Vlad> Especially I did not like David Edelhson's phrase "and no new
Vlad> private dataflow schemes will be allowed in gcc passes". It was not
Vlad> such his first expression. Such phrases are killing competition which
Vlad> is bad for gcc. What if the new speciali
On Mon, Feb 12, 2007 at 01:16:43PM -0800, Ian Lance Taylor wrote:
> Mark Mitchell <[EMAIL PROTECTED]> writes:
>
> > But, aren't big C++ shared libraries rather different? Does KDE
> > actually use throw() everywhere, or visibility attributes? But,
> > presumably, most people don't replace the im
David Edelsohn wrote:
Vladimir Makarov writes:
Third, I am disappointed that you chose to make this argument
personal.
David, I really apologize to make it personal. We are all one community
and we are all thinking to make gcc a better compiler.
On Mon, Feb 12, 2007 at 01:30:41PM -0800, Richard Henderson wrote:
> On Mon, Feb 12, 2007 at 01:16:43PM -0800, Ian Lance Taylor wrote:
> > Mark Mitchell <[EMAIL PROTECTED]> writes:
> >
> > > But, aren't big C++ shared libraries rather different? Does KDE
> > > actually use throw() everywhere, or
Richard Henderson wrote:
> On Mon, Feb 12, 2007 at 01:16:43PM -0800, Ian Lance Taylor wrote:
>> Mark Mitchell <[EMAIL PROTECTED]> writes:
>>
>>> But, aren't big C++ shared libraries rather different? Does KDE
>>> actually use throw() everywhere, or visibility attributes? But,
>>> presumably, most
Joe Buck wrote:
>> If KDE doesn't use throw(), or visibility attributees, that's a
>> failing in KDE, not the compiler.
>
> Will 4.1.2 be worse than 4.1.1 for code that has these kinds of failings?
Yes. On workstation and server systems, most of the issue will be
somewhat larger binaries. On e
Joe Buck wrote:
> > Will 4.1.2 be worse than 4.1.1 for code that has these kinds of failings?
On Mon, Feb 12, 2007 at 01:53:10PM -0800, Mark Mitchell wrote:
> Yes
> > If so, then it might be better to push the fix that allows overrides that
> > throw back to 4.2, and circulate warnings to af
Snapshot gcc-4.1-20070212 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20070212/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.1 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
Given that we're not going to mess about further with DECL_REPLACEABLE_P
(since the case that Kaven raised involving PIC compilation of functions
using exceptions is a non-bug), I don't think we need to do RC3.
The only changes that we've had since RC2 are Andrew Haley's Java
timezone changes and
> > Vladimir Makarov writes:
>
> Vlad> Especially I did not like David Edelhson's phrase "and no new
> Vlad> private dataflow schemes will be allowed in gcc passes". It was not
> Vlad> such his first expression. Such phrases are killing competition which
> Vlad> is bad for gcc. What if the
> On Sunday I had accidentally chat about the df infrastructure on
> IIRC. I've got some thoughts which I'd like to share.
>
> I like df infrastructure code from the day one for its clearness.
> Unfortunately users don't see it and probably don't care about it.
> With my point of view the df
Vlad,
I think that different people can have different perspectives.
You have been working on improving the register allocation for several
years, but very little has come of it because the reload
infrastructure does not suit itself to being integrated with modern
register allocators. You ha
On Feb 11, 2007, at 1:17 PM, Brendon Costa wrote:
I am coding an extension for GCC and am having some difficulty with
pre-compiled headers. I dont know if my understanding of how they
work is completely correct and so my code is getting a segfault.
You _must_ have clean data structures and c
Richard Kenner wrote:
Vladimir Makarov writes:
Vlad> Especially I did not like David Edelhson's phrase "and no new
Vlad> private dataflow schemes will be allowed in gcc passes". It was not
Vlad> such his first expression. Such phrases are killing competition which
Vlad> is bad
On Feb 12, 2007, at 12:54 PM, Jiahua He wrote:
Oh, I see. For reduction and induction, you don't need to deal with
the condition with vdef. I am considering how to implement an idiom
with vdef, like SCAN (prefix sum). And by the way, do you support
idioms with vuses?
Jiahua
2007/2/12, Dorit Nu
Steven Bosscher wrote:
On 2/12/07, Vladimir Makarov <[EMAIL PROTECTED]> wrote:
I like df infrastructure code from the day one for its clearness.
Unfortunately users don't see it and probably don't care about it.
With my point of view the df infrastructure has a design flaw. It
extracts a lo
Mark Mitchell wrote:
Vladimir Makarov wrote:
On Sunday I had accidentally chat about the df infrastructure on
IIRC. I've got some thoughts which I'd like to share.
I like df infrastructure code from the day one for its clearness.
Unfortunately users don't see it and probably don't care abo
Vladimir N. Makarov wrote:
>> However, my understanding (as someone who's not an expert on the DF code
>> base) is that, as you say, the new stuff is much tidier. I understood
>> the objective to be not so much that DF itself would directly improve
>> the generated code, but rather than it would
On 2/12/07, Vladimir Makarov <[EMAIL PROTECTED]> wrote:
On Sunday I had accidentally chat about the df infrastructure on
IIRC. I've got some thoughts which I'd like to share.
I like df infrastructure code from the day one for its clearness.
Unfortunately users don't see it and probably don'
On 2/13/07, Vladimir N. Makarov <[EMAIL PROTECTED]> wrote:
> There are certainly performance issues here. There are limits on
> how much I, and the others who have worked on this have been able to
> change before we do our merge. So far, only those passes that were
> directly hacked into flow,
"Vladimir N. Makarov" <[EMAIL PROTECTED]> writes:
> I know some work is being done on incremental df analysis. It could
> decrease time for rescanning RTL between passes. Let us hope on this.
My understanding is that on dataflow-branch the DF information is now
fully incremental.
I don't real
Hello
On Mon, 12 Feb 2007 19:46:35 -0800 Mike Stump wrote
> The mental model you should use for PCH is this, when processing a header,
> the compiler does a complete memory walk and dumps it to a file. Upon
> `reading' the pch file, it mmaps all that memory back in, throwing out all
> previousl
what happens with the data previously loaded by a previous pch include file?
I can't figure out why every GTY()-ed global data (extern or static) should
be overwritten at each PCH inclusion, but then maybe I am wrong.
There can be only one PCH inclusion in every compilation.
Paolo
45 matches
Mail list logo
