Perl optimizes // away incorrectly #7209

p5pRT · 2004-03-31T20:58:32Z

Migrated from rt.perl.org#28123 (status was 'resolved')

Searchable as RT28123$

p5pRT · 2004-03-31T20:58:33Z

From [email protected]

Created by [email protected]

Perl seems to be optimizing away // at compile time as if it were ||. A few
examples:

$ perl -e 'print 0 // 2'
2

$ perl -e 'use constant FOO => ""; print FOO // 2'
2

$ perl -MO=Deparse -e 'print 0 // 2'
print 2;
-e syntax OK

Perl Info


Flags:
    category=core
    severity=high

Site configuration information for perl v5.9.1:

Configured by Gentoo at Wed Mar 31 11:41:30 PST 2004.

Summary of my perl5 (revision 5 version 9 subversion 1) configuration:
  Platform:
    osname=linux, osvers=2.6.5-rc2-mm3, archname=i686-linux-thread-multi
    uname='linux cytherea.office.gossamer-threads.com 2.6.5-rc2-mm3 #1 thu mar 25 15:51:44 pst 2004 i686 amd athlon(tm) xp authenticamd gnulinux '
    config_args='-des -Darchname=i686-linux-thread -Dcccdlflags=-fPIC -Dccdlflags=-rdynamic -Dcc=gcc -Dprefix=/usr -Dvendorprefix=/usr -Dsiteprefix=/usr -Dlocincpth=  -Doptimize=-march=athlon-xp -O3 -mmmx -msse -m3dnow -mfpmath=sse -pipe -fomit-frame-pointer -fforce-addr -funroll-loops -frerun-loop-opt -Dusedevel -Duselargefiles -Dd_dosuid -Dd_semctl_semun -Dscriptdir=/usr/bin -Dman3ext=3pm -Dcf_by=Gentoo -Ud_csh -Dusethreads -Di_gdbm -Di_db -Di_ndbm'
    hint=recommended, useposix=true, d_sigaction=define
    usethreads=define useithreads=define usemultiplicity=define
    useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
    use64bitint=undef use64bitall=undef uselongdouble=undef
    usemymalloc=n, bincompat5005=undef
  Compiler:
    cc='gcc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -fno-strict-aliasing -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
    optimize='-march=athlon-xp -O3 -mmmx -msse -m3dnow -mfpmath=sse -pipe -fomit-frame-pointer -fforce-addr -funroll-loops -frerun-loop-opt',
    cppflags='-DPERL5 -D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -fno-strict-aliasing'
    ccversion='', gccversion='3.3.2 20031218 (Gentoo Linux 3.3.2-r5, propolice-3.3-7)', gccosandvers=''
    intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
    ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
    alignbytes=4, prototype=define
  Linker and Libraries:
    ld='gcc', ldflags =' -L/usr/local/lib'
    libpth=/usr/local/lib /lib /usr/lib
    libs=-lpthread -lnsl -lndbm -lgdbm -ldb -ldl -lm -lcrypt -lutil -lc
    perllibs=-lpthread -lnsl -ldl -lm -lcrypt -lutil -lc
    libc=/lib/libc-2.3.3.so, so=so, useshrplib=false, libperl=libperl.a
    gnulibc_version='2.3.3'
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic'
    cccdlflags='-fPIC', lddlflags='-shared -L/usr/local/lib'

Locally applied patches:
    


@INC for perl v5.9.1:
    /etc/perl
    /usr/lib/perl5/site_perl/5.9.1/i686-linux-thread-multi
    /usr/lib/perl5/site_perl/5.9.1
    /usr/lib/perl5/site_perl
    /usr/lib/perl5/vendor_perl/5.9.1/i686-linux-thread-multi
    /usr/lib/perl5/vendor_perl/5.9.1
    /usr/lib/perl5/vendor_perl
    /usr/lib/perl5/5.9.1/i686-linux-thread-multi
    /usr/lib/perl5/5.9.1
    /usr/local/lib/site_perl
    .


Environment for perl v5.9.1:
    HOME=/home/jagerman
    LANG (unset)
    LANGUAGE (unset)
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
    PATH=/usr/bin/wrappers:/bin:/usr/bin:/sbin:/usr/sbin:/usr/local/bin:/opt/bin:/usr/i686-pc-linux-gnu/gcc-bin/3.3:/opt/ati/bin:/opt/Acrobat5:/opt/f-prot:/usr/X11R6/bin:/opt/sun-j2sdk-1.4.2/bin:/opt/sun-j2sdk-1.4.2/jre/bin:/usr/qt/3/bin:/usr/games/bin:/opt/quake3:/opt/vmware/bin:/usr/X11R6/bin:/home/jagerman/bin:/opt/perl/perl-5.00404/bin:/opt/perl/perl-5.005/bin:/opt/perl/perl-5.00503/bin:/opt/perl/perl-5.6.1/bin
    PERL_BADLANG (unset)
    SHELL=/bin/bash

p5pRT · 2004-04-01T06:02:35Z

From [email protected]

On Wed, Mar 31, 2004 at 08:58:34PM +0000 perl@jagerman.com (via RT) wrote:

# New Ticket Created by perl@jagerman.com
# Please include the string: [perl #28123]
# in the subject line of all future correspondence about this issue.
# <URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=28123 >

This is a bug report for perl from perl@jagerman.com,
generated with the help of perlbug 1.35 running under perl v5.9.1.

-----------------------------------------------------------------
[Please enter your report here]

Perl seems to be optimizing away // at compile time as if it were ||. A few
examples:

$ perl -e 'print 0 // 2'
2

$ perl -e 'use constant FOO => ""; print FOO // 2'
2

$ perl -MO=Deparse -e 'print 0 // 2'
print 2;
-e syntax OK

That seems to be the right thing to do. After all, // is just like ||
except that it will only nuke undefined values instead of false ones.

Tassilo
--
$_=q#",}])!JAPH!qq(tsuJ[{@"tnirp}3..0}_$;//::niam/s~=)]3[))_$-3(rellac(=_$({
pam{rekcahbus})(rekcah{lrePbus})(lreP{rehtonabus})!JAPH!qq(rehtona{tsuJbus#;
$_=reverse,s+(?<=sub).+q#q!'"qq.\t$&."'!#+sexisexiixesixeseg;y~\n~~dddd;eval

p5pRT · 2004-04-01T06:02:37Z

The RT System itself - Status changed from 'new' to 'open'

p5pRT · 2004-04-01T06:09:57Z

From @mhx

On 2004-04-01, at 08:02:09 +0200, Tassilo von Parseval wrote:

On Wed, Mar 31, 2004 at 08:58:34PM +0000 perl@jagerman.com (via RT) wrote:

# New Ticket Created by perl@jagerman.com
# Please include the string: [perl #28123]
# in the subject line of all future correspondence about this issue.
# <URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=28123 >

This is a bug report for perl from perl@jagerman.com,
generated with the help of perlbug 1.35 running under perl v5.9.1.

-----------------------------------------------------------------
[Please enter your report here]

Perl seems to be optimizing away // at compile time as if it were ||. A few
examples:

$ perl -e 'print 0 // 2'
2

$ perl -e 'use constant FOO => ""; print FOO // 2'
2

$ perl -MO=Deparse -e 'print 0 // 2'
print 2;
-e syntax OK

That seems to be the right thing to do. After all, // is just like ||
except that it will only nuke undefined values instead of false ones.

But then it shouldn't nuke 0, or should it?
I'd expect:

$ perl -e 'print 0 // 2'
0

$ perl -e 'use constant FOO => ""; print FOO // 2'

$ perl -MO=Deparse -e 'print 0 // 2'
print 0;

Marcus

--
BOFH Excuse #378:

Operators killed by year 2000 bug bite.

p5pRT · 2004-04-01T06:16:58Z

From [email protected]

On Thu, Apr 01, 2004 at 08:08:31AM +0200 Marcus Holland-Moritz wrote:

On 2004-04-01, at 08:02:09 +0200, Tassilo von Parseval wrote:

On Wed, Mar 31, 2004 at 08:58:34PM +0000 perl@jagerman.com (via RT) wrote:

# New Ticket Created by perl@jagerman.com
# Please include the string: [perl #28123]
# in the subject line of all future correspondence about this issue.
# <URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=28123 >

This is a bug report for perl from perl@jagerman.com,
generated with the help of perlbug 1.35 running under perl v5.9.1.

-----------------------------------------------------------------
[Please enter your report here]

Perl seems to be optimizing away // at compile time as if it were ||. A few
examples:

$ perl -e 'print 0 // 2'
2

$ perl -e 'use constant FOO => ""; print FOO // 2'
2

$ perl -MO=Deparse -e 'print 0 // 2'
print 2;
-e syntax OK

That seems to be the right thing to do. After all, // is just like ||
except that it will only nuke undefined values instead of false ones.

But then it shouldn't nuke 0, or should it?

Eh, right, sorry! My mind apparently isn't working until I have finished
the first cup of coffee (only had 1/4 so far).

I withdraw in shame...

Tassilo
--
$_=q#",}])!JAPH!qq(tsuJ[{@"tnirp}3..0}_$;//::niam/s~=)]3[))_$-3(rellac(=_$({
pam{rekcahbus})(rekcah{lrePbus})(lreP{rehtonabus})!JAPH!qq(rehtona{tsuJbus#;
$_=reverse,s+(?<=sub).+q#q!'"qq.\t$&."'!#+sexisexiixesixeseg;y~\n~~dddd;eval

p5pRT · 2004-04-01T06:23:41Z

From @mhx

On 2004-03-31, at 20:58:34 -0000, perl@jagerman.com (via RT) wrote:

# New Ticket Created by perl@jagerman.com
# Please include the string: [perl #28123]
# in the subject line of all future correspondence about this issue.
# <URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=28123 >

This is a bug report for perl from perl@jagerman.com,
generated with the help of perlbug 1.35 running under perl v5.9.1.

-----------------------------------------------------------------
[Please enter your report here]

Perl seems to be optimizing away // at compile time as if it were ||. A few
examples:

$ perl -e 'print 0 // 2'
2

$ perl -e 'use constant FOO => ""; print FOO // 2'
2

$ perl -MO=Deparse -e 'print 0 // 2'
print 2;
-e syntax OK

Thanks a lot for your report.

I can confirm that this bug is still present in the latest
development version of perl. The problem was that the same
short-circuit optimization was used for || and //.

The attached patch (applied to bleadperl as change #22625)
should fix it.

Marcus

p5pRT · 2004-04-01T06:23:41Z

From @mhx

dor.diff

--- op.c.orig	2004-04-01 07:08:56.000000000 +0200
+++ op.c	2004-04-01 07:25:25.000000000 +0200
@@ -3368,7 +3368,9 @@
 	    no_bareword_allowed(first);
 	else if (ckWARN(WARN_BAREWORD) && (first->op_private & OPpCONST_BARE))
 		Perl_warner(aTHX_ packWARN(WARN_BAREWORD), "Bareword found in conditional");
-	if ((type == OP_AND) == (SvTRUE(((SVOP*)first)->op_sv))) {
+	if ((type == OP_AND &&  SvTRUE(((SVOP*)first)->op_sv)) ||
+	    (type == OP_OR  && !SvTRUE(((SVOP*)first)->op_sv)) ||
+	    (type == OP_DOR && !SvOK(((SVOP*)first)->op_sv))) {
 	    op_free(first);
 	    *firstp = Nullop;
 	    other->op_private |= OPpCONST_SHORTCIRCUIT;
--- t/op/dor.t.orig	2004-04-01 07:09:41.000000000 +0200
+++ t/op/dor.t	2004-04-01 07:58:21.000000000 +0200
@@ -10,7 +10,7 @@
 package main;
 require './test.pl';
 
-plan( tests => 30 );
+plan( tests => 33 );
 
 my($x);
 
@@ -72,3 +72,9 @@
 is( $@, '' );
 eval q# sub { print $fh /2 } #;
 like( $@, qr/^Search pattern not terminated/ );
+
+# [perl #28123] Perl optimizes // away incorrectly
+
+is(0 // 2, 0, 		'	// : left-hand operand not optimized away');
+is('' // 2, '',		'	// : left-hand operand not optimized away');
+is(undef // 2, 2, 	'	// : left-hand operand optimized away');

p5pRT · 2004-04-01T23:15:56Z

@iabyn - Status changed from 'open' to 'resolved'

p5pRT · 2004-04-05T07:31:04Z

From @Tux

On Thu 01 Apr 2004 08:22, Marcus Holland-Moritz <mhx-perl@gmx.net> wrote:

I can confirm that this bug is still present in the latest
development version of perl. The problem was that the same
short-circuit optimization was used for || and //.

The attached patch (applied to bleadperl as change #22625)
should fix it.

Thanks, that change now also included in the dor-patch for 5.8.x
most recent version available on CPAN

$CPAN/authors/id/H/HM/HMBRAND/dor@22645.diff

Enjoy, Have FUN!

Marcus

--
H.Merijn Brand Amsterdam Perl Mongers (http://amsterdam.pm.org/)
using perl-5.6.1, 5.8.3, & 5.9.x, and 806 on HP-UX 10.20 & 11.00, 11i,
AIX 4.3, SuSE 9.0, and Win2k. http://www.cmve.net/~merijn/
http://archives.develooper.com/daily-build@perl.org/ perl-qa@perl.org
send smoke reports to: smokers-reports@perl.org, QA: http://qa.perl.org

p5pRT closed this as completed Apr 1, 2004

p5pRT added Severity High distro-Linux type-core labels Oct 18, 2019

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Perl optimizes // away incorrectly #7209

Perl optimizes // away incorrectly #7209

p5pRT commented Mar 31, 2004

p5pRT commented Mar 31, 2004

Uh oh!

p5pRT commented Apr 1, 2004

Uh oh!

p5pRT commented Apr 1, 2004

Uh oh!

p5pRT commented Apr 1, 2004

Uh oh!

p5pRT commented Apr 1, 2004

Uh oh!

p5pRT commented Apr 1, 2004

Uh oh!

p5pRT commented Apr 1, 2004

Uh oh!

p5pRT commented Apr 1, 2004

Uh oh!

p5pRT commented Apr 5, 2004

Uh oh!

Perl optimizes // away incorrectly #7209

Perl optimizes // away incorrectly #7209

Comments

p5pRT commented Mar 31, 2004

p5pRT commented Mar 31, 2004

From [email protected]

Created by [email protected]

Uh oh!

p5pRT commented Apr 1, 2004

From [email protected]

Uh oh!

p5pRT commented Apr 1, 2004

Uh oh!

p5pRT commented Apr 1, 2004

From @mhx

Uh oh!

p5pRT commented Apr 1, 2004

From [email protected]

Uh oh!

p5pRT commented Apr 1, 2004

From @mhx

Uh oh!

p5pRT commented Apr 1, 2004

From @mhx

Uh oh!

p5pRT commented Apr 1, 2004

Uh oh!

p5pRT commented Apr 5, 2004

From @Tux

Uh oh!