: In function `acos':
:137: Internal compiler error in ?, at :724
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
I might be able to trace it from a different approach, getting more
information about that internal error
2009/11/28 Richard Guenther :
> On Sat, Nov 28, 2009 at 11:43 PM, Shaun Jackman wrote:
>> When assigning a bool to a single bit of a bitfield located in the
>> bit-addressable region of memory, better code is produced by
>> if (flag)
>> bitfield.bit = true;
>> else
>>
If GC does that, then how come there is all this effort to do
mmap testing to see if it has the facility to zero memory, and
I can't see what you are refering to.
I obviously misinterpreted that then.
why is the surrounding code (in GCC 4.4's alloc_page())
calling XCNEWVEC instead of XNEWVE
On Sat, Nov 28, 2009 at 11:43 PM, Shaun Jackman wrote:
> When assigning a bool to a single bit of a bitfield located in the
> bit-addressable region of memory, better code is produced by
> if (flag)
> bitfield.bit = true;
> else
> bitfield.bit = false;
>
When assigning a bool to a single bit of a bitfield located in the
bit-addressable region of memory, better code is produced by
if (flag)
bitfield.bit = true;
else
bitfield.bit = false;
than
bitfield.bit = flag;
I've included a short test and
Toon Moene wrote:
Toon Moene wrote:
Tim Prince wrote:
> If you want those, you must request them with -mtune=barcelona.
OK, so it is an alignment issue (with -mtune=barcelona):
.L6:
movups 0(%rbp,%rax), %xmm0
movups (%rbx,%rax), %xmm1
incl%ecx
addps %
Toon Moene wrote:
Tim Prince wrote:
> If you want those, you must request them with -mtune=barcelona.
OK, so it is an alignment issue (with -mtune=barcelona):
.L6:
movups 0(%rbp,%rax), %xmm0
movups (%rbx,%rax), %xmm1
incl%ecx
addps %xmm1, %xmm0
Tim Prince wrote:
> If you want those, you must request them with -mtune=barcelona.
OK, so it is an alignment issue (with -mtune=barcelona):
.L6:
movups 0(%rbp,%rax), %xmm0
movups (%rbx,%rax), %xmm1
incl%ecx
addps %xmm1, %xmm0
movaps %xmm0, (%r8,
On Sat, Nov 28, 2009 at 5:35 PM, Paul Edwards wrote:
>>> Anyway, I tracked down the particular malloc() which gave changed
>>> behaviour depending on whether the malloc() did a memory initialization
>>> to NULs or not.
>
>> Well, GC hands out non-zeroed memory - the callers are responsible
>> for
On Sat, Nov 28, 2009 at 5:31 PM, Tim Prince wrote:
> Richard Guenther wrote:
>>
>> On Sat, Nov 28, 2009 at 4:26 PM, Tim Prince wrote:
>>>
>>> Toon Moene wrote:
H.J. Lu wrote:
>
> On Sat, Nov 28, 2009 at 3:21 AM, Toon Moene wrote:
>>
>> L.S.,
>>
>> Due to the dis
Anyway, I tracked down the particular malloc() which gave changed
behaviour depending on whether the malloc() did a memory initialization
to NULs or not.
Well, GC hands out non-zeroed memory - the callers are responsible
for initializing it. So the fix below is not a fix but papering over an
i
Richard Guenther wrote:
On Sat, Nov 28, 2009 at 4:26 PM, Tim Prince wrote:
Toon Moene wrote:
H.J. Lu wrote:
On Sat, Nov 28, 2009 at 3:21 AM, Toon Moene wrote:
L.S.,
Due to the discussion on register allocation, I went back to a hobby of
mine: Studying the assembly output of the compiler.
On Sat, Nov 28, 2009 at 4:26 PM, Tim Prince wrote:
> Toon Moene wrote:
>>
>> H.J. Lu wrote:
>>>
>>> On Sat, Nov 28, 2009 at 3:21 AM, Toon Moene wrote:
L.S.,
Due to the discussion on register allocation, I went back to a hobby of
mine: Studying the assembly output of the c
On Sat, Nov 28, 2009 at 4:13 PM, Paul Edwards wrote:
> I think I have found a bug in gcc, that still exists in gcc 4.4
>
> I found the problem on 3.2.3 though.
>
> While MVS and VM have basically been working fine, when I did
> the port to MUSIC/SP I started getting strange compilation failures.
>
Toon Moene wrote:
H.J. Lu wrote:
On Sat, Nov 28, 2009 at 3:21 AM, Toon Moene wrote:
L.S.,
Due to the discussion on register allocation, I went back to a hobby of
mine: Studying the assembly output of the compiler.
For this Fortran subroutine (note: unless otherwise told to the Fortran
front
I think I have found a bug in gcc, that still exists in gcc 4.4
I found the problem on 3.2.3 though.
While MVS and VM have basically been working fine, when I did
the port to MUSIC/SP I started getting strange compilation failures.
Initializing the stack to NULs made the problem go away, but I
H.J. Lu wrote:
On Sat, Nov 28, 2009 at 3:21 AM, Toon Moene wrote:
L.S.,
Due to the discussion on register allocation, I went back to a hobby of
mine: Studying the assembly output of the compiler.
For this Fortran subroutine (note: unless otherwise told to the Fortran
front end, reals are 32 b
On Sat, Nov 28, 2009 at 3:21 AM, Toon Moene wrote:
> L.S.,
>
> Due to the discussion on register allocation, I went back to a hobby of
> mine: Studying the assembly output of the compiler.
>
> For this Fortran subroutine (note: unless otherwise told to the Fortran
> front end, reals are 32 bit flo
L.S.,
Due to the discussion on register allocation, I went back to a hobby of
mine: Studying the assembly output of the compiler.
For this Fortran subroutine (note: unless otherwise told to the Fortran
front end, reals are 32 bit floating point numbers):
subroutine sum(a, b, c, n)
19 matches
Mail list logo
