Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

no-iteration until loop incorrectly optimised away #10236

Open
p5pRT opened this issue Mar 17, 2010 · 4 comments
Open

no-iteration until loop incorrectly optimised away #10236

p5pRT opened this issue Mar 17, 2010 · 4 comments

Comments

@p5pRT
Copy link

p5pRT commented Mar 17, 2010

Migrated from rt.perl.org#73618 (status was 'open')

Searchable as RT73618$

@p5pRT
Copy link
Author

p5pRT commented Mar 17, 2010

From zefram@fysh.org

Created by zefram@fysh.org

$ perl -lwe 'sub foo { $i=0; while($i) { } } print foo()'
0
$ perl -lwe 'sub foo { while(0) { } } print foo()'

$

These two should really behave the same. The former is compiled as
a real loop, which terminates on the first test of $i, and `returns'
the last value computed. (The return value of the statement is, of
course, only visible due to it being the last statement in the function.)
The latter is optimised to no ops, `returning' an empty list. I think
the latter should instead have been compiled to a const op, with value 0,
which would in turn be optimised out if it were not the last statement
of the function.

Perl Info

Flags:
    category=core
    severity=low

Site configuration information for perl 5.10.0:

Configured by Debian Project at Fri Aug 28 22:23:22 UTC 2009.

Summary of my perl5 (revision 5 version 10 subversion 0) configuration:
  Platform:
    osname=linux, osvers=2.6.30.5-dsa-amd64, archname=x86_64-linux-gnu-thread-multi
    uname='linux brahms 2.6.30.5-dsa-amd64 #1 smp mon aug 17 02:18:43 cest 2009 x86_64 gnulinux '
    config_args='-Dusethreads -Duselargefiles -Dccflags=-DDEBIAN -Dcccdlflags=-fPIC -Darchname=x86_64-linux-gnu -Dprefix=/usr -Dprivlib=/usr/share/perl/5.10 -Darchlib=/usr/lib/perl/5.10 -Dvendorprefix=/usr -Dvendorlib=/usr/share/perl5 -Dvendorarch=/usr/lib/perl5 -Dsiteprefix=/usr/local -Dsitelib=/usr/local/share/perl/5.10.0 -Dsitearch=/usr/local/lib/perl/5.10.0 -Dman1dir=/usr/share/man/man1 -Dman3dir=/usr/share/man/man3 -Dsiteman1dir=/usr/local/man/man1 -Dsiteman3dir=/usr/local/man/man3 -Dman1ext=1 -Dman3ext=3perl -Dpager=/usr/bin/sensible-pager -Uafs -Ud_csh -Ud_ualarm -Uusesfio -Uusenm -DDEBUGGING=-g -Doptimize=-O2 -Duseshrplib -Dlibperl=libperl.so.5.10.0 -Dd_dosuid -des'
    hint=recommended, useposix=true, d_sigaction=define
    useithreads=define, usemultiplicity=define
    useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
    use64bitint=define, use64bitall=define, uselongdouble=undef
    usemymalloc=n, bincompat5005=undef
  Compiler:
    cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
    optimize='-O2 -g',
    cppflags='-D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fno-strict-aliasing -pipe -I/usr/local/include'
    ccversion='', gccversion='4.3.2', gccosandvers=''
    intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
    ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
    alignbytes=8, prototype=define
  Linker and Libraries:
    ld='cc', ldflags =' -L/usr/local/lib'
    libpth=/usr/local/lib /lib /usr/lib /lib64 /usr/lib64
    libs=-lgdbm -lgdbm_compat -ldb -ldl -lm -lpthread -lc -lcrypt
    perllibs=-ldl -lm -lpthread -lc -lcrypt
    libc=/lib/libc-2.7.so, so=so, useshrplib=true, libperl=libperl.so.5.10.0
    gnulibc_version='2.7'
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E'
    cccdlflags='-fPIC', lddlflags='-shared -O2 -g -L/usr/local/lib'

Locally applied patches:
    


@INC for perl 5.10.0:
    /etc/perl
    /usr/local/lib/perl/5.10.0
    /usr/local/share/perl/5.10.0
    /usr/lib/perl5
    /usr/share/perl5
    /usr/lib/perl/5.10
    /usr/share/perl/5.10
    /usr/local/lib/site_perl
    .


Environment for perl 5.10.0:
    HOME=/home/zefram
    LANG (unset)
    LANGUAGE (unset)
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
    PATH=/home/zefram/pub/x86_64-unknown-linux-gnu/bin:/home/zefram/pub/common/bin:/usr/bin:/usr/X11R6/bin:/bin:/usr/local/bin:/usr/games
    PERL_BADLANG (unset)
    SHELL=/usr/bin/zsh

@p5pRT
Copy link
Author

p5pRT commented Mar 18, 2010

From @nwc10

On Wed, Mar 17, 2010 at 02​:37​:33PM -0700, Zefram wrote​:

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

[Please enter your report here]

$ perl -lwe 'sub foo { $i=0; while($i) { } } print foo()'
0
$ perl -lwe 'sub foo { while(0) { } } print foo()'

$

These two should really behave the same. The former is compiled as
a real loop, which terminates on the first test of $i, and `returns'
the last value computed. (The return value of the statement is, of
course, only visible due to it being the last statement in the function.)
The latter is optimised to no ops, `returning' an empty list. I think
the latter should instead have been compiled to a const op, with value 0,
which would in turn be optimised out if it were not the last statement
of the function.

Historically, the return values of control structures have been "undefined".
I don't see a reason not incrementally define what each means - I suspect
that it hasn't happened simply because no-one has had the itch to work on it.

For this particular case, yes, 0 seems sane, although I'm wondering whether
it would actually be better as &PL_sv_no - ie the result of 0 == 1

Nicholas Clark

@p5pRT
Copy link
Author

p5pRT commented Mar 18, 2010

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

@p5pRT
Copy link
Author

p5pRT commented Jul 3, 2012

From @doy

Fixed in 317f3b6, but only for the case of 'while', not the case of
'until'. Fixing 'until' is harder because the parser itself rewrites
"until (1)" to "while (!1)" directly, and so "!1" is constant-folded to
'' before the while loop is even constructed. I'll leave this open (with
an updated title) in the hopes that someone else feels like fixing that
aspect of it (I left a TODO test in t/op/loopctl.t).

-doy

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants