I'm getting an ICE on 64-bit sparc for some vector test cases but
I'm not sure where the fix belongs.
When the compiler expands a vecor shift by scalar into a vector
shift by a vector it uses expand_vector_broadcast(), which has
a comment which states:
"The mode of OP must be the element mode of
On Thu, 27 Oct 2011 23:31:14 -0400
Robert Dewar wrote:
> > - I am missing a gcc flag
>
> probably you should avoid extra precision and all the
> issues it brings, as well as speed up your program, by
> using SSE 64-bit arithmetic (using the appropriate gcc
> flags)
Indeed. -mpc64 fixes the issu
On 10/27/2011 10:17 PM, Zoltán Kócsi wrote:
I wonder whether
- I know the IEEE rounding rules incorrectly
yes, you do, but you are ignoring the extended precision
phenomenon which can lead to double rounding
- I am missing a gcc flag
probably you should avoid extra precision and all the
i
From: Eric Botcazou
Date: Thu, 27 Oct 2011 23:55:00 +0200
>> I quickly tried the patch below, but this does not prevent the
>> transformation.
>
> The quoted code is in copyprop_hardreg_forward_1.
Indeed :-)
This patch below works for the specific test case, and I'll post to
gcc-patches and co
I found something very strange, although it might be just a misunderstanding.
As far as I know, the IEEE-754 standard defines round-to-nearest, tie-to-even
as follows:
- For rounding purposes, the operation must be performed as if it were done
with infinite precision
- Then, if the bit right of
Hi,
On the page of http://gcc.gnu.org/onlinedocs/, links to following
libstdc++ documents are inaccessible:
http://gcc.gnu.org/onlinedocs/gcc-4.6.2/libstdc++/manual/spine.html
http://gcc.gnu.org/onlinedocs/gcc-4.6.2/libstdc++/libstdc++-manual.pdf.bz2
http://gcc.gnu.org/onlinedocs/gcc-4.6.2/lib
Snapshot gcc-4.5-20111027 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20111027/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.5 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
> I quickly tried the patch below, but this does not prevent the
> transformation.
The quoted code is in copyprop_hardreg_forward_1.
--
Eric Botcazou
From: Eric Botcazou
Date: Thu, 27 Oct 2011 23:11:33 +0200
>> Sorry, the final path component should be "mzero2.c"
>
> Thanks. I think we that need the same treatment in:
...
> as:
...
> i.e. we need to bail out if we are narrowing and this is a big-endian target.
I quickly tried the patch be
> Sorry, the final path component should be "mzero2.c"
Thanks. I think we that need the same treatment in:
/* If we are accessing SRC in some mode other that what we
set it in, make sure that the replacement is valid. */
if (mode != vd->e[regno].mode)
From: Eric Botcazou
Date: Thu, 27 Oct 2011 15:17:40 +0200
>> On 64-bit sparc, integer regs are 64-bit and float regs are
>> (basically) 32-bit. So HARD_REGNO_NREGS(float_reg, DFmode) is 2, and
>> HARD_REGNO_NREGS(integer_reg, DImode) is 1.
>>
>> cprop sees the sequence:
>>
>> (insn 330 172 230 .
> If I have a structure e.g.
> struct test_s {
> int32_t var1;
> int32_t var2;
> uint64_t var3;
> int var4;
> } test;
>
> If I have an offset value of 8, I wish to do a lookup and get to:
> test.var3
>
> Is there some part of gcc that I could use to parse .h files and
> produce a t
On Thu, Oct 27, 2011 at 9:29 PM, Ian Lance Taylor wrote:
>> This testfile:
>>
>> #define aa 2
>> #undef aa
>> #define aa 3
>>
>> does not generate correct output with -fdump-go-spec. The result is:
>>
>> const _aa = 2
>> // undef _aa
>>
>> One would expect:
>>
>> const _aa = 2
>> // undef _aa
>>
James Courtier-Dutton writes:
> If I have a structure e.g.
> struct test_s {
> int32_t var1;
> int32_t var2;
> uint64_t var3;
> int var4;
> } test;
>
> If I have an offset value of 8, I wish to do a lookup and get to:
> test.var3
>
> Is there some part of gcc that I could use to p
Uros Bizjak writes:
> This testfile:
>
> #define aa 2
> #undef aa
> #define aa 3
>
> does not generate correct output with -fdump-go-spec. The result is:
>
> const _aa = 2
> // undef _aa
>
> One would expect:
>
> const _aa = 2
> // undef _aa
> const _aa = 3
Did this come up in a real situation?
From: Eric Botcazou
Date: Thu, 27 Oct 2011 15:17:40 +0200
>> To reproduce build gcc.c-torture/execute/ieee/mzero.c with
>> "-m64 -mcpu=niagara3 -O2" on sparc.
>
> AFAICS there is no such file as gcc.c-torture/execute/ieee/mzero.c.
Sorry, the final path component should be "mzero2.c"
Hello!
This testfile:
#define aa 2
#undef aa
#define aa 3
does not generate correct output with -fdump-go-spec. The result is:
const _aa = 2
// undef _aa
One would expect:
const _aa = 2
// undef _aa
const _aa = 3
xgcc (GCC) 4.7.0 20111027 (experimental) [trunk revision 180567]
Uros.
Hi,
If I have a structure e.g.
struct test_s {
int32_t var1;
int32_t var2;
uint64_t var3;
int var4;
} test;
If I have an offset value of 8, I wish to do a lookup and get to:
test.var3
Is there some part of gcc that I could use to parse .h files and
produce a table for me of offse
The GNU Compiler Collection version 4.6.2 has been released.
GCC 4.6.2 is a bug-fix release containing fixes for regressions and serious
bugs in GCC 4.6.1, with over 110 bugs fixed since previous release. This
release is available from the FTP servers listed at:
http://www.gnu.org/order/ftp.ht
Hello!
> The GCC trunk is still in stage1. Stage1 will last until
> Nov 7th (including, use your timezone to your advantage) after
> which we will have been in stage1 for nearth 8 months.
> In stage3 the trunk will be open for general bugfixing, no
> new features will be accepted.
There is a pat
> On 64-bit sparc, integer regs are 64-bit and float regs are
> (basically) 32-bit. So HARD_REGNO_NREGS(float_reg, DFmode) is 2, and
> HARD_REGNO_NREGS(integer_reg, DImode) is 1.
>
> cprop sees the sequence:
>
> (insn 330 172 230 .. (set (reg:DI %g2) const_int)
> (insn 171 330 173 .. (set (reg:DF
On 10/27/2011 04:55 AM, Richard Guenther wrote:
I am really expecting this branch to be merged for 4.7. The current
status is very presentable IMHO.
If you get (or already got) ack from maintainers covering the areas you
touch then I am fine with merging this branch for 4.7 from a RM point
of
> I'm trying to understand what you mean, but your comments are rather
> obscure. Which file do you think I should change? Just tell me where to
> look and I'll do it.
glibc/ports/sysdeps/unix/sysv/linux/arm/eabi/sigrestorer.S Currently has:
.fnstart
.save {r0-r15}
.pad #
Status
==
The GCC trunk is still in stage1. Stage1 will last until
Nov 7th (including, use your timezone to your advantage) after
which we will have been in stage1 for nearth 8 months.
In stage3 the trunk will be open for general bugfixing, no
new features will be accepted.
Now is time to b
On 10/27/2011 12:53 PM, Paul Brook wrote:
>> On 10/27/2011 02:15 AM, Paul Brook wrote:
>> So, suggestions welcome. Is there a nice way to detect a signal
>> frame?
>>>
>>> That just makes me ask why are you're trying to detect a signal frame in
>>> the first place?
>>
>> Because I need bac
> On 10/27/2011 02:15 AM, Paul Brook wrote:
> So, suggestions welcome. Is there a nice way to detect a signal
> frame?
> >
> > That just makes me ask why are you're trying to detect a signal frame in
> > the first place?
>
> Because I need backtrace() to work when called from a signal
Although copy_value() in regcprop.c tries to avoid recording cases
where substitutions would be illegal, there are some bad cases it
still can let through.
On 64-bit sparc, integer regs are 64-bit and float regs are
(basically) 32-bit. So HARD_REGNO_NREGS(float_reg, DFmode) is 2, and
HARD_REGNO_
On Wed, Oct 26, 2011 at 6:31 PM, Benjamin Kosnik wrote:
>
>> Whats left
>> ===
>> Functionality is pretty much complete, but there are a few minor lose
>> ends still to deal with. They could be done after a merge, in the
>> next stage, or required before... you tell me :-)
>>
>> - potentia
On 2011/10/27 04:33 PM, Revital Eres wrote:
> Hello,
>
> I'm working on estimating register pressure in SMS and using
> ira_available_class_regs for getting the number of available
> registers.
> However I encounter a case where ira_available_class_regs showed 64
> available regs for a certain cla
On 10/27/2011 02:15 AM, Paul Brook wrote:
So, suggestions welcome. Is there a nice way to detect a signal frame?
>
> That just makes me ask why are you're trying to detect a signal frame in the
> first place?
Because I need backtrace() to work when called from a signal handler.
>>> Libunw
Hello,
I'm working on estimating register pressure in SMS and using
ira_available_class_regs for getting the number of available
registers.
However I encounter a case where ira_available_class_regs showed 64
available regs for a certain class while ira_class_hard_regs_num
showed 61 so I am not sur
31 matches
Mail list logo
