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
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
"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
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,
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'
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
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
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
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
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 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
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 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
> > 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
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
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
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
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
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
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
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: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
> 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 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
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
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
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
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
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
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
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 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
> 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 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.
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 dependences that are associat
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)
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
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
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
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?
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.
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
-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
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
45 matches
Mail list logo
