Re: [perl #18189] Test failures with 'long long' on i386/linux
Andy Dougherty
> This bug seems to have resolved itself at least on amd64/linux. Please
> re-open this bug if it's still failing for you. Thanks for reporting.
This configuration (intval=long long, opcode=long long, i386/linux) still
fails. Last time I tried, it didn't even build, failing with a core dump
at
../../parrot mklib.pir >PGE/Library.pir
make: *** [PGE.pbc] Error 139
If I force it to run the test suite anyway, I still see *lots* of
failures. Of course I don't know if this configuration is expected to
work or not, but I'm pretty sure it used to a very long time ago.
Failed Test Stat Wstat Total Fail Failed List of Failed
-------------------------------------------------------------------------------
t/compilers/imcc/syn/bsr.t 1 256 12 1 8.33% 8
t/compilers/imcc/syn/tail.t 3 768 6 3 50.00% 1-3
t/compilers/pge/p5regexp/p5rx.t 254 65024 800 357 44.62% 1-77 83-87 89-
98 101-129 137
145-147 150-
154 158-159
165-166 168-
170 173-183
186-231 235-
240 242 245
250-251 255
258-259 262-
263 399-406
409-418 420-
421 423-427
430-431 433-
434 437-438
450-451 456-
457 486 494
497 499 513-
514 516-521
525-526 529-
530 533-535
537-539 542
546-547 550-
552 555 558-
562 565 567
608 618-620
622 626 636-
638 640 644
654-662 672-
680 690-692
694 698 708-
716 726-734
744-746 748
752 762-770
780-788 798-
799
t/compilers/pge/p6rules/backtrack 17 4352 17 17 100.00% 1-17
t/compilers/pge/p6rules/builtins. 67 17152 71 67 94.37% 1-59 61-68
t/compilers/pge/p6rules/capture.t 44 11264 44 44 100.00% 1-44
t/compilers/pge/p6rules/cclass.t 58 14848 62 58 93.55% 1-18 20-55 57-
60
t/compilers/pge/p6rules/closure.t 3 768 3 3 100.00% 1-3
t/compilers/pge/p6rules/context.t 19 4864 20 19 95.00% 1-15 17-20
t/compilers/pge/p6rules/metachars 192 49152 208 192 92.31% 1-65 68 70-78
81 85 87 89-95
97-101 107-208
t/compilers/pge/p6rules/modifiers 94 24064 98 94 95.92% 1-86 88-91 93-
96
t/compilers/pge/p6rules/subrules. 6 1536 6 6 100.00% 1-6
t/compilers/pge/p6rules/text_brk. 12 3072 12 12 100.00% 1-12
t/compilers/pge/pge-hs.t 1 256 1 1 100.00% 1
t/compilers/pge/pge.t 45 11520 45 45 100.00% 1-45
t/compilers/pge/pge_examples.t 2 512 2 2 100.00% 1-2
t/compilers/pge/pge_globs.t 22 5632 22 22 100.00% 1-22
t/compilers/tge/basic.t 1 256 2 1 50.00% 1
t/compilers/tge/grammar.t 1 256 1 1 100.00% 1
Failed Test Stat Wstat Total Fail Failed List of Failed
-------------------------------------------------------------------------------
t/compilers/tge/parser.t 1 256 1 1 100.00% 1
t/examples/pir.t 1 256 19 1 5.26% 5
t/examples/streams.t 1 256 12 1 8.33% 5
t/library/dumper.t 4 1024 27 4 14.81% 6-8 15
t/library/json.t 4 1024 22 4 18.18% 11-14
t/library/md5.t 1 256 6 1 16.67% 3
t/library/sort.t 9 2304 9 9 100.00% 1-9
t/library/streams.t 3 768 20 3 15.00% 10 13 17
t/library/test_builder_tester.t 0 11 12 8 66.67% 9-12
t/library/test_more.t 0 11 20 40 200.00% 1-20
t/op/64bit.t 1 256 1 1 100.00% 1
t/op/bitwise.t 1 256 26 1 3.85% 6
t/op/comp.t 2 512 80 2 2.50% 7-8
t/op/debuginfo.t 1 256 8 1 12.50% 8
t/op/gc.t 4 1024 22 4 18.18% 14-15 17 22
t/op/macro.t 1 256 18 1 5.56% 15
t/op/spawnw.t 1 256 7 1 14.29% 7
t/pmc/boolean.t 1 256 9 1 11.11% 6
t/pmc/complex.t 6 1536 25 6 24.00% 5-8 24-25
t/pmc/delegate.t 2 512 9 2 22.22% 8-9
t/pmc/fixedpmcarray.t 1 256 14 1 7.14% 10
t/pmc/fixedstringarray.t 1 256 13 1 7.69% 13
t/pmc/float.t 15 3840 45 15 33.33% 2-9 39-45
t/pmc/hash.t 2 512 37 2 5.41% 9 14
t/pmc/integer.t 1 256 16 1 6.25% 11
t/pmc/managedstruct.t 4 1024 6 4 66.67% 2-5
t/pmc/mmd.t 18 4608 31 18 58.06% 11-24 26-28 30
t/pmc/n_arithmetics.t 9 2304 20 9 45.00% 6 9-13 15-17
t/pmc/nci.t 24 6144 60 24 40.00% 2-3 5 8 26-37
42 46-48 50-53
t/pmc/object-meths.t 2 512 33 2 6.06% 29 32
t/pmc/objects.t 6 1536 63 6 9.52% 48-52 61
t/pmc/perlhash.t 1 256 37 1 2.70% 13
t/pmc/perlint.t 48 12288 70 48 68.57% 10-11 13-17
20-21 23-36
38-40 42-47
49-58 60-61 63
65-66 70
t/pmc/perlnum.t 30 7680 55 30 54.55% 7-34 45-46
t/pmc/perlstring.t 39 9984 67 39 58.21% 6 15-18 20-21
24-45 49-57 62
t/pmc/perlundef.t 8 2048 10 8 80.00% 1-5 7-8 10
t/pmc/pmc.t 3 768 24 3 12.50% 10-11 23
t/pmc/resizablepmcarray.t 1 256 23 1 4.35% 14
t/pmc/resizablestringarray.t 1 256 28 1 3.57% 21
t/pmc/string.t 15 3840 38 15 39.47% 4 8 11-13 17-
25 28
t/pmc/sub.t 2 512 41 2 4.88% 11-12
t/pmc/tqueue.t 1 256 1 1 100.00% 1
t/pmc/undef.t 1 256 10 1 10.00% 1
t/src/compiler.t 1 256 1 1 100.00% 1
t/src/io.t 2 512 20 2 10.00% 4 7
Failed 64/228 test scripts, 71.93% okay. 1249/4846 subtests failed, 74.23% okay.
9 tests and 728 subtests skipped.
--
Andy Dougherty doug...@lafayette.edu
Leopold Toetsch
On Feb 16, 2006, at 17:34, Andy Dougherty wrote:
>
>> This bug seems to have resolved itself at least on amd64/linux.
>> Please
>> re-open this bug if it's still failing for you. Thanks for reporting.
A long long is 64 bit on amd64/linux this is the standard config and of
course is working.
> This configuration (intval=long long, opcode=long long, i386/linux)
> still
> fails.
sizeof(opcode_t) != sizeof(void*) is for sure broken. But why would one
use 64-bit opcodes on a 32-bit system?
leo
Andy Dougherty
>
> On Feb 16, 2006, at 17:34, Andy Dougherty wrote:
>
> >
> >> This bug seems to have resolved itself at least on amd64/linux.
> >> Please
> >> re-open this bug if it's still failing for you. Thanks for reporting.
>
> A long long is 64 bit on amd64/linux this is the standard config and of
> course is working.
>
> > This configuration (intval=long long, opcode=long long, i386/linux)
> > still
> > fails.
>
> sizeof(opcode_t) != sizeof(void*) is for sure broken.
Well, it used to work, but that was a long time ago. Configure actually
tests for this case and still claims it will work; perhaps that test
should be changed to emit a much more dire message, or even die (unless
overridden).
> But why would one
> use 64-bit opcodes on a 32-bit system?
At the time I submitted the original bug report, that's what you would get
by default if you happened to use a 64-bit perl to run parrot's
Configure.pl. Since I could easily see that sort of thing happening, I
used to test for it.
Now, Configure.pl no longer picks 'long long' by default in such
situations, so you have to go out of your way to get this configuration.
At this point, I don't particuarly care. I only bothered to test it
because I was asked to.
--
Andy Dougherty doug...@lafayette.edu
Joshua Hoblitt via RT
re-open this bug if it's still failing for you. Thanks for reporting.
-J
--
Leopold Toetsch
On Feb 16, 2006, at 19:24, Andy Dougherty wrote:
>> sizeof(opcode_t) != sizeof(void*) is for sure broken.
>
> Well, it used to work, but that was a long time ago. Configure
> actually
> tests for this case and still claims it will work; perhaps that test
> should be changed to emit a much more dire message, or even die (unless
> overridden).
It's not really easy to state, which type combinations are valid,
because the combinations depend on other config options. Given that
current type abuse in parrot were fixed, we'd have these constraints:
sizeof(opcode_t) >= sizeof(INTVAL) [1]
sizeof(void *) >= sizeof(INTVAL) [2]
[1] We are storing INTVAL constants in the opcode stream directly.
Moving INTVAL constants into the constant table or decode INTVAL
constants with more than one opcode would fix that
[2] The direct threaded run core (CGP) is using labels as values, which
are 'void *' according to 'info gcc'. The prederefed opcode stream also
contains INTVAL constants.
If the C compiler doesn't provide this feature there is still the
prederefed switched runcore where a mix of (opcode_t, INTVAL, and
void*) is in the opcode stream, but that could be a max-sized type
probably.
I hope that makes some sense,
leo