Has anyone tried SPEC CPU 2006 with gcc mainline and 4.1 branch?
Currently, there is at least one regression affecting SPEC CPU 2006:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28908
I was wondering if anyone had run into problems with gcc. I need 3
patches for SPEC CPU 2006 to support gcc on Li
mathieu lacage wrote:
I have spent a considerable amount of time looking at the abbrev tables
output by gcc are not totally random: their entries are sorted by their
abbrev code. That is, the abbrev code of entry i+1 is higher than that
of entry i.
That's an interesting observation. Essential
On Fri, Sep 01, 2006 at 07:42:08AM +0900, Mikiya Matsuzaka wrote:
>`(const:M EXP)'
> Represents a constant that is the result of an assembly-time
> arithmetic computation. The operand, EXP, is an expression that
> contains only constants (`const_int', `symbol_ref' and `
I found this description in GCC Internals info file.
11.7 Constant Expression Types
==
...
`(const:M EXP)'
Represents a constant that is the result of an assembly-time
Snapshot gcc-4.0-20060831 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.0-20060831/
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
Sorry I didn't reply to this earlier. I was unexpectedly in a place with
very bad network access.
> The one exception to this is if the address of the temp is taken before
> I call pop_temp_slots. In that instance, even though I may be "done"
> with the temp, it needs to live until the end of th
On Thu, Aug 31, 2006 at 05:52:16PM -0400, Miguel Angel Champin Catalan wrote:
> We ask you for a simple explanation (if it's possible) about our
> warning, telling that "gets" is not too dangerous, because in our case,
> works perfectly, under some restrictions obviously.
Really a gcc-help topic
>
> Hello:
>
> We are students of computer sciences in the Santa Maria University,
> Chile. We just want to know if the function "gets" it's too dangerous
> for a warning. The fact is that our teacher's assistant give us a
> homework, and one restriction was to use gcc to compile our code,
>
Hello:
We are students of computer sciences in the Santa Maria University,
Chile. We just want to know if the function "gets" it's too dangerous
for a warning. The fact is that our teacher's assistant give us a
homework, and one restriction was to use gcc to compile our code,
without warnings
Geoff,
What happened to regress to allow it to suddenly do make checks
at every svn revision? I assume it isn't a measly G4 anymore (grin).
If you have that many clock cycles to do builds and make checks
every revision how about adding in -m64 make checks now?
Jack
Hello,
> >is there the data reference for it in the datarefs array?
> >
> >Zdenek
> >
>
> Using this code after the construction of the data dependance :
>
>
> datarefs = VEC_alloc (data_reference_p, heap, 10);
> dependence_relations = VEC_alloc (ddr_p, heap, 10 * 10);
> compu
is there the data reference for it in the datarefs array?
Zdenek
Using this code after the construction of the data dependance :
datarefs = VEC_alloc (data_reference_p, heap, 10);
dependence_relations = VEC_alloc (ddr_p, heap, 10 * 10);
compute_data_dependences_for_loop (lo
Brad,
If you google "dyld: Symbol not found: ___dso_handle", you'll
come up with the following messages...
http://gcc.gnu.org/ml/gcc/2006-03/msg00712.html
http://gcc.gnu.org/ml/gcc/2006-03/msg00718.html
http://gcc.gnu.org/ml/gcc/2006-03/msg00735.html
So it certainly sounds like your cctools i
Daniel Jacobowitz wrote:
On Thu, Aug 31, 2006 at 09:24:20AM -0700, Mark Mitchell wrote:
Here, we won't be making syscalls
Yes, you almost certainly will.
OK, good point.
In any case, my concern is that we're worrying a lot about on-disk
encoding, but that there are lots of other hard probl
Mark Mitchell wrote:
> Kenneth Zadeck wrote:
>
>> I am not so concerned with running out of virtual address space than I
>> am about being able to break this up so that it can be done in parallel,
>> on a farm of machines. Otherwise, lto can never be part of anyone's
>> compile/test loop.
>
> I t
Hello,
> >what you do seems basically OK to me. The problem is that you also need
> >to fix the ssa form for the virtual operands of the added calls
> >(i.e., you must call mark_new_vars_to_rename for each of the calls,
> >and update_ssa once at the end of tree_handle_loop).
> >
> >Zdenek
> >
>
Is there anyone out there who might have a SPARC environment with Ada
support who could run the attached Ada testcase on a version of gcc
patched with the attached patch? I'd like to verify whether the test
behaves correctly when compiled at -O0, -O1, and -O2. The expected
(correct) behavior is t
Kenneth Zadeck wrote:
I am not so concerned with running out of virtual address space than I
am about being able to break this up so that it can be done in parallel,
on a farm of machines. Otherwise, lto can never be part of anyone's
compile/test loop.
I think we just expanded the scope of w
On Thu, Aug 31, 2006 at 09:24:20AM -0700, Mark Mitchell wrote:
> Here, we won't be making syscalls
Yes, you almost certainly will. If you've got a thousand object files,
you probably don't want to keep them all opened all the time; there are
these pesky things like open file descriptor limits, fo
Daniel Berlin wrote:
On 8/31/06, Kenneth Zadeck <[EMAIL PROTECTED]> wrote:
Mark Mitchell wrote:
> Kenneth Zadeck wrote:
>
>> Even if we decide that we are going to process all of the functions in
>> one file at one time, we still have to have access to the functions
that
>> are going to be inl
On Tue, Aug 30, 2005 at 05:44:52PM -0700, Mike Stump wrote:
> 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.
[snip]
> M-x gr
Dear all,
Any idea why ? I've looked around in the code to see how they parse
the data dependance tree but I don't see a difference.
Interesting.
So what statements *are* in the list of data dependences if not these.
Ok apparently it's more a problem of optimization levels in O3 the
compiler
"kernel coder" <[EMAIL PROTECTED]> writes:
>Thanks for your explaination.I just figured out the
> problem.actually a pattern named "bgtu" was generated by gcc and in
> my backend ,i defined all branch patterns except bgtu.So when gcc
> tried to match "bgtu" pattern ,it could not find it and g
Brad,
You build system certainly has issues. Why don't you strip
down your .cshrc or .bashrc to a completely empty file, open
a new terminal session so none of the previous .cshrc settings
are in effect and rebuild gcc trunk. Also, I am assuming you
are running MacOS X 10.4 and have at least Xco
Any idea why ? I've looked around in the code to see how they parse
the data dependance tree but I don't see a difference.
Interesting.
So what statements *are* in the list of data dependences if not these.
As some few people might already know, the GGCC (globalgcc) project is
just starting (partly funded within the ITEA framework by french,
spanish, swedish public money) - its kick off meeting is next week in
Paris.
GGCC aims to provide a (GPL opensource) extension to GCC for program
wide static an
On Aug 30, 2006, at 9:55 PM, Jack Howarth wrote:
Try building
some of the g++ testcases manually and see what the errors
are.
Perhaps this is a problem:
grep 'Symbol not found' g++.log | sort | uniq -c
1254 dyld: Symbol not found: ___dso_handle
hi,
Thanks for your explaination.I just figured out the
problem.actually a pattern named "bgtu" was generated by gcc and in
my backend ,i defined all branch patterns except bgtu.So when gcc
tried to match "bgtu" pattern ,it could not find it and generated
above mentioned error.Now i have define
On 8/31/06, Kenneth Zadeck <[EMAIL PROTECTED]> wrote:
Mark Mitchell wrote:
> Kenneth Zadeck wrote:
>
>> Even if we decide that we are going to process all of the functions in
>> one file at one time, we still have to have access to the functions that
>> are going to be inlined into the function b
Christian Joensson writes:
> This is on a cygwin/winxp system... while building gcc trunk,
> currently, and for quite some time, I have been getting this warning:
>
> /usr/local/src/trunk/objdir/./gcc/xgcc
> -B/usr/local/src/trunk/objdir/./gcc/ -B/usr/local/i686-pc-cygwin/bin/
> -B/usr/local
last one, again on cygwin/winxp, I get an error:
../../../../../../gcc/libjava/classpath/native/fdlibm/mprec.c:105:
error: expected identifier or '(' before '{' token
hints?
--
Cheers,
/ChJ
again, on cygwin/winxp, I get an error
../../../../../../gcc/libjava/classpath/native/fdlibm/mprec.c:104:
error: static declaration of 'calloc' follows non-static declaration
am I doing something seriously wrong here?
--
Cheers,
/ChJ
This is on a cygwin/winxp system... while building gcc trunk,
currently, and for quite some time, I have been getting this warning:
/usr/local/src/trunk/objdir/./gcc/xgcc
-B/usr/local/src/trunk/objdir/./gcc/ -B/usr/local/i686-pc-cygwin/bin/
-B/usr/local/i686-pc-cygwin/lib/ -isystem
/usr/local/i68
Mark Mitchell wrote:
> Kenneth Zadeck wrote:
>
>> Even if we decide that we are going to process all of the functions in
>> one file at one time, we still have to have access to the functions that
>> are going to be inlined into the function being compiled. Getting at
>> those functions that are g
hi,
On Wed, 2006-08-30 at 16:44 -0500, Mark Mitchell wrote:
[snip]
> (Implied, but not stated, in your mail is the fact that the abbreviation
> table cannot be indexed directly. If it could be, then you wouldn't
> have to read the entire abbreviation table for each function; you would
> just
what you do seems basically OK to me. The problem is that you also need
to fix the ssa form for the virtual operands of the added calls
(i.e., you must call mark_new_vars_to_rename for each of the calls,
and update_ssa once at the end of tree_handle_loop).
Zdenek
Ok, by inserting the mark_new
36 matches
Mail list logo
