> It seems according to http://gcc.gnu.org/install/prerequisites.html that the
> minimal version of bison required in GCC (for those hacking the few .y
> files) is 1.28 (released in july 1999).
>
> Is there a reason why a 2.x version of bison would not be acceptable? FWIW,
> I am not considering u
The 4.1 branch is now open for changes under the usual regression-only
rules for release branches.
Here are the changes that I commited during the release process.
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
2007-02-14 Mark Mitchell <[EMAIL PROTECTED]>
* DEV
Kaveh R. GHAZI wrote:
> 2007-02-13 Kaveh R. Ghazi <[EMAIL PROTECTED]>
>
> * g++.dg/tree-ssa/nothrow-1.C: Skip test if -fpic/-fPIC is used.
>
> diff -rup orig/egcc-SVN20070211/gcc/testsuite/g++.dg/tree-ssa/nothrow-1.C
> egcc-SVN20070211/gcc/testsuite/g++.dg/tree-ssa/nothrow-1.C
> --- ori
>
> Andrew Pinski wrote:
> >> In http://gcc.gnu.org/gcc-4.3/changes.html appears
> >>
> >> "Support for SSSE3 built-in functions and code generation are available
> >> via |-mssse3|."
> >>
> >> Is it SSE3 (i686 SIMD) or SSSE3 (strange, unknown)?
> >> Is it -mssse3 or -msse3?
> >
> > -mssse3 is S
On Wed, Feb 14, 2007 at 11:41:48PM +0100, J.C. noticed that there
is a tarball with an interesting name on gcc.gnu.org.
The actual announcement is always delayed by 24 hours or so to allow time
for all of the mirrors around the world to pick it up.
This should not be a surprise, given that there
Andrew Pinski wrote:
In http://gcc.gnu.org/gcc-4.3/changes.html appears
"Support for SSSE3 built-in functions and code generation are available
via |-mssse3|."
Is it SSE3 (i686 SIMD) or SSSE3 (strange, unknown)?
Is it -mssse3 or -msse3?
-mssse3 is S-SSE3 which was added for code dual 2.
Yes
Then it's filed as PR 30801.
FX
>
> In http://gcc.gnu.org/gcc-4.3/changes.html appears
>
> "Support for SSSE3 built-in functions and code generation are available
> via |-mssse3|."
>
> Is it SSE3 (i686 SIMD) or SSSE3 (strange, unknown)?
> Is it -mssse3 or -msse3?
-mssse3 is S-SSE3 which was added for code dual 2.
Yes the opt
In http://gcc.gnu.org/gcc-4.3/changes.html appears
"Support for SSSE3 built-in functions and code generation are available
via |-mssse3|."
Is it SSE3 (i686 SIMD) or SSSE3 (strange, unknown)?
Is it -mssse3 or -msse3?
Note: -msse3 appears in the GCC-3.3.6's info! Is this option -msse3 new
in G
Snapshot gcc-4.2-20070214 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20070214/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.2 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
ftp://gcc.gnu.org/pub/gcc/releases/gcc-4.1.2/
Good bye people ;)
Christophe LYON <[EMAIL PROTECTED]> writes:
> What is the difference between the [bounds-checking and mudflap]
> systems?
Mudflap is a tree-level rewriting pass amidst the optimizers that
limits its attention to pointer dereference and addressable object
lifetime events. It's upstream, having be
>
> Hi Rask,
>
> Basically the CPU has the 'SCALE_28_4' instruction which does the following:
> output = (operand1 >> 28) | (operand2 << 4)
Isn't that a rotate? if so you can use either rotate or rotatert instead.
Thanks,
Andrew Pinski
Hi Rask,
Basically the CPU has the 'SCALE_28_4' instruction which does the following:
output = (operand1 >> 28) | (operand2 << 4)
From my understanding the OR operation (ior), doesn't get canonicalized
since it's second operand (in this case (lshiftrt:SI (match_operand:SI 2
"register_operand"
On Wed, Feb 14, 2007 at 05:31:36PM +, Sami Khawam wrote:
> (define_insn "scale_28_4"
> [(set (match_operand:SI 0 "register_operand" "=r")
> (ior:SI
> (ashift:SI (match_operand:SI 1 "register_operand" "r")
> (const_int 28 ))
> (lshiftrt:SI (match_operand:SI 2 "register_operand" "r
Hi,
I try to introduce a new intrinsic in gcc's back-end, for the alpha
machines. In doing that, I referenced to the implementaions of altivec
intrinsics for the PowerPC. In the mean time I noticed that the
gcc-4.0 and gcc-4.1 implements these in different way which confused
me. The difference is
Hi,
Although I have been porting and using gcc for quite a while now, I am
still a newbie at the internals and would be grateful if you can help me.
I have designed a CPU architecture where most of the instructions only
accept data operands as registers and no immediate values are allowed,
w
> Some of the combine simplifications (you obviously know that) work by
> "hoping" that the CLOBBER is simplified away. I don't think you can
> preserve all their power if you propagate NULL. In most cases you can
> replace CLOBBER with NULL, but I don't think that's possible everywhere.
Yeah
On 14/02/07, Andreas Schwab <[EMAIL PROTECTED]> wrote:
Tobias Pflug <[EMAIL PROTECTED]> writes:
> That's not desirable is it ?
If you are concerned, you are free to use -Wreturn-type. There are many
types of undefined behaviour that are not warned by default.
And Wreturn-type is enabled by
Hi all,
I was somewhat used to the bounds-checking patches for GCC 3.x from
Herman ten Brugge.
Now that GCC-4.x ships with mudflap, I am a bit confused, since the
bounds-checking patches also exist at least for until GCC-4.0.2.
What is the difference between the two systems?
Thanks,
Chris
H. J. Lu wrote on 02/14/07 09:22:
Is this the saem as
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30735
No, it isn't.
Tobias Pflug <[EMAIL PROTECTED]> writes:
> That's not desirable is it ?
If you are concerned, you are free to use -Wreturn-type. There are many
types of undefined behaviour that are not warned by default.
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfe
Richard Kenner wrote:
Yes, one possibility is to use a RTX hook for this too. By default you
would return NULL (and this would propagate up); in combine you could
override it to return the CLOBBER.
I really don't see why. Look at when combine calls the simplify routines now.
If they return z
Andreas Schwab wrote:
Tobias Pflug <[EMAIL PROTECTED]> writes:
This will compile just fine. When compiled with -Wall it will at least
bring up a warning about the missing return statement in foo(), nothing
about main tho either. Or is there some standard that implicitly declares
main to return
> Yes, one possibility is to use a RTX hook for this too. By default you
> would return NULL (and this would propagate up); in combine you could
> override it to return the CLOBBER.
I really don't see why. Look at when combine calls the simplify routines now.
If they return zero, it uses the o
Tobias Pflug <[EMAIL PROTECTED]> writes:
> This will compile just fine. When compiled with -Wall it will at least
> bring up a warning about the missing return statement in foo(), nothing
> about main tho either. Or is there some standard that implicitly declares
> main to return 0 when there is n
[trimming down the Cc list]
1) what to do with (clobber (const_int 0)). This should be not so much
of a problem thanks to validate_change, but I'd be weary of having such
CLOBBER rtx-en in REG_EQUAL notes!
Just return NULL. The philosophy of simplify_rtx is different from combine.
In the fo
Hello,
It seems according to http://gcc.gnu.org/install/prerequisites.html that the
minimal version of bison required in GCC (for those hacking the few .y
files) is 1.28 (released in july 1999).
Is there a reason why a 2.x version of bison would not be acceptable? FWIW,
I am not considering usin
> Actually, simplify-rtx.c now uses nonzero_bits and num_sign_bit_copies:
> these ask combine for the value in the case of pseudos, via the "RTL
> hooks" mechanism.
Right. That was certainly a step (and was discussed a while ago), but doing
it more globally would make it even easier.
> 1) what
On Tue, Feb 13, 2007 at 06:21:41PM -0800, Ian Lance Taylor wrote:
> Should __attribute__ ((gnu_inline)) be treated the same as a gnu89
> extern inline definition? Or should the extern part be optional?
> That is, should there be a difference between these two definitions?
>
> extern __attribute
On Wed, Feb 14, 2007 at 02:34:24PM +0100, Paweł Sikora wrote:
> François-Xavier Coudert napisał(a):
>
> >$ gcc -march=pentium4 -O3 a.c && time ./a.out
> >064069fbc13963b920219c3e939225e38e38e38e3956d81c71c71c71c0ba0f00
> >./a.out 1.81s user 0.00s system 99% cpu 1.818 total
> >$ gcc-4.3 -march=pen
Hi,
I was lately having some issues with a cross platform project where
the code compiled fine with gcc and didn't under vc++. Turned out it had
to do with me forgetting a return statement in an int function.
I find it kind of weird that such misbehavior won't even reported as Warning
unless you
On Tue, 13 Feb 2007, Mark Mitchell wrote:
> Kaveh R. GHAZI wrote:
>
> > What I need to work out is what combinations of target and flags this
> > problem occurs under. E.g. is this problem sparc-solaris only or does it
> > occur on any target using pic? Or is it some subset of all platforms?
> >
François-Xavier Coudert napisał(a):
$ gcc -march=pentium4 -O3 a.c && time ./a.out
064069fbc13963b920219c3e939225e38e38e38e3956d81c71c71c71c0ba0f00
./a.out 1.81s user 0.00s system 99% cpu 1.818 total
$ gcc-4.3 -march=pentium4 -O3 a.c && time ./a.out
064069fbc13963b920219c3e939225e38e38e38e3956d8
Well before GCC 4.x there was an attempt that a few of us worked on to try to
move the algebraic simplifications from combine to simplify-rtx.c, just like
we put tree folding in fold-const.c. At that point, combine just becomes
"bookkeeping". The problem with that approach was what to do with
I noticed a performance regression on the following code:
$ cat a.c
#include
#include
void
add256 (uint64_t x[4], const uint64_t y[4])
{
unsigned char carry;
x[0] += y[0];
carry = (x[0] < y[0]);
x[1] += y[1]+carry;
carry = carry ? (x[1] <= y[1]) : (x[1] < y[1]);
x[2] += y[2]+carry;
carr
> Combiner is an older approach of code selection.
Combine can be considered both as code selection or optimization. Likewise,
CSE. In many cases, especially now that we have the tree optimizers, CSE
does more code selection (best choice of operand) than CSE. So you could say
that CSE and Com
Sir/Madam
I seek help from designers, developers, testers,defect fixers,project
managers or playing any other key role in Free/Open Source software
development or maintenence
in carrying out a study to identify practices and problems of defect
management in various Free/Open Source Software pr
38 matches
Mail list logo
