develooper Front page | perl.perl5.porters | Postings from May 2010

Re: 5.12: inplace sort <*> segfault (gcc 4.5.0 bug?)

Thread Previous | Thread Next
May 11, 2010 03:35
Re: 5.12: inplace sort <*> segfault (gcc 4.5.0 bug?)
Message ID:
Alex Hunsaker <> wrote:
:(Find at the bottom gcc, perl -V and uname output)
:While trying to get mod_perl 2 up and running on 5.12, running perl
:Makefile.PL resulted in segfaults.  It boiled down to some sorts
:Apache-Test/lib/Apache/  Commenting those out
:everything was peachy.  Find below a simple test case:
:$  ./perl -Ilib/ -e 'sort glob("*")'
:Segmentation fault

I get the same result with gcc-4.5.0 here, only with -Dusemultiplicity.

There are two calls to S_is_inplace_av(). In the second case (OP_REVERSE):

            if ((oright = cLISTOPo->op_first)
                    && (oright->op_type == OP_PUSHMARK)
                    && (oright = oright->op_sibling)
                    && (oleft = is_inplace_av(o, oright))) {

gcc has added a NULL check just after the (oright = oright->op_sibling)
before calling is_inplace_av(). In the first case (OP_SORT):

            if (oright->op_type == OP_NULL) { /* skip sort block/sub */
                oright = cUNOPx(oright)->op_sibling;
            oleft = is_inplace_av(o, oright);

it hasn't added the extra check that would allow it to elide it within
S_is_inplace_av() itself.

(Note also the inconsistency of 'oright->op_sibling' v.
'cUNOPx(oright)->op_sibling' - I think either the first is wrong or
the second is redundant. I'm not sure whether the cast in the second
case is helping to cause the confusion for gcc.)

I'll try to distil this down to a bug report for gcc; I suggest a hint
to lower optimization for op.c in this case (gcc-4.5.x and usemultiplicity).
I don't see the same problem with gcc-4.4.3.


Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About