On Sat, Jan 11, 2014 at 6:54 PM, Denis K wrote:
> Hello,
>
> I've been trying to compile gcc 4.5.4 from the sources using
> --with-fpmath=387 but I'm getting this error: "Invalid
> --with-fpmath=387". I looked in the configs and found that it doesn't
> support this option:
>
> case ${with_fpmath}
Hello,
I've been trying to compile gcc 4.5.4 from the sources using
--with-fpmath=387 but I'm getting this error: "Invalid
--with-fpmath=387". I looked in the configs and found that it doesn't
support this option:
case ${with_fpmath} in
avx)
tm_file="${tm_file} i386/avxmath.h"
;;
sse)
Snapshot gcc-4.7-20140111 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.7-20140111/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.7 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
On Sat, 2014-01-11 at 15:24 +, Rob wrote:
> On Sat, 11 Jan 2014, Nick wrote:
> > I'm very surprised by the result in #6. #7 seems to be doing the same
> > thing, except that it uses a local variable to hold the sum.
>
> Sounds to me like it could be related to excess precision - checkout the
On Sat, 2014-01-11 at 16:24 +0100, Marc Glisse wrote:
> First, this is not an appropriate list for this question. gcc-help would
> be better.
Sorry about that--my e-mail auto completed the address and I wasn't
paying enough attention.
> Second, there are hundreds of places on the internet answer
On Sat, 11 Jan 2014, Nick wrote:
I'm very surprised by the result in #6. #7 seems to be doing the same
thing, except that it uses a local variable to hold the sum.
Sounds to me like it could be related to excess precision - checkout the
-ffloat-store option. I don't see it on my machine either
On Sat, 11 Jan 2014, Nick wrote:
First, I know that floating point variables should not be compared "raw"
due to the way they're represented. But the behavior I'm seeing has me
surprised.
First, this is not an appropriate list for this question. gcc-help would
be better. Second, there are hu
First, I know that floating point variables should not be compared "raw"
due to the way they're represented. But the behavior I'm seeing has me
surprised.
Here's a small repo example:
---
#include
using namespace std;
int main()
{
float f1(4.94f + 0.2f
On Sat, Jan 11, 2014 at 2:12 AM, Richard Sandiford
wrote:
> Tejas Belagod writes:
>> When I relaxed CANNOT_CHANGE_MODE_CLASS to undefined for AArch64,
>> gcc.c-torture/execute/copysign1.c generates incorrect code because LRA cannot
>> seem to handle subregs like
>>
>> (subreg:DI (reg:TF hard_re
Tejas Belagod writes:
> When I relaxed CANNOT_CHANGE_MODE_CLASS to undefined for AArch64,
> gcc.c-torture/execute/copysign1.c generates incorrect code because LRA cannot
> seem to handle subregs like
>
> (subreg:DI (reg:TF hard_reg) 8)
>
> on hard registers where the subreg byte offset is unal
> FWIW, it was fixed in 4.8 and later by making CODE_FOR_nothing be 0
> and starting the real instructions at 1.
Indeed, thanks for the heads-up:
2012-07-09 Steven Bosscher
* gensupport.c (init_rtx_reader_args_cb): Start counting code
generating patterns from 1 to free up 0 fo
Jeff Law writes:
> On 01/10/14 14:44, Eric Botcazou wrote:
>>> In my backend movdi pattern has unfortunately code '0' (depends on pattern
>>> declaration order). When gcc tried to determine if my DI regs can be saved
>>> and restore as 'caller saves' (in caller-save.c::init_caller_save()) it
>>> f
12 matches
Mail list logo
