The immediate issue is resolved, so I'm resolving the ticket. Larger
issues about gcc should be dealt with in a new, separate ticket.
On Mon, Dec 17, 2007 at 05:33:51PM -0500, Jeff Horwitz wrote:
On Mon, 17 Dec 2007, chromatic wrote:
Okay, so memcpy doesn't fix it. That's good to know. How about explicitly
putting the destination PMC in a named variable so there's less pointer
shuffling and macro madness?
memmove
Nicholas Clark wrote:
Do the structures actually overlap, or is this necessary band aid for a subtly
broken compiler?
I think the compiler is to blame. It only happens when compiling the
code in the computed goto core. I *suspect* the compiler backs out of a
lot of analysis and transforms
Nicholas Clark wrote:
Do the structures actually overlap, or is this necessary band aid for a
subtly broken compiler?
Jonathan Worthington replied:
I think the compiler is to blame.
Are we hurling abuse at^H^H^H^H^H^H^H^H informing the GNU folks about the
apparent problem? :-)*
BTW, I
On Sat Dec 15 15:11:53 2007, [EMAIL PROTECTED] wrote:
This afternoon I began to get failures in 'make'. Via IRC, pmichaud,
jonathan and I tracked the break point down to r23917.
Given that I originally reported this failure as occurring on a fairly
standard Debian installation (the only
On Saturday 15 December 2007 15:11:54 James Keenan wrote:
This afternoon I began to get failures in 'make'. Via IRC, pmichaud,
jonathan and I tracked the break point down to r23917.
At r23917, when I configure with 'perl Configure.pl' -- and no
options -- I get the breakage described in
No, at least not on Ubuntu. (Will have to check later on other OSes.)
Here's the last part of the 'make' output:
src/string.c
src/ops/core_ops.c
src/ops/debug.ops: In function ‘Parrot_debug_break’:
src/ops/debug.ops:103: warning: null argument where non-null required
(argument 2)
On Monday 17 December 2007 12:52:05 James Keenan via RT wrote:
No, at least not on Ubuntu. (Will have to check later on other OSes.)
Okay, so memcpy doesn't fix it. That's good to know. How about explicitly
putting the destination PMC in a named variable so there's less pointer
shuffling
Jeff Horwitz wrote:
unfortunately, chromatic's memcpy patch still generated the compiler
error, perhaps because gcc is optimizing it back to the original code
it was replacing.
using memmove fixes this issue. it performs the copy, but it's not
optimized in the same way because it deals with
On Mon, 17 Dec 2007, chromatic wrote:
Okay, so memcpy doesn't fix it. That's good to know. How about explicitly
putting the destination PMC in a named variable so there's less pointer
shuffling and macro madness?
memmove fixes it. i submitted a patch, but for some reason it hasn't made
it
On Mon Dec 17 14:44:55 2007, jhorwitz wrote:
t/op/copy.t passes with this patch. can others try it out?
Jeff's patch enabled me to build successfully on both Darwin and Linux
(the Debian box). I ran 'make test' on the Linux and all non-TODO tests
passed. So I have applied it to trunk in
Jonathan Worthington wrote:
I suspect re-writing it to do a memcpy would solve the problem...anyway,
sleep calls...
See the thread from earlier this year:
http://groups.google.com/group/perl.perl6.internals/browse_frm/thread/f50d1057d4855b7f/93fdb2d7e24e35f5
Allison
Allison Randal wrote:
Jonathan Worthington wrote:
I suspect re-writing it to do a memcpy would solve the
problem...anyway, sleep calls...
See the thread from earlier this year:
http://groups.google.com/group/perl.perl6.internals/browse_frm/thread/f50d1057d4855b7f/93fdb2d7e24e35f5
Having
Hi,
Basically, it appears to me that the failure happens with some versions
of GCC when you're doing (once you look through the macros):
*d = *s;
Where d and s are PMCs. I can only conclude that the compiler is
generating all the reads, then all the writes, which of course requires
14 matches
Mail list logo
