Maybe in another six years cpu improvements will outpace gcc bootstrap
times enough to reconsider.
We'll have 60 cores per CPU, and 1 minute after invoking "make" we'll be
cursing how much it takes for insn-attrtab.c to finish compiling. :-)
Paolo
> I can sympathize with that, I have a slightly different problem. Right
> now there are some java test that time-out 10x on solaris2.10. I run four
> passes of the testsuite with different options each time, so that 40
> timeouts. (This is without any extra RTL checking turned on.) At 5
> minu
> Figures? Tree checking is not cheap with GCC 4.x either.
Here are mine (Athlon64 2.4 GHz, 1 GB, c,c++,objc,obj-c++,java,fortran,ada):
gcc version 4.3.0 20061103 (experimental)
assert,runtime (aka release): 115 min
assert,runtime,misc:176 min
asser
On 11/7/06, Mike Stump <[EMAIL PROTECTED]> wrote:
On Nov 6, 2006, at 9:30 PM, Mohamed Shafi wrote:
> My target (non gcc/private one) fails for long long testcases
Does it work flawlessly otherwise, if not, fix all those problems
first. After those are all fixed, then you can see if it then jus
>
> How do i determine if two type nodes in the C front end are equivilent?
> In C++ i use same_type_p() but do not see an equivilant for the C front end.
The function you want is comptypes.
Thanks,
Andrew Pinski
On Nov 9, 2006, at 6:39 AM, Mohamed Shafi wrote:
When i diff the rtl dumps for programs passing negative value with and
without frame pointer i find changes from file.greg .
And, is that change bad? We do expect changes in codegen, you didn't
say if those changes are invalid, or what was in
This message outlines a plan for modifying the GCC driver to support
compilation in LTO mode. The goal is that:
gcc --lto foo.c bar.o
will generate LTO information for foo.c, while compiling it, then invoke
the LTO front end for foo.o and bar.o, and then invoke the linker.
However, as a first
> I can dig out actual real live numbers, if you're curious. For
example, when calling comptypes, the no answers are (were) 34x more
likely than yes answers. If you cannot return false immediately when
point_to_type1 != pointer_to_type2, you then have to run a structural
equality tester, and on
On Thu, Nov 09, 2006 at 09:06:42PM +, Joern RENNECKE wrote:
> > I can dig out actual real live numbers, if you're curious. For
> example, when calling comptypes, the no answers are (were) 34x more
> likely than yes answers. If you cannot return false immediately when
> point_to_type1 != poin
The function you want is comptypes.
Thanks. That is working well.
Hi Brendon,
Wouldn't the C++ one (mostly) be a superset of the C?
Types are reasonably different between the C and C++ front ends though you do
have the common ones because as you said, C++ is a superset of C. The C++
Mark Mitchell <[EMAIL PROTECTED]> writes:
> 1. Add a --lto option to collect2. When collect2 sees this option,
> treat all .o files as if they were .rpo files and recompile them. We
> will do this after all C++ template instantiation has been done, since
> we want to optimize the .o files after
Snapshot gcc-4.0-20061109 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.0-20061109/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.0 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
Reminder: if you need access to x86 machines to run your boring
batches or to test your software with GCC snapshots with even
more boring batches, the GCC compile farm is for you:
http://gcc.gnu.org/wiki/CompileFarm
<<
GCC Compile Farm Project
The GCC CompileFarm Project is seeking volunteers to
On Nov 8, 2006, at 5:59 AM, Doug Gregor wrote:
However, this approach could have some odd side effects when there are
multiple mappings within one context. For instance, we could have
something like:
typedef int foo_t;
typedef int bar_t;
foo_t* x = strlen("oops");
x is a decl, the decl has
On Nov 8, 2006, at 7:14 AM, Ian Lance Taylor wrote:
The way to canonicalize them is to have all equivalent types point to
a single canonical type for the equivalence set. The comparison is
one memory dereference and one pointer comparison, not the current
procedure of checking for structural equ
On Nov 9, 2006, at 4:54 PM, Mike Stump wrote:
On Nov 8, 2006, at 7:14 AM, Ian Lance Taylor wrote:
The way to canonicalize them is to have all equivalent types point to
a single canonical type for the equivalence set. The comparison is
one memory dereference and one pointer comparison, not the
I compared the generated code with an equivalent explicit test,
and discovered that gcc uses a separate rtx for the intermediate:
i = 0xf;
if (j >= 16)
{
int i2;
i2 = i >> 8;
i = i2 >> 8;
j -= 16;
}
This seems to avoid the combiner problem, becuase you don't have the
same
On Thu, Nov 09, 2006 at 04:54:23PM -0800, Mike Stump wrote:
> Once not equal addresses might mean equal types, you have to do a
> structure walk to compare types, and you're right back were we
> started.
Not quite. A structure walk is required to be certain of equality,
but if inequality is t
On Nov 9, 2006, at 1:06 PM, Joern RENNECKE wrote:
I think in order to handle the C type system with the non-transitive
type compatibility effectively, for each type we have to pre-compute
the most general variant, even if that has no direct representative in
the current program.
The scheme you
Reminder: if you need access to x86 machines to run your boring
batches or to test your software with GCC snapshots with even
more boring batches, the GCC compile farm is for you:
http://gcc.gnu.org/wiki/CompileFarm
<<
GCC Compile Farm Project
The GCC CompileFarm Project is seeking volunteers to
On Nov 8, 2006, at 5:11 AM, Richard Kenner wrote:
My confusion here is how can you "canonicalize" types that are
different
(meaning have different names) without messing up debug information.
If you have:
Foo xyz;
typedef int Foo;
TREE_TYPE (xyz) == int
map(int, &TREE_TYPE (xyz))
On Nov 9, 2006, at 5:00 PM, Dale Johannesen wrote:
On Nov 9, 2006, at 4:54 PM, Mike Stump wrote:
else if (p1->ptr_equality_suffices_for_this_type || p2-
>ptr_equality_suffices_for_this_type)
not equal
else
tree walk
For trivial things, those things that are fast anyw
On Nov 9, 2006, at 5:11 PM, Joe Buck wrote:
On Thu, Nov 09, 2006 at 04:54:23PM -0800, Mike Stump wrote:
Once not equal addresses might mean equal types, you have to do a
structure walk to compare types, and you're right back were we
started.
Not quite.
Ah, you're right, thanks for spotting t
On Thu, 2006-11-09 at 12:32 -0800, Mark Mitchell wrote:
> 1. Add a --lto option to collect2. When collect2 sees this option,
> treat all .o files as if they were .rpo files and recompile them. We
> will do this after all C++ template instantiation has been done, since
> we want to optimize the .o
Andrew Pinski wrote:
> On Thu, 2006-11-09 at 12:32 -0800, Mark Mitchell wrote:
>> 1. Add a --lto option to collect2. When collect2 sees this option,
>> treat all .o files as if they were .rpo files and recompile them. We
>> will do this after all C++ template instantiation has been done, since
>>
Ian Lance Taylor wrote:
> Mark Mitchell <[EMAIL PROTECTED]> writes:
>
>> 1. Add a --lto option to collect2. When collect2 sees this option,
>> treat all .o files as if they were .rpo files and recompile them. We
>> will do this after all C++ template instantiation has been done, since
>> we want
Thanks for the input and the questions
Did you examine:
long long l, k;
l = -k;
for correctness by itself? Was it valid or invalid?
Yes this is working.
[ read ahead for spoilers, I'd rather you pull this information out
of the dump and present it to us... ]
A quick glance at th
I am having some trouble with getting type names as declared by the user
in source. In particular if i have two functions:
void Function(int i);
void Function(char c);
when processing the parameters i get an INTEGER_TYPE node in the
parameter list for both function as expected, however
IDENTI
The function cp_parser_parameter_declaration_clause says that it returns
NULL if the parameters are (...). However, there is a line of code that
is:
/* Parse the parameter-declaration-list. */
parameters = cp_parser_parameter_declaration_list (parser, &is_error);
/* If a parse error occurre
Mark Mitchell <[EMAIL PROTECTED]> writes:
> > I assume that in the long run, the gcc driver with --lto will invoke
> > the LTO frontend rather than collect2. And that the LTO frontend will
> > then open all the .o files which it is passed.
>
> Either that, or, at least, collect2 will invoke LTO
"Mohamed Shafi" <[EMAIL PROTECTED]> writes:
> and one more thing. In the dumps i noticed that before using a
> register in DI mode they are all clobbred first, like
>
> (insn 30 54 28 6 (clobber (reg:DI 34)) -1 (nil)
> (nil))
>
> What is the use of this insns ... Why do we need to clobber th
Mike Stump <[EMAIL PROTECTED]> writes:
> On Nov 8, 2006, at 7:14 AM, Ian Lance Taylor wrote:
> > The way to canonicalize them is to have all equivalent types point to
> > a single canonical type for the equivalence set. The comparison is
> > one memory dereference and one pointer comparison, not
DJ Delorie <[EMAIL PROTECTED]> writes:
> I compared the generated code with an equivalent explicit test,
> and discovered that gcc uses a separate rtx for the intermediate:
>
> i = 0xf;
> if (j >= 16)
> {
> int i2;
> i2 = i >> 8;
> i = i2 >> 8;
> j -= 16;
> }
>
> This see
The Fortran front end currently has a lang.opt entry of the following form:
ffixed-line-length-
Fortran RejectNegative Joined UInteger
I would like to add to this the following option which differs in the
last character, but should be treated identically:
ffixed-line-length=
Fortran R
Ian Lance Taylor wrote:
> Mark Mitchell <[EMAIL PROTECTED]> writes:
>
>>> I assume that in the long run, the gcc driver with --lto will invoke
>>> the LTO frontend rather than collect2. And that the LTO frontend will
>>> then open all the .o files which it is passed.
>> Either that, or, at least,
35 matches
Mail list logo
