Dave Korn wrote:
What becomes to Cygwin and MinGW, the same attitude as followed with
Linux, that "producing any apps for Windoze should happen only on
Windoze, or that when one does it on some other host, it still should
happen just like on Windoze!", is totally weird to me.
It seems weir
Mike Stump wrote:
On Friday, August 26, 2005, at 12:59 AM, Kai Ruottu wrote:
Is there any sane reasons for this on systems which never have had that
non-GNU native 'cc' ?
Consistency. This is only bad if one abhors consistency and
predicability. No?
I understand people coming from all
Hello!
I'm implementing a new IPA phase in GCC-4.1. I need to pass the address
of a variable found in the stmt list to a newly created function (eg.
"f") like this:
{
int x; /* ordinary non-pointertype local vars */
int y;
[...]
x = 5;
y = x + 9;
f (&x); /* new call stmt inserted to
On Tuesday 30 August 2005 01:49, Timothy Miller wrote:
> me a minor revision of the Linux
> kernel comes out, there's no scarcity of news articles written about
> it. Indeed, any time something interesting happens, someone writes an
> article about it, like for instance, you may recall the time wh
Hi!
Uros Bizjak schrieb:
>>I am using MMX built-ins and gcc-4.0-20050825 and I am experiencing generation
>>of uneeded movq (at least I guess so, I am no assembler pro). I don't know
>>which gcc snapshot introduced this, but a I know that some pre-release gcc 4.0
>>didn't show this bad behaviour.
On 08/30/05 00:49, Timothy Miller wrote:
This is probably an odd request, but I'd like to see more news
articles on GCC development. Every time a minor revision of the Linux
You may want to browse the GCC Summit proceedings
(www.gccsummit.org/200[345]) and the GCC Wiki (http://gcc.gnu.org/wik
On Tue, 30 Aug 2005, Rafael ?vila de Esp?ndola wrote:
One problem is that compiler technology generally requires more background
then OS:
1) the new O(1) scheduler
2) the new PCI interface
or
1) the new SSA based intermediate representation
2) the new DFA based pipeline hazard recognizer
I don
On 8/30/05, Nicholas Nethercote <[EMAIL PROTECTED]> wrote:
> Timothy has a good point. GCC is arguably more important than the Linux
> kernel, yet it gets very little press and recognition. Note also that
> everybody loves Linux (more or less) but people mostly bitch about GCC if
> they think ab
Steven Bosscher wrote:
>
> So GCC 4.1 right now is a small compile time disaster. Are there any
> ideas for what can be done about it before releasing it?
>
I was looking at the testcase sent by Dale Johannesen both at tree
level and at rtl level:
> extern int a[];
> int foo(int w) {
> int n
On Tue, 2005-08-30 at 10:52 +, Ferenc Kovacs wrote:
> Hello!
>
> I'm implementing a new IPA phase in GCC-4.1. I need to pass the address
> of a variable found in the stmt list to a newly created function (eg.
> "f") like this:
>
> {
> int x; /* ordinary non-pointertype local vars */
> int
Dan,
Since Wiki is supposed to be documentation, the link to your patch
tracker on the main page of the Wiki seemed out of place. Especially
since after you got to the actual patch tracker then you got a link to
the email on how it works.
So, I changed the initial link to be to a new a Wiki page
I'm seeing splay tree usage from tree-ipa-type-escape in the first
places of profiles from tramp3d-v4:
samples %image name app name symbol
name
1418146.5462 no-vmlinux no-vmlinux (no
symbols)
71471 3.2992 cc1plus
There was some discussion a few weeks ago about some apps running slower
with FDO enabled.
I've recently investigated a similar situation using mainline. In my case,
the fact that the loop_optimize pass is disabled during FDO was the cause
of the slowdown. It appears that was recently disabled
On Tuesday 30 August 2005 17:53, Peter Steinmetz wrote:
> While this doesn't explain all of the degradations discussed (some were
> showing up on older versions of the compiler), it may explain some.
There is a lot of empirical evidence that the loop optimizer already
doesn't do many useful things
On Tue, 2005-08-30 at 09:31 -0400, Timothy Miller wrote:
> On 8/30/05, Nicholas Nethercote <[EMAIL PROTECTED]> wrote:
>
> > Timothy has a good point. GCC is arguably more important than the Linux
> > kernel, yet it gets very little press and recognition. Note also that
> > everybody loves Linux
On Tue, 2005-08-30 at 15:37 +0200, Sebastian Pop wrote:
> Steven Bosscher wrote:
> >
> tree level: 7 times
> Breakpoint 3, number_of_iterations_cond (type=0x2adf84d0,
> base0=0x2ae03d80, step0=0x0, code=LE_EXPR, base1=0x2afd5b90,
> step1=0x2afc8d20,
> niter=0xc174b0) at tre
>A more likely source of performance degradation is that loop unrolling
>is enabled when profiling, and loop unrolling is almost always a bad
>pessimization on 32 bits x86 targets.
To clarify, I was compiling with -funroll-loops and -fpeel-loops
enabled in both cases.
The FDO slowdown in my case
Dale Johannesen wrote:
> I think this is a simple pasto; this code was evidently copied from
> the previous block:
>
I don't think that this was a simple pasto. The code looks correct.
We have the same code in tree-ssa-loop-niter.c around line 436, since
we inherited this code from the rtl-level
>
> There was some discussion a few weeks ago about some apps running slower
> with FDO enabled.
>
> I've recently investigated a similar situation using mainline. In my case,
> the fact that the loop_optimize pass is disabled during FDO was the cause
> of the slowdown. It appears that was rece
On 29 Aug 2005, Gerald Pfeifer said:
> On Fri, 26 Aug 2005, Nix wrote:
>> --enable-version-specific-runtime-libs and
>> --program-{prefix,suffix,transform-name} and make slight adjustments
>> after installation (ditch libiberty.a and some locale and manpage stuff
>> that doesn't get its name suitab
Daniel Berlin wrote:
>
> I agree completely.
> We need to be a lot smarter about invalidating certain types of
> expensive to compute information.
The way that we compute niter, for the moment, could be considered as
not expensive. But the fact that we think that this is inexpensive
makes us c
the splay tree in question is there as part of the type unification.
This is required because our design for combining modules does not unify
the types and this messes up the type escape analysis.
Because of this, the type name must be the key. However, there is the
possibility that doing so
I have tried with gcc 3.4.4 and still see the same
20%slowdown. If you folks are able to crack this, do
let me know. On my earlier attempts I had tried to
disable all of the flags that feedback optimization
turns on (except the ones that are turned on by
default) and still got the 20% slowdown.
Is
> Do you have specific testcase? It would be interesting to see if new
> optimizer can catch up at least on kill-loop branch.
Here is a simplified version of what I observed. In the non-FDO case,
the loop invariant load of the constant 32 is removed from the loop.
When FDO is enabled, the load r
This is to request reinstatement of the -I- command line directory
search option. Sorry for the late request, we only recently became
aware that -I- is deprecated in gcc 4.0.
The Lucent(R) nmake tool (http://www.bell-labs.com/project/nmake/)
relies on -I- to implement the Lucent(R) nmake viewpath
> applications will just work, but introducing the very serious risk of
> security problems, leading to, say:
>
> gcc: dj:yourpassword:1234:567:DJ: invalid argument
>
> instead of
>
> gcc: @/etc/passwd: invalid argument
If you want to use gcc to read a file, you get a closer likeness
to the data
I was looking at a failure of the test
gcc.c-torture/compile/20001226-1.c on one of my machines and I see that
it is timing out on a slow machine that I have. I tried to look around
to find out how and where the timeout limit was set and could not find
it. Can someone explain to me how much time
Snapshot gcc-3.4-20050830 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/3.4-20050830/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 3.4 CVS branch
with the following options: -rgcc-ss-3_4-20050830
You'll
On Aug 30, 2005, at 4:34 PM, Steve Ellcey wrote:
I see that it is timing out on a slow machine that I have. I tried
to look around to find out how and where the timeout limit was set
and could not find it. Can someone explain to me how much time a
compile is given and where this limit is s
extern int a[];
int foo(int w) {
int n = w;
while (n >= 512)
{
a[n] = 42;
n -= 256;
}
}
On Aug 30, 2005, at 9:25 AM, Sebastian Pop wrote:
Thanks for looking at this. But...
Dale Johannesen wrote:
I think this is a simple pasto; this code was evidently copied from
the previous block:
I don't th
> By hand, I can compile the test in about 3 1/2 minutes on the machine in
> question (the machine may have been busier when the failure occured and thus
> taken longer).
I think it's a real regression (memory consumption/speed) of the compiler, it
is timing out on all the slow SPARC machines I
31 matches
Mail list logo
