Suggestion for removing flex/bison as a dependancy
Hi,
I would like to propose a set of diffs to enable compilation of gcc
without requiring flex/bison. I feel that this would greatly benefit
the variety of users building gcc.
The only files which really need these are:
gcc/gengtype-lex.l
gcc/treelang/lex.l
gcc/treelang/parse.y
One more thing to note is that, in the toplevel directories: intl/
(for libintl) and libjava/ already ship with the bison-ed .y files (as
plural.c and XQueryParser.java) respectively; They are also present in
the svn repository. So I fell it wouldn't be against the rule to ship
these as part of the core-distro as well.
I wish that this same procedure is applied to the files I have mentioned above.
Things to be done:
1. flex gcc/gengtype-lex.l into gcc/gengtype-lex.c
2. flex gcc/treelang/lex.l into gcc/treelang/lex.c
3. bison gcc/treelang/parse.y into gcc/treelang/parse.h,
gcc/treelang/parse.c, gcc/treelang/parse.output (bison's output)
And finally:
4. Cleanup gcc/Makefile.in, gcc/treelang/Make-lang.in, gcc/configure.ac
5. Rerun autoconf in gcc/.
Because the version of flex/bison/autoconf on my build system may be
newer than what is used by the maintainers, I am not unable to send
patches for 1, 2, 3 and 5. I am sending the diffs for 4. If someone
can help me with the rest/in submitting a diff, Please reply to this.
I hereby request for comments/acknowledgments/suggestions;
--
Karthik
--- gcc/configure.ac 2007-11-08 22:09:59.0 +0530
+++ ../configure.ac 2007-11-26 16:31:16.0 +0530
@@ -865,14 +865,6 @@
MISSING="${CONFIG_SHELL-/bin/sh} $ac_aux_dir/missing"
-# How about lex?
-dnl Don't use AC_PROG_LEX; we insist on flex.
-dnl LEXLIB is not useful in gcc.
-AC_CHECK_PROGS([FLEX], flex, [$MISSING flex])
-
-# Bison?
-AC_CHECK_PROGS([BISON], bison, [$MISSING bison])
-
# Binutils are not build modules, unlike bison/flex/makeinfo. So we
# check for build == host before using them.
--- gcc/Makefile.in 2007-11-13 19:23:33.0 +0530
+++ ../Makefile.in 2007-11-26 16:36:00.0 +0530
@@ -209,10 +209,6 @@
AWK = @AWK@
CC = @CC@
-BISON = @BISON@
-BISONFLAGS =
-FLEX = @FLEX@
-FLEXFLAGS =
AR = @AR@
AR_FLAGS = rc
NM = @NM@
@@ -933,12 +929,8 @@
export slibdir
FLAGS_TO_PASS = \
- "BISON=$(BISON)" \
- "BISONFLAGS=$(BISONFLAGS)" \
"CFLAGS=$(CFLAGS) $(WARN_CFLAGS)" \
"LDFLAGS=$(LDFLAGS)" \
- "FLEX=$(FLEX)" \
- "FLEXFLAGS=$(FLEXFLAGS)" \
"LN=$(LN)" \
"LN_S=$(LN_S)" \
"MAKEINFO=$(MAKEINFO)" \
--- gcc/Makefile.in 2007-11-13 19:23:33.0 +0530
+++ ../Makefile.in 2007-11-26 16:07:33.0 +0530
@@ -1718,8 +1718,7 @@
srcextra: gcc.srcextra lang.srcextra
-gcc.srcextra: gengtype-lex.c
- -cp -p $^ $(srcdir)
+gcc.srcextra:
c-incpath.o: c-incpath.c c-incpath.h $(CONFIG_H) $(SYSTEM_H) $(CPPLIB_H) \
intl.h prefix.h coretypes.h $(TM_H) cppdefault.h $(TARGET_H) \
@@ -3251,10 +3250,6 @@
build/gengtype$(build_exeext) : build/gengtype-lex.o build/gengtype-parse.o \
$(BUILD_ERRORS)
-# Generated source files for gengtype.
-gengtype-lex.c : gengtype-lex.l
- -$(FLEX) $(FLEXFLAGS) -o$@ $<
-
#
# Remake internationalization support.
intl.o: intl.c $(CONFIG_H) $(SYSTEM_H) coretypes.h $(TM_H) intl.h Makefile
--- gcc/treelang/Make-lang.in 2007-11-22 21:52:14.0 +0530
+++ ../../gcc-mainline-dp/gcc/treelang/Make-lang.in 2007-11-26 16:50:21.0 +0530
@@ -53,7 +53,7 @@
# GCC_FOR_TREELANG = ./xgcc $(GCC_EXTRAS)
-TREE_GENERATED = lex.c parse.c parse.h parse.output
+TREE_GENERATED =
# We need to use something other than treelang here because the directory
# is called treelang
TREE_EXES = gtreelang
@@ -123,21 +123,6 @@
$(TM_H) $(DIAGNOSTIC_H) $(TREE_H) treelang/treelang.h input.h \
treelang/parse.h toplev.h
-# generated files the files from lex and yacc are put into the source
-# directory in case someone wants to build but does not have
-# lex/yacc
-
-treelang.srcextra: treelang/parse.c treelang/parse.h treelang/lex.c
- -cp -p $^ $(srcdir)/treelang
-
-treelang/lex.c: treelang/lex.l
- -$(FLEX) $(FLEXFLAGS) -o$@ $<
-
-treelang/parse.c treelang/parse.h treelang/parse.output: treelang/parse.y
- -$(BISON) $(BISONFLAGS) -v --defines --output=treelang/parse.c $<
-
-# -v
-
#
# Build hooks:
Fwd: Suggestion for removing flex/bison as a dependancy
Hi, On Nov 27, 2007 12:13 AM, J.C. Pizarro <[EMAIL PROTECTED]> wrote: > On Mon, Nov 26, 2007, Karthik Kumar wrote: > > I would like to propose a set of diffs to enable compilation of gcc > > without requiring flex/bison. I feel that this would greatly benefit > > the variety of users building gcc. > > Dear Karthik Kumar, why not flex/bison? It's bad idea not using them. I'm not saying we don't use flex/bison. I am only saying we can remove that as a build dependancy; Many people have to use specific versions of lex (flex) and yacc (bison) if they wish to compile gcc. All directories which have configure scripts also have their autoconf files (configure.ac) in the tree. And many directories which have Makefile.in have Makefile.am as well. It is generally a good idea for the user to keep the autotools as well; But there is no need to use those if the configure and Makefile.in files are already there. Besides, taking a look at the tree, libintl and libjava have processed .y files. I only suggest that we keep the C versions of these files in the tree as well. > > The tools flex/bison are required as any tool > ( e.g. patch, diff, binutils, sed, bash, gzip, cvs, m4, etc. ) and > they are smaller executables to be stored in a CD. > > The generated files from flex/bison are a lot of "trashing hexadecimals" that > don't must to be commited to any cvs/svn/git/hg because it consumes > a lot of diskspace for only a modification of few lines of flex/bison sources. The configure/Makefile.in scripts are significantly large as well. -- Karthik
Re: Function specific optimizations call for discussion
On Nov 29, 2007 2:27 AM, Michael Meissner <[EMAIL PROTECTED]> wrote: > One of the things that I've been interested in is adding support to GCC to > compile individual functions with specific target options. I first presented > a > draft at the Google mini-summit, and then another draft at the GCC developer > summit last July. > > In the x86 world this would mean saying that an individual function can use > SSE5 instructions or SSE4.1 instructions. This would simplify things for > people who need to write high performance libraries that run on different > architectures, and need to be optimal on each platform. Ultimately, the goal > is to allow hotspot functions to be compiled several times with different > target specific optimizations. I would welcome any thoughts or suggestions > about this proposal. > > The proposal is at: > http://gcc.gnu.org/wiki/FunctionSpecificOpt Regarding the static constructors/destructors, we can version them as well. In case a person wishes to annotate them, he can use: __attribute__(sse4a) or change the constructor function name to name__v__sse4a__ or so. He can safely assume that it won't execute if the feature bit isn't present. We would simply ret if the feature bit isn't supported. Multiple attributes are supported for any function, and it shouldnt be a problem :-) This means the detection of features would be done before the program's actual execution. > > Part of the infrastructure work for doing this is already addressed in > function > adaption project and we will work together with that team: > http://gcc.gnu.org/wiki/functionAdaptation > > One of the things that I have considered and not added to the current proposal > is to change most of the -f, -O, -W options for a function. This would be > relatively simple to add once the infrastructure is in place, but it can > really > complicate things, since various optimizations depend on other optimizations > having been done. Similarly, the -mtune= and -march= options can overly > complicate matters. > As for setting -f, there are flags like: stack-protector-all which can not be set at a function level. The problem happens when a flag is set to 0/1 (not 2) and is valid for a whole compilation unit.. (It might be there, I'm saying); We should clearly split the common.opt/annotate it with the required information so we can determine which ones can not be unset when set or vice-versa. The warn/optimization levels would inherit/differenciate from the parent settings (compilation unit or enclosing function). > In addition, attribute(cold) and attribute(hot) will set the optimization > level > to -Os and -O3. > It might be possible that he wishes to optimize for size (not inline function calls/unroll loops, for instance) but he might want it versioned; . Versioning will increase text size only if all versions are loaded during runtime. > I will be away on vacation from December 3-8th, and not reading mail during > that time. > > -- > Michael Meissner, AMD > 90 Central Street, MS 83-29, Boxborough, MA, 01719, USA > [EMAIL PROTECTED] > > > -- Karthik
Fwd: Function specific optimizations call for discussion
On Nov 29, 2007 2:09 PM, Ramana Radhakrishnan <[EMAIL PROTECTED]> wrote: > Hi Michael, > > I had a comment / query regarding Stage 2 where you talk about > Function cloning for different targets. > > I understand that the mechanism is to have a hidden function pointer > that actually gets initialized based on the cpuid. > > I don't know if it is worth the effort to have debug info also > enhanced to be such that a breakpoint put on the function my_min > actually sets the breakpoint on any of the clones since the logic > would be similar to the same. This sounds logically similar to the > way that gdb currently handles breakpoints to multiple constructors. > If the user has written the clone (for manual dispatch), then the debug info would point to his code version. If it were generated automatically (stage 2), the information would pertain to the function cloned multiple times.The disassembly on those breakpoints might be different, of course. > The other option ofcourse is to fake debug information for such to > actually set a breakpoint on the value of the function pointer that > you so set up. I am no DWARF expert but there might be other folks on > the list who might have better ideas about how to implement this. > There is an idea to modify the dynamic linker to take advantage of the detection; If in such case, setting a breakpoint would be easier. Then we wouldn't require indirect calls either. The breakpoints can be set in each of the clones, and they will be processed only after setting up the pointer and their subsequent execution. The idea is to make use of the debugging information as provided by the inline-cloner. > cheers > Ramana Karthik -- Karthik http://guilt.bafsoft.net
Require help with the backend in gcc
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I require help with some work i've been doing lately on gcc (4.2.1 tree). I have managed to put some code in. Now, for function compilation, i require to invoke the i386 (as of now) backend multiple times and with different switches; one time with 3dnow!, another with mmx, another with sse2. And floating point code will require usage of both 387 and sse. It is intended that multiple archs are passed as part of the -march option. (-m3dnow,sse2,sse3 or -march=k6,nocona or maybe - -march=sse2,sse3) Eventually, some of this code may also get used in the PowerPC backend (one time with AltiVec and one time without).. it is intended that multiple versions of functions would go into the assembly file; The global data segment would be created only once, aligned to targeted instruction sets' requirement for efficient accesses (if mmx and sse, alignment might be 8 bytes than 4). I have started working, but not sure which parts I should be touching by now. Please give me your suggestions. Any help in this regard would be greatly appreciated. Regards, Karthik - -BEGIN PGP PUBLIC KEY BLOCK- Version: GnuPG v1.4.7 (GNU/Linux) mQGiBEa0y88RBACpSIuwbUvraagYtkWKMlwe+KI6Sh2UU2vipE8Fotkrq/iTnRiK pu2dJcP+jTNvbatcLGedWQOHiCvGfadZD/SxmYsJpQXazL/CORGvdzZwq4eBsDVV 94E/pibIT6ouaOFVMsvARPOyk+Q6N8T/tsvtCxFYrx/NnUIoMdb1DCXEZwCgs90U 9xQExo7OfJYyafTYLyXSzbsD/jqNhMJwnNsT+/GOqDeod98s54IImpgVA/bGyOQi ek+l2SGlrZ6LmZzGO/zVRqsPISAm7Wa5xbVe6qL+hUr1XIFOQoj+08yOCYPDrPoh m4QtFQHKlr5E0u6ev188wI6uIyz6jpzt6C/Aq3Q4irCj3Graeg9xGnHgsjMujubR WebABACgJzTS2mfEu5Rb75+KlgGgnA8zkTpf/Qqdwk/eo1WZPbcIijROEP4MNhVS IWacQXt4Ng8aWviFTZvysAc4k4hxnmFJgyRcUOSOmYd3uWkQI0OV1+cS5FoXmiQ2 Oucsw4iBC3VHqQmNhtuCNZ4Nx1v0kexqfBQCRBSB3HGXGBKjQ7REVi4gS2FydGhp ayBLdW1hciAoaHR0cDovL2d1aWx0LmJhZnNvZnQubmV0KSA8a2FydGhpa2t1bWFy QGdtYWlsLmNvbT6IZgQTEQIAJgUCRrTLzwIbAwUJAeEzgAYLCQgHAwIEFQIIAwQW AgMBAh4BAheAAAoJEEc052Xw3SBP+dkAoI5xfNw/7M7OVpmquFAwRb0k9KbYAJ0e IOypL+F8bUsxqISUIw3GFeb60LkEDQRGtMvPEBAA4SptM/eorjFWmC1S7xBfvKMF UMyFQvkwiWtDsWIrD0AMU4acT7fjYlMEKmVsaymXppxyvK6e/4jOX72UcsJZ4LL/ jtm4SGfknC6yEXdeyYz5Mmd6CN52LC/KfS4b771zO9yMDAl79/FxHIR7AvoSWb14 sbc7yKiF7OwfEFeZNtOYsZwDsQabnuFd5mzIMev/W2hgs55DF4ZJnmaVYb/PQbbw X5g7OwsN17OESPF/syaCzqKJ0GuzhnGHYgwY/84eeWkzqnGTxG52HH6Y1sYwKEmJ 32XLkUEHxHKoCvMW8C6E/s72Aw/WrBzq2yHhqW5npBrCIBCYWC70wzkew2DaOG/j WYtRP2ahJKxV9598D86w97M+6kNX2efMdSgJyLlFyyXlqX95sobE8BJRxjXqkiJy uaLgXv3CQZ1+kizhnkZeInA85NNahb3f2j/jA03eVoAhRq64fqN8W1kfvQwv YF31G7dsLLI2gx2ui1ouj6phIIlZPzypoDkoYZiXn3qXMDiyxJb+4wT5MZz2hjTU w51Z5WPe2ylPXKPqmiDw6zMNQW8OWVIXFljxLcRAhY9DQC9MIgnw7wCz9Bdu8sUs kkZjSsLo6Mc1SPCwjcuD8bDuvc7JIugNn/QFrLtV0o/BVpxMX0ujm2gC8/y7ruBJ cGPvx99e7lj7cmgac7cAAwUP/2h7MDCA3o1Bt1mInBlC+LHdJIaipToVc72lF8nN H3InjMppUkgvHQ+D/4r5hcWtskkRY+YG1iG45RbWMQlprfONOWEYfjkc/WDRj+PO lFszhcOSc2IlgCYsY1yEIF6HfE2MZpFWjM0z0hjotEULxlvi9meMV0OZRqwDdhEp 871jk1+3WkdjGMcZI3AO3wGRwb60eYW0cVNMv1umH0Cgh2pgU/vTbCqB7P5DaNHf BxflFAWumm7P70qJMoCa9SRNKh7vitlLBLGnSuhgT22aE/N/zslcprS7tFM3JFAl Jvr9V3pXzMmkk4zGwzpfvA8LpCPNVqqABrkGsduTsTyoPjLDmPH/CuFMu6RZCUHL sSKKhTpbE3zTgmyGja8DiJFKWmtojFPDEnPDSQweJYItkfnGSbHQVx5wkKhjABQ6 bCraNqgem0C+tKnDoRk/NlhKBCpGVdt8kIRNZ+iTA+4VB+R1usUY3ZpvrHYZFDX5 RxJ4jYLnhlKspSYvKkLg4IP7KnGr9dC16XJCa2wqR68EJa0u5XxigV4zscaawGYA Mx56+PoouaWI24+9JUPTMkV3UvF5xU2BumOW/IsKqs2qYEkG3QdczVwTnNuAZFQa 1WJAKOT7elDsrYsrdGWZpge2d/uoIFKjDobz7eZnkSLiX2rIzbkDniDD+aZd8G60 NVJliE8EGBECAA8FAka0y88CGwwFCQHhM4AACgkQRzTnZfDdIE91ngCgpgLiwwXQ MbyOCWjuWGY+phmYeagAnj7nMffLNWLpfVmKtA4yrtOHkSAM =RuU8 - -END PGP PUBLIC KEY BLOCK- -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG+pp+RzTnZfDdIE8RArIGAJ9XtceYSNA7hZU8GUjkJkXviXqsJQCgnBYS 5Y+CCpTarGE8ojPiNCb4PEM= =HpQ2 -END PGP SIGNATURE-
Re: Require help with the backend in gcc
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thank you for a quick reply! :) I was to do dynamic cpu dispatching code (which could also benefit autovectorization). I'm checking out the trunk now. I've already implemented an userland library to do cpu detection, and the initialization hook goes into expand_main; I'm looking forward to using this framework. Thank you once again! Karthik "V. Karthik Kumar" <[EMAIL PROTECTED]> writes: > I require help with some work i've been doing lately on gcc (4.2.1 > tree). I have managed to put some code in. > > Now, for function compilation, i require to invoke the i386 (as of > now) backend multiple times and with different switches; one time with > 3dnow!, another with mmx, another with sse2. And floating point code > will require usage of both 387 and sse. > > It is intended that multiple archs are passed as part of the -march > option. (-m3dnow,sse2,sse3 or -march=k6,nocona or maybe > -march=sse2,sse3) > > Eventually, some of this code may also get used in the PowerPC backend > (one time with AltiVec and one time without).. > > it is intended that multiple versions of functions would go into the > assembly file; The global data segment would be created only once, > aligned to targeted instruction sets' requirement for efficient > accesses (if mmx and sse, alignment might be 8 bytes than 4). > > I have started working, but not sure which parts I should be touching > by now. > > Please give me your suggestions. Any help in this regard would be > greatly appreciated. The first thing you need to do is move to mainline, and take advantage of the patch by Sandra Loosemore, David Ung, and Nigel Stephens to add TARGET_SET_CURRENT_FUNCTION. That is the framework you'll need to change the architecture on a per-function basis. Then you'll need to figure out how to clone the function the way the inliner does, and presumably give each copy different names or something--you didn't mention how you plan to handle that issue. Then you can wind up compiling each function with different parameters. This is a nontrivial exercise, but an interesting one. Good luck. Ian - -- - -BEGIN PGP PUBLIC KEY BLOCK- Version: GnuPG v1.4.7 (GNU/Linux) mQGiBEa0y88RBACpSIuwbUvraagYtkWKMlwe+KI6Sh2UU2vipE8Fotkrq/iTnRiK pu2dJcP+jTNvbatcLGedWQOHiCvGfadZD/SxmYsJpQXazL/CORGvdzZwq4eBsDVV 94E/pibIT6ouaOFVMsvARPOyk+Q6N8T/tsvtCxFYrx/NnUIoMdb1DCXEZwCgs90U 9xQExo7OfJYyafTYLyXSzbsD/jqNhMJwnNsT+/GOqDeod98s54IImpgVA/bGyOQi ek+l2SGlrZ6LmZzGO/zVRqsPISAm7Wa5xbVe6qL+hUr1XIFOQoj+08yOCYPDrPoh m4QtFQHKlr5E0u6ev188wI6uIyz6jpzt6C/Aq3Q4irCj3Graeg9xGnHgsjMujubR WebABACgJzTS2mfEu5Rb75+KlgGgnA8zkTpf/Qqdwk/eo1WZPbcIijROEP4MNhVS IWacQXt4Ng8aWviFTZvysAc4k4hxnmFJgyRcUOSOmYd3uWkQI0OV1+cS5FoXmiQ2 Oucsw4iBC3VHqQmNhtuCNZ4Nx1v0kexqfBQCRBSB3HGXGBKjQ7REVi4gS2FydGhp ayBLdW1hciAoaHR0cDovL2d1aWx0LmJhZnNvZnQubmV0KSA8a2FydGhpa2t1bWFy QGdtYWlsLmNvbT6IZgQTEQIAJgUCRrTLzwIbAwUJAeEzgAYLCQgHAwIEFQIIAwQW AgMBAh4BAheAAAoJEEc052Xw3SBP+dkAoI5xfNw/7M7OVpmquFAwRb0k9KbYAJ0e IOypL+F8bUsxqISUIw3GFeb60LkEDQRGtMvPEBAA4SptM/eorjFWmC1S7xBfvKMF UMyFQvkwiWtDsWIrD0AMU4acT7fjYlMEKmVsaymXppxyvK6e/4jOX72UcsJZ4LL/ jtm4SGfknC6yEXdeyYz5Mmd6CN52LC/KfS4b771zO9yMDAl79/FxHIR7AvoSWb14 sbc7yKiF7OwfEFeZNtOYsZwDsQabnuFd5mzIMev/W2hgs55DF4ZJnmaVYb/PQbbw X5g7OwsN17OESPF/syaCzqKJ0GuzhnGHYgwY/84eeWkzqnGTxG52HH6Y1sYwKEmJ 32XLkUEHxHKoCvMW8C6E/s72Aw/WrBzq2yHhqW5npBrCIBCYWC70wzkew2DaOG/j WYtRP2ahJKxV9598D86w97M+6kNX2efMdSgJyLlFyyXlqX95sobE8BJRxjXqkiJy uaLgXv3CQZ1+kizhnkZeInA85NNahb3f2j/jA03eVoAhRq64fqN8W1kfvQwv YF31G7dsLLI2gx2ui1ouj6phIIlZPzypoDkoYZiXn3qXMDiyxJb+4wT5MZz2hjTU w51Z5WPe2ylPXKPqmiDw6zMNQW8OWVIXFljxLcRAhY9DQC9MIgnw7wCz9Bdu8sUs kkZjSsLo6Mc1SPCwjcuD8bDuvc7JIugNn/QFrLtV0o/BVpxMX0ujm2gC8/y7ruBJ cGPvx99e7lj7cmgac7cAAwUP/2h7MDCA3o1Bt1mInBlC+LHdJIaipToVc72lF8nN H3InjMppUkgvHQ+D/4r5hcWtskkRY+YG1iG45RbWMQlprfONOWEYfjkc/WDRj+PO lFszhcOSc2IlgCYsY1yEIF6HfE2MZpFWjM0z0hjotEULxlvi9meMV0OZRqwDdhEp 871jk1+3WkdjGMcZI3AO3wGRwb60eYW0cVNMv1umH0Cgh2pgU/vTbCqB7P5DaNHf BxflFAWumm7P70qJMoCa9SRNKh7vitlLBLGnSuhgT22aE/N/zslcprS7tFM3JFAl Jvr9V3pXzMmkk4zGwzpfvA8LpCPNVqqABrkGsduTsTyoPjLDmPH/CuFMu6RZCUHL sSKKhTpbE3zTgmyGja8DiJFKWmtojFPDEnPDSQweJYItkfnGSbHQVx5wkKhjABQ6 bCraNqgem0C+tKnDoRk/NlhKBCpGVdt8kIRNZ+iTA+4VB+R1usUY3ZpvrHYZFDX5 RxJ4jYLnhlKspSYvKkLg4IP7KnGr9dC16XJCa2wqR68EJa0u5XxigV4zscaawGYA Mx56+PoouaWI24+9JUPTMkV3UvF5xU2BumOW/IsKqs2qYEkG3QdczVwTnNuAZFQa 1WJAKOT7elDsrYsrdGWZpge2d/uoIFKjDobz7eZnkSLiX2rIzbkDniDD+aZd8G60 NVJliE8EGBECAA8FAka0y88CGwwFCQHhM4AACgkQRzTnZfDdIE91ngCgpgLiwwXQ MbyOCWjuWGY+phmYeagAnj7nMffLNWLpfVmKtA4yrtOHkSAM =RuU8 - -END PGP PUBLIC KEY BLOCK- -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG+qbnRzTnZfDdIE8RAttoAJ43zPb6TvQ32exV0O2oIER1E7jLegCfWcIW 1WHocs+ml0VSyx/q2g8PmMU= =wBtI -END PGP SIGNATURE-
