Re: [perl #50684] String Failures with -O2 (GCC 4.1.3, 32-bit x86 Linux)
- Original Message - From: "chromatic (via RT)" <[EMAIL PROTECTED]> Sent: Saturday, February 09, 2008 11:29 PM Subject: [perl #50684] String Failures with -O2 (GCC 4.1.3, 32-bit x86 Linux) I recompiled Parrot with the -march and -O2 flags, to see what kind of speed boosts we get from optimization (modest improvements in IMCC, about 20% overall). Unfortunately, several tests failed with segfaults, due to a problem somewhere in string handling: t/op/string.t Failed test number(s): 71, 73 (gdb) run -G t/op/string_73.pasm (gdb) bt #0 0xb7ce5376 in string_length (interp_unused=0x804f008, s=0x0) at src/string.c:746 #1 0xb7ce55e6 in string_ord (interp=0x804f008, s=0x0, idx=0) at src/string.c:832 #2 0xb7cfa7bf in Parrot_ord_i_s_ic (cur_opcode=0x8256918, interp=0x804f008) at src/ops/string.ops:47 Looking at just this one case, we see that string_ord is called with a NULL s argument, whereas the function header states that s is nonnull. The GCC optimiser believes what it is told, and therefore discards the test for s being not null, and calls string_length regardless. string_length has also been told to expect a nonnull argument, and behaves accordingly. I strongly suspect that most, if not all, the other failures stem from the same logic. There are two apparent solutions: check all notnull arguments before calling the functions or remove the nonnull attribute where it is not true. Regards Peter Gibbs
Parrot Bug Summary
Parrot Bug Summary
http://rt.perl.org/rt3/NoAuth/parrot/Overview.html
Generated at Mon Feb 11 14:01:06 2008 GMT
---
* Numbers
* New Issues
* Overview of Open Issues
* Ticket Status By Version
* Requestors with most open tickets
---
Numbers
Ticket Counts: 110 new + 732 open = 842
Created this week: 12
Closed this week: 13
---
New Issues
New issues that have not been responded to yet
1 - 2 weeks old
50520 [PATCH][NQP] method call and =:= tests
50508 [PATCH] evaluate the first child of a PAST::Var :scope('attribute') as
the object
50500 [PROPOSAL][PAST] add PAST::Var :scope('attribute')
50448 [Memory Leak] IMCC Can Leak Lexer Data on Exception
50424 [PROPOSAL][PCT] allow empty PAST::Stmts nodes
50400 [BUG] segfault in pdd17pmc branch
50360 Redesign Parrot NCI callback functionality
2 - 3 weeks old
50238 [PATCH] Remove cast in fetch_buf_... calls in pf_items.c
50092 [TODO] pct - explicit transcode in PCT::Grammar::string_literal
50090 [TODO] pge - throw useful exception on non-quoted non-word characters
50068 Configure doesn't detect backtrace* on ubuntu gutsy
3 - 4 weeks old
49970 [BUG] -O1 and -O2 don't turn on -Ot as per docs
49968 [BUG] 'parrot -O2 oofib.pir' errors out, when -O1 succeeds
49966 [BUG] parrot -v -O2 segfaults, when -v and -O2 separately both work
49832 Error making parrot-0.5.2 in MacosX
49818 [PATCH] Build on QNX 6
4 - 5 weeks old
49718 JIT Core Needs to Handle Scheduler Tasks
5 - 6 weeks old
49328 [BUG] problem between PBC loading and garbage collection
49258 Parrot::Test with --run-exec assumes "." is in $PATH
6 - 7 weeks old
49177 [TODO] pct - PAST::Val node should throw exception if :value attribute
not set
7 - 8 weeks old
49023 Error in library/pg on Ubuntu 7.10
49001 [PROPOSAL][DOCS] Change word "compilation_unit" into something else (like
"sub")
48877 [TODO] Don't generate .constant declarations for vtable method names.
8 - 9 weeks old
48749 [BUG] t/examples/tutorial.t if_unless failure (Win32)
48645 [CAGE] Make PMCs depend on Parrot::Pmc2c::* Modules
48587 [BUG] pmc.num contains missing PMCs
48581 [DEPRECATED] vtable type_keyed_str
48549 [RFC][PIR] Let .namespace (no args) have empty brackets
48513 [TODO][PCT] Use of int registers in PCT.
48507 [BUG] oo - n_add, n_sub, etc. don't work with objects
48467 [BUG] assignment of objects creates Ref instead of copy
48445 [TODO] [NQP] - report undeclared variable usage
48439 [TODO] [configure] compiling Parrot with LLVM
9 - 10 weeks old
48367 intlist_get could be dereferencing NULL
48357 Initialize vtables for newly created interpreter
48320 [BUG] Example in pdd23 doesn't work
48296 Implement get_namespace vtable from pdd17
48286 [TODO] [C] Warnings aren't emitted if a var isn't initialised and -w flag
is on in propagate_need()
48282 [TODO] [C] Check that invoke is ok near the set_addr instruction in
bb_findadd_edge()
48280 [TODO] [C] Check for a sub with more up-to-date unit->type lookup
48278 [TODO] [C] Should we call GetLastError for failure messages in .../win32/
exec.c?
48276 [TODO] [C] Warn when failure occurs in Parrot_setenv()
48274 [TODO] [C] Stop ignoring the known errors in Parrot_dlopen()
48272 [TODO] [C] Stop exporting Parrot_signbit()
48264 [TODO] [C] Write file-level documentation
48212 "make smoke" hangs on win32 latest build
48206 [TODO] [cola] Check that expression evaluates to a method in
gen_method_call()
48204 [TODO] [cola] Check method signature in gen_arg_list_expr() and find out
what type is expected
48202 [TODO] [cola] Rewrite push_sym() to call generic Node versions of calls
48200 [TODO] [cola] Add documentation to files and functions
48198 [TODO] [cola] Add support for member resolution in lookup_type()
48196 [TODO] [APL] Should the PMC in set_shape() be cloned?
48194 [TODO] [APL] Move any constant string declarations into class_init()
48192 [TODO] [amber] Correct overflow issue in integer()
48190 [TODO] [amber] Can null variable check be reinstated by generating n_neg
instead of neg?
48188 [TODO] [amber] Correct overflow for -maxint in abs()
48186 [TODO] [amber] Consider using unicode in character()
48184 [TODO] [amber] Use has(index) to check indices in set_item()
48182 [TODO] [amber] Reject out of range values in item()
48180 [TODO] [amber] Reject first() and last() methods if count = 0
48176 [TODO] [pugs] Warning: use of uninitialized value
48174 [TODO] [pugs] Store undef for consistency
48172 [TODO] [pugs] Getting nonexistent value, exception or undef?
48170 [TODO] [regex] Remove 'use of uninitialized value' issues in match.pmc
48168 [TODO] [regex] Implement init_pmc
48164 [TODO] [Tcl] Document the functions in tcl/src/binary.c
48162 [TODO] [Tcl] Document what the tcl/src/binary.c file does in the
DESCRIPT
Re: [perl #50492] AutoReply: [PATCH][lolcode] Allow arguments to functions. Pass parameters to the appropriate functions at runtime.
Not long ago, Stuart Jansen via RT proclaimed... > I'm really glad to see you're still working on this, but I don't think > this patch is ready to be merged yet. You've raised several points. Attached is a modified patch that addresses most of them. The largest problem with this patch is that it needs more explicit null checking in a few places. This version of this patch has operator support as well, and a pair of tests, one testing the math ops directly, and one also testing some more complicated expressions using the first twenty 'four fours' problems. Doesn't test slurpy functions and MKAY, though. > I don't think this is correct behavior. VISIBLE is a statement, but it > is not an expression. I can't find a defined return value for VISIBLE, > nor can I find any evidence that VISIBLE should set IT. > > In additon, I can't find any evidence that '!' is a value. It is only a > special syntax case for VISIBLE. This patch parses VISIBLE as an expression because that looks like the least awkward way of dispatching arguments to it properly. This patch explicitly checks for 'VISIBLE' in method statement, where the bind-to-IT nodes are emitted to skip emitting a binding to IT on VISIBLE statements. I've moved the ! handing into VISIBLE. As we discussed on IM, the alternative is explicitly emit a call to SMOOSH and duplicate method expression inside of method VISIBLE. I don't like this option much, but at least it avoids the explicit bang rules. I can write a version using an explicit SMOOSH for comparison. > > Function return values are a bit sketchy, but that's waiting on PAST > > support for return statements anyway, iirc. > > They can currently be accomplished using inline PIR. > See /languages/ecmascript/src/parser/actions.pm for an example. Yes, but that is outside the scope of this patch. IT is properly returned, as it has been since that was added earlier. > > Functions can't return null values, as null is currently being used as > > the 'end of statement' marker in expr_parse. > > This will have to change. I interpret NOOB to be null. Function can > return NOOB using GTFO, for example. This has been fixed. MKAY is currently passed along as a variable, as it's a reserved word anyway, and checked with issame, so nulls can be returned properly. Isn't NOOB more like Undef than null, though? > > Optional parameters to functions aren't dealt with properly. > > > > Auto-assignment to IT is still a bit sketchy. I'm unsure of the proper > > semantics here, but the test suite passes, so it's good enough for now. > > IT should only be set by a bare expression. Hence the special case in > the grammar. The new handling for IT is not correct because bare > expressions can consist of multiple tokens once we have proper support > for operators. Is a 'bare expression' any expression which is not a call to VISIBLE? If so, this patch handles that appropriately. That's the meaning that I get out of my reading of the spec. > -- > Stuart Jansen <[EMAIL PROTECTED]> > Guru Labs > Index: languages/lolcode/t/99-four-fours.t === --- languages/lolcode/t/99-four-fours.t (revision 0) +++ languages/lolcode/t/99-four-fours.t (revision 0) @@ -0,0 +1,49 @@ +HAI 1.2 + VISIBLE "1..20" + + BTW 1 + VISIBLE "ok " SUM OF QUOSHUNT OF 4 AN 4 AN DIFF OF 4 AN 4 + + BTW 2 + VISIBLE "ok " SUM OF QUOSHUNT OF 4 AN 4 AN QUOSHUNT OF 4 AN 4 + + BTW 3 + VISIBLE "ok " QUOSHUNT OF SUM OF SUM OF 4 AN 4 AN 4 AN 4 + + BTW 4 + VISIBLE "ok " SUM OF PRODUKT OF DIFF OF 4 AN 4 AN 4 AN 4 + + BTW 5 + VISIBLE "ok " QUOSHUNT OF SUM OF PRODUKT OF 4 AN 4 AN 4 AN 4 + + BTW 6 + VISIBLE "ok " SUM OF QUOSHUNT OF SUM OF 4 AN 4 AN 4 AN 4 + + BTW 7 + VISIBLE "ok " DIFF OF SUM OF 4 AN 4 AN QUOSHUNT OF 4 AN 4 + + BTW 8 + VISIBLE "ok " DIFF OF SUM OF 4 AN 4.4 AN 0.4 + + BTW 9 + VISIBLE "ok " SUM OF SUM OF 4 AN 4 AN QUOSHUNT OF 4 AN 4 + + BTW 10 + VISIBLE "ok " QUOSHUNT OF DIFF OF 44 AN 4 AN 4 + + BTW 11 + VISIBLE "ok " SUM OF QUOSHUNT OF 4 AN 0.4 AN QUOSHUNT OF 4 AN 4 + + BTW 12 + VISIBLE "ok " QUOSHUNT OF SUM OF 44 AN 4 AN 4 + + BTW 13 + VISIBLE "ok " DIFF OF FAKTORIAL OF 4 AN QUOSHUNT OF 44 AN 4 + + BTW 14 + VISIBLE "ok " DIFF OF PRODUKT OF 4 AN DIFF OF 4 AN 0.4 AN 0.4 + + BTW 15 + VISIBLE "ok " DIFF OF PRODUKT OF 4 AN 4 AN QUOSHUNT OF 4 AN 4 + + BTW 16 + VISIBLE "ok " QUOSHUNT OF PRODUKT OF PRODUKT OF 4 AN 4 AN 4 AN 4 + + BTW 17 + VISIBLE "ok " SUM OF PRODUKT OF 4 AN 4 AN QUOSHUNT OF 4 AN 4 + + BTW 18 + VISIBLE "ok " SUM OF PRODUKT OF 44 AN 0.4 AN 0.4 + + BTW 19 + VISIBLE "ok " DIFF OF DIFF OF FAKTORIAL OF 4 AN 4 AN QUOSHUNT OF 4 AN 4 + + BTW 20 + VISIBLE "ok " PRODUKT OF 4 AN SUM OF QUOSHUNT OF 4 AN 4 AN 4 + +KTHXBYE Index: languages/lolcode/t/05-math.t === --- languages/lolcode/t/05-math.t (revision 0) +++ languages/lolcode/t/05-math.t (revision 0) @@ -0,0 +1,38 @@ +
Problem with lexical scoping
Hi all,
I was checking a couple of things in the compiler that I wrote and put
together a simple program:
let x = 1 in let x = x + 1 in x
which ends up being pretty much equivalent to the perl5:
my $x = 1; { my $x = $x + 1; print "$x\n"; }
The generated code doesn't work however. The problem seems to come
down to the problem that in PIR you cannot distinquish between lexical
variables of an outer scope and an inner scope that have the same name
(try running the following PIR).
.namespace
.sub "outer"
new $P12, "Integer"
assign $P12, 1
.lex "x", $P12
get_global $P18, "inner"
newclosure $P18, $P18
$P17 = $P18()
print $P17
print "\n"
.end
.sub "inner" :outer("outer")
find_lex $P14, "x"
n_add $P15, $P14, 1
.lex "x", $P15
.return ($P15)
.end
One might think that because the .lex in "inner" comes after the
find_lex it would find the outer "x" var, but it doesn't seem to. The
only reason I can think of is that it is because the LexInfo is
defined at compile time based on the .lexs in a scope.
I'm not sure what is wrong. The solutions that I can think of for
this are:
* mangle variable names in PAST so that we can distinquish the scopes
from the var names
* change how PIR and LexInfos work to pay attention to the order in
which lexical vars are declared and used in scopes
Any ideas?
Andrew Parker
Problem with lexical scoping
From: Andrew Parker <[EMAIL PROTECTED]>
Date: Mon, 11 Feb 2008 22:27:27 +0100
Hi all,
I was checking a couple of things in the compiler that I wrote and put
together a simple program:
let x = 1 in let x = x + 1 in x
which ends up being pretty much equivalent to the perl5:
my $x = 1; { my $x = $x + 1; print "$x\n"; }
The generated code doesn't work however. The problem seems to come
down to the problem that in PIR you cannot distinquish between lexical
variables of an outer scope and an inner scope that have the same name
(try running the following PIR) . . .
One might think that because the .lex in "inner" comes after the
find_lex it would find the outer "x" var, but it doesn't seem to. The
only reason I can think of is that it is because the LexInfo is
defined at compile time based on the .lexs in a scope.
Yes; .lex is more of a declaration, and is scoped to the whole sub.
I'm not sure what is wrong. The solutions that I can think of for
this are:
* mangle variable names in PAST so that we can distinquish the scopes
from the var names
This is what I do (for now anyway).
* change how PIR and LexInfos work to pay attention to the order in
which lexical vars are declared and used in scopes
That would certainly require some work to implement in Parrot, but it
would have the strong advantage of giving Parrot more detailed variable
metadata, the sort that debuggers need to report variable values in HLL
terms, and evaluate expressions in context.
Any ideas?
Andrew Parker
A third solution, which is certainly more complicated for the compiler
writer, is to split out each lexical scope into its own sub, though this
may not be feasible for your language if it allows "goto" into scopes.
This is the only solution for taking distinct closures within loops; see
the "Lexical scopes are too coarse-grained for loops" discussion
(RT#44395) of 3-Aug-07.
HTH,
-- Bob Rogers
http://rgrjr.dyndns.org/
Re: [svn:parrot] r25656 - in trunk: include/parrot src tools/build
On Monday 11 February 2008 15:41:42 [EMAIL PROTECTED] wrote: > Log: > Added Parrot_assert() as a true assert wrapper around Parrot_confess(), > because splint needs to operate on a function to understand the assert() > semantics, not a macro How do we get the assert() semantics where it gets compiled out in non-debugging builds? -- c
Quick config/auto/pack.pm Question
I noticed the following in pack.pm.
sub _set_ptrconst {
my ($conf, $ptrsize, $intsize, $longsize) = @_;
if ( $intsize == $ptrsize ) {
$conf->data->set( ptrconst => "u" );
}
elsif ( $longsize == $ptrsize ) {
$conf->data->set( ptrconst => "ul" );
}
else {
warn <<"AARGH";
Configure.pl: Unable to find an integer type that fits a pointer.
AARGH
}
}
The first condition is good, but I don't think the second ($longsize ==
$ptrsize) is. "l" is documented as:
l A signed long (32-bit) value.
So, this only works okay if $longsize is 4, or am I missing something?
Shouldn't it better be like this?
sub _set_ptrconst {
my ($conf, $ptrsize) = @_;
if ( $ptrsize == 2 ) {
$conf->data->set( ptrconst => "us" );
}
elsif ( $ptrsize == 4 ) {
$conf->data->set( ptrconst => "ul" );
}
elsif ( $ptrsize == 8 ) {
$conf->data->set( ptrconst => "uq" );
}
else {
warn <<"AARGH";
Configure.pl: Unable to find an integer type that fits a pointer.
AARGH
}
}
Ron
[perl #50708] segfault in pbc_merge
# New Ticket Created by Ryan Voots # Please include the string: [perl #50708] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=50708 > When calling pbc_merge outside of the parrot root I encountered a segfault because pbc_merge cannot find lua_group.so, when run inside the parrot root it is able to find the .so inside the runtime directory. a simple test case of this is to compile these two files to pbc's and then use pbc_merge on them outside the parrot root. I would think either an option to pbc_merge to tell it where to find the parrot runtime, or an envrionment variable might be appropriate, but a check should be made that it can find the needed files to merge and print an error when not found -BEGIN main.pir- .HLL 'Lua', 'lua_group' .sub _main :main _testcall() .end --END main.pir-- -BEGIN call.pir- .sub _testcall print 42 .end --END call.pir--
Re: Quick config/auto/pack.pm Question
Ron Blaschke wrote: "l" is documented as: l A signed long (32-bit) value. I'm not expert in this, so let me ask: Where is this documented other than 'perldoc -f pack'? kid51 (... who refactored the code cited into subroutines but didn't come up with it in the first place.)
