Hi All,
BACKGROUND:
Downloaded the source code of the Xemics CoolRISC gcc port from Raisonance's
website (ftp://www.raisonance.com/pub/CoolRISC/cool3_2.zip). I
concluded that the port is based in gcc 3.2 from looking at the NEWS
file in the gcc folder.
I what to bring to this gcc port up to the l
Snapshot gcc-4.1-20080512 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20080512/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.1 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
Status
==
GCC 4.2.4-rc1 is now available from
<ftp://gcc.gnu.org/pub/gcc/snapshots/4.2.4-RC-20080512/>. All commits
to the GCC 4.2 branch need to be approved by a release manager until
GCC 4.2.4 is released. All fixes going on that branch should first
have gone on trunk and 4.3 branch
FX wrote:
Here is my report on Fortran benchmarking. I compare the trunk dated
20080507 (no revision number, sorry) and the IRA branch rev. 135035. I
run the Polyhedron benchmark
(http://www.polyhedron.co.uk/polyhedron_benchmark_suite0html) which is
probably the most widely used benchmark in the
David Edelsohn wrote:
FX writes:
FX> The performance regression is mainly due to one testcase, induct,
FX> which is taking a 30% hit on IRA. If the performance of that one were
FX> the same with IRA than with the old allocator, the switch would be
FX> (for this benchmark) performa
Ian,
Sounds great, thanks, I'll work with Chad to get the vul note updated
accordingly.
rCs
"Robert C. Seacord" <[EMAIL PROTECTED]> writes:
Once a new version or patch is available that will warn users that
this optimization is taking place, I will recommend that we change the
work aro
There were a couple of fixes needed due to the SFT removal.
Bootstrapped and tested on x86_64.
2008-05-12 Diego Novillo <[EMAIL PROTECTED]>
Mainline merge @135136
* configure.ac (ACX_PKGVERSION): Update revision merge string.
* configure: Regenerate.
2008-05-12 Diego
This merge brought quite a few conflicts because of recent changes in
trunk to SFTs and other middle-end changes.
Bootstrapped and tested x86_64.
Diego.
"Robert C. Seacord" <[EMAIL PROTECTED]> writes:
> Once a new version or patch is available that will warn users that
> this optimization is taking place, I will recommend that we change the
> work around from "Avoid newer versions of gcc" to "Avoid effected
> versions of gcc" and/or recommend that
> If it doesn't today, then there's no tests covering the problems.
It does if you have a 64-bit HOST_WIDE_INT on your 32-bit host and this is now
enforced for most 64-bit targets.
--
Eric Botcazou
On Mon, May 12, 2008 at 12:11:26PM -0400, Richard Kenner wrote:
> > Yes, but for example when cross-compiling from a 32bit host to a 64bit
> > target
>
> ... which is something that's always never worked completey properly ...
If it doesn't today, then there's no tests covering the problems.
Cod
Diego Novillo wrote:
The tuples branch is at the point now that it should bootstrap all
primary languages and targets. There are things that are still broken
and being worked on (http://gcc.gnu.org/wiki/tuples), but by and large
things should Just Work.
I expect things like code generation
> Yes, but for example when cross-compiling from a 32bit host to a 64bit target
... which is something that's always never worked completey properly ...
> Does this mean that if the sizetype is 32bit then bitsizetype is 64bit?
Yes.
On Mon, May 12, 2008 at 3:24 PM, Richard Kenner
<[EMAIL PROTECTED]> wrote:
> > I gues you'll get funny effects then, as for Nbit sizetype there's
> > usually no valid mode for (N+8)bit bitsizetype. In fact, I believe
> > bitsizetype simply "inherits" the mode from sizetype.
>
> No. We pick the
> FX writes:
FX> The performance regression is mainly due to one testcase, induct,
FX> which is taking a 30% hit on IRA. If the performance of that one were
FX> the same with IRA than with the old allocator, the switch would be
FX> (for this benchmark) performance-neutral. So, I have investig
Here is my report on Fortran benchmarking. I compare the trunk dated
20080507 (no revision number, sorry) and the IRA branch rev. 135035. I
run the Polyhedron benchmark
(http://www.polyhedron.co.uk/polyhedron_benchmark_suite0html) which is
probably the most widely used benchmark in the Fortran comm
On Mon, May 12, 2008 at 6:54 PM, Richard Kenner
<[EMAIL PROTECTED]> wrote:
>> I gues you'll get funny effects then, as for Nbit sizetype there's
>> usually no valid mode for (N+8)bit bitsizetype. In fact, I believe
>> bitsizetype simply "inherits" the mode from sizetype.
>
> No. We pick the mode
> I gues you'll get funny effects then, as for Nbit sizetype there's
> usually no valid mode for (N+8)bit bitsizetype. In fact, I believe
> bitsizetype simply "inherits" the mode from sizetype.
No. We pick the mode that's *at least* 3 bits wider than sizetype, so
it's usually the next larger int
On Mon, May 12, 2008 at 1:26 PM, Richard Kenner
<[EMAIL PROTECTED]> wrote:
> > bitsizetype is a type that can hold any values of sizetype *
> > BITS_PER_UNIT so we can safely do bit-size calculations without overflow.
> > This type shouldn't end up used in code though.
>
> Unfortunately, it does
> bitsizetype is a type that can hold any values of sizetype *
> BITS_PER_UNIT so we can safely do bit-size calculations without overflow.
> This type shouldn't end up used in code though.
Unfortunately, it does, though not in C. Ada's 'Size attribute returns
the size in bits, so the proper type
Paolo Bonzini wrote:
>
>> I'd like to implement something similar for MaverickCrunch, using the
>> integer 32-bit MAC functions, but there is no reciprocal estimate
>> function on the MaverickCrunch. I guess a lookup table could be
>> implemented, but how many entries will need to be generated, a
Till Straumann wrote:
> What is the proper way to tell gcc that a
> inline assembly statement either modifies
> a particular area of memory or needs it
> to be updated/in-sync because the assembly
> reads from it.
>
> E.g., assume I have a
>
> struct blah {
>int sum;
> ...
> };
>
> which i
On Mon, May 12, 2008 at 11:58 AM, Mohamed Shafi <[EMAIL PROTECTED]> wrote:
> Hello all,
>
> During debugging in gimple dumps i found a term that is used along
> with other data types - bit_size_type.
>
> I am getting ICEs when size of int is 32 bit and no errors when the
> size of int is 16. Th
Hello all,
During debugging in gimple dumps i found a term that is used along
with other data types - bit_size_type.
I am getting ICEs when size of int is 32 bit and no errors when the
size of int is 16. This is for a back-end whose native size is 16bit.
Is this any internal data type used to fo
> What is the proper way to tell gcc that a inline assembly statement either
> modifies
> a particular area of memory or needs it to be updated/in-sync because the
> assembly
> reads from it.
Maybe also related to:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32642
i.e. "=m" works for variables
26 matches
Mail list logo
