Hello,
Ada is the last user of the tree_exp->complexity field. Removing this
field should reduce GCC's memory usage by about 5% on a 64 bit host.
Could an Ada maintainer see if it possible to remove the use of this
field? I would think it shouldn't be too hard -- TREE_COMPLEXITY is
used only ins
On Thu, 2007-01-18 at 12:44 +0530, pranav bhandarkar wrote:
> On 1/17/07, Mircea Namolaru <[EMAIL PROTECTED]> wrote:
> > > Thanks. Another question I have is that, in this case, will the
> > following
> > >
> > > http://gcc.gnu.org/wiki/Sign_Extension_Removal
> > >
> > > help in removal of the sign
On Thursday 18 January 2007 09:31, Jeffrey Law wrote:
> I haven't followed this thread that closely, but it seems to me this
> could be done in the propagation engine.
>
> Basically we keep track of the known zero, sign bit copies and known
> nonzero bits for SSA names, then propagate them in the o
On Thu, 2007-01-18 at 09:41 +0100, Steven Bosscher wrote:
> There appear to be more bit operations in RTL, so perhaps it is a
> better idea to implement a known-bits propagation pass for RTL, with
> the new dataflow engine.
If that's the case then most of the opportunities are appearing due to
low
I'd like to know if gcc has implemented some generic way to help
optimizer job by allowing programmers to specify assumptions (or
constraints).
This is somewhat different from assertions: suppose we have this simple
code:
#include
int p(int a) {
assert(a > 0);
return a <= 0;
}
Compiling w
Robert Dewar writes:
> Joe Buck wrote:
>
> (off topic!)
>
> > On Wed, Jan 17, 2007 at 06:40:21PM -0500, Robert Dewar wrote:
> >> H .. I wish some of the more important bugs in gcc received
> >> the attention that this very unimportant issue is receiving :-)
> >>
> >> I guess the diff
Ian Lance Taylor writes:
> Robert Dewar <[EMAIL PROTECTED]> writes:
>
> > Ian Lance Taylor wrote:
> >
> > > We do want to generate a trap for x / 0, of course.
> >
> > Really? Is this really defined to generate a trap in C?
> > I would be surprised if so ...
>
> As far as I know, but
On Thu, 18 Jan 2007, Andrew Haley wrote:
| Robert Dewar writes:
| > Joe Buck wrote:
| >
| > (off topic!)
| >
| > > On Wed, Jan 17, 2007 at 06:40:21PM -0500, Robert Dewar wrote:
| > >> H .. I wish some of the more important bugs in gcc received
| > >> the attention that this very unimpor
FX Coudert wrote:
Is there any reason why libgomp and libdecnumber don't have a svn:ignore
property containing autom4te.cache? I noticed the following always
showing up in my "svn status" after a maintainer-mode build:
? libdecnumber/autom4te.cache
? libgomp/autom4te.cache
Go ahead
Hi all,
I was quite surprised to see that the C Parser was manually
implemented and you didn't use any parser generator.
I would be curious regarding this decision. I would think the
development of a C parser would be an almost unsurmountable task and
not very logic given the parser generators i
> Ada is the last user of the tree_exp->complexity field. Removing
> this field should reduce GCC's memory usage by about 5% on a 64 bit
> host. Could an Ada maintainer see if it possible to remove the use
> of this field? I would think it shouldn't be too hard --
> TREE_COMPLEXITY is used only
> Basically we keep track of the known zero, sign bit copies and known
> nonzero bits for SSA names, then propagate them in the obvious ways.
> Basically replicating a lot of what combine & cse do in this area,
> but at the tree level. It's something I've always wanted to see
> implemented, but
Hello all,
After reading the internals of gcc wikibooks some questions come up.
So, gcc has front end for C, C++, java, fortran, etc..
All these languages have a frontend which parse into AST and then
GIMPLE which is converted to RTX and then assembly. Now, my guess is
that GIMPLE is the _common_
On 1/18/07, Richard Kenner <[EMAIL PROTECTED]> wrote:
> Ada is the last user of the tree_exp->complexity field. Removing
> this field should reduce GCC's memory usage by about 5% on a 64 bit
> host. Could an Ada maintainer see if it possible to remove the use
> of this field? I would think it
Probably someone else may give better answer, but shortly with the
many extensions (ad-hocks) to the C/C++ grammar the task of preparing
the inputs for the lex and bison seems not so trivial. Also, the
automatically generated parser wouldn't be as efficient as it is now.
On 1/18/07, Paulo J. Mato
> I'm not immediately aware of too many cases where lowering the IL is
> going to expose new opportunities to track and optimize nonzero/zero
> bits stuff.
Bitfield are the big one. If you have both bitfield and logical operations,
you can often merge the logical operations with those used to r
On 1/18/07, Paulo J. Matos <[EMAIL PROTECTED]> wrote:
Hi all,
I was quite surprised to see that the C Parser was manually
implemented and you didn't use any parser generator.
I would be curious regarding this decision. I would think the
development of a C parser would be an almost unsurmountabl
> I had thought of a hash table, too, but I couldn't figure out where to
> initialize and free it (i.e. where it is a "live" table, so to speak). For
> example, I don't know if this table would be required after gimplification,
> and I also don't even know how GNAT translates its own representatio
On 1/18/07, Richard Kenner <[EMAIL PROTECTED]> wrote:
> I'm not immediately aware of too many cases where lowering the IL is
> going to expose new opportunities to track and optimize nonzero/zero
> bits stuff.
Bitfield are the big one. If you have both bitfield and logical operations,
you can o
Andrew Haley wrote:
Mm, but although the problem being dicussed here is trivial, some of
the proposed solutions aren't. As the saying goes, "the cure is worse
than the disease."
Indeed! Well whenever you have umpteen people all trying to solve
a simple problem, things always get out of hand,
Gabriel Dos Reis wrote:
I would say that is a bit extreme. I don't think we're going to
implement any of the solutions without giving people options to
disable the correct instruction generation when they don't care about
it.
I would hesitate a bit about options in this general class of
gene
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
> constraints).
The answer is no, there is nothing quite like you describe.
But I think it would be a good idea.
Ian
"Paulo J. Matos" <[EMAIL PROTECTED]> writes:
> I was quite surprised to see that the C Parser was manually
> implemented and you didn't use any parser generator.
>
> I would be curious regarding this decision. I would think the
> development of a C parser would be an almost unsurmountable task an
"Paulo J. Matos" <[EMAIL PROTECTED]> writes:
> After reading the internals of gcc wikibooks some questions come up.
> So, gcc has front end for C, C++, java, fortran, etc..
> All these languages have a frontend which parse into AST and then
> GIMPLE which is converted to RTX and then assembly. Now
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
> > constraints).
>
> The answer is no, there is nothing quite like you describe
Hi,
Please, would you suggest me any clues on how to get a tree node for a
field of a variable within the AST.
Let's say that somewhere I declared:
MyStruct *var;
What I want to do is to get a tree node of a field within "var", i.e.
"var->field"
What I want actually is to modify "var->field",
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 allowing programmers to specify assumptions (or
> > > constraints).
> >
> >
Ian Lance Taylor wrote:
I'm sure Joseph could explain the reasons better, but some of the
problems with the bison parser were 1) it's hard to generate good
error messages at the right places; 2) C is not LALR(1) (at least, not
in a natural sense) because of the declaration syntax; 3) it made it
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
Richard Guenther wrote:
Providing a __builtin_assert () function is still one thing on my
TODO, we can
derive proper ASSERT_EXPRs from it in VRP even in the -DNDEBUG case.
Great! Certainly could be profitably used in libstdc++.
Paolo.
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
> > constraints).
>
> The answer is no, there is nothing
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
>
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 it in VRP even in the -DNDEBUG case.
|
| Great! Certainly could be profitably used in libstdc++.
Indee
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 it in VRP even in the -DNDEB
On 1/18/07, Jeffrey Law <[EMAIL PROTECTED]> wrote:
On Thu, 2007-01-18 at 12:44 +0530, pranav bhandarkar wrote:
> On 1/17/07, Mircea Namolaru <[EMAIL PROTECTED]> wrote:
> > > Thanks. Another question I have is that, in this case, will the
> > following
> > >
> > > http://gcc.gnu.org/wiki/Sign_Exte
"Ferad Zyulkyarov" <[EMAIL PROTECTED]> writes:
> Please, would you suggest me any clues on how to get a tree node for a
> field of a variable within the AST.
Look in tree.def.
Given the RECORD_TYPE node, walk down TYPE_FIELDS looking for the
FIELD_DECL that you want.
To assign to a field use a
Hello, from "GENERIC and GIMPLE: A New Tree Representation for Entire
Functions" by Jason Merrill it says there's a flag -fdump-tree-simple
to get the gimple tree (page 3). However, this doesn't exist in gcc
4.1:
$ gcc -fdump-tree-simple bigger3.c
cc1: error: unrecognized command line option "-fdu
Argh, forget it!
Found the answer in:
http://gcc.gnu.org/onlinedocs/gcc-4.1.1/gcc/Debugging-Options.html#Debugging-Options
Regards,
Paulo Matos
On 1/18/07, Paulo J. Matos <[EMAIL PROTECTED]> wrote:
Hello, from "GENERIC and GIMPLE: A New Tree Representation for Entire
Functions" by Jason Merri
On 18 Jan 2007 07:42:38 -0800, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
"Paulo J. Matos" <[EMAIL PROTECTED]> writes:
> After reading the internals of gcc wikibooks some questions come up.
> So, gcc has front end for C, C++, java, fortran, etc..
> All these languages have a frontend which pars
I think this warning is starting to happen for valid code because of
64-bit machines.
You can avoid it by using unsigned types. I think that something like
this will do the trick:
#define FIXNUM_OVERFLOW_P(i)\
((unsigned long long)(i) > M
On Tue, Jan 16, 2007 at 07:05:34PM +0300, Grigory Zagorodnev wrote:
> Toon Moene wrote:
> >Calculix is a combined C/Fortran program. Did you try to compile the
> >Fortran parts with --param max-aliased-vops= >default 50> ?
> Right, calculix is a combined program. Gprof says the regression is in
On 18/01/07, Richard Stallman <[EMAIL PROTECTED]> wrote:
Is this documented as a way to avoid problems with that warning?
No. This is an undocumented, unnamed, unconditional warning.
We are working on fixing those for GCC 4.3 :-)
Cheers,
Manuel.
On 18/01/07, Gabriel Dos Reis <[EMAIL PROTECTED]> wrote:
On Thu, 18 Jan 2007, Manuel López-Ibáñez wrote:
| On 18/01/07, Gabriel Dos Reis <[EMAIL PROTECTED]> wrote:
| > On Thu, 18 Jan 2007, Manuel López-Ibáñez wrote:
| >
| > | Does that apply also to:
| > |
| > | unsigned int y = -10;
| >
| > Yes
Manuel --
I read it and still don't get it. We know we should not warn about
system headers but we do and that is a known bug. So again, why is
libstdc++ using Wconversion at all?
I appreciate your help with this issue, and I'm confident that we'll
soon converge to a nice solution. Thanks, re
On 18/01/07, Paolo Carlini <[EMAIL PROTECTED]> wrote:
Manuel --
> I read it and still don't get it. We know we should not warn about
> system headers but we do and that is a known bug. So again, why is
> libstdc++ using Wconversion at all?
I appreciate your help with this issue, and I'm confide
On Thu, 18 Jan 2007, Manuel López-Ibáñez wrote:
[...]
| > As the PR you noted, it wasn't part of C++.
| >
|
| You are wrong.
"the PR you noted" is
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26167#c3
which you described as your favorite. The PR starts with this
gcc reports the signedne
On Thu, 18 Jan 2007, Paolo Carlini wrote:
| Manuel --
|
| > I read it and still don't get it. We know we should not warn about
| > system headers but we do and that is a known bug. So again, why is
| > libstdc++ using Wconversion at all?
|
| I appreciate your help with this issue, and I'm confiden
Gabriel Dos Reis wrote:
The pragma thing will be fixed; however, we will still be left with
unhelful warning for what has become idiomatic because of the way C++
tends to see sequences.
In Ada, we changed things a while ago to give warnings ONLY on the
extended main unit being compiled, and no
"Manuel López-Ibáñez" <[EMAIL PROTECTED]> writes:
[...]
| I just felt that the conversation was going in the direction of "we
| should shut the warnings of Wconversion up because people using it
| will get warnings for libstdc++".
I'm afraid you did not read the conversation carefully.
-- Gaby
On Thu, 18 Jan 2007, Robert Dewar wrote:
| Gabriel Dos Reis wrote:
|
| > The pragma thing will be fixed; however, we will still be left with
| > unhelful warning for what has become idiomatic because of the way C++
| > tends to see sequences.
|
| In Ada, we changed things a while ago to give warni
On 18/01/07, Gabriel Dos Reis <[EMAIL PROTECTED]> wrote:
On Thu, 18 Jan 2007, Manuel López-Ibáñez wrote:
[...]
| > As the PR you noted, it wasn't part of C++.
| >
|
| You are wrong.
"the PR you noted" is
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26167#c3
which you described as your favo
H. J. Lu wrote:
Is that possible to extract a smaller testcase?
I'm working on the small reproducer. That would take some time because
of benchmark complexity.
- Grigory
On Thu, 18 Jan 2007, Manuel López-Ibáñez wrote:
| On 18/01/07, Gabriel Dos Reis <[EMAIL PROTECTED]> wrote:
| > On Thu, 18 Jan 2007, Manuel López-Ibáñez wrote:
| >
| > [...]
| >
| > | > As the PR you noted, it wasn't part of C++.
| > | >
| > |
| > | You are wrong.
| >
| > "the PR you noted" is
| >
gcc doesn't build on powerpc-apple-darwin9:
/Volumes/mrs3/net/gcc-darwinO2/./prev-gcc/xgcc
-B/Volumes/mrs3/net/gcc-darwinO2/./p
rev-gcc/ -B/Volumes/mrs3/Packages/gcc-061208/powerpc-apple-darwin9/bin/ -c -g
-O2
-mdynamic-no-pic -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing
> Mike Stump writes:
Mike> gcc doesn't build on powerpc-apple-darwin9:
Mike> ../../gcc/gcc/config/rs6000/rs6000.c: In function
ârs6000_emit_vector_compareâ:
Mike> ../../gcc/gcc/config/rs6000/rs6000.c:11904: warning: ISO C90 forbids
mixed declarat
Mike> ions and code
Is this due
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 the source of a given instruction?
M.
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 the source of a given instruction?
M.
Sure it traps, but what happens when that trap occurs is of course
O/S dependent, ther
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 the source of a given instruction?
> >
> >M.
>
>
David Daney wrote:
MIPS does *not* seem to suffer from this 'defect', [...]
In my opinion, if this is not a defect, then the only thing
that needs to be done is writing a few lines in some "Known Issues"
section of the documentation. This because, at least for me,
standard conformance is the f
hi all,
i meet some problem when use the ARM gcc 4.1.1 with arg -msoft-float, the gcc
can't find the -lfloat.
while to found the source code of float lib?
Br
Thomas
60 matches
Mail list logo
