Quoting Jan Hubicka <[EMAIL PROTECTED]>:
> If you make FPCTR/MXCSR real registers, you will need to add use to all
> the arithmetic and move pattern that would consume quite some memory and
> confuse optimizers. I think you can get better around simply using volatile
> unspecs inserted by LCM pas
On Wed, 2005-05-25 at 23:46 +0200, Andreas Schwab wrote:
> Jeffrey A Law <[EMAIL PROTECTED]> writes:
>
> > So, if I wanted to be able to bootstrap Ada, what I do I need
> > to do? Disable VRP? Disable something in the loop optimizer?
> > Anything else?
>
> The patch from PR21029 (comment #6) is
> which is defined to correspond to some physical mode
Close. Defined to correspond to one or more physical modes.
> - Huh?, can you provide a single example of where a char type would
> be mapped by the target to two different target specified modes?
i386 can hold a char in %al (QImode) o
> From: DJ Delorie <[EMAIL PROTECTED]>
>> - ok, and how does it know that it needs a 32-bit unsigned scalar?
>
> tm.h: #define INT_TYPE_SIZE 32
>
> Combined with "unsigned int foo;" in the user's source file.
>
> The MI doesn't need to know that this fits in a QImode.
- agreed, all it needs to
Uros,
> > Actually, in many cases, SSE did help x86 performance as
> well. That
> > happens in FP-intensive applications which spend a lot of time in
> > loops when the XMM register set can be used more
> efficiently than the x87 stack.
>
> This code could be a perfect example how XMM reg
Vincent Lefevre wrote:
You may be interested in my web page "Linux and the Extended Precision
on x86 Processors":
http://www.vinc17.org/research/extended.en.html
Also, comments are welcome.
William Kahan seems to take the opposite viewpoint. See e.g.:
http://www.cs.berkeley.edu/~w
> - ok, and how does it know that it needs a 32-bit unsigned scalar?
tm.h: #define INT_TYPE_SIZE 32
Combined with "unsigned int foo;" in the user's source file.
The MI doesn't need to know that this fits in a QImode.
> the world is it desirable to go go in a big circle to identify
> which
Jeffrey A Law <[EMAIL PROTECTED]> writes:
> So, if I wanted to be able to bootstrap Ada, what I do I need
> to do? Disable VRP? Disable something in the loop optimizer?
> Anything else?
The patch from PR21029 (comment #6) is working for me.
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTE
On Wed, May 25, 2005 at 03:37:29PM -0600, Jeffrey A Law wrote:
> So, if I wanted to be able to bootstrap Ada, what I do I need
> to do? Disable VRP?
>
Applying the patches in the PRs I mentioned. If that doesn't
work, try with VRP disabled.
Diego.
On Wed, 2005-05-25 at 14:14 -0400, Diego Novillo wrote:
> On Wed, May 25, 2005 at 02:09:12PM -0400, Richard Kenner wrote:
> > I may be mistaken, but didn't GCC miscompile the Ada front end because
> > of this VRP bug here: http://gcc.gnu.org/PR21332 ?
> >
> > I'm not sure if that was it,
> First off, is anyone working on providing GCC or libm with a (complete)
> set of C99 math functions with SSE/SSE2 calling conventions? If not, I
> will start with something like the following plan:
>
> 1. There is already support for switching the ABI function-wise in
> the backend for loc
> Hello!
>
> > Well you really want both the fpcr and the mxcsr registers, since the fpcr
> > only controls the x87 and the mxcsr controls the xmm registers. Note, in
> > adding these registers, you are going to have to go through all of the
> > floating
> > point patterns to add (use:HI FPCR_RE
On Wed, May 25, 2005 at 09:26:29PM +0200, Richard Guenther wrote:
> 1. There is already support for switching the ABI function-wise in
> the backend for local static functions. As a first step I'd like
> to expose this functionality as a function attribute.
Sure.
> 3. Emit calls to alt
First off, is anyone working on providing GCC or libm with a (complete)
set of C99 math functions with SSE/SSE2 calling conventions? If not, I
will start with something like the following plan:
1. There is already support for switching the ABI function-wise in
the backend for local static fu
> From: DJ Delorie <[EMAIL PROTECTED]>
>
>> where then the target may declare class machine_mode
>> target_int_mode ("HI", 16),
>
> This is where we disagree. The *target* shouldn't map types to modes.
> The *MI* should map types to modes. The target just creates the modes
> it supports and
Zack Weinberg <[EMAIL PROTECTED]> wrote:
>>> This doesn't do what I want at all. The goal is to make the *symbolic
>>> enumeration constants* inaccessible to most code.
>>
> ...
>> If it's OK to have the enums in a header, provided you can't *use*
them...
>>
>> enum {
>> #ifdef TVQ_AUTHORITATIVE_
On Wed, May 25, 2005 at 02:09:12PM -0400, Richard Kenner wrote:
> I may be mistaken, but didn't GCC miscompile the Ada front end because
> of this VRP bug here: http://gcc.gnu.org/PR21332 ?
>
> I'm not sure if that was it, but there was a VRP item on my plate from a
> few weeks ago since
I may be mistaken, but didn't GCC miscompile the Ada front end because
of this VRP bug here: http://gcc.gnu.org/PR21332 ?
I'm not sure if that was it, but there was a VRP item on my plate from a
few weeks ago since I claimed that it was an Ada front-end bug and not
a VRP bug. Unfortunat
Hello Evandro!
x87 registers. In contrast, x86_64 ABI specifies that FP
values are passed in SSE registers, so they avoid costly SSE
reg->stack moves. Until i386 ABI (together with supporting
math functions) is changed to something similar to x86_64,
use of -mfpmath=sse won't show all its pow
And YES I have a port with multiple pointer sizes, and YES the
customer wanted both sizes supported in a single compilation unit
This is actually not that uncommon.
Oh, and sometimes gcc randomly uses pointer_mode instead of Pmode. I
haven't a clue why there's a difference, or h
On Wednesday 25 May 2005 16:22, chris jefferson wrote:
>
> On the other hand, in general using != and == on floating point numbers
> is always dangerous if you do not know all the consequences. For
> example, on your above program if I use 30.1 and 90.3, the program fails
> without -ffast-math.
>
Y
> where then the target may declare class machine_mode
> target_int_mode ("HI", 16),
This is where we disagree. The *target* shouldn't map types to modes.
The *MI* should map types to modes. The target just creates the modes
it supports and describes them. The MI looks them up by descripti
Hi, Uros.
> Due to outdated i386 ABI, where all FP parameters are
> passed on stack, SSE code does not show all its power when
> used. When math library function is called, SSE regs are
> pushed on stack and called math library function (that is
> currently implemented again with i387 insns) p
On 5/25/05, Graham Stott <[EMAIL PROTECTED]> wrote:
> Jeff,
>
> The last time I bootstrapped with Ada successfully on i686-pc-linux-gnu
> was around 9/10th May after that it hangs in stage3 so I've had it disabled
> since then.
>
> Maybe it's time once it back bootstraping to enable Ada by defaul
Jeff,
The last time I bootstrapped with Ada successfully on i686-pc-linux-gnu
was around 9/10th May after that it hangs in stage3 so I've had it disabled
since then.
Maybe it's time once it back bootstraping to enable Ada by default during
bootstraps.
Graham
On 2005-05-25 15:59:28 +0100, Dave Korn wrote:
> Original Message
> >From: chris jefferson
> >Sent: 25 May 2005 15:23
> > On the other hand, in general using != and == on floating point numbers
> > is always dangerous if you do not know all the consequences. For
> > example, on your above p
Steven Bosscher <[EMAIL PROTECTED]> writes:
> On Wednesday 25 May 2005 16:56, Jeffrey A Law wrote:
>> So when's the last time someone bootstrapped Ada with the mainline
>> sources on i686-pc-linux-gnu?
>>
>> I was trying to get it built to further exercise the ADDR_EXPR
>> status bit checking code
On Tue, 24 May 2005 17:32:27 -0700, Zack Weinberg <[EMAIL PROTECTED]> wrote:
> On Tue, 2005-05-24 at 20:11 -0400, Daniel Jacobowitz wrote:
>> If that's why you were confused by my response, I was not suggesting
>> freezing the ABI. I think it's an awful idea.
>
> Why? To be honest, I keep har
On 2005-05-25, Dave Korn <[EMAIL PROTECTED]> wrote:
>Vincent Deffontaines:
>> This page mentions the website :
>> http://www2.iro.umontreal.ca/~pinard/po/registry.cgi?team=index
>>
>> while www2.iro.umontreal.ca has no DNS resolution.
>
> It does resolve now; but then the webserver returns a 302
On Wednesday 25 May 2005 16:56, Jeffrey A Law wrote:
> So when's the last time someone bootstrapped Ada with the mainline
> sources on i686-pc-linux-gnu?
>
> I was trying to get it built to further exercise the ADDR_EXPR
> status bit checking code and it consistently hangs building the
> stage3 com
Original Message
>From: chris jefferson
>Sent: 25 May 2005 15:23
> Vincent Lefevre wrote:
>>
>> float x = 30.0;
>> int main()
>> {
>> if ( 90.0/x != 3.0)
>>abort();
>> return 0;
>> }
>>
>> fails with -ffast-math (on x86). I would not recommend it, unless
>> the user knows all th
On 2005-05-25 15:22:31 +0100, chris jefferson wrote:
> On the other hand, in general using != and == on floating point
> numbers is always dangerous if you do not know all the consequences.
> For example, on your above program if I use 30.1 and 90.3, the
> program fails without -ffast-math.
Yes, b
So when's the last time someone bootstrapped Ada with the mainline
sources on i686-pc-linux-gnu?
I was trying to get it built to further exercise the ADDR_EXPR
status bit checking code and it consistently hangs building the
stage3 compiler (even with all the recent ADDR_EXPR stuff disabled).
Rat
Phil Endecott <[EMAIL PROTECTED]> writes:
> I'm having trouble compiling code that uses the following macro from
> the Apache Portable Runtime:
>
> #define apr_atomic_cas(mem,with,cmp) \
> ({ apr_atomic_t prev; \
> asm volatile ("lock; cmpxchgl %1, %2" \
> : "=a" (prev
Original Message
>From: Vincent Deffontaines
>Sent: 25 May 2005 10:28
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> This page mentions the website :
> http://www2.iro.umontreal.ca/~pinard/po/registry.cgi?team=index
>
> while www2.iro.umontreal.ca has no DNS resolution.
>
> Vince
* Phil Endecott:
> I've found bug 10153 and its duplicates which seem to be describing
> essentially the same thing, but say that the input is invalid because it
> uses "r" rather than "q". I don't know enough about x86 to understand
> this; presumably only certain registers can be used with t
Vincent Lefevre wrote:
On 2005-05-24 09:04:11 +0200, Uros Bizjak wrote:
I would like to point out that for applications that crunch data
from real world (no infinites or nans, where precision is not
critical) such as various simulations, -ffast-math is something that
can speed up applicatio
On 2005-05-23 11:14:52 -0400, Scott Robert Ladd wrote:
[...]
> Naturally, due to hardware availability, I'll be focusing on x86 and
> x86_64 systems.
>
> I'd appreciate comments, ideas, and suggestions from the folk on this
> mailing list.
You may be interested in my web page "Linux and the Exten
On 2005-05-24 09:04:11 +0200, Uros Bizjak wrote:
> I would like to point out that for applications that crunch data
> from real world (no infinites or nans, where precision is not
> critical) such as various simulations, -ffast-math is something that
> can speed up application a lot.
But note th
Theodore Papadopoulo wrote:
>..(actually there is still a
>pending core compiler ABI change pending)
>
Indeed, I think you are right: I clearly remember Mark saying: let's
synchronize any possible library ABI change with a core compiler
change. In my understanding, we
On Wed, 25 May 2005, Theodore Papadopoulo wrote:
| On that topic, my point was more to say "give some warranty/promise".
There is no point in making a promise when one does not have enough
data to keep it. That does not mean, we don't want; just that it is
hard work. And we have been carefully
On Wed, 2005-05-25 at 08:29 -0500, Gabriel Dos Reis wrote:
> The project I'm proposing is not to move to C++. Just to move to the
> intersection of C and C++, which is what we had agreed on in previous
> discussions. Someone needs to implement those decisions, that is what
> I'm trying to do (of c
On Wed, 2005-05-25 at 14:48 +0200, Paolo Carlini wrote:
> Just a quick comment: this is *already* happening, no doubts. We have
> v6 since 3.4.0...
I know (well almost) Apologies if my mail was suggesting the
opposite. As you might have noticed, I tried to avoid to make too strong
statements a
Dear GCC experts,
I'm having trouble compiling code that uses the following macro from the
Apache Portable Runtime:
#define apr_atomic_cas(mem,with,cmp) \
({ apr_atomic_t prev; \
asm volatile ("lock; cmpxchgl %1, %2" \
: "=a" (prev) \
: "r" (wit
On Wed, 25 May 2005, Theodore Papadopoulo wrote:
| All that being said, I do not know why this C++ transition should be
| blocked by libstdc++ ABI stability. Given the history the GCC project
| and the amount of work (and the expected benefits) that would arise just
| from converting to a simple s
Theodore Papadopoulo wrote:
>The real problem I think is not really casting an ABI in stone, but
>merely to have "some stability" over time. Maybe the only thing that is
>missing is a "commitment" of the C++ library ABI stable over a few (two,
>three ?) major gcc releases as there is one for the c
On Wed, 2005-05-25 at 10:37 +0200, Paolo Carlini wrote:
> >>Why? To be honest, I keep harping on this mostly because I think it
> >>should happen. All the C++-in-GCC noise is a digression.
> [.]
> In practice, we have got an handful of bugs unfixable within the
> current
> ABI (mostly alrea
> > Now we have e.g. XNEW* and all we need is a new -W* flag to catch
> > things like using C++ keywords and it should be fairly automatic to
> > keep incompatibilities out of the sources.
>
> Why not this?
>
> #ifndef __cplusplus
> #pragma GCC poison class template new . . .
> #endif
T
* Christoph Hellwig:
> Why can't libstdc++ use symbol versioning?
Via stack allocation, templates and inline functions, the internal
representation of libstdc++ data structures is exported. All of its
users would have to be versioned, too, and you'd need bridging code
between the ABIs (e.g. to p
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
This page mentions the website :
http://www2.iro.umontreal.ca/~pinard/po/registry.cgi?team=index
while www2.iro.umontreal.ca has no DNS resolution.
Vincent Deffontaines
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using Gn
Daniel Jacobowitz wrote:
>>Why? To be honest, I keep harping on this mostly because I think it
>>should happen. All the C++-in-GCC noise is a digression.
>>
>>You know how much work it is for the distributors every time we bump the
>>libstdc++ soname. Why wouldn't we want to stop inflicting t
Hello!
> Well you really want both the fpcr and the mxcsr registers, since the fpcr
> only controls the x87 and the mxcsr controls the xmm registers. Note, in
> adding these registers, you are going to have to go through all of the
> floating
> point patterns to add (use:HI FPCR_REG) and (use:SI
52 matches
Mail list logo
