2007/2/22, Christian Joensson <[EMAIL PROTECTED]>:
well, I ended up reinstalling gmp, libgmp-devel, libgmp3, mpfr,
libmpfr-devel, libmpfr0 (which I don't think is nessecary) and
libmpfr1.
now, its testsuite is being run
thanks brian and brooks for you help.
here's the test results
http://gc
Markus Franke wrote:
---snip---
Processing file 2120-2.c
2120-2.c: In function 'foo':
2120-2.c:13: error: unrecognizable insn:
(call_insn 14 13 15 1 (parallel [
(set:SI (reg:SI 1 r1)
(call (mem:QI (symbol_ref:SI ("odd") [flags 0x3]
) [0 S1 A8])
Hi,
I am currently on a mingw32 port for x86_64. It is operatable and I am
allready able to generate the crt-stuff and have some needed
import-libraries.
Executables are linkable and executeable, but wildcard methods are leading
to wrong execution, as found out.
I detected, that the MS-ABI does
i am trying to build gcc-3.4.6
for that i untar gcc-ada-3.4.6 and gcc-core-3.4.6 in directory "/source"
and my build directory is not subdirectory of source directory
i got error like this:-
gcc -c -g -O2 -gnatpg -gnata -I- -I. -Iada
-I../../source/gcc-3.4.6/gcc/ada
../../source/gcc-3.4.6/g
Here is the comparison of 4.1 branch and 4.2 branch. In brief, 4.2
has 0.47% better performance in SPECInt2000 and 2.2% better
performance in SPECFP2000.
As I remeber this increase in SPECFP performance is as mostly from
implementation of Itanium speculation support for scheduling by ISP
RAS (m
"Rohit Arul Raj" <[EMAIL PROTECTED]> writes:
> I am adding floating point support to GCC 4.1.1 for a private target.
>
> My machine can issue
> (1) Two instructions, [one integer insns (16 bit) + one floating point
> insn (16 bit) ]or
> (2) one 32 bit integer insn.
>
> For case (1) , Since both
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
> 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:
>
> i
> > 1. Is there a way to check for dependency b/w this two instructions.
> > 2. Any existing backend that has this type of design.
>
> gcc currently does a relatively crummy job of handling this type of
> VLIW architecture. You can describe the dependencies in the
> scheduler, but the scheduler wo
Paul Brook <[EMAIL PROTECTED]> writes:
> > > 1. Is there a way to check for dependency b/w this two instructions.
> > > 2. Any existing backend that has this type of design.
> >
> > gcc currently does a relatively crummy job of handling this type of
> > VLIW architecture. You can describe the dep
Vladimir N. Makarov wrote:
> Here is the comparison of 4.1 branch and 4.2 branch. In brief, 4.2
> has 0.47% better performance in SPECInt2000 and 2.2% better
> performance in SPECFP2000.
Thanks!
I assume that is with the aliasing safety patches turned on, i.e.,
current state of the 4.2 branch?
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
Mark Mitchell wrote:
Vladimir N. Makarov wrote:
Here is the comparison of 4.1 branch and 4.2 branch. In brief, 4.2
has 0.47% better performance in SPECInt2000 and 2.2% better
performance in SPECFP2000.
Thanks!
I assume that is with the aliasing safety patches turned on, i.e.,
curren
Kai Tietz writes:
>I detected, that the MS-ABI does not support SSE or MMX argument passing
>(as gcc does for x86_64). Therefore I search some advice about the
>enforcement of passing (sse,mmx) registers passing via the standard
>integer registers (for MS they are ecx,edx,r9) and via stack.
I t
On Thu, Feb 22, 2007 at 11:10:09AM +0100, Markus Franke wrote:
> ;; calls that return int in r1
> ;;
> (define_insn "call_val_internal_return_r1"
> [(parallel [(set (reg:SI 1)
> (call (match_operand:QI 0 "sym_ref_mem_operand" "")
Why would you have a specific pattern for (reg:SI
On Thu, Feb 22, 2007 at 05:03:21PM -0800, Ian Lance Taylor wrote:
> > > It is to improve performance of string functions on larger chunks of
> > > data. x86-64 specify this, for x86 it is optional. I don't think we
> > > should end up warning here - it is done only for static variables where
> >
On Fri, Feb 23, 2007 at 07:00:01AM -0800, Ian Lance Taylor wrote:
> gcc currently does a relatively crummy job of handling this type of
> VLIW architecture. You can describe the dependencies in the
> scheduler, but the scheduler won't insert any required nops for you.
> The usual approach is walk
> I thought BIGGEST_ALIGNMENT was the largest alignment that the
> processor ever requires for any data type. Which is not the
> same thing, since this is alignment desired for performance.
Since varasm complains when alignment exceeds MAX_OFILE_ALIGNMENT, and
MAX_OFILE_ALIGNMENT defaults to BIG
On Fri, Feb 23, 2007 at 01:42:42PM -0500, DJ Delorie wrote:
> I like the "min (256, MAX_OFILE_ALIGNMENT)" fix...
So do I.
> Note that elfos.h defines MAX_OFILE_ALIGNMENT so big that it is
> effectively unlimited, so no elf target would ever trip over these
> types of bugs.
Yep.
r~
I've been trying to keep the GCC_4.3_Release_Planning wiki page up to
date, and I'd like to be sure I haven't missed anything going in. I've
moved several projects to the Completed section, and if I've done
anything in error there, please correct it.
So here's a survey of what's left:
* Autovec
On Fri, 23 Feb 2007, Matthew Wilcox wrote:
> The projects I think are completed:
>
> * TreeRepresentationChanges (2007-02-15)
Only partly completed. The CALL_EXPR changes have been merged but the
TYPE_ARG_TYPES ones haven't yet.
(There are many smaller such changes on the LTO branch as well t
See http://msdn2.microsoft.com/en-us/library/ms235286(VS.80).aspx.
HTH
--
___
Evandro Menezes AMDAustin, TX
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of Kai Tietz
Hi,
For easy testing I installed 8 GCC releases with all languages including
Ada on the Compile Farm machines:
* /n/b01/guerby/release/X.Y.Z/bin with X.Y.Z in 3.4.6, 4.0.0-4, 4.1.0-2
has the official GCC X.Y.Z release installed with all languages compiled
in, including Ada.
If you wish to get an
> > I like the "min (256, MAX_OFILE_ALIGNMENT)" fix...
>
> So do I.
Ok to apply then? Tested via djgpp cross-compile and cross-host.
* config/i386/i386.c (ix86_data_alignment): Don't specify an
alignment bigger than the object file can handle.
Index: i386.c
===
>
> > > I like the "min (256, MAX_OFILE_ALIGNMENT)" fix...
> >
> > So do I.
>
> Ok to apply then? Tested via djgpp cross-compile and cross-host.
Yes, this is OK. (to be very pedantic, we can assert that
MAX_OFILE_ALIGNMENT>=256 on x86-64 targets, but well). I fully agree with
Richard's interpr
> >
> > > > I like the "min (256, MAX_OFILE_ALIGNMENT)" fix...
> > >
> > > So do I.
> >
> > Ok to apply then? Tested via djgpp cross-compile and cross-host.
>
> Yes, this is OK. (to be very pedantic, we can assert that
> MAX_OFILE_ALIGNMENT>=256 on x86-64 targets, but well). I fully agree with
On Feb 23, 2007, at 1:46 PM, Jan Hubicka wrote:
One extra bit - we do use alignments of base > 32 bytes for code
alignment. What would be the behaviour on targets with
MAX_OFILE_ALIGNMENT set to 16 bytes?
min (MAX_OFILE_ALIGNMENT, 32) of course.
I.e. if we end up with gas producing many nops
Snapshot gcc-4.3-20070223 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20070223/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.3 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk
> The assembler should produce a hard error if one asks it for an
> alignment that can't be satisfied.
The djgpp assembler quietly ignores such requests (not intentional);
the object file just stops at 2**4. I only noticed the bug because
gcc itself complains, and with -Werror (as djgpp and bi
> Yes, this is OK.
Thanks, applied.
> (to be very pedantic, we can assert that MAX_OFILE_ALIGNMENT>=256 on
> x86-64 targets, but well).
My head hurts at the thought of x86_64-aout.
> I fully agree with Richard's interpretation concerning
> BIGGEST_ALIGNMENT meaning - ie in special cases for pe
I am targeting GCC 4.1.1 to a custom RISC processor; which has some vector
instructions (32 bit vectors). It can perform two 16 bit/ or four 8 bit
additions, subtractions, multiplications & shift operations simultaneously.
I would like to use the Auto-Vectorizing capability to generate these
instr
On Fri, Feb 23, 2007 at 06:19:28PM -0500, DJ Delorie wrote:
> Something like this, then?
Sure.
r~
On Fri, Feb 23, 2007 at 04:13:39PM -0800, sdutta wrote:
> I am targeting GCC 4.1.1 to a custom RISC processor; which has some vector
> instructions (32 bit vectors). It can perform two 16 bit/ or four 8 bit
> additions, subtractions, multiplications & shift operations simultaneously.
>
> I would l
On Fri, Feb 23, 2007 at 11:09:29AM -0500, Vladimir N. Makarov wrote:
> Yes, that is the current state of 4.1 and 4.2 branches (as of
> yesterday). I don't think we will see a change with the reverted
> alaising patches for itanium because conservative aliasing most probably
> will be compensate
> 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 type of t, you just created an invalid value!
Yes, but why n
Joe Buck wrote:
Perhaps I'm missing something obvious, but often conservative aliasing
results in reading lots of extra data from memory. How can speculation
compensate for that? It seems that the best you can do is reduce the
penalty, if you can do something in parallel with the extra I/O.
Y
> > Something like this, then?
>
> Sure.
Committed, then.
> I thought BIGGEST_ALIGNMENT was the largest alignment that the
> processor ever requires for any data type.
That's my understanding of what it was originally *supposed* to be,
though it wouldn't surprise me all that much if it were used in subtly
different ways in some places.
Joe Buck <[EMAIL PROTECTED]> writes:
> On Fri, Feb 23, 2007 at 11:09:29AM -0500, Vladimir N. Makarov wrote:
> > Yes, that is the current state of 4.1 and 4.2 branches (as of
> > yesterday). I don't think we will see a change with the reverted
> > alaising patches for itanium because conservativ
39 matches
Mail list logo
