Hi Daniel,
thank you very much for fixing these issues. I hope JIT is working well on your
system now (If you can share some performance results as well, I am really
interested). I would like to add your changes to the project but the patch has
a strange syntax on my machine:
--_e03c4e17-38a7-4221-a4b1-fe0372a519e7_
Content-Transfer-Encoding: uuencode
Content-Disposition: attachment; filename="pcre-fixes.patch"
Content-Type: application/octet-stream; name="pcre-fixes.patch"
begin 666 pcre-fixes.patch
M26YD97@Z(%)U;E1E<W0*/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]
M/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/0HM+2T@4G5N
M5&5S= DH<F5V:7-I;VX@.3@R*0HK*RL@4G5N5&5S= DH=V]R:VEN9R!C;W!Y
M*0I 0" M,34U+#<@*S$U-2PX($! "B C(%-E="!U<"!A('-U:71A8FQE(")D
M:69F(B!C;VUM86YD(&9O<B!C;VUP87)I<V]N+B!3;VUE('-Y<W1E;7,*(",@
...
How can I decode your patch?
Regards,
Zoltan
"Daniel Richard G." <o...@teragram.com> írta:
>Hello folks,>
>
I've put in some work on PCRE lately, and would like to submit my changes.>
They largely address (1) compatibility with the IBM C compiler (xlc), and>
(2) memory leaks in the pcretest test driver.>
>
Everything is in the attached patch, against SVN trunk. A walk-through is>
below:>
>
>
++ RunTest>
>
@ The initial goal here was to quell the "illegal option" error message>
from older diff(1) programs; the restructuring of the conditional is a>
parallel to my changes to RunGrepTest>
>
++ pcre_jit_compile.c>
>
@ This comment is intended to help folks who are led to that>
SLJIT_MALLOC() by Valgrind. It certainly would have helped me, as>
pcretest was doing the clear-the-PCRE_EXTRA_EXECUTABLE_JIT-flag thing!>
>
++ sljit/sljitNativePPC_common.c>
>
@ Allow this file to be compiled by IBM's xlc compiler, which specifically>
supports GCC asm syntax, but does not define __GNUC__. This support can>
be switched off with -qnoasm, however...>
>
http://publib.boulder.ibm.com/infocenter/lnxpcomp/v8v101/topic/com.ibm.xlcpp8l.doc/compiler/ref/ruoptasm.htm>
>
... so give a more helpful error in that case.>
>
Use __asm__ instead of plain "asm", as the latter can be de-recognized as>
a keyword with -qnokeyword=asm, and so the former is more robust:>
>
http://publib.boulder.ibm.com/infocenter/lnxpcomp/v8v101/topic/com.ibm.xlcpp8l.doc/compiler/ref/ruoptkey.htm>
>
Also, I encountered a mysterious assembly error when building with -O3>
and -qfuncsect:>
>
--------8<-------->
libtool: compile: /usr/vac/bin/xlc_r -DHAVE_CONFIG_H -I. -I/srcdir/pcre-8.30
-O3 -q64 -qfuncsect -c -M>
/srcdir/pcre-8.30/pcre_jit_compile.c -DPIC -o pcre_jit_compile.o>
"/srcdir/pcre-8.30/sljit/sljitNativePPC_common.c", line 42.2: 1506-948 (W)
#warning "This file may fail to compile if -qfuncsect is>
used">
Assembler:>
pcre_jit_compile.s: line 59973: undefined symbol "S.8704.IPRA._sljit_emit_cmp">
pcre_jit_compile.s: line 59973: illegal expression>
pcre_jit_compile.s: line 59988: undefined symbol
"S.8705.IPRA._compile_xclass_hotpath">
pcre_jit_compile.s: line 59988: illegal expression>
pcre_jit_compile.s: line 59991: undefined symbol
"S.8706.IPRA._compile_char1_hotpath">
pcre_jit_compile.s: line 59991: illegal expression>
pcre_jit_compile.s: line 60000: undefined symbol
"S.8707.IPRA._compile_iterator_hotpath">
pcre_jit_compile.s: line 60000: illegal expression>
1500-067: (S) asm statement generates errors in assembler output.>
1586-346 (U) An error occurred during code generation. The code generation
return code was 1.>
make: The error code from the last command is 1.>
>
Stop.>
make: The error code from the last command is 2.>
-------->8-------->
>
(I was using a handful of other options as well, but they had no bearing>
on this failure mode.)>
>
This error appears to be due to the inline assembly of ppc_cache_flush(),>
because if I comment out the asm statement, the error goes away.>
>
Removing -qfuncsect allows the source to compile, asm and all, so I added>
a #warning for folks using the IBM compiler to help them diagnose the>
problem.>
>
@ Quelled a warning about converting a function pointer to void*>
>
++ sljit/sljitNativePPC_64.c>
>
@ Allow compilation with the IBM compiler and use __asm__ instead of "asm">
>
++ sljit/sljitConfigInternal.h>
>
@ The IBM compiler does define __powerpc__, but not __powerpc64__, even in>
64-bit mode. It does, however, define _ARCH_PPC and _ARCH_PPC64:>
>
http://publib.boulder.ibm.com/infocenter/comphelp/v8v101/topic/com.ibm.xlcpp8a.doc/compiler/ref/ruoptarc.htm>
>
++ pcretest.c>
>
@ There were a few "if (re != NULL) ..." bits below this, and I thought,>
this is silly---just check whether "re" is NULL right after the>
new_malloc() call, and bail out if it is>
>
@ "re" was being leaked>
>
@ new_free(re) unconditionally, because we know it's not NULL>
>
@ "re" and "f" were being leaked>
>
@ extra->executable_jit was being leaked because an existing pcre_extra>
object with JIT data would enter this block, then have its>
PCRE_EXTRA_EXECUTABLE_JIT cleared, and then there was no way to>
subsequently tell whether extra->executable_jit was a valid pointer or not.>
>
I resolved this just by calling PCRE_FREE_STUDY() and allocating a new>
pcre_extra object every time. (Maybe there would be a use for a>
pcre_clear_study() routine, that does everything pcre_free_study() does>
except for the final free().)>
>
@ dfa_workspace was being leaked>
>
++ autogen.sh>
>
@ test(1) a.k.a. "[" has "=" as an operator, not "==">
>
++ RunGrepTest>
>
@ Rewrote the diff check. Again, the initial goal was to quash the error>
message printed by older diff programs that don't do -u. The secondary>
goal was to simplify the nested shell conditionals into something more>
elegant; here, I've implemented a progression from the least-desirable>
diff invocation to the most. Subjectively, I think this is cleaner.>
>
>
Comments and critique welcome,>
>
>
--Daniel>
>
>
-->
Daniel Richard G. || dani...@teragram.com || Software Developer>
Teragram Linguistic Technologies (a division of SAS)>
http://www.teragram.com/>
>
>
-- >
## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
--
## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
