Skip Menu |
Report information
Id: 133495
Status: pending release
Priority: 0/
Queue: perl5

Owner: Nobody
Requestors: hako [at] affrc.go.jp
Cc:
AdminCc:

Operating System: (no value)
PatchStatus: (no value)
Severity: medium
Type: core
Perl Version: 5.26.2
Fixed In: (no value)



From: Hiroshi Hakoyama <hako [...] affrc.go.jp>
Date: Mon, 3 Sep 2018 08:59:27 +0900
Subject: perl-5.28.0 fails to build on Solaris 10
CC: solaris-pkg-people [...] NetBSD.org, gnats-admin [...] netbsd.org, pkgsrc-bugs [...] netbsd.org
To: perlbug [...] perl.org
Download (untitled) / with headers
text/plain 5.2k
This is a bug report for perl from hako@affrc.go.jp, generated with the help of perlbug 1.40 running under perl 5.26.2. ----------------------------------------------------------------- [Please describe your issue here] perl-5.28.0 fails to build on Solaris 10. I send this bug report with an advice from Benny, gnats-bugs@netbsd.org. Thanks in advance. Hiroshi Hakoyama The following reply was made to PR pkg/53568; it has been noted by GNATS. From: Benny Siegert <bsiegert@gmail.com> To: gnats-bugs@netbsd.org Cc: pkg-manager@netbsd.org, gnats-admin@netbsd.org, pkgsrc-bugs@netbsd.org Subject: Re: pkg/53568: perl-5.28.0 fails to build on Solaris 10 Date: Sun, 2 Sep 2018 16:06:27 +0000 perl-5.28.0 fails to build on Solaris 10. perl-5.26.2 was OK. ... gcc -c -DPERL_CORE -D_REENTRANT -O3 -mcpu=3Dultrasparc3 -mtune=3Dultraspa= rc3 -D_FORTIFY_SOURCE=3D2 -pthread -I/usr/include -fwrapv -fno-strict-alias= ing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=3D64= -DPERL_USE_SAFE_PUTENV -O3 -mcpu=3Dultrasparc3 -mtune=3Dultrasparc3 -D_FOR= TIFY_SOURCE=3D2 -pthread -I/usr/include -Wall -Werror=3Ddeclaration-after-s= tatement -Werror=3Dpointer-arith -Wextra -Wc++-compat -Wwrite-strings -fPIC= miniperlmain.c gcc -pthread -L/usr/lib -Wl,-R/usr/lib -Wl,-R/usr/pkg/lib -o miniperl op= mini.o perlmini.o gv.o toke.o perly.o pad.o regcomp.o dump.o util.o mg.o r= eentr.o mro_core.o keywords.o hv.o av.o run.o pp_hot.o sv.o pp.o scope.o pp= _ctl.o pp_sys.o doop.o doio.o regexec.o utf8.o taint.o deb.o universal.o gl= obals.o perlio.o perlapi.o numeric.o mathoms.o locale.o pp_pack.o pp_sort.o= caretx.o dquote.o time64.o miniperlmain.o -lm -ldl -lsocket -lnsl -lpthr= ead -lrt LD_LIBRARY_PATH=3D/usr/pkgsrc/lang/perl5/work/perl-5.28.0 ./miniperl -w -= Ilib -Idist/Exporter/lib -MExporter -e '<?>' || sh -c 'echo >&2 Failed to b= uild miniperl. Please run make minitest; exit 1' /usr/bin/bash: line 1: 28934 Bus Error (core dumped) LD_LIB= RARY_PATH=3D/usr/pkgsrc/lang/perl5/work/perl-5.28.0 ./miniperl -w -Ilib -Id= ist/Exporter/lib -MExporter -e '<?>' Failed to build miniperl. Please run make minitest *** Error code 1 This sounds like an upstream regression. Please file a bug report upstream (bugs.perl.org) and send a link to this list. --=20 Benny [Please do not change anything below this line] ----------------------------------------------------------------- --- Flags: category=core severity=medium --- Site configuration information for perl 5.26.2: Configured by hako at Tue May 1 10:08:44 JST 2018. Summary of my perl5 (revision 5 version 26 subversion 2) configuration: Platform: osname=solaris osvers=2.10 archname=sparc-solaris-thread-multi uname='sunos ec21 5.10 generic_147147-26 sun4u sparc sunw,sun-blade-1000 ' config_args='-sde -Dldflags= -pthread -L/usr/lib -Wl,-R/usr/lib -Wl,-R/usr/pkg/lib -Duseshrplib -Duseithreads -Uusemymalloc' hint=recommended useposix=true d_sigaction=define useithreads=define usemultiplicity=define use64bitint=undef use64bitall=undef uselongdouble=undef usemymalloc=n default_inc_excludes_dot=define bincompat5005=undef Compiler: cc='gcc' ccflags ='-D_REENTRANT -O3 -mcpu=ultrasparc3 -mtune=ultrasparc3 -D_FORTIFY_SOURCE=2 -pthread -I/usr/include -fwrapv -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DPERL_USE_SAFE_PUTENV' optimize=' -O3 -mcpu=ultrasparc3 -mtune=ultrasparc3 -D_FORTIFY_SOURCE=2 -pthread -I/usr/include' cppflags='-D_REENTRANT -O3 -mcpu=ultrasparc3 -mtune=ultrasparc3 -D_FORTIFY_SOURCE=2 -pthread -I/usr/include -fwrapv -fno-strict-aliasing -pipe -I/usr/local/include' ccversion='' gccversion='4.9.4' gccosandvers='' intsize=4 longsize=4 ptrsize=4 doublesize=8 byteorder=4321 doublekind=4 d_longlong=define longlongsize=8 d_longdbl=define longdblsize=16 longdblkind=2 ivtype='long' ivsize=4 nvtype='double' nvsize=8 Off_t='off_t' lseeksize=8 alignbytes=8 prototype=define Linker and Libraries: ld='gcc' ldflags ='-pthread -L/usr/lib -Wl,-R/usr/lib -Wl,-R/usr/pkg/lib' libpth=/usr/lib /usr/ccs/lib /usr/local/lib libs=-lm -ldl -lsocket -lnsl -lpthread -lrt perllibs=-lm -ldl -lsocket -lnsl -lpthread -lrt libc=/lib/libc.so so=so useshrplib=true libperl=libperl.so gnulibc_version='' Dynamic Linking: dlsrc=dl_dlopen.xs dlext=so d_dlsymun=undef ccdlflags=' -R /usr/pkg/lib/perl5/5.26.0/sparc-solaris-thread-multi/CORE' cccdlflags='-fPIC' lddlflags='-G -L/usr/lib -Wl,-R/usr/lib -Wl,-R/usr/pkg/lib -L/usr/local/lib' --- @INC for perl 5.26.2: /usr/pkg/lib/perl5/site_perl/5.26.0/sparc-solaris-thread-multi /usr/pkg/lib/perl5/site_perl/5.26.0 /usr/pkg/lib/perl5/vendor_perl/5.26.0/sparc-solaris-thread-multi /usr/pkg/lib/perl5/vendor_perl/5.26.0 /usr/pkg/lib/perl5/5.26.0/sparc-solaris-thread-multi /usr/pkg/lib/perl5/5.26.0 --- Environment for perl 5.26.2: HOME=/export/home/hako LANG=ja LANGUAGE (unset) LD_LIBRARY_PATH (unset) LOGDIR (unset) PATH=/usr/ccs/bin:/usr/pkg/gcc49/bin:/usr/pkg/bin:/usr/pkg/sbin:/usr/local/bin:/usr/local/sbin:/usr/sunvts/bin:/usr/bin:/usr/sbin:/usr/sadm/admin/bin:/usr/sadm/bin:/bin:/sbin:/usr/openwin/bin PERL_BADLANG (unset) SHELL=/usr/bin/tcsh
RT-Send-CC: perl5-porters [...] perl.org
On Mon, 03 Sep 2018 00:00:45 GMT, hako@affrc.go.jp wrote: Show quoted text
> This is a bug report for perl from hako@affrc.go.jp, > generated with the help of perlbug 1.40 running under perl 5.26.2. > > > ----------------------------------------------------------------- > [Please describe your issue here] > perl-5.28.0 fails to build on Solaris 10. > I send this bug report with an advice from Benny, gnats- > bugs@netbsd.org. > Thanks in advance. > > Hiroshi Hakoyama > > The following reply was made to PR pkg/53568; it has been noted by > GNATS. > > From: Benny Siegert <bsiegert@gmail.com> > To: gnats-bugs@netbsd.org > Cc: pkg-manager@netbsd.org, gnats-admin@netbsd.org, pkgsrc- > bugs@netbsd.org > Subject: Re: pkg/53568: perl-5.28.0 fails to build on Solaris 10 > Date: Sun, 2 Sep 2018 16:06:27 +0000 > > perl-5.28.0 fails to build on Solaris 10. perl-5.26.2 was OK. > > ... > gcc -c -DPERL_CORE -D_REENTRANT -O3 -mcpu=3Dultrasparc3 > -mtune=3Dultraspa= > rc3 -D_FORTIFY_SOURCE=3D2 -pthread -I/usr/include -fwrapv -fno-strict- > alias= > ing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE > -D_FILE_OFFSET_BITS=3D64= > -DPERL_USE_SAFE_PUTENV -O3 -mcpu=3Dultrasparc3 -mtune=3Dultrasparc3 > -D_FOR= > TIFY_SOURCE=3D2 -pthread -I/usr/include -Wall -Werror=3Ddeclaration- > after-s= > tatement -Werror=3Dpointer-arith -Wextra -Wc++-compat -Wwrite-strings > -fPIC= > miniperlmain.c > gcc -pthread -L/usr/lib -Wl,-R/usr/lib -Wl,-R/usr/pkg/lib -o miniperl > op= > mini.o perlmini.o gv.o toke.o perly.o pad.o regcomp.o dump.o util.o > mg.o r= > eentr.o mro_core.o keywords.o hv.o av.o run.o pp_hot.o sv.o pp.o > scope.o pp= > _ctl.o pp_sys.o doop.o doio.o regexec.o utf8.o taint.o deb.o > universal.o gl= > obals.o perlio.o perlapi.o numeric.o mathoms.o locale.o pp_pack.o > pp_sort.o= > caretx.o dquote.o time64.o miniperlmain.o -lm -ldl -lsocket -lnsl > -lpthr= > ead -lrt > LD_LIBRARY_PATH=3D/usr/pkgsrc/lang/perl5/work/perl-5.28.0 ./miniperl > -w -= > Ilib -Idist/Exporter/lib -MExporter -e '<?>' || sh -c 'echo >&2 > Failed to b= > uild miniperl. Please run make minitest; exit 1' > /usr/bin/bash: line 1: 28934 Bus Error (core dumped) > LD_LIB= > RARY_PATH=3D/usr/pkgsrc/lang/perl5/work/perl-5.28.0 ./miniperl -w > -Ilib -Id= > ist/Exporter/lib -MExporter -e '<?>' > Failed to build miniperl. Please run make minitest > *** Error code 1 > > This sounds like an upstream regression. Please file a bug report > upstream (bugs.perl.org) and send a link to this list. > > --=20 > Benny > >
We have to concede that this report is prima facie plausible, because we don't have any smoke-test reports for Perl on Solaris 2.10 since 2013 -- the perl-5.19.* development cycle (http://perl5.test-smoke.org/search; enter "Solaris" in drop-down for OS and "2.10" for OS version). We are, however, receiving satisfactory smoke-test reports for Solaris 2.11 (same site; clear the OS version drop-down). So to resolve this we'd need access to a Solaris 2.10 machine. List: any suggestions? Thank you very much. Show quoted text
> --- > Site configuration information for perl 5.26.2: > > Configured by hako at Tue May 1 10:08:44 JST 2018. > > Summary of my perl5 (revision 5 version 26 subversion 2) > configuration: > > Platform: > osname=solaris > osvers=2.10 > archname=sparc-solaris-thread-multi > uname='sunos ec21 5.10 generic_147147-26 sun4u sparc sunw,sun-blade- > 1000 ' > config_args='-sde -Dldflags= -pthread -L/usr/lib -Wl,-R/usr/lib > -Wl,-R/usr/pkg/lib -Duseshrplib -Duseithreads -Uusemymalloc' > [snip] > Compiler: > cc='gcc' > ccflags ='-D_REENTRANT -O3 -mcpu=ultrasparc3 -mtune=ultrasparc3 > -D_FORTIFY_SOURCE=2 -pthread -I/usr/include -fwrapv -fno-strict- > aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE > -D_FILE_OFFSET_BITS=64 -DPERL_USE_SAFE_PUTENV' > optimize=' -O3 -mcpu=ultrasparc3 -mtune=ultrasparc3 > -D_FORTIFY_SOURCE=2 -pthread -I/usr/include' > cppflags='-D_REENTRANT -O3 -mcpu=ultrasparc3 -mtune=ultrasparc3 > -D_FORTIFY_SOURCE=2 -pthread -I/usr/include -fwrapv -fno-strict- > aliasing -pipe -I/usr/local/include'
[snip] -- James E Keenan (jkeenan@cpan.org)
From: Leon Timmermans <fawaka [...] gmail.com>
Subject: Re: [perl #133495] perl-5.28.0 fails to build on Solaris 10
Date: Mon, 3 Sep 2018 16:30:30 +0200
CC: bugs-bitbucket [...] rt.perl.org
To: Perl5 Porters <perl5-porters [...] perl.org>
On Mon, Sep 3, 2018 at 5:34 AM Hiroshi Hakoyama (via RT) <perlbug-followup@perl.org> wrote: Show quoted text
> > # New Ticket Created by Hiroshi Hakoyama > # Please include the string: [perl #133495] > # in the subject line of all future correspondence about this issue. > # <URL: https://rt.perl.org/Ticket/Display.html?id=133495 > > > > This is a bug report for perl from hako@affrc.go.jp, > generated with the help of perlbug 1.40 running under perl 5.26.2. > > > ----------------------------------------------------------------- > [Please describe your issue here] > perl-5.28.0 fails to build on Solaris 10. > I send this bug report with an advice from Benny, gnats-bugs@netbsd.org. > Thanks in advance. > > Hiroshi Hakoyama > > The following reply was made to PR pkg/53568; it has been noted by GNATS. > > From: Benny Siegert <bsiegert@gmail.com> > To: gnats-bugs@netbsd.org > Cc: pkg-manager@netbsd.org, gnats-admin@netbsd.org, pkgsrc-bugs@netbsd.org > Subject: Re: pkg/53568: perl-5.28.0 fails to build on Solaris 10 > Date: Sun, 2 Sep 2018 16:06:27 +0000 > > perl-5.28.0 fails to build on Solaris 10. perl-5.26.2 was OK. > > ... > gcc -c -DPERL_CORE -D_REENTRANT -O3 -mcpu=3Dultrasparc3 -mtune=3Dultraspa= > rc3 -D_FORTIFY_SOURCE=3D2 -pthread -I/usr/include -fwrapv -fno-strict-alias= > ing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=3D64= > -DPERL_USE_SAFE_PUTENV -O3 -mcpu=3Dultrasparc3 -mtune=3Dultrasparc3 -D_FOR= > TIFY_SOURCE=3D2 -pthread -I/usr/include -Wall -Werror=3Ddeclaration-after-s= > tatement -Werror=3Dpointer-arith -Wextra -Wc++-compat -Wwrite-strings -fPIC= > miniperlmain.c > gcc -pthread -L/usr/lib -Wl,-R/usr/lib -Wl,-R/usr/pkg/lib -o miniperl op= > mini.o perlmini.o gv.o toke.o perly.o pad.o regcomp.o dump.o util.o mg.o r= > eentr.o mro_core.o keywords.o hv.o av.o run.o pp_hot.o sv.o pp.o scope.o pp= > _ctl.o pp_sys.o doop.o doio.o regexec.o utf8.o taint.o deb.o universal.o gl= > obals.o perlio.o perlapi.o numeric.o mathoms.o locale.o pp_pack.o pp_sort.o= > caretx.o dquote.o time64.o miniperlmain.o -lm -ldl -lsocket -lnsl -lpthr= > ead -lrt > LD_LIBRARY_PATH=3D/usr/pkgsrc/lang/perl5/work/perl-5.28.0 ./miniperl -w -= > Ilib -Idist/Exporter/lib -MExporter -e '<?>' || sh -c 'echo >&2 Failed to b= > uild miniperl. Please run make minitest; exit 1' > /usr/bin/bash: line 1: 28934 Bus Error (core dumped) LD_LIB= > RARY_PATH=3D/usr/pkgsrc/lang/perl5/work/perl-5.28.0 ./miniperl -w -Ilib -Id= > ist/Exporter/lib -MExporter -e '<?>' > Failed to build miniperl. Please run make minitest > *** Error code 1 > > This sounds like an upstream regression. Please file a bug report > upstream (bugs.perl.org) and send a link to this list. > > --=20 > Benny
Given that that is a SPARC machine, and you're receiving a SIGBUS, this is probably an alignment issue (and thus being sparc specific, not solaris specific). Can you run that miniperl command (or possibly any small one-liner) in a debugger and give us a backtrace? That should give us much more information on what's happening here. Leon
CC: solaris-pkg-people [...] NetBSD.org, gnats-admin [...] netbsd.org, pkgsrc-bugs [...] netbsd.org, gnats-bugs [...] NetBSD.org
From: Hiroshi Hakoyama <hako [...] affrc.go.jp>
Subject: Re: [perl #133495] perl-5.28.0 fails to build on Solaris 10: Re: pkg/53568: perl-5.28.0 fails to build on Solaris 10
Date: Tue, 11 Sep 2018 09:45:32 +0900
To: perlbug-followup [...] perl.org
Download (untitled) / with headers
text/plain 5.8k
I found a workaround: A build with CFLAGS+= -O2 -mcpu=ultrasparc3 -mtune=ultrasparc3 was OK. Optimization level -O3 causes the problem. Show quoted text
> Can you run that miniperl command (or possibly any small one-liner) in > a debugger and give us a backtrace? That should give us much more > information on what's happening here. > > Leon
Please see the following result: # dbx ./miniperl core For information about new features see `help changes' To remove this message, put `dbxenv suppress_startup_message 7.6' in your .dbxrc Reading miniperl dbx: warning: unknown location expression code (0xf2) dbx: warning: unknown location expression code (0x9e) dbx: warning: unknown location expression code (0x9e) dbx: warning: unknown location expression code (0x9e) dbx: warning: unknown location expression code (0x9e) dbx: warning: unknown location expression code (0x9e) dbx: warning: unknown location expression code (0x9e) dbx: warning: unknown location expression code (0x9e) dbx: warning: unknown location expression code (0x9e) dbx: warning: unknown location expression code (0x9e) dbx: warning: unknown location expression code (0x9e) dbx: warning: unknown location expression code (0x9e) dbx: warning: unknown location expression code (0x9e) dbx: warning: unknown location expression code (0x9e) dbx: warning: unknown location expression code (0x9e) dbx: warning: unknown location expression code (0x9e) dbx: warning: unknown location expression code (0x9e) dbx: warning: unknown location expression code (0x9e) dbx: warning: unknown location expression code (0x9e) dbx: warning: unknown location expression code (0x9e) core file header read successfully Reading ld.so.1 Reading libm.so.2 Reading libdl.so.1 Reading libsocket.so.1 Reading libnsl.so.1 Reading libpthread.so.1 Reading librt.so.1 Reading libssp.so.0.0.0 Reading libc.so.1 Reading libaio.so.1 Reading libmd.so.1 Reading libgcc_s.so.1 Reading libc_psr.so.1 t@1 (l@1) program terminated by signal BUS (invalid address alignment) 0x000ecf6c: Perl_hv_common+0x156c: ld [%g3], %o0 (dbx) where current thread: t@1 =>[1] Perl_hv_common(0x5b65439d, 0x338818, 0x0, 0xffbffaaa, 0x33d1e8, 0x0), at 0xecf6c [2] Perl_hv_common_key_len(0x29bba8, 0x338818, 0xffbffaaa, 0x19, 0x8, 0x0), at 0xee2f0 [3] S_init_postdump_symbols(0x29bba8, 0x338818, 0xffbffac3, 0xffbfede0, 0x19, 0xffbffaaa), at 0x5765c [4] perl_parse(0x0, 0x334290, 0x339820, 0xffbfece0, 0x1, 0x338758), at 0x5c758 [5] main(0x4, 0xffbfecd4, 0xffbfece8, 0x2959b8, 0xff170100, 0x0), at 0x1bd9dc (dbx) quit dbx: internal warning: td_ta_clear_event() failed -- debugger service failed dbx: internal warning: td_ta_sync_tracking_enable(0) failed -- debugger service failed Show quoted text
> 2018/09/03 23:30、Leon Timmermans via RT <perlbug-followup@perl.org>のメール: > > On Mon, Sep 3, 2018 at 5:34 AM Hiroshi Hakoyama (via RT) > <perlbug-followup@perl.org> wrote:
>> >> # New Ticket Created by Hiroshi Hakoyama >> # Please include the string: [perl #133495] >> # in the subject line of all future correspondence about this issue. >> # <URL: https://rt.perl.org/Ticket/Display.html?id=133495 > >> >> >> This is a bug report for perl from hako@affrc.go.jp, >> generated with the help of perlbug 1.40 running under perl 5.26.2. >> >> >> ----------------------------------------------------------------- >> [Please describe your issue here] >> perl-5.28.0 fails to build on Solaris 10. >> I send this bug report with an advice from Benny, gnats-bugs@netbsd.org. >> Thanks in advance. >> >> Hiroshi Hakoyama >> >> The following reply was made to PR pkg/53568; it has been noted by GNATS. >> >> From: Benny Siegert <bsiegert@gmail.com> >> To: gnats-bugs@netbsd.org >> Cc: pkg-manager@netbsd.org, gnats-admin@netbsd.org, pkgsrc-bugs@netbsd.org >> Subject: Re: pkg/53568: perl-5.28.0 fails to build on Solaris 10 >> Date: Sun, 2 Sep 2018 16:06:27 +0000 >> >> perl-5.28.0 fails to build on Solaris 10. perl-5.26.2 was OK. >> >> ... >> gcc -c -DPERL_CORE -D_REENTRANT -O3 -mcpu=3Dultrasparc3 -mtune=3Dultraspa= >> rc3 -D_FORTIFY_SOURCE=3D2 -pthread -I/usr/include -fwrapv -fno-strict-alias= >> ing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=3D64= >> -DPERL_USE_SAFE_PUTENV -O3 -mcpu=3Dultrasparc3 -mtune=3Dultrasparc3 -D_FOR= >> TIFY_SOURCE=3D2 -pthread -I/usr/include -Wall -Werror=3Ddeclaration-after-s= >> tatement -Werror=3Dpointer-arith -Wextra -Wc++-compat -Wwrite-strings -fPIC= >> miniperlmain.c >> gcc -pthread -L/usr/lib -Wl,-R/usr/lib -Wl,-R/usr/pkg/lib -o miniperl op= >> mini.o perlmini.o gv.o toke.o perly.o pad.o regcomp.o dump.o util.o mg.o r= >> eentr.o mro_core.o keywords.o hv.o av.o run.o pp_hot.o sv.o pp.o scope.o pp= >> _ctl.o pp_sys.o doop.o doio.o regexec.o utf8.o taint.o deb.o universal.o gl= >> obals.o perlio.o perlapi.o numeric.o mathoms.o locale.o pp_pack.o pp_sort.o= >> caretx.o dquote.o time64.o miniperlmain.o -lm -ldl -lsocket -lnsl -lpthr= >> ead -lrt >> LD_LIBRARY_PATH=3D/usr/pkgsrc/lang/perl5/work/perl-5.28.0 ./miniperl -w -= >> Ilib -Idist/Exporter/lib -MExporter -e '<?>' || sh -c 'echo >&2 Failed to b= >> uild miniperl. Please run make minitest; exit 1' >> /usr/bin/bash: line 1: 28934 Bus Error (core dumped) LD_LIB= >> RARY_PATH=3D/usr/pkgsrc/lang/perl5/work/perl-5.28.0 ./miniperl -w -Ilib -Id= >> ist/Exporter/lib -MExporter -e '<?>' >> Failed to build miniperl. Please run make minitest >> *** Error code 1 >> >> This sounds like an upstream regression. Please file a bug report >> upstream (bugs.perl.org) and send a link to this list. >> >> --=20 >> Benny
> > Given that that is a SPARC machine, and you're receiving a SIGBUS, > this is probably an alignment issue (and thus being sparc specific, > not solaris specific). > > Can you run that miniperl command (or possibly any small one-liner) in > a debugger and give us a backtrace? That should give us much more > information on what's happening here. > > Leon >
RT-Send-CC: fawaka [...] gmail.com, perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 4.6k
On Mon, 10 Sep 2018 21:47:05 -0700, hako@affrc.go.jp wrote: Show quoted text
> I found a workaround: > A build with CFLAGS+= -O2 -mcpu=ultrasparc3 -mtune=ultrasparc3 was OK. > Optimization level -O3 causes the problem.
This didn't work for me (Sun Blade 100, UltraSPARC IIe 500MHz, Solaris 10, 32-bits target), so I tried with CFLAGS="-g pipe". This did get me a working interpreter, so I added back -O2 to CFLAGS leaving in the -g in order to hopefully get a better pointer at where the alignment issue is happening. Show quoted text
> > Can you run that miniperl command (or possibly any small one-liner) > > in > > a debugger and give us a backtrace? That should give us much more > > information on what's happening here. > > > > Leon
% env LD_LIBRARY_PATH=/gentoo/prefix32/var/tmp/portage/dev-lang/perl-5.28.0/work/perl-5.28.0 gdb --args ./miniperl -w -Ilib -Idist/Exporter/lib -MExporter -e '<?>' GNU gdb (Gentoo 8.2.1 p1) 8.2.1 Copyright (C) 2018 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "sparc-sun-solaris2.10". Type "show configuration" for configuration details. For bug reporting instructions, please see: <https://bugs.gentoo.org/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from ./miniperl...done. (gdb) r Starting program: /gentoo/prefix32/var/tmp/portage/dev-lang/perl-5.28.0/work/perl-5.28.0/miniperl -w -Ilib -Idist/Exporter/lib -MExporter -e \<\?\> [Thread debugging using libthread_db enabled] [New Thread 1 (LWP 1)] Thread 2 received signal SIGSEGV, Segmentation fault. [Switching to Thread 1 (LWP 1)] 0x0004562c in zaphod32_hash_with_state (key_len=29, key=0x26d036 "dist/Exporter/lib/Exporter.pm", state_ch=<optimized out>) at zaphod32_hash.h:280 280 v1 -= U8TO32_LE(key+0); (gdb) bt #0 0x0004562c in zaphod32_hash_with_state (key_len=29, key=0x26d036 "dist/Exporter/lib/Exporter.pm", state_ch=<optimized out>) at zaphod32_hash.h:280 #1 Perl_newGP (gv=<optimized out>) at gv.c:206 #2 0x00046b38 in Perl_gv_init_pvn (gv=0x27bc30, stash=0x27b5d0, name=0x27fce2 "Debug", len=5, flags=2) at gv.c:421 #3 0x00047bc0 in Perl_gv_fetchpvn_flags (nambeg=0x27fcd8 "Exporter::Debug", full_len=15, flags=2, sv_type=<optimized out>) at gv.c:2454 #4 0x0004a704 in Perl_gv_fetchsv (name=0x27bc20, flags=2, sv_type=SVt_PV) at gv.c:1588 #5 0x00060010 in S_pending_ident () at toke.c:9059 #6 Perl_yylex () at toke.c:4847 #7 0x00076414 in Perl_yyparse (gramtype=<optimized out>) at perly.c:340 #8 0x00118d14 in S_doeval_compile (gimme=<optimized out>, outside=<optimized out>, seq=<optimized out>, hh=0x0) at pp_ctl.c:3501 #9 0x0011ec90 in S_require_file (sv=<optimized out>) at pp_ctl.c:4321 #10 Perl_pp_require () at pp_ctl.c:4345 #11 0x000d2780 in Perl_runops_standard () at run.c:42 #12 0x0003a7dc in Perl_call_sv (sv=0x27bae0, flags=<optimized out>) at perl.c:3021 #13 0x0003dcbc in Perl_call_list (oldscope=2, paramList=0x266f48) at perl.c:5065 #14 0x00016de4 in S_process_special_blocks (floor=<optimized out>, fullname=<optimized out>, cv=<optimized out>, gv=<optimized out>) #15 0x000317e0 in Perl_newATTRSUB_x (floor=47, o=<optimized out>, proto=<optimized out>, attrs=<optimized out>, block=<optimized out>, o_is_gv=<optimized out>) at op.c:10269 #16 0x00035e40 in Perl_utilize (aver=<optimized out>, floor=47, version=<optimized out>, idop=<optimized out>, arg=<optimized out>) at op.c:7484 #17 0x00077988 in Perl_yyparse (gramtype=<optimized out>) at perly.y:329 #18 0x00042930 in S_parse_body (xsinit=<optimized out>, env=<optimized out>) at perl.c:2509 #19 perl_parse (my_perl=<optimized out>, xsinit=<optimized out>, argc=<optimized out>, argv=<optimized out>, env=<optimized out>) at perl.c:1803 #20 0x00012e38 in main (argc=<optimized out>, argv=<optimized out>, env=<optimized out>) at miniperlmain.c:127 % gcc --version gcc (Gentoo 8.2.0-r5 p1.6) 8.2.0 Copyright (C) 2018 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. % ld --version GNU ld (Gentoo 2.29.1 p3) 2.29.1 Copyright (C) 2017 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or (at your option) a later version. This program has absolutely no warranty.
RT-Send-CC: fawaka [...] gmail.com, perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 1.2k
On Wed, 16 Jan 2019 01:50:32 -0800, grobian@gentoo.org wrote: Show quoted text
> Thread 2 received signal SIGSEGV, Segmentation fault. > [Switching to Thread 1 (LWP 1)] > 0x0004562c in zaphod32_hash_with_state (key_len=29, > key=0x26d036 "dist/Exporter/lib/Exporter.pm", state_ch=<optimized
> out>)
> at zaphod32_hash.h:280 > 280 v1 -= U8TO32_LE(key+0);
Sorry I didn't report this at my first message. I just found a bit of time to look into this. my Configure run somehow found: try.c: In function 'main': try.c:46:28: warning: format '%x' expects argument of type 'unsigned int', but argument 2 has type 'long unsigned int' [-Wformat=] printf("read failed (%x)\n", *up); ~^ ~~~ %lx try.c:56:29: warning: format '%x' expects argument of type 'unsigned int', but argument 2 has type 'long unsigned int' [-Wformat=] printf("write failed (%x)\n", *up); ~^ ~~~ %lx (Testing for character data alignment may crash the test. That's okay.) You can access character data pretty unalignedly. This is obviously wrong on sparc. The check also fails on 5.26.2 but for some reason no bus-error there. I manually set d_u32align and that made the 5.28.0 build succeed.
Subject: Re: [perl #133495] perl-5.28.0 fails to build on Solaris 10
Date: Thu, 17 Jan 2019 03:33:56 +0100
CC: Perl5 Porters <perl5-porters [...] perl.org>
To: perlbug <perlbug-followup [...] perl.org>
From: Leon Timmermans <fawaka [...] gmail.com>
Download (untitled) / with headers
text/plain 2.1k
On Wed, Jan 16, 2019 at 3:47 PM Fabian Groffen via RT <perlbug-followup@perl.org> wrote: Show quoted text
> > On Wed, 16 Jan 2019 01:50:32 -0800, grobian@gentoo.org wrote:
> > Thread 2 received signal SIGSEGV, Segmentation fault. > > [Switching to Thread 1 (LWP 1)] > > 0x0004562c in zaphod32_hash_with_state (key_len=29, > > key=0x26d036 "dist/Exporter/lib/Exporter.pm", state_ch=<optimized
> > out>)
> > at zaphod32_hash.h:280 > > 280 v1 -= U8TO32_LE(key+0);
> > Sorry I didn't report this at my first message. I just found a bit of time to look into this. > > my Configure run somehow found: > > try.c: In function 'main': > try.c:46:28: warning: format '%x' expects argument of type 'unsigned int', but argument 2 has type 'long unsigned int' [-Wformat=] > printf("read failed (%x)\n", *up); > ~^ ~~~ > %lx > try.c:56:29: warning: format '%x' expects argument of type 'unsigned int', but argument 2 has type 'long unsigned int' [-Wformat=] > printf("write failed (%x)\n", *up); > ~^ ~~~ > %lx > (Testing for character data alignment may crash the test. That's okay.) > You can access character data pretty unalignedly. > > This is obviously wrong on sparc. The check also fails on 5.26.2 but for some reason no bus-error there. I manually set d_u32align and that made the 5.28.0 build succeed.
That is most helpful. That macro has two implementations, one for platforms little endian platforms without alignment requirement and one for platforms with requirements. It clearly picks the wrong options here. It's not just that, it picks the wrong one (the aligned version) on x64 as well. This appears to be caused by not taking into account 64bitness. That doesn't explain why it thinks it can access those bytes unalignedly on SPARC though. Could an overeager optimizer cause it not to fail? What is the autodetected value of d_u32align when it does work? Yves added some hashing code in 5.27 that made usage of this macro, AFAICT it wasn't used anywhere except in an optimization in Digest::MD5. I guess that's why we never noticed something was broken about it. Leon
RT-Send-CC: fawaka [...] gmail.com, perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 8.4k
On Wed, 16 Jan 2019 18:34:24 -0800, LeonT wrote: Show quoted text
> On Wed, Jan 16, 2019 at 3:47 PM Fabian Groffen via RT
> > This is obviously wrong on sparc. The check also fails on 5.26.2 but > > for some reason no bus-error there. I manually set d_u32align and > > that made the 5.28.0 build succeed.
> > That is most helpful. That macro has two implementations, one for > platforms little endian platforms without alignment requirement and > one for platforms with requirements. It clearly picks the wrong > options here. > > It's not just that, it picks the wrong one (the aligned version) on > x64 as well. This appears to be caused by not taking into account > 64bitness. That doesn't explain why it thinks it can access those > bytes unalignedly on SPARC though. Could an overeager optimizer cause > it not to fail? What is the autodetected value of d_u32align when it > does work?
I think that the GCC compiler is actually doing "too smart" things here when optimisations are enabled. I extracted the code it tries: % cat unaligned.c #include <stdio.h> #define I_STDLIB #ifdef I_STDLIB #include <stdlib.h> #endif #define U32 unsigned long #define BYTEORDER 0x4321 #define U8 unsigned char #include <signal.h> #ifdef SIGBUS void bletch(int s) { exit(4); } #endif int main() { #if BYTEORDER == 0x1234 || BYTEORDER == 0x4321 volatile U8 buf[8]; volatile U32 *up; int i; if (sizeof(U32) != 4) { printf("sizeof(U32) is not 4, but %d\n", sizeof(U32)); exit(1); } fflush(stdout); #ifdef SIGBUS signal(SIGBUS, bletch); #endif buf[0] = 0; buf[1] = 0; buf[2] = 0; buf[3] = 1; buf[4] = 0; buf[5] = 0; buf[6] = 0; buf[7] = 1; for (i = 0; i < 4; i++) { up = (U32*)(buf + i); if (! ((*up == 1 << (8*i)) || /* big-endian */ (*up == 1 << (8*(3-i))) /* little-endian */ ) ) { printf("read failed (%x)\n", *up); exit(2); } } /* write test */ for (i = 0; i < 4; i++) { up = (U32*)(buf + i); *up = 0xBeef; if (*up != 0xBeef) { printf("write failed (%x)\n", *up); exit(3); } } exit(0); #else printf("1\n"); exit(1); #endif return 0; } Next, I compile and run this example like Configure does: $ for flag in "-O2" "-g" ; do for cc in /usr/sfw/bin/gcc gcc-6.4.0 gcc-7.3.0 gcc-8.2.0 ; do $cc --version ; $cc $flag -o unaligned unaligned.c ; ./unaligned ; echo "$cc $flag -> $?" ; done ; done gcc (GCC) 3.4.3 (csl-sol210-3_4-branch+sol_rpath) Copyright (C) 2004 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. /usr/sfw/bin/gcc -O2 -> 4 gcc-6.4.0 (Gentoo 6.4.0-r2 p1.4) 6.4.0 Copyright (C) 2017 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. unaligned.c: In function ‘main’: unaligned.c:46:28: warning: format ‘%x’ expects argument of type ‘unsigned int’, but argument 2 has type ‘long unsigned int’ [-Wformat=] printf("read failed (%x)\n", *up); ^ unaligned.c:56:29: warning: format ‘%x’ expects argument of type ‘unsigned int’, but argument 2 has type ‘long unsigned int’ [-Wformat=] printf("write failed (%x)\n", *up); ^ gcc-6.4.0 -O2 -> 4 gcc-7.3.0 (Gentoo 7.3.0-r3 p1.4) 7.3.0 Copyright (C) 2017 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. unaligned.c: In function ‘main’: unaligned.c:46:28: warning: format ‘%x’ expects argument of type ‘unsigned int’, but argument 2 has type ‘long unsigned int’ [-Wformat=] printf("read failed (%x)\n", *up); ~^ ~~~ %lx unaligned.c:56:29: warning: format ‘%x’ expects argument of type ‘unsigned int’, but argument 2 has type ‘long unsigned int’ [-Wformat=] printf("write failed (%x)\n", *up); ~^ ~~~ %lx gcc-7.3.0 -O2 -> 4 gcc-8.2.0 (Gentoo 8.2.0-r5 p1.6) 8.2.0 Copyright (C) 2018 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. unaligned.c: In function ‘main’: unaligned.c:46:28: warning: format ‘%x’ expects argument of type ‘unsigned int’, but argument 2 has type ‘long unsigned int’ [-Wformat=] printf("read failed (%x)\n", *up); ~^ ~~~ %lx unaligned.c:56:29: warning: format ‘%x’ expects argument of type ‘unsigned int’, but argument 2 has type ‘long unsigned int’ [-Wformat=] printf("write failed (%x)\n", *up); ~^ ~~~ %lx gcc-8.2.0 -O2 -> 0 gcc (GCC) 3.4.3 (csl-sol210-3_4-branch+sol_rpath) Copyright (C) 2004 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. /usr/sfw/bin/gcc -g -> 4 gcc-6.4.0 (Gentoo 6.4.0-r2 p1.4) 6.4.0 Copyright (C) 2017 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. unaligned.c: In function ‘main’: unaligned.c:46:28: warning: format ‘%x’ expects argument of type ‘unsigned int’, but argument 2 has type ‘long unsigned int’ [-Wformat=] printf("read failed (%x)\n", *up); ^ unaligned.c:56:29: warning: format ‘%x’ expects argument of type ‘unsigned int’, but argument 2 has type ‘long unsigned int’ [-Wformat=] printf("write failed (%x)\n", *up); ^ gcc-6.4.0 -g -> 4 gcc-7.3.0 (Gentoo 7.3.0-r3 p1.4) 7.3.0 Copyright (C) 2017 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. unaligned.c: In function ‘main’: unaligned.c:46:28: warning: format ‘%x’ expects argument of type ‘unsigned int’, but argument 2 has type ‘long unsigned int’ [-Wformat=] printf("read failed (%x)\n", *up); ~^ ~~~ %lx unaligned.c:56:29: warning: format ‘%x’ expects argument of type ‘unsigned int’, but argument 2 has type ‘long unsigned int’ [-Wformat=] printf("write failed (%x)\n", *up); ~^ ~~~ %lx gcc-7.3.0 -g -> 4 gcc-8.2.0 (Gentoo 8.2.0-r5 p1.6) 8.2.0 Copyright (C) 2018 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. unaligned.c: In function ‘main’: unaligned.c:46:28: warning: format ‘%x’ expects argument of type ‘unsigned int’, but argument 2 has type ‘long unsigned int’ [-Wformat=] printf("read failed (%x)\n", *up); ~^ ~~~ %lx unaligned.c:56:29: warning: format ‘%x’ expects argument of type ‘unsigned int’, but argument 2 has type ‘long unsigned int’ [-Wformat=] printf("write failed (%x)\n", *up); ~^ ~~~ %lx gcc-8.2.0 -g -> 4 So, basically above list without the barf: /usr/sfw/bin/gcc -O2 -> 4 gcc-6.4.0 -O2 -> 4 gcc-7.3.0 -O2 -> 4 gcc-8.2.0 -O2 -> 0 /usr/sfw/bin/gcc -g -> 4 gcc-6.4.0 -g -> 4 gcc-7.3.0 -g -> 4 gcc-8.2.0 -g -> 4 Behaviour seems to be pretty much limited to gcc-8.2 while optimising at the moment. Show quoted text
> Yves added some hashing code in 5.27 that made usage of this macro, > AFAICT it wasn't used anywhere except in an optimization in > Digest::MD5. I guess that's why we never noticed something was broken > about it.
Yes, including the fact that at the time I compiled 5.26.2, I used GCC-7.3, which produced the correct result for the unaligned check. This makes me wonder what the problem of OP is, though. His env seems to suggest using GCC-4.9, which I don't have anymore for verification of the results.
Date: Thu, 17 Jan 2019 16:36:15 +0100
CC: Perl5 Porters <perl5-porters [...] perl.org>
Subject: Re: [perl #133495] perl-5.28.0 fails to build on Solaris 10
From: Leon Timmermans <fawaka [...] gmail.com>
To: perlbug <perlbug-followup [...] perl.org>
On Thu, Jan 17, 2019 at 9:26 AM Fabian Groffen via RT <perlbug-followup@perl.org> wrote: Show quoted text
> I think that the GCC compiler is actually doing "too smart" things here when optimisations are enabled. > > /usr/sfw/bin/gcc -O2 -> 4 > gcc-6.4.0 -O2 -> 4 > gcc-7.3.0 -O2 -> 4 > gcc-8.2.0 -O2 -> 0 > /usr/sfw/bin/gcc -g -> 4 > gcc-6.4.0 -g -> 4 > gcc-7.3.0 -g -> 4 > gcc-8.2.0 -g -> 4 > > Behaviour seems to be pretty much limited to gcc-8.2 while optimising at the moment.
Yeah. I guess that means we need a better test that confuses the compiler a little bit more. One would expect volatile to take care of that but apparently not; The C standard is notoriously fuzzy on volatiles (C99 6.7.6). What happens if you put the array outside the function? Show quoted text
> Yes, including the fact that at the time I compiled 5.26.2, I used GCC-7.3, which produced the correct result for the unaligned check. > > This makes me wonder what the problem of OP is, though. His env seems to suggest using GCC-4.9, which I don't have anymore for verification of the results.
They did use -O3, so I guess that always enabled that optimization. Leon
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 1.5k
On Thu, 17 Jan 2019 07:36:42 -0800, LeonT wrote: Show quoted text
> On Thu, Jan 17, 2019 at 9:26 AM Fabian Groffen via RT > <perlbug-followup@perl.org> wrote:
> > I think that the GCC compiler is actually doing "too smart" things > > here when optimisations are enabled. > > > > /usr/sfw/bin/gcc -O2 -> 4 > > gcc-6.4.0 -O2 -> 4 > > gcc-7.3.0 -O2 -> 4 > > gcc-8.2.0 -O2 -> 0 > > /usr/sfw/bin/gcc -g -> 4 > > gcc-6.4.0 -g -> 4 > > gcc-7.3.0 -g -> 4 > > gcc-8.2.0 -g -> 4 > > > > Behaviour seems to be pretty much limited to gcc-8.2 while optimising > > at the moment.
> > Yeah. I guess that means we need a better test that confuses the > compiler a little bit more. One would expect volatile to take care of > that but apparently not; The C standard is notoriously fuzzy on > volatiles (C99 6.7.6). > > What happens if you put the array outside the function?
The results are the same, unfortunately. Show quoted text
>
> > Yes, including the fact that at the time I compiled 5.26.2, I used > > GCC-7.3, which produced the correct result for the unaligned check. > > > > This makes me wonder what the problem of OP is, though. His env > > seems to suggest using GCC-4.9, which I don't have anymore for > > verification of the results.
> > They did use -O3, so I guess that always enabled that optimization.
It seems you're correct about that (code from original test): /usr/sfw/bin/gcc -O3 -> 4 gcc-6.4.0 -O3 -> 0 gcc-7.3.0 -O3 -> 0 gcc-8.2.0 -O3 -> 0 /usr/sfw/bin/gcc -O2 -> 4 gcc-6.4.0 -O2 -> 4 gcc-7.3.0 -O2 -> 4 gcc-8.2.0 -O2 -> 0 /usr/sfw/bin/gcc -g -> 4 gcc-6.4.0 -g -> 4 gcc-7.3.0 -g -> 4 gcc-8.2.0 -g -> 4 Fabian
RT-Send-CC: fawaka [...] gmail.com, perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 2.3k
On Mon, 21 Jan 2019 01:26:47 -0800, grobian@gentoo.org wrote: Show quoted text
> On Thu, 17 Jan 2019 07:36:42 -0800, LeonT wrote:
> > On Thu, Jan 17, 2019 at 9:26 AM Fabian Groffen via RT > > <perlbug-followup@perl.org> wrote:
> > > I think that the GCC compiler is actually doing "too smart" things > > > here when optimisations are enabled. > > > > > > /usr/sfw/bin/gcc -O2 -> 4 > > > gcc-6.4.0 -O2 -> 4 > > > gcc-7.3.0 -O2 -> 4 > > > gcc-8.2.0 -O2 -> 0 > > > /usr/sfw/bin/gcc -g -> 4 > > > gcc-6.4.0 -g -> 4 > > > gcc-7.3.0 -g -> 4 > > > gcc-8.2.0 -g -> 4 > > > > > > Behaviour seems to be pretty much limited to gcc-8.2 while optimising > > > at the moment.
> > > > Yeah. I guess that means we need a better test that confuses the > > compiler a little bit more. One would expect volatile to take care of > > that but apparently not; The C standard is notoriously fuzzy on > > volatiles (C99 6.7.6). > > > > What happens if you put the array outside the function?
> > The results are the same, unfortunately.
I've replaced, however, the stack allocated buf with a simple buf = malloc(sizeof(U8) * 8); and now gcc-8.2 returns 4 with -O2, but -O3 still is too clever and returning 0. So I decided to complicate matters a bit more by getting the buffer offset no longer statically known: data = malloc(sizeof(U8) * 32); bte = rand() % 24; buf = data + bte; I chose rand because it lives in stdlib.h, but I'm aware this might be a porting problem. Alternative would be time, or parsing argv[1], just to ensure the compiler doesn't know what the offset is going to be. With this change gcc-8.2 -O3 returns 4, as the test expects. Fabian Show quoted text
> > > Yes, including the fact that at the time I compiled 5.26.2, I used > > > GCC-7.3, which produced the correct result for the unaligned check. > > > > > > This makes me wonder what the problem of OP is, though. His env > > > seems to suggest using GCC-4.9, which I don't have anymore for > > > verification of the results.
> > > > They did use -O3, so I guess that always enabled that optimization.
> > It seems you're correct about that (code from original test): > > /usr/sfw/bin/gcc -O3 -> 4 > gcc-6.4.0 -O3 -> 0 > gcc-7.3.0 -O3 -> 0 > gcc-8.2.0 -O3 -> 0 > /usr/sfw/bin/gcc -O2 -> 4 > gcc-6.4.0 -O2 -> 4 > gcc-7.3.0 -O2 -> 4 > gcc-8.2.0 -O2 -> 0 > /usr/sfw/bin/gcc -g -> 4 > gcc-6.4.0 -g -> 4 > gcc-7.3.0 -g -> 4 > gcc-8.2.0 -g -> 4 > > Fabian
RT-Send-CC: solaris-pkg-people [...] NetBSD.org, fawaka [...] gmail.com, perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 3.6k
On Thu, 17 Jan 2019 07:36:42 -0800, LeonT wrote: Show quoted text
> On Thu, Jan 17, 2019 at 9:26 AM Fabian Groffen via RT > <perlbug-followup@perl.org> wrote:
> > I think that the GCC compiler is actually doing "too smart" things > > here when optimisations are enabled. > > > > /usr/sfw/bin/gcc -O2 -> 4 > > gcc-6.4.0 -O2 -> 4 > > gcc-7.3.0 -O2 -> 4 > > gcc-8.2.0 -O2 -> 0 > > /usr/sfw/bin/gcc -g -> 4 > > gcc-6.4.0 -g -> 4 > > gcc-7.3.0 -g -> 4 > > gcc-8.2.0 -g -> 4 > > > > Behaviour seems to be pretty much limited to gcc-8.2 while optimising > > at the moment.
> > Yeah. I guess that means we need a better test that confuses the > compiler a little bit more. One would expect volatile to take care of > that but apparently not; The C standard is notoriously fuzzy on > volatiles (C99 6.7.6). > > What happens if you put the array outside the function? >
> > Yes, including the fact that at the time I compiled 5.26.2, I used > > GCC-7.3, which produced the correct result for the unaligned check. > > > > This makes me wonder what the problem of OP is, though. His env > > seems to suggest using GCC-4.9, which I don't have anymore for > > verification of the results.
> > They did use -O3, so I guess that always enabled that optimization. > > Leon
We filed a GCC bug upstream (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91197). They closed as INVALID because the C code in the test is provoking undefined behavior. Namely, that it is accessing data through an unaligned pointer. So GCC is within its rights to do what it is doing, frustratingly so. See https://stackoverflow.com/questions/46790550/c-undefined-behavior-strict-aliasing-rule-or-incorrect-alignment for citations in the C11 spec for the claim that accessing data through unaligned pointers is undefined behavior. Digging into the code more, it's not just that the test in Configure provokes undefined behavior, but actually that the code it enables (in the little-endian && unaligned-ok paths) is potentially provoking undefined behavior. For example, in cpan/Digest-MD5/MD5.xs where buf is const U8* buf: #ifndef U32_ALIGNMENT_REQUIRED const U32 *x = (U32*)buf; /* really just type casting */ #endif Throughout the code base it looks like we go out of our way to optimize byte swaps and hit the little-endian && unaligned-ok path if possible, but I don't think that's necessary at all. Comments like "Without a known fast bswap32 we're just as well off doing this" followed by an open-coded shift and OR implementation of bswap indicate to me that the authors didn't realize that compilers can easily recognize this pattern (or wrote the code when they couldn't). Regardless, today compilers can easily see through this and generate a bswap/movbe instruction on x86. And in fact, it's not clear to me that even using GCC __builtin_bswap* is better or worse than the open-coded implementations (see https://gitlab.freedesktop.org/xorg/xserver/merge_requests/176) Similarly, while what the C code is doing in accessing unaligned pointers is undefined behavior, x86 instruction certainly can do that. But again, the compiler is perfectly capable of making that decision on its own. So, I propose that we just cut all of that code out and use what is currently the alignment-required path today. Please review the attached patches. I have never contributed to Perl before, and I stepped on quite a few landmines during the development of these patches (md5sum of MD5.xs goes in the test case; make regen; BYTEORDER is 0x1234 vs 0x12345678), so some help getting the patches in would be extremely appreciated. Passes the perl test suite when applied to 5.30.0 on Gentoo/Linux on amd64, 32-bit userland sparc, and 64-bit userland sparc.
Subject: p.patch
Download p.patch
text/plain 27.5k

Message body is not shown because it is too large.

RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 3.9k
On Wed, 04 Sep 2019 22:12:06 -0700, mattst88@gmail.com wrote: Show quoted text
> On Thu, 17 Jan 2019 07:36:42 -0800, LeonT wrote:
> > On Thu, Jan 17, 2019 at 9:26 AM Fabian Groffen via RT > > <perlbug-followup@perl.org> wrote:
> > > I think that the GCC compiler is actually doing "too smart" things > > > here when optimisations are enabled. > > > > > > /usr/sfw/bin/gcc -O2 -> 4 > > > gcc-6.4.0 -O2 -> 4 > > > gcc-7.3.0 -O2 -> 4 > > > gcc-8.2.0 -O2 -> 0 > > > /usr/sfw/bin/gcc -g -> 4 > > > gcc-6.4.0 -g -> 4 > > > gcc-7.3.0 -g -> 4 > > > gcc-8.2.0 -g -> 4 > > > > > > Behaviour seems to be pretty much limited to gcc-8.2 while > > > optimising > > > at the moment.
> > > > Yeah. I guess that means we need a better test that confuses the > > compiler a little bit more. One would expect volatile to take care of > > that but apparently not; The C standard is notoriously fuzzy on > > volatiles (C99 6.7.6). > > > > What happens if you put the array outside the function? > >
> > > Yes, including the fact that at the time I compiled 5.26.2, I used > > > GCC-7.3, which produced the correct result for the unaligned check. > > > > > > This makes me wonder what the problem of OP is, though. His env > > > seems to suggest using GCC-4.9, which I don't have anymore for > > > verification of the results.
> > > > They did use -O3, so I guess that always enabled that optimization. > > > > Leon
> > > We filed a GCC bug upstream > (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91197). They closed as > INVALID because the C code in the test is provoking undefined > behavior. Namely, that it is accessing data through an unaligned > pointer. So GCC is within its rights to do what it is doing, > frustratingly so. > > See https://stackoverflow.com/questions/46790550/c-undefined-behavior- > strict-aliasing-rule-or-incorrect-alignment for citations in the C11 > spec for the claim that accessing data through unaligned pointers is > undefined behavior. > > Digging into the code more, it's not just that the test in Configure > provokes undefined behavior, but actually that the code it enables (in > the little-endian && unaligned-ok paths) is potentially provoking > undefined behavior. For example, in cpan/Digest-MD5/MD5.xs where buf > is const U8* buf: > > #ifndef U32_ALIGNMENT_REQUIRED > const U32 *x = (U32*)buf; /* really just type casting */ > #endif > > Throughout the code base it looks like we go out of our way to > optimize byte swaps and hit the little-endian && unaligned-ok path if > possible, but I don't think that's necessary at all. Comments like > "Without a known fast bswap32 we're just as well off doing this" > followed by an open-coded shift and OR implementation of bswap > indicate to me that the authors didn't realize that compilers can > easily recognize this pattern (or wrote the code when they couldn't). > Regardless, today compilers can easily see through this and generate a > bswap/movbe instruction on x86. And in fact, it's not clear to me that > even using GCC __builtin_bswap* is better or worse than the open-coded > implementations (see > https://gitlab.freedesktop.org/xorg/xserver/merge_requests/176) > > Similarly, while what the C code is doing in accessing unaligned > pointers is undefined behavior, x86 instruction certainly can do that. > But again, the compiler is perfectly capable of making that decision > on its own. > > So, I propose that we just cut all of that code out and use what is > currently the alignment-required path today. > > Please review the attached patches. I have never contributed to Perl > before, and I stepped on quite a few landmines during the development > of these patches (md5sum of MD5.xs goes in the test case; make regen; > BYTEORDER is 0x1234 vs 0x12345678), so some help getting the patches > in would be extremely appreciated. > > Passes the perl test suite when applied to 5.30.0 on Gentoo/Linux on > amd64, 32-bit userland sparc, and 64-bit userland sparc.
This did not make it to perl5-porters yet. I'm replying to it to see if that thaws it. -- Karl Williamson
RT-Send-CC: solaris-pkg-people [...] NetBSD.org, fawaka [...] gmail.com, perl5-porters [...] perl.org
I've opened a pull request again Digest-MD5 here: https://github.com/gisle/digest-md5/pull/16
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 392b
In the patches' commit messages I made the claim: Show quoted text
> Moreover, compilers are more than capable of recognizing these open-coded byte-swap patterns and emitting a bswap instruction, or an unaligned load instruction
Here's proof that GCC can do those things: Bswap: https://godbolt.org/z/w__OsV Unaligned store: https://godbolt.org/z/xSQm6m Unaligned load left as an exercise to the reader :)
From: Hiroshi Hakoyama <hiroshi-hakoyama [...] nagano.ac.jp>
Subject: Re: [perl #133495] perl-5.28.0 fails to build on Solaris 10
Date: Sun, 8 Sep 2019 18:10:19 +0900
To: "mattst88 [...] gmail.com via RT" <perlbug-followup [...] perl.org>
Download (untitled) / with headers
text/plain 32.9k

Message body is not shown because it is too large.

RT-Send-CC: hiroshi-hakoyama [...] nagano.ac.jp, perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 209b
On Tue, 10 Sep 2019 22:24:59 -0700, hiroshi-hakoyama@nagano.ac.jp wrote: Show quoted text
> Please tell me if you want to ask me to do some tests on Solaris 10 / > sparc64.
That would be welcome, but certainly not required :)
RT-Send-CC: hiroshi-hakoyama [...] nagano.ac.jp, perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 216b
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 310b
On Tue, 08 Oct 2019 13:21:39 -0700, mattst88@gmail.com wrote: Show quoted text
And closing. Tony


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

For issues related to this RT instance (aka "perlbug"), please contact perlbug-admin at perl.org