On 10/10/06, Jochen Haerdtlein
<[EMAIL PROTECTED]> wrote:
Hello,
I am a PhD student working on the extended use of
expression templates for solving partial differential equations.
Thus, I did a lot of studying of expression templates papers,
articles and expression templates implementations.
On 10/14/06, Brendon Costa <[EMAIL PROTECTED]> wrote:
Hi all,
I have yet another question that has arisen as i have started testing my
code. Basically I am trying to get the type that is being used in
throwing an exception.
Is there a simple macro i can use to get the type of an exception from
On 10/23/06, Rafael Espíndola <[EMAIL PROTECTED]> wrote:
I have an approved patch that factors code that is common to all
builtin_function implementations
(http://gcc.gnu.org/ml/gcc-patches/2006-03/msg00195.html,
http://gcc.gnu.org/ml/gcc-patches/2006-06/msg01499.html).
I have just updated and
On 10/27/06, Aldy Hernandez <[EMAIL PROTECTED]> wrote:
> My vote is to merge into mainline sooner rather than later. However, it
> is a big patch and affects just about every module in the compiler, so I
> wouldn't want to barge in without getting some consensus first.
I agree with you and Mark
On 11/4/06, Kenneth Zadeck <[EMAIL PROTECTED]> wrote:
I think that it is time that we in the GCC community took some time to
address the problem of compiling very large functions in a somewhat
systematic manner.
GCC has two competing interests here: it needs to be able to provide
state of the a
On 11/4/06, Kenneth Zadeck <[EMAIL PROTECTED]> wrote:
Richard Guenther wrote:
> On 11/4/06, Kenneth Zadeck <[EMAIL PROTECTED]> wrote:
>> I think that it is time that we in the GCC community took some time to
>> address the problem of compiling very large functions
On 11/4/06, Kenneth Zadeck <[EMAIL PROTECTED]> wrote:
Richard Guenther wrote:
> On 11/4/06, Kenneth Zadeck <[EMAIL PROTECTED]> wrote:
>> Richard Guenther wrote:
>> > On 11/4/06, Kenneth Zadeck <[EMAIL PROTECTED]> wrote:
>> >> I think that it is tim
On 11/10/06, Howard Chu <[EMAIL PROTECTED]> wrote:
I see a lot of APIs (e.g. Cyrus SASL) that have accessor functions
returning values through a void ** argument. As far as I can tell, this
doesn't actually cause any problems, but gcc 4.1 with -Wstrict-aliasing
will complain. For example, take th
On 11/11/06, FX Coudert <[EMAIL PROTECTED]> wrote:
> Just wanted to note to the list that Tobias spotted a performance
> regression on Polyhedron ac.
>
> http://www.suse.de/~gcctest/c++bench/polyhedron/polyhedron-
> summary.txt-2-0.html
Hum, the performance change on ac is significant. Anyway we
On Sat, 11 Nov 2006, FX Coudert wrote:
> >Just wanted to note to the list that Tobias spotted a performance regression
> >on Polyhedron ac.
> >
> >http://www.suse.de/~gcctest/c++bench/polyhedron/polyhedron-summary.txt-2-0.html
>
> Hum, the performance change on ac is significant. Anyway we can ge
On 11/11/06, Revital1 Eres <[EMAIL PROTECTED]> wrote:
Hello,
-fno-rounding-math enables the transformation of (-(X - Y)) -> (Y - X)
in simplify-rtx.c which seems to be the same transformation
that enabled by -funsafe-math-optimizations in fold-const.c.
If I understand currently -frounding-mat
tly?
Yes this is a dual-socket machine. But I don't see how this can be
an issue here?
Richard.
--
Richard Guenther <[EMAIL PROTECTED]>
Novell / SUSE Labs
On 08 Nov 2006 08:07:50 -0800, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
Andrew Haley <[EMAIL PROTECTED]> writes:
> > 2006-11-07 Paolo Bonzini <[EMAIL PROTECTED]>
> >
> > * gimplify.c (fold_indirect_ref_rhs): Use
> > STRIP_USELESS_TYPE_CONVERSION rather than STRIP_NOPS.
On 11/16/06, Andrew Haley <[EMAIL PROTECTED]> wrote:
Zdenek Dvorak writes:
> Hello,
>
> >I am pleased to announce that the GCC Steering Committee has
> > appointed Zdenek Dvorak and Daniel Berlin as non-algorithmic maintainers
> > of the RTL and Tree loop optimizer infrastructure in GCC.
On 11/15/06, Richard Guenther <[EMAIL PROTECTED]> wrote:
On 08 Nov 2006 08:07:50 -0800, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
> Andrew Haley <[EMAIL PROTECTED]> writes:
>
> > > 2006-11-07 Paolo Bonzini <[EMAIL PROTECTED]>
> > >
> >
On 12/1/06, Uros Bizjak <[EMAIL PROTECTED]> wrote:
Hello!
At least on x86_64 and i686 SPEC score [1] and polyhedron [2] scores
dropped noticeably. For SPEC benchmarks, mgrid, galgel, ammp and
sixtrack tests are affected and for polygedron, ac (second regression
in the peak) and protein (?) regre
On 12/3/06, Kaveh R. GHAZI <[EMAIL PROTECTED]> wrote:
This patch updates configure to require MPFR 2.2.1 as promised here:
http://gcc.gnu.org/ml/gcc/2006-12/msg00054.html
Tested on sparc-sun-solaris2.10 using mpfr-2.2.1, mpfr-2.2.0 and an older
mpfr included with gmp-4.1.4. Only 2.2.1 passed (a
On 12/3/06, Toon Moene <[EMAIL PROTECTED]> wrote:
Richard,
Somewhere, in a mail lost in my large e-mail clash with my ISP
(verizon), you said that gfortran couldn't profit from the pow(x, 1./3.)
-> cbrt(x) conversion because gfortran didn't "know" of cbrt.
Could you be more explicit about this
On 12/4/06, Howard Hinnant <[EMAIL PROTECTED]> wrote:
On Dec 4, 2006, at 11:27 AM, Richard Guenther wrote:
> On 12/3/06, Toon Moene <[EMAIL PROTECTED]> wrote:
>> Richard,
>>
>> Somewhere, in a mail lost in my large e-mail clash with my ISP
>> (verizon),
On 12/4/06, David Edelsohn <[EMAIL PROTECTED]> wrote:
I am pleased to announce that the GCC Steering Committee has
appointed Richard Guenther as non-algorithmic middle-end maintainer.
Please join me in congratulating Richi on his new role. Richi,
please update your listi
On 12/4/06, Richard Guenther <[EMAIL PROTECTED]> wrote:
On 12/4/06, David Edelsohn <[EMAIL PROTECTED]> wrote:
> I am pleased to announce that the GCC Steering Committee has
> appointed Richard Guenther as non-algorithmic middle-end maintainer.
>
> Please j
On 12/4/06, Howard Hinnant <[EMAIL PROTECTED]> wrote:
On Dec 4, 2006, at 4:57 PM, Richard Guenther wrote:
>
>> My inclination is that if pow(x, 1./3.) (computed
>> correctly to the last bit) ever differs from cbrt(x) (computed
>> correctly to the last bit) then this
On 12/5/06, Joseph S. Myers <[EMAIL PROTECTED]> wrote:
On Tue, 5 Dec 2006, Richard Guenther wrote:
> is whether a correctly rounded "exact" cbrt differs from the pow
> replacement by more than 1ulp - it looks like this is not the case.
They fairly obviously differ for neg
On 05 Dec 2006 07:16:04 -0800, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
Paul Brook <[EMAIL PROTECTED]> writes:
> > This all may just be a shakedown problem with MPFR, and maybe it will
> > stabilize shortly. But it's disturbing that after one undistributed
> > version became a requirement, w
On 12/5/06, Toon Moene <[EMAIL PROTECTED]> wrote:
Richard Guenther wrote:
> It's a matter of making the cbrt builtin available - I have a patch for
> this, but wondered if the fortran frontend can rely on the cbrt library call
> being available? Or available in a fast var
On 12/5/06, Toon Moene <[EMAIL PROTECTED]> wrote:
Toon Moene wrote:
> Toon Moene wrote:
>
>> Richard Guenther wrote:
>>
>>> It's a matter of making the cbrt builtin available - I have a patch
>>> for this,
>
> Oh, BTW, my own version of this
On 12/3/06, Gerald Pfeifer <[EMAIL PROTECTED]> wrote:
Hi Richie,
On Tue, 21 Nov 2006, Richard Guenther wrote:
> Public monitoring would be more useful. If you have working single-file
> testcases that you want be monitored for compile-time and memory-usage
> just contact me and
On 12/13/06, Grigory Zagorodnev <[EMAIL PROTECTED]> wrote:
Meissner, Michael wrote:
>>> 437.leslie3d-26%
> it was felt that the PPRE patches that were added on November 13th were
> the cause of the slowdown:
> http://gcc.gnu.org/ml/gcc/2006-12/msg00023.html
>
> Has anybody tried doing a r
On 12/13/06, Menezes, Evandro <[EMAIL PROTECTED]> wrote:
> Meissner, Michael wrote:
> >>> 437.leslie3d -26%
> > it was felt that the PPRE patches that were added on
> November 13th were
> > the cause of the slowdown:
> > http://gcc.gnu.org/ml/gcc/2006-12/msg00023.html
> >
> > Has anybody tri
On 12/14/06, Mark Shinwell <[EMAIL PROTECTED]> wrote:
I am currently involved in building GCC toolchains by configuring them with
the prefix that is to be used on the target system (somewhere in /opt)
and then installing them in a separate "working installation" directory
(say somewhere in my scr
On 12/29/06, Robert Dewar <[EMAIL PROTECTED]> wrote:
Daniel Berlin wrote:
> I'm sure no matter what argument i come up with, you'll just explain it away.
> The reality is the majority of our users seem to care more about
> whether they have to write "typename" in front of certain declarations
>
On 12/29/06, Paul Eggert <[EMAIL PROTECTED]> wrote:
Ian Lance Taylor <[EMAIL PROTECTED]> writes:
> Does anybody think that Paul's proposed patch to autoconf would be
> better than changing VRP?
I don't.
I haven't noticed anyone else addressing this question,
which I think is a good one.
I don
On 12/29/06, Daniel Jacobowitz <[EMAIL PROTECTED]> wrote:
On Fri, Dec 29, 2006 at 10:44:02PM +0100, Florian Weimer wrote:
> (BTW, I would be somewhat disappointed if this had to be pampered over
> on the autoconf side. If the GNU project needs -fwrapv for its own
> software by default, this shou
On 12/30/06, Paul Eggert <[EMAIL PROTECTED]> wrote:
For example, GCC itself assumes wrapv semantics internally,
but according to the -fwrapv opponents GCC is obviously "at
fault" here and should be fixed, so that shouldn't count,
right? (If that's the way the data will be collected, I
think I k
On 30 Dec 2006 23:55:46 +0100, Gabriel Dos Reis
<[EMAIL PROTECTED]> wrote:
[EMAIL PROTECTED] (Richard Kenner) writes:
| > Here's an example from the intprops module of gnulib.
|
| These are interesting case.
|
| Note that all the computations are constant-folded.
|
| And I think this points the
On 31 Dec 2006 00:10:23 +0100, Gabriel Dos Reis
<[EMAIL PROTECTED]> wrote:
"Richard Guenther" <[EMAIL PROTECTED]> writes:
| On 30 Dec 2006 23:55:46 +0100, Gabriel Dos Reis
| <[EMAIL PROTECTED]> wrote:
| >/* Wrapper around int_const_binop. If the operation ove
On 31 Dec 2006 00:40:39 +0100, Gabriel Dos Reis
<[EMAIL PROTECTED]> wrote:
"Richard Guenther" <[EMAIL PROTECTED]> writes:
| On 31 Dec 2006 00:10:23 +0100, Gabriel Dos Reis
| <[EMAIL PROTECTED]> wrote:
| > "Richard Guenther" <[EMAIL PROTECTED]>
On 12/31/06, Richard Kenner <[EMAIL PROTECTED]> wrote:
> What would you suggest this function to do, based on your comments?
I'm not familiar enough with VRP to answer at that level, but at a higher
level, what I'd advocate is that the *generator* of information would track
things both ways, ass
On 12/31/06, Duncan Sands <[EMAIL PROTECTED]> wrote:
> > for this specific function (vrp_int_const_binop), I'm issuing a
> > warning inside the else-if branch that tests for the overflowed
> > result. I'm unclear why that is a false positive since the result is
> > known to overflow. Could you
On 31 Dec 2006 12:42:57 +0100, Gabriel Dos Reis
<[EMAIL PROTECTED]> wrote:
"Richard Guenther" <[EMAIL PROTECTED]> writes:
| On 12/31/06, Richard Kenner <[EMAIL PROTECTED]> wrote:
| > > What would you suggest this function to do, based on your comments?
| >
On 12/31/06, Daniel Berlin <[EMAIL PROTECTED]> wrote:
On 12/31/06, Paul Eggert <[EMAIL PROTECTED]> wrote:
> "Steven Bosscher" <[EMAIL PROTECTED]> writes:
>
> > On 12/31/06, Paul Eggert <[EMAIL PROTECTED]> wrote:
> >> Also, as I understand it this change shouldn't affect gcc's
> >> SPEC benchmark
On 12/31/06, Robert Dewar <[EMAIL PROTECTED]> wrote:
Paul Eggert wrote:
> The question is not whether GCC should support wrapv
> semantics; it already does, if you specify -fwrapv.
> The question is merely whether wrapv should be the default
> with optimization levels -O0 through -O2.
That over
On 12/31/06, Richard Kenner <[EMAIL PROTECTED]> wrote:
> I think this is a fragile and not very practical approach. How do
> you define these "traditional" cases?
You don't need to define the "cases" in advance. Rather, you look at
each place where you'd be making an optimization based on the
On 12/31/06, Richard Kenner <[EMAIL PROTECTED]> wrote:
> Are you volunteering to audit the present cases and argue whether they
> fall in the "traditional" cases?
I'm certainly willing to *help*, but I'm sure there will be some cases
that will require discussion to get a consensus.
> Note that
On 1/1/07, Richard Kenner <[EMAIL PROTECTED]> wrote:
> the seemingly prevalent attitude "but it is undefined; but it is not
> C" is the opinion of the majority of middle-end maintainers.
Does anybody DISAGREE with that "attitude"? It isn't valid C to assume that
signed overflow wraps. I've hea
On 1/1/07, Geert Bosch <[EMAIL PROTECTED]> wrote:
On Dec 31, 2006, at 19:13, Daniel Berlin wrote:
> Note the distinct drop in performance across almost all the benchmarks
> on Dec 30, including popular programs like bzip2 and gzip.
Not so.
To my eyes, the specint 2000 mean went UP by about 1% f
On 1/2/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
Daniel Berlin wrote:
>> Richard Guenther added -fwrapv to the December 30 run of SPEC at
>> <http://www.suse.de/~gcctest/SPEC/CFP/sb-vangelis-head-64/recent.html>
>> and
>> <http://www.suse.de/~gcctest/SP
On 1/2/07, Robert Dewar <[EMAIL PROTECTED]> wrote:
Richard Guenther wrote:
> On 1/1/07, Geert Bosch <[EMAIL PROTECTED]> wrote:
specfp.
>
> I would support the proposal to enable -fwrapv for -O[01], but
> not for -O2 as that is supposed to be "optimize for speed&quo
On 1/2/07, Richard Kenner <[EMAIL PROTECTED]> wrote:
> We do that with -fstrict-aliasing, which also changes language semantics.
Well, yes, but not quite in the same way. Indeed it's rather hard to
describe in what way it changes the language semantics but easier to
describe the effect it has o
On 1/4/07, Richard Sandiford <[EMAIL PROTECTED]> wrote:
Paul Eggert <[EMAIL PROTECTED]> writes:
> Mark Mitchell <[EMAIL PROTECTED]> writes:
>> it sounds like that would eliminate most of the problem. Certainly,
>> making -INT_MIN evaluate to INT_MIN, when expressed like that, is an
>> easy thing
On 1/4/07, Richard Sandiford <[EMAIL PROTECTED]> wrote:
"Richard Guenther" <[EMAIL PROTECTED]> writes:
> On 1/4/07, Richard Sandiford <[EMAIL PROTECTED]> wrote:
>> Paul Eggert <[EMAIL PROTECTED]> writes:
>> > Mark Mitchell <[EMAIL PROTEC
On 1/4/07, drizzle drizzle <[EMAIL PROTECTED]> wrote:
Still no luck so far .. I got the gcc3.4 from the gcc archive. Any way
I can make gcc 3.4 not use these libraries ?
3.4 doesn't use gmp or mpfr, gfortran introduces this dependency but it
appears with 4.0 or newer only.
Richard.
On 1/4/07, drizzle drizzle <[EMAIL PROTECTED]> wrote:
I configure with --enable-languages=c,c++ . Shudnt that disable gfortran ?
You are not configuring gcc 3.4.
Richard.
thanks
dz
On 1/4/07, Richard Guenther <[EMAIL PROTECTED]> wrote:
> On 1/4/07, drizzle drizzle <[EMAIL
On 1/5/07, Joe Buck <[EMAIL PROTECTED]> wrote:
On Fri, Jan 05, 2007 at 07:26:27AM -0800, Ian Lance Taylor wrote:
> David Edelsohn <[EMAIL PROTECTED]> writes:
>
> > Are 4.0 snapshots still necessary? I suspect they should be
> > discontinued.
>
> 4.0 still seems to be regarded as an active br
On 1/5/07, David Fang <[EMAIL PROTECTED]> wrote:
> > > > Are 4.0 snapshots still necessary? I suspect they should be
> > > > discontinued.
> > >
> > > 4.0 still seems to be regarded as an active branch.
> > >
> > > I don't mind closing it, myself. Does anybody think we should have a
> > > 4
On 1/8/07, George R Goffe <[EMAIL PROTECTED]> wrote:
/tools/gcc/obj-i686-pc-linux-gnu/./prev-gcc/xgcc
-B/tools/gcc/obj-i686-pc-linux-gnu/./prev-gcc/
-B/usr/lsd/Linux/x86_64-unknown-linux-gnu/bin/ -c -g -O2 -DIN_GCC -W -Wall
-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic
-
On 1/15/07, pranav bhandarkar <[EMAIL PROTECTED]> wrote:
Hello Everyone,
I have the following source code
static int i;
static char a;
char foo_gen(int);
void foo_assert(char);
void foo ()
{
int *x = &i;
a = foo_gen(0);
a |= 1; /* 1-*/
if (*x) goto end:
a | =1; /* --
On 17 Jan 2007 16:36:04 -0600, Gabriel Dos Reis <[EMAIL PROTECTED]> wrote:
Paolo Carlini <[EMAIL PROTECTED]> writes:
| Joe Buck wrote:
|
| >In the case of the containers, we are asserting/relying on the fact that
| >the pointer difference is zero or positive. But this has become a
| >widespread
On 18 Jan 2007 07:51:51 -0800, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
Andrew Haley <[EMAIL PROTECTED]> writes:
> Ian Lance Taylor writes:
> > Abramo Bagnara <[EMAIL PROTECTED]> writes:
> >
> > > I'd like to know if gcc has implemented some generic way to help
> > > optimizer job by allo
On 1/18/07, Robert Dewar <[EMAIL PROTECTED]> wrote:
Andrew Haley wrote:
> Ian Lance Taylor writes:
> > Abramo Bagnara <[EMAIL PROTECTED]> writes:
> >
> > > I'd like to know if gcc has implemented some generic way to help
> > > optimizer job by allowing programmers to specify assumptions (or
>
On 18 Jan 2007 10:19:37 -0600, Gabriel Dos Reis <[EMAIL PROTECTED]> wrote:
Paolo Carlini <[EMAIL PROTECTED]> writes:
| Richard Guenther wrote:
|
| > Providing a __builtin_assert () function is still one thing on my
| > TODO, we can
| > derive proper ASSERT_EXPRs from
On 1/19/07, Joe Buck <[EMAIL PROTECTED]> wrote:
On Thu, Jan 18, 2007 at 05:36:23PM -0500, Robert Dewar wrote:
> Morten Welinder wrote:
> >>For sure a/b is undefined
> >
> >In C, it is. In assembler it is perfectly well defined, i.e., it
> >traps. But how is the
> >trap handler supposed to know
On 1/24/07, David Carlton <[EMAIL PROTECTED]> wrote:
On Tue, 23 Jan 2007 17:54:10 -0500, Diego Novillo <[EMAIL PROTECTED]> said:
> So, I was doing some archeology on past releases and we seem to be
> getting into longer release cycles.
Interesting.
I'm a GCC observer, not a participant, but he
On 1/25/07, Steven Bosscher <[EMAIL PROTECTED]> wrote:
On 1/25/07, H. J. Lu <[EMAIL PROTECTED]> wrote:
> > >Gcc 4.2 has a serious FP performace issue:
> > >
> > >http://gcc.gnu.org/ml/gcc/2007-01/msg00408.html
> > >
> > >on both ia32 and x86-64. If there will be a 4.2.0 release, I hope it
> > >wi
On 25 Jan 2007 10:29:27 -0600, Gabriel Dos Reis <[EMAIL PROTECTED]> wrote:
Hi,
There were over 250 PRs open against GCC-4.0.4. Almost all of
them are "benign" in the sense that we can leave without fixing them
in GCC-4.0.4 -- many are already fixed in more recent versions.
I'm now giving att
On 1/25/07, Gabriel Dos Reis <[EMAIL PROTECTED]> wrote:
On Thu, 25 Jan 2007, Richard Guenther wrote:
| You might want to consider middle-end/28651 given the recent integer overflow
| discussions.
Good suggestion!
| I can do the backport work if you like.
If you could work out a backp
On 1/25/07, Volker Reichelt <[EMAIL PROTECTED]> wrote:
Hi,
> | Well, there's another serious (wrong-code) bug which should be fixed
IMHO:
> |
> | PR c++/29106 is a C++ front-end issue.
> | It has a one-line fix (plus comment) on the 4.1 branch.
> | Well, actually one should also backport the fix
On 1/26/07, Diego Novillo <[EMAIL PROTECTED]> wrote:
Paulo J. Matos wrote on 01/26/07 06:52:
> Is the output of -fdump-tree-optimized a subset of GIMPLE?
>
Yes. The output is an incomplete textual representation of the GIMPLE
form of the program.
It's after doing TER, so the statements are no
On 1/27/07, Paul Schlie <[EMAIL PROTECTED]> wrote:
>> On Fri, Jan 26, 2007 at 06:57:43PM -0500, Paul Schlie wrote:
> Likewise, if the program has an uninitialized variable, the behavior
> will differ depending on details of optimization and how variables are
> assigned to memory. Heap allocated
On 1/28/07, Steven Bosscher <[EMAIL PROTECTED]> wrote:
Hello rth,
Can you explain what went through your mind when you picked the
tree_exp.complexity field for something implemented new... :-(
Not much...
http://gcc.gnu.org/ml/gcc-patches/2005-10/msg01117.html
"... but my brain isn't workin
On 1/28/07, tbp <[EMAIL PROTECTED]> wrote:
Let it be clear from the start this is a potshot and while those
trends aren't exactly new or specific to my code, i haven't tried to
provide anything but specific data from one of my app, on
win32/cygwin.
Primo, gcc getting much better wrt inling exace
On 1/28/07, Denis Vlasenko <[EMAIL PROTECTED]> wrote:
char p;
int main() {
p = "";
return 0;
}
Don't you think that "" should end up in rw data?
Why? It's not writable after all.
Richard.
On 1/28/07, Jan Hubicka <[EMAIL PROTECTED]> wrote:
> tbp wrote:
>
> > Secundo, while i very much appreciate the brand new string ops, it
> > seems that on ia32 some array initialization cases where left out,
> > hence i still see oodles of 'movl $0x0' when generating code for k8.
> > Also those z
On 1/29/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
Steven Bosscher wrote:
> On 1/29/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
>> Email is a tricky thing. I've learned -- the hard way -- that it's best
>> to put a smiley on jokes, because otherwise people can't always tell
>> that they're jo
On 1/29/07, Eric Botcazou <[EMAIL PROTECTED]> wrote:
> There's a later ;) simley in the mail and maybe you missed one after
> the second paragraph. (certainly you did)
Then I guess the question is: what is the scope of a smiley? Does it
retroactively cover all the preceding sentences, includin
On 1/30/07, Brooks Moses <[EMAIL PROTECTED]> wrote:
I've been trying to track down an build failure that I was pretty sure
came about from some patches I've been trying to merge, but I've now
reduced things to a bare unmodified tree and it's still failing. I
could have sworn that it wasn't doing
On 2/1/07, Ismail Dönmez <[EMAIL PROTECTED]> wrote:
On Wednesday 31 January 2007 11:26:38 Ismail Dönmez wrote:
> On Tuesday 30 January 2007 18:43:52 Ian Lance Taylor wrote:
> > Ismail Dönmez <[EMAIL PROTECTED]> writes:
> > > I am getting this when I try to compile gcc trunk:
> > >
> > > ../../lib
On 2/5/07, Dorit Nuzman <[EMAIL PROTECTED]> wrote:
Grigory Zagorodnev <[EMAIL PROTECTED]> wrote on 05/02/2007
08:18:34:
> Dorit Nuzman wrote:
> > I'm seeing this bootstrap failure on i686-pc-linux-gnu (revision
121579) -
> > something I'm doing wrong, or is anyone else seeing this?
>
> Yes. I se
I believe reverting this patch on the branch is the only option (to
fixing the HP-UX assembler). I don't know of any real-life issue
it fixes.
Richard.
--
Richard Guenther <[EMAIL PROTECTED]>
Novell / SUSE Labs
n general (I pushed
for this some time ago).
Thoughts?
Thanks,
Richard.
--
Richard Guenther <[EMAIL PROTECTED]>
Novell / SUSE Labs
out of this
(and the vectorizer leaves us with a lot of cruft which is only
removed much later).
The above case would also ask for an early vectorization pass if the
loop was wrapped into another.
Finding a good heuristic for which loops to completely unroll early
is not easy, though for odd small nu
n work in
this case (though after vectorization aliasing is in an "interesting"
state).
> Did you run some benchmarks?
Not yet - I'm looking at the C++ SPEC 2006 benchmarks at the moment
and using vectorization there seems to do a lot of collateral damage
(maybe not measurable though).
Richard.
--
Richard Guenther <[EMAIL PROTECTED]>
Novell / SUSE Labs
On 2/5/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
Daniel Berlin wrote:
>> Daniel, 30088 is another aliasing problem. IIIRC, you've in the past
>> said that these were (a) hard to fix, and (b) uncommon. Is this the
>> same problem? If so, do you still feel that (b) is true? I'm
>> suspiciou
y don't want to vectorize
> anyhow, and even that - only temporarily - until we have straight-line-code
> vectorization in place. So I'm all for it.
Ok, I'll dig out the patches I had for this and will do some SPEC
runs. As soon as I have time for this (no hurry necessary here I think).
Thanks!
Richard.
--
Richard Guenther <[EMAIL PROTECTED]>
Novell / SUSE Labs
On Tue, 6 Feb 2007, Dorit Nuzman wrote:
> Ira Rosen/Haifa/IBM wrote on 06/02/2007 11:49:17:
>
> > Dorit Nuzman/Haifa/IBM wrote on 05/02/2007 21:13:40:
> >
> > > Richard Guenther <[EMAIL PROTECTED]> wrote on 05/02/2007 17:59:00:
> > >
> ...
> &g
On 2/18/07, Daniel Berlin <[EMAIL PROTECTED]> wrote:
On 2/17/07, H. J. Lu <[EMAIL PROTECTED]> wrote:
> On Sat, Feb 17, 2007 at 01:35:28PM +0300, Vladimir Sysoev wrote:
> > Hello, Daniel
> >
> > It looks like your changeset listed bellow makes performance
> > regression ~40% on SPEC2006/leslie3d.
On 2/20/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
So, my feeling is that the best course of action is to set a relatively
low threshold for GCC 4.2.0 and target 4.2.0 RC1 soon: say, March 10th.
Then, we'll have a 4.2.0 release by (worst case, and allowing for
lameness on my part) March 3
On 2/20/07, Vladimir Makarov <[EMAIL PROTECTED]> wrote:
As for proposal to revert the aliasing fixes on the 4.2, IMHO aliasing
bugs are pretty nasty it is hard to find a option to work around because
alias info is used in many optimizations.
All bugs we are talking about can be worked around b
On 2/20/07, Vladimir Makarov <[EMAIL PROTECTED]> wrote:
Richard Guenther wrote:
> On 2/20/07, Vladimir Makarov <[EMAIL PROTECTED]> wrote:
>
>> As for proposal to revert the aliasing fixes on the 4.2, IMHO aliasing
>> bugs are pretty nasty it is hard to find a
On 2/20/07, Grigory Zagorodnev <[EMAIL PROTECTED]> wrote:
Mark Mitchell wrote:
>> FP performance regressions of the recent GCC 4.2 (revision 120817)
>> compiler against September GCC 4.2 (revision 116799)
> What does that translate to in terms of overall score?
>
Hi,
This is 4.7% drop of SPECfp_b
On 2/21/07, Benjamin Kosnik <[EMAIL PROTECTED]> wrote:
> 4.0 branched with critical flaws that were not noticed until 4.2.0 which
> is why we end up with the missed optimiation regression in the first place.
>
> So the question is do we want to correct the regressions or not, because
> right now
On 2/21/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
To be honest, my instinct for the FSF is to take the 4% hit and get rid
of this nasty class of bugs. Users measure compiler quality by more
than just floating-point benchmarks; FP code is a relatively small
(albeit important, and substantial)
On 2/22/07, Alok kataria <[EMAIL PROTECTED]> wrote:
Hi,
I was trying some inline assembly with gcc.
Running the assembly program on 64 bit system ( with 64bit gcc
version) gives errors of the form
/tmp/cc28kO9v.s: Assembler messages:
/tmp/cc28kO9v.s:57: Error: suffix or operands invalid for `
Currently for example in fold_sign_changed_comparison we produce
integer constants that are not inside the range of its type values
denoted by [TYPE_MIN_VALUE (t), TYPE_MAX_VALUE (t)]. For example
consider a type with range [10, 20] and the comparison created by
the Ada frontend:
if ((signed ch
On Fri, 23 Feb 2007, Duncan Sands wrote:
> > Currently for example in fold_sign_changed_comparison we produce
> > integer constants that are not inside the range of its type values
> > denoted by [TYPE_MIN_VALUE (t), TYPE_MAX_VALUE (t)]. For example
> > consider a type with range [10, 20] and the
On Fri, 23 Feb 2007, Richard Kenner wrote:
> > That said, this whole thing is a can of worms. Suppose the compiler wants
> > to
> > calculate t+1. Of course you do something like this:
> >
> > int_const_binop (PLUS_EXPR, t, build_int_cst (TREE_TYPE (t), 1), 0);
> >
> > But if 1 is not in the
On 2/27/07, Menezes, Evandro <[EMAIL PROTECTED]> wrote:
Honza,
> Well, rather than unstable, they seems to be more memory layout
> sensitive I would say. (the differences are more or less reproducible,
> not completely random, but independent on the binary itself. I can't
> think of much else th
On 03 Mar 2007 11:00:11 -0800, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
Grigory Zagorodnev <[EMAIL PROTECTED]> writes:
> Trunk GCC shows massive (2 compile-time and 6 run-time) failures on
> SPEC CPU2000 and CPU2006 at i386 and x86_64 on -O2 optimization
> level. Regression introduced somewhe
On 3/3/07, Fabio Giovagnini <[EMAIL PROTECTED]> wrote:
Thanks for the answer.
I go deeper in my thought so that maybe you can give me more infos about how I
have to investagte about gcc/gdb
We are developers of embedded software on board designed and build by us;
Generally we use 16 bit cisc and
On 3/3/07, Grigory Zagorodnev <[EMAIL PROTECTED]> wrote:
Hi,
Trunk GCC shows massive (2 compile-time and 6 run-time) failures on SPEC
CPU2000 and CPU2006 at i386 and x86_64 on -O2 optimization level.
Regression introduced somewhere between revision 122487 and 122478.
There are three checkins, ca
1 - 100 of 2444 matches
Mail list logo
