Does anyone have any objections to 7.8.680 becoming the next official release of Pike? Do note that machine code is non-functional on (at least more modern instances of) i386. If I don't hear any objections in 24 hours, I will attempt to update the website, etc, with the new information.
Best,
Bill
On Mon, May 21, 2012 at 11:16:43PM -0400, H. William Welliver III wrote:
Do note that machine code is non-functional on (at least more modern instances of) i386.
not an objection, but is this fixable?
greetings, martin.
On Mon, May 21, 2012 at 11:16:43PM -0400, H. William Welliver III wrote:
Do note that machine code is non-functional on (at least more modern instances of) i386.
not an objection, but is this fixable?
It's an incompatibility in the generated code with recent versions of gcc/x86, and has been fixed in Pike 7.9 since a month or two ago. It should be rather simple to backport the code to Pike 7.8.
/grubba
I tried porting the fix, but it doesn't seem to make any difference. It's possible I've made an error in my port (the cherry-pick generated a merge conflict so I did it by hand). I'll try it again tomorrow.
As a side note, on Darwin, the problem with machine code on ia32 (and perhaps 64-bit as well,) is that the assembly generated isn't PIC, so it fails to compile with errors about registers being clobbered.
Bill
On May 22, 2012, at 4:30 AM, Henrik Grubbström (Lysator) @ Pike (-) developers forum wrote:
On Mon, May 21, 2012 at 11:16:43PM -0400, H. William Welliver III wrote:
Do note that machine code is non-functional on (at least more modern instances of) i386.
not an objection, but is this fixable?
It's an incompatibility in the generated code with recent versions of gcc/x86, and has been fixed in Pike 7.9 since a month or two ago. It should be rather simple to backport the code to Pike 7.8.
/grubba
I tried porting the fix, but it doesn't seem to make any difference. It's possible I've made an error in my port (the cherry-pick generated a merge conflict so I did it by hand). I'll try it again tomorrow.
The fix involves more than one commit. You will eg need commit 4555f37d5b014dd680cf86b735fb20b659f296d3 which adds a function to interpret.c that was needed by the amd64 code-generator, and then by the new x86 code-generator.
The easiest approach is probably to first backport the amd64 code-generator, and then the new x86 code-generator.
As a side note, on Darwin, the problem with machine code on ia32 (and perhaps 64-bit as well,) is that the assembly generated isn't PIC, so it fails to compile with errors about registers being clobbered.
Bill
/grubba
Yes, I realized that after I stepped away from the computer... I had ported the 2 changes from ~April 6th, and after thinking about it don't remember anything in the changesets that actually used the new macros.
I'll take a closer look and see if I can do a proper job this time around.
Bill
On Wed, 23 May 2012, Henrik Grubbström (Lysator) @ Pike (-) developers forum wrote:
I tried porting the fix, but it doesn't seem to make any difference. It's possible I've made an error in my port (the cherry-pick generated a merge conflict so I did it by hand). I'll try it again tomorrow.
The fix involves more than one commit. You will eg need commit 4555f37d5b014dd680cf86b735fb20b659f296d3 which adds a function to interpret.c that was needed by the amd64 code-generator, and then by the new x86 code-generator.
The easiest approach is probably to first backport the amd64 code-generator, and then the new x86 code-generator.
As a side note, on Darwin, the problem with machine code on ia32 (and perhaps 64-bit as well,) is that the assembly generated isn't PIC, so it fails to compile with errors about registers being clobbered.
Bill
/grubba
I've had some time to think about this a little bit more, and I'm not completely convinced that it would be a good idea to back port a new machine code generator to 7.8. After all, that seems like a pretty major change to insert into what should theoretically be a stable release.
Perhaps it makes more sense to release 7.8 as-is and then focus attention on doing a stable release of 7.9/7.10/8.0/whatever. How far from being stable is 7.9 at this point? I've dabbled with it, but haven't done much serious work with it yet.
Bill
On May 23, 2012, at 6:49 PM, Bill Welliver wrote:
Yes, I realized that after I stepped away from the computer... I had ported the 2 changes from ~April 6th, and after thinking about it don't remember anything in the changesets that actually used the new macros.
I'll take a closer look and see if I can do a proper job this time around.
Bill
On Wed, 23 May 2012, Henrik Grubbström (Lysator) @ Pike (-) developers forum wrote:
The fix involves more than one commit. You will eg need commit 4555f37d5b014dd680cf86b735fb20b659f296d3 which adds a function to interpret.c that was needed by the amd64 code-generator, and then by the new x86 code-generator.
The easiest approach is probably to first backport the amd64 code-generator, and then the new x86 code-generator. /grubba
H. William Welliver III wrote:
I've had some time to think about this a little bit more, and I'm not completely convinced that it would be a good idea to back port a new machine code generator to 7.8. After all, that seems like a pretty major change to insert into what should theoretically be a stable release.
Well, that depends. If the machine code generator for 32-bit has been broken in all previous 7.8 releases already, then it is not a large problem to not fix it. However, if during the 7.8 release cycle, the 32-bit machine code generator has worked at one point or another, then it should keep working in this release. The question then becomes, is it more work to figure out why it broke since that release, or is it more work to backport the generator from the current 7.9.
On Fri, Jun 01, 2012 at 07:40:08AM +0000, Per Hedbor () @ Pike (-) developers forum wrote:
However, if during the 7.8 release cycle, the 32-bit machine code generator has worked at one point or another, then it should keep working in this release.
The change is in gcc, not pike.
gcc 4.6+ generates broken code for calls to our (old) x86-32 machine-code.
then as a stopgap measure we could say: if you want machinecode you need to use an older compiler. i think most linux distributions and i am pretty sure *bsd should still support gcc 4.5
so at least a workaround is available which can be added to the releasenotes.
what about other c-compilers like clang?
greetings, martin.
Martin B?hr wrote:
On Fri, Jun 01, 2012 at 07:40:08AM +0000, Per Hedbor () @ Pike (-) developers forum wrote:
gcc 4.6+ generates broken code for calls to our (old) x86-32 machine-code.
then as a stopgap measure we could say: if you want machinecode you need to use an older compiler. i think most linux distributions and i am pretty sure *bsd should still support gcc 4.5
so at least a workaround is available which can be added to the releasenotes.
That is good enough for me, I guess. Ideally the autoconfigure would detect that it is gcc 4.6 and then disables machinecode automatically on 32 bit.
Ideally the autoconfigure would detect that it is gcc 4.6 and then disables machinecode automatically on 32 bit.
Should be simple enough to do:
--- src/configure.in.orig 2012-06-01 14:46:35.000000000 +0200 +++ src/configure.in 2012-06-01 14:47:21.000000000 +0200 @@ -5433,7 +5433,7 @@ AC_CACHE_VAL(pike_cv_machine_code_arch, [ pike_cv_machine_code_arch=unknown AC_TRY_COMPILE([ -#if defined(__GNUC__) +#if defined(__GNUC__) && (__GNUC__<4 || (__GNUC__==4 && __GNUC_MINOR__<6)) #if !defined(__i386__) && !defined(__i386) #error Not ia32 architecture #endif
Is the code generation problem a gcc bug that will be fixed in a future gcc 4.x release, or is it an incompatibility that Pike must accomodate (like 7.9 has)?
it's also probably worth noting that there are problems with machine code on Darwin/i386, and it's still using gcc-4.2. I think that situation is related to position independent code, and does appear to have broken at some point (my 7.8.352 does have machine code, for example).
Bill
On Fri, 1 Jun 2012, Jonas Walldén @ Pike developers forum wrote:
Is the code generation problem a gcc bug that will be fixed in a future gcc 4.x release, or is it an incompatibility that Pike must accomodate (like 7.9 has)?
I've had some time to think about this a little bit more, and I'm not completely convinced that it would be a good idea to back port a new machine code generator to 7.8. After all, that seems like a pretty major change to insert into what should theoretically be a stable release.
Agreed.
Perhaps it makes more sense to release 7.8 as-is and then focus attention on doing a stable release of 7.9/7.10/8.0/whatever. How far from being stable is 7.9 at this point? I've dabbled with it, but haven't done much serious work with it yet.
The _Regexp.PCRE module will not compile if you have a recent (from this spring) libpcre unless you have a Pike 7.8 from today.
On Jun 11, 2012, at 4:30 AM, Henrik Grubbström (Lysator) @ Pike (-) developers forum wrote:
Perhaps it makes more sense to release 7.8 as-is and then focus attention on doing a stable release of 7.9/7.10/8.0/whatever. How far from being stable is 7.9 at this point? I've dabbled with it, but haven't done much serious work with it yet.
The _Regexp.PCRE module will not compile if you have a recent (from this spring) libpcre unless you have a Pike 7.8 from today.
I noticed that the pcre_info function has finally gone away a few months ago. I thought that I had contributed a patch for that at the time, but if you've just fixed it, it means I must never have pushed it.
I think that's a good reason to do another beta build. I'll start working on that tomorrow.
Bill
On Tue, Jun 12, 2012 at 8:18 AM, H. William Welliver III bill@welliver.org wrote:
On Jun 11, 2012, at 4:30 AM, Henrik Grubbström (Lysator) @ Pike (-) developers forum wrote:
The _Regexp.PCRE module will not compile if you have a recent (from this spring) libpcre unless you have a Pike 7.8 from today.
I think that's a good reason to do another beta build. I'll start working on that tomorrow.
Another good reason might be cf093b13d5c9578e6e6230022afa03755f2d08f9, which I just pushed. Apparently gentoo did a weird zlib change (WTF?), apparently that is not from upstream. As Gz is kind of handy, maybe include this one in the new 7.8, too?
Best,
Tobi
pike-devel@lists.lysator.liu.se
-
Bill Welliver -
H. William Welliver III
-
Henrik Grubbstr�m (Lysator) ＠ Pike (-) developers forum -
Jonas Walld�n ＠ Pike developers forum
-
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum
-
Martin Bähr -
Per Hedbor () ＠ Pike (-) developers forum
-
Stephen R. van den Berg -
Tobias S. Josefowitz