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
regex qr/(?[ [B] | ! ( [^B] ) ])/ fails to compile on Solaris x64 debugging optimized builds #15159
Comments
From @tonycozWhen blead@42d92f4a6420c9e925e441055e97be24645d0a52 is built with Solaris Studio 12.3 for 64bitall and -DDEBUGGING, re/regex_sets.t fails to compile, choking on the regular expression: qr/(?[ [B] | ! ( [^B] ) ])/ as follows: tony@nereid:~/dev/perl/git/perl$ LD_LIBRARY_PATH=/home/tony/dev/perl/git/perl ./perl -e 'qr/(?[ [B] | ! ( [^B] ) ])/' Building with -Doptimize=-O0\ -g produces a segmentation fault during the build process: LD_LIBRARY_PATH=/home/tony/dev/perl/git/perl ./miniperl -Ilib lib/unicore/mktables -C lib/unicore -P pod -maketest -makelist -p Backtrace: Updating 'mktables.lst' Program received signal SIGSEGV, Segmentation fault. Summary of my perl5 (revision 5 version 23 subversion 8) configuration: Characteristics of this binary (from libperl): |
@khwilliamson - Status changed from 'new' to 'open' |
@khwilliamson - Status changed from 'open' to 'abandoned' |
@khwilliamson - Status changed from 'abandoned' to 'open' |
From @iabynOn Tue, Feb 02, 2016 at 03:48:35PM -0800, Tony Cook wrote:
This is hopefully fixed by: commit d9cb841 regex sets: fix Solaris optimiser bug Affected files ... Differences ... Inline Patchdiff --git a/regcomp.c b/regcomp.c
index ffee749..e1dc3c8 100644
--- a/regcomp.c
+++ b/regcomp.c
@@ -15122,7 +15122,22 @@ redo_curchar:
* stack, we have to check if it is a !. But first, the code above
* may have altered the stack in the time since we earlier set
* 'top_index'. */
- top_index = av_tindex_nomg(stack);
+
+ {
+ /* Work round an optimiser bug in Solaris Studio 12.3:
+ * for some reason, the presence of the __assert() in
+ * av_tindex_nomg() causes the value of fence to get
+ * corrupted, even though the assert is never called. So
+ * save the value then restore afterwards.
+ * Note that in fact merely accessing the value of fence
+ * prior to the statement containing the assert is enough
+ * to make the bug go away.
+ */
+ IV f = fence;
+ top_index = av_tindex_nomg(stack);
+ fence = f;
+ }
+
if (top_index - fence >= 0) {
/* If the top entry on the stack is an operator, it had better
* be a '!', otherwise the entry below the top operand should
-- Indomitable in retreat, invincible in advance, insufferable in victory |
From @khwilliamsonIt's unfortunate, given that there's so few of us coding this project, Tony Cook (mostly him) and I also had been tracking this down, and I don't know if one approach is better than the others. Also, av_tindex_nomg() is a new construct that I added based on Tony's SvGETMAGIC( (SV *) av); IV x = av_tindex_nomg(av); and that doesn't work as they might expect it to. My current thinking On 03/12/2016 03:26 AM, Dave Mitchell wrote:
|
From @iabynOn Sat, Mar 12, 2016 at 09:47:20AM -0700, Karl Williamson wrote:
Well, my one's
Is it really necessary for av_tindex_nomg(av) to assert that av is an AV? AS for SvGETMAGIC documentation, I'd say leave it alone. There's nothing -- |
From @khwilliamsonOn 03/14/2016 02:59 AM, Dave Mitchell wrote:
That's fine with me. But I notice that there are still problems on the
Is it necessary really to use any assert()? It is here just a guard I don't want to use AvFILLp() because it is obscure. I had no idea it
The code for av_tindex() indicates that SvGETMAGIC() does not work on |
From @iabynOn Thu, Mar 17, 2016 at 06:30:38PM -0600, Karl Williamson wrote:
Bother. I've just pushed 34f817b, which
There's a bit of continuum, and that assert seems to be at the less
Well, I personally find the names av_tindex*() just as obscure as I think the 'p' suffix is well-established as a private or short-cut How about av_top_index_x()? The _x is fairly non-mnemonic, but at least Finally, if you are to have an access function/macro that explicitly only
Well, what I said earlier may have been a bit too strong; its certainly -- |
From @khwilliamsonThat commit did fix this problem. There are other failures, covered in #127746 |
@khwilliamson - Status changed from 'open' to 'pending release' |
From @khwilliamsonThank you for submitting this report. You have helped make Perl better. Perl 5.24.0 may be downloaded via https://metacpan.org/release/RJBS/perl-5.24.0 |
@khwilliamson - Status changed from 'pending release' to 'resolved' |
From @khwilliamsonOn Fri, 18 Mar 2016 16:11:25 -0700, davem wrote:
We actually went through this name process earlier starting with an RFC by me http://www.nntp.perl.org/group/perl.perl5.porters/2012/10/msg194085.html In that thread, you said you recalled AvFILL sounded strange when you first saw it, but you had come to know what it meant. I talked about AvFILLp, and how it didn't make much sense to me. In the meantime, I had forgotten completely that I had ever heard of AvFILLp. Anyway, that thread concluded with av_top_index() and av_tindex() being new synonyms with not dissent.
In commit 9506e94, I changed the names to either based on looking through the source and finding instances of where it uses 'skip_foo_mg'. I think that these are no longer misleading.
-- |
Migrated from rt.perl.org#127455 (status was 'resolved')
Searchable as RT127455$
The text was updated successfully, but these errors were encountered: