Re: Need JIT help please - JIT broken with optimized build on Windows (VC)
Paolo Molaro wrote: On 08/16/07 Ron Blaschke wrote: This optimization reaches likely back to times, when the opcode engine was designed. It's saving one interpreter push statement [1] per JIT calling one external function, and I've always thought of it as a very cool (and valid) thingy, when I first realized, why the interpreter is the second argument in opcode functions ;) I think it's a really cool idea, too. I'd like to have a way to disable it, though, to measure its effect, and maybe to work around compilers like VC (at least until a better solution comes around). The optimization done by the parrot jit is invalid for the x86 C calling convention: the area of memory containing the passed arguments can be used as scratch space by the called function. If you can make sure it's not harmful that way you could still use it when calling parrot's own jitted functions which could use a different calling convention, but it is wrong when interoperating with other code (gcc can generate the same issues, so it's not just VC). Many thanks for your help. I couldn't find detailed descriptions of the x86 C calling convention, which also talk about this. But as nobody explicitly says you can reuse it, I guess it's undefined and should be avoided. Thanks, Ron
Re: Current win32 linking issues: Summary
Mark Glines wrote: On Tue, 21 Aug 2007 13:08:05 +0200 Ron Blaschke [EMAIL PROTECTED] wrote: The win32 skippage will need to be removed again, once the PMCNULL symbol is exported correctly from libparrot.dll. Not adding the skip on the other t/src tests will cause them to fail. I think it would be best to skip them all, or none of them. I agree. If we can't find a quick fix to get the tests to pass, I can clean things up to make them consistent (all-failing or all-skipped) before the release. I don't have a preference which route we take. Don't know if its a problem if they fail. I don't have a problem with failures as they tell me there's something that needs attention. True. Well, these issues do need attention, so maybe they *should* fail. :) Jerry mentioned yesterday that there shouldn't be any failures for a release, which makes sense as it would only upset users. Maybe there should be a ticket for the failures then? Or an environment variable like PARROT_PORTER which makes all tests fail that are skipped because they are broken, not because the feature is not supported on the platform? 1. Do you have any ideas for how we need to decorate PMCNULL so it gets exported by the dll? PARROT_API doesn't seem to be sufficient. I think maybe its because its a variable, not a function. 2. Do you have any preference on how we fix up the Parrot::Config stuff so we can put libparrot.lib on the link command-line for win32, in the t/src/ tests? Sorry to ask so many questions, but I'm a linux geek, and utterly clueless about win32... Many thanks for helping with the t/src issues, I'm glad you jumped on the Windows train. Some things work differently on Windows and Visual C++, especially the linking and loading part, with symbol exports/imports on the very top. One great way to find out about compiled objects, libraries and executables is the COFF/PE Dumper (dumpbin), which shows details about the binary image. Another fine tool is the Dependency Walker (depends), which exactly shows you which libraries would be loaded, including their full path, what symbols they export and which they import. Please don't hesitate to ask if you have any questions. Depending on $job workload it might take some time before I can get back to you, though. Ron
Re: [svn:parrot] r20688 - in trunk: include/parrot src
On Mon, Aug 20, 2007 at 05:26:22PM -0400, Andy Dougherty wrote: Nor can I. Thus you either use lots of platform-specific code (determined by Configure.pl) or turn off gcc's -Wfloat-equal warning flag and just write f == 0.0. Or, maybe f = 0.0 f = 0.0 which I believe is identical, even in the face of NaNs. Nicholas Clark
Re: Current win32 linking issues: Summary
On 07/08/22 11:16 +0200, Ron Blaschke wrote: Jerry mentioned yesterday that there shouldn't be any failures for a release, which makes sense as it would only upset users. Maybe there should be a ticket for the failures then? Or an environment variable like PARROT_PORTER which makes all tests fail that are skipped because they are broken, not because the feature is not supported on the platform? isn't what the TODO tests are meant to be? ie, bonus points if it works, but no harm if they fail... jérôme -- [EMAIL PROTECTED]
Re: Current win32 linking issues: Summary
On Wed, 22 Aug 2007 11:16:12 +0200 Ron Blaschke [EMAIL PROTECTED] wrote: Don't know if its a problem if they fail. I don't have a problem with failures as they tell me there's something that needs attention. True. Well, these issues do need attention, so maybe they *should* fail. :) Jerry mentioned yesterday that there shouldn't be any failures for a release, which makes sense as it would only upset users. Maybe there should be a ticket for the failures then? Or an environment variable like PARROT_PORTER which makes all tests fail that are skipped because they are broken, not because the feature is not supported on the platform? Or maybe we should wait until the release, then stop skipping the error, which should help ensure it gets fixed before the next release. (It is a pretty important issue, I think, so I don't want to mask it any longer than absolutely necessary. Embeddability is important to me.) Many thanks for helping with the t/src issues, I'm glad you jumped on the Windows train. Some things work differently on Windows and Visual C++, especially the linking and loading part, with symbol exports/imports on the very top. One great way to find out about compiled objects, libraries and executables is the COFF/PE Dumper (dumpbin), which shows details about the binary image. Another fine tool is the Dependency Walker (depends), which exactly shows you which libraries would be loaded, including their full path, what symbols they export and which they import. Great, good tips. I don't know if I'm really on the windows train, though. I'm still primarily linux with a bit of freebsd on the side; for me, win32 is mostly in the category of bizarre platform to make portability testing more interesting. But it will be good to know my way around a little bit better, so I can solve things more quickly next time. :) Please don't hesitate to ask if you have any questions. Depending on $job workload it might take some time before I can get back to you, though. I know the feeling. Thanks! Mark
[perl #44845] [PATCH] C++ cleanups for Solaris CC
# New Ticket Created by Steve Peters # Please include the string: [perl #44845] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=44845 Solaris CC is a bit more sensative than g++ in three cases. First, making sure that arguments have the correct type. Second, making sure that that return type is correct. Finally, functions that return something, must return. The attached patch fixes these things. Steve Peters [EMAIL PROTECTED] --- src/encoding.c.old Wed Aug 22 08:15:22 2007 +++ src/encoding.c Wed Aug 22 08:15:58 2007 @@ -105,6 +105,7 @@ { UNUSED(encodingname); real_exception(interp, NULL, UNIMPLEMENTED, Can't load encodings yet); +return NULL; } /* --- src/interpreter.c.old Wed Aug 22 08:16:48 2007 +++ src/interpreter.c Wed Aug 22 08:17:39 2007 @@ -692,6 +692,7 @@ PIO_eprintf(interp, Computed goto unavailable in this configuration.\n); Parrot_exit(interp, 1); +return pc; #endif } --- src/string.c.oldWed Aug 22 08:14:21 2007 +++ src/string.cWed Aug 22 08:14:50 2007 @@ -2262,7 +2262,7 @@ enc_char = ascii; /* check for encoding: */ -p = strchr(enc_char, ':'); +p = (char *)strchr(enc_char, ':'); if (p) { *p = '\0'; --- src/ops/math.ops.oldWed Aug 22 08:43:16 2007 +++ src/ops/math.opsWed Aug 22 08:42:46 2007 @@ -432,7 +432,7 @@ real_exception(interp, NULL, E_ZeroDivisionError, Divide by zero); - f = floor($1 / den); + f = floor((FLOATVAL)$1 / den); $1 = (INTVAL)f; goto NEXT(); } @@ -454,7 +454,7 @@ real_exception(interp, NULL, E_ZeroDivisionError, Divide by zero); - f = floor($2 / den); + f = floor((FLOATVAL)$2 / den); $1 = (INTVAL)f; goto NEXT(); } --- src/ops/experimental.ops.oldWed Aug 22 08:40:58 2007 +++ src/ops/experimental.opsWed Aug 22 08:38:34 2007 @@ -139,8 +139,8 @@ yk = ykp1; } $1 = r1; - $2 = (INTVAL)(xk * pow(-1, n)); - $3 = (INTVAL)(yk * pow(-1, n+1)); + $2 = (INTVAL)(xk * pow(-1, (FLOATVAL)n)); + $3 = (INTVAL)(yk * pow(-1, (FLOATVAL)n+1)); x = $2 * $4; y = $3 * $5;
Re: [perl #44845] [PATCH] C++ cleanups for Solaris CC
--- src/encoding.c.old Wed Aug 22 08:15:22 2007 +++ src/encoding.c Wed Aug 22 08:15:58 2007 @@ -105,6 +105,7 @@ { UNUSED(encodingname); real_exception(interp, NULL, UNIMPLEMENTED, Can't load encodings yet); +return NULL; } /* --- src/interpreter.c.old Wed Aug 22 08:16:48 2007 +++ src/interpreter.c Wed Aug 22 08:17:39 2007 @@ -692,6 +692,7 @@ PIO_eprintf(interp, Computed goto unavailable in this configuration.\n); Parrot_exit(interp, 1); +return pc; #endif } I don't know if these two changes bring anything. Neither function actually returns even though there is a return value expected, so the added code is actually dead code as it will never get executed. The function real_exception() doesn't return, and we should be able to tell the compiler that (this is what Andy Lester has been doing a lot of with his recent function attribute work). I'm guessing that suncc throws a warning here can be rectified in the fullness of time. Just my $0.02 Paul
Re: [perl #44845] [PATCH] C++ cleanups for Solaris CC
On Wed, Aug 22, 2007 at 04:11:38PM +0200, Paul Cochrane wrote: --- src/encoding.c.old Wed Aug 22 08:15:22 2007 +++ src/encoding.c Wed Aug 22 08:15:58 2007 @@ -105,6 +105,7 @@ { UNUSED(encodingname); real_exception(interp, NULL, UNIMPLEMENTED, Can't load encodings yet); +return NULL; } /* --- src/interpreter.c.old Wed Aug 22 08:16:48 2007 +++ src/interpreter.c Wed Aug 22 08:17:39 2007 @@ -692,6 +692,7 @@ PIO_eprintf(interp, Computed goto unavailable in this configuration.\n); Parrot_exit(interp, 1); +return pc; #endif } I don't know if these two changes bring anything. Neither function actually returns even though there is a return value expected, so the added code is actually dead code as it will never get executed. The function real_exception() doesn't return, and we should be able to tell the compiler that (this is what Andy Lester has been doing a lot of with his recent function attribute work). I'm guessing that suncc throws a warning here can be rectified in the fullness of time. Just my $0.02 Paul We can leave it out, but then we'll never be able to compile Parrot with Solaris CC. Steve Peters [EMAIL PROTECTED]
[perl #44847] Parrot 0.4.16 Release
# New Ticket Created by Patrick R. Michaud # Please include the string: [perl #44847] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=44847 This ticket is a placeholder for the 0.4.16 release on 18 September 2007.
Re: [perl #44845] [PATCH] C++ cleanups for Solaris CC
On 8/22/07, Steve Peters [EMAIL PROTECTED] wrote: On Wed, Aug 22, 2007 at 04:11:38PM +0200, Paul Cochrane wrote: --- src/encoding.c.old Wed Aug 22 08:15:22 2007 +++ src/encoding.c Wed Aug 22 08:15:58 2007 @@ -105,6 +105,7 @@ { UNUSED(encodingname); real_exception(interp, NULL, UNIMPLEMENTED, Can't load encodings yet); +return NULL; } /* --- src/interpreter.c.old Wed Aug 22 08:16:48 2007 +++ src/interpreter.c Wed Aug 22 08:17:39 2007 @@ -692,6 +692,7 @@ PIO_eprintf(interp, Computed goto unavailable in this configuration.\n); Parrot_exit(interp, 1); +return pc; #endif } I don't know if these two changes bring anything. Neither function actually returns even though there is a return value expected, so the added code is actually dead code as it will never get executed. The function real_exception() doesn't return, and we should be able to tell the compiler that (this is what Andy Lester has been doing a lot of with his recent function attribute work). I'm guessing that suncc throws a warning here can be rectified in the fullness of time. Just my $0.02 Paul We can leave it out, but then we'll never be able to compile Parrot with Solaris CC. these are compile *errors*? wow. they'll cause 'unreachable code' warnings on msvc, but that's for the greater good if it allows solaris cc to build parrot. however, please put a note somewhere or mark these so that they're not removed by somebody who later decides to remove unreachable code. ~jerry
Re: [perl #44845] [PATCH] C++ cleanups for Solaris CC
On 22/08/07, Steve Peters [EMAIL PROTECTED] wrote: On Wed, Aug 22, 2007 at 04:11:38PM +0200, Paul Cochrane wrote: --- src/encoding.c.old Wed Aug 22 08:15:22 2007 +++ src/encoding.c Wed Aug 22 08:15:58 2007 @@ -105,6 +105,7 @@ { UNUSED(encodingname); real_exception(interp, NULL, UNIMPLEMENTED, Can't load encodings yet); +return NULL; } /* --- src/interpreter.c.old Wed Aug 22 08:16:48 2007 +++ src/interpreter.c Wed Aug 22 08:17:39 2007 @@ -692,6 +692,7 @@ PIO_eprintf(interp, Computed goto unavailable in this configuration.\n); Parrot_exit(interp, 1); +return pc; #endif } I don't know if these two changes bring anything. Neither function actually returns even though there is a return value expected, so the added code is actually dead code as it will never get executed. The function real_exception() doesn't return, and we should be able to tell the compiler that (this is what Andy Lester has been doing a lot of with his recent function attribute work). I'm guessing that suncc throws a warning here can be rectified in the fullness of time. Just my $0.02 Paul We can leave it out, but then we'll never be able to compile Parrot with Solaris CC. That's weird as I had suncc compiling Parrot recently...
Re: [perl #44845] [PATCH] C++ cleanups for Solaris CC
We can leave it out, but then we'll never be able to compile Parrot with Solaris CC. I just tried to compile Parrot with suncc and everything works (the tests are running atm). Did you configure with --cgoto=0? This is a known problem that suncc should be able to handle computed gotos but switching them off actually makes suncc build Parrot and allows the tests to run. Paul
[perl #44851] Update step 2.f in release_manager_guide.pod
# New Ticket Created by Patrick R. Michaud # Please include the string: [perl #44851] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=44851 Supposedly a change to the pbc format eliminates the need for step 2.f in the release manager guide: : =item f : : Update FPBC_COMPAT, perhaps by collapsing intra-release entries : into a single entry naming the release. I've published the 0.4.15 release having skipped this step (i.e., _not_ updating PBC_COMPAT), but I think we should verify that things work as expected before officially removing it from the guide. So, this ticket is a placeholder to review the results of the 0.4.15 release and to update the guide accordingly. Pm
[perl #44855] Re: Current win32 linking issues: Summary
On Wed, 22 Aug 2007 11:16:12 +0200 Ron Blaschke [EMAIL PROTECTED] wrote: Jerry mentioned yesterday that there shouldn't be any failures for a release, which makes sense as it would only upset users. Maybe there should be a ticket for the failures then? I have created ticket #44855 for this issue. It sounds like we need to pass -DIN_LIBPARROT or somesuch to the compiler when compiling objects that end up in libparrot.dll. Then, we can use that to decide how PARROT_API will be defined. Sometime in the next couple of days, I'll see what's required to pass additional defines to the compiler, from within the Makefile system. Mark
[perl #44861] [TODO]: remove compiler warnings note from README
# New Ticket Created by Patrick R. Michaud # Please include the string: [perl #44861] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=44861 For the 0.4.15 release a note was added to README regarding the large number of compiler warnings in the release: + As of the 0.4.15 release you may see a large number of compiler + warnings throughout the make process -- this is normal. The configure + system now enables a lot of additional compiler warning options, and + we're still in the process of reviewing/cleaning up the warnings. When the number of warnings comes back down, we should remove this note. Pm
[perl #44865] [BUG] t/stm/basic_mt.t fails on x86_64
# New Ticket Created by Patrick R. Michaud # Please include the string: [perl #44865] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=44865 As of r20786, t/stm/basic_mt.t is failing on my x86_64 box with a failed assertion: $ prove -v t/stm/basic_mt.t t/stm/basic_mt1..4 ok 1 - wait (simple) ok 2 - wait (simple, strings) not ok 3 - get deadlock # Failed test (t/stm/basic_mt.t at line 168) # Exited with error code: 134 # Received: # src/stm/backend.c:608: failed assertion 'successp' # Backtrace - Obtained 13 stack frames (max trace depth is 32). # (unknown) # Parrot_confess # (unknown) # (unknown) # Parrot_stm_commit_ic # (unknown) # (unknown) # (unknown) # (unknown) # Parrot_runops_fromc_args # (unknown) # (unknown) # clone # Aborted (core dumped) # # Expected: # /okay/ # ok 4 - wait + invalidate outer transcation ok All tests successful. Files=1, Tests=4, 5 wallclock secs ( 1.92 cusr + 0.26 csys = 2.18 CPU) $ For the 0.4.15 release I'm marking this test as 'todo' for 64-bit platforms. Pm
Re: [perl #44845] [PATCH] C++ cleanups for Solaris CC
On 22/08/07, Nicholas Clark [EMAIL PROTECTED] wrote: On Wed, Aug 22, 2007 at 05:40:45PM +0200, Paul Cochrane wrote: We can leave it out, but then we'll never be able to compile Parrot with Solaris CC. I just tried to compile Parrot with suncc and everything works (the CC isn't cc (C++ compiler versus C compiler) Ooops. Didn't realise, sorry.
Re: [perl #44809] [PATCH] use Storable instead of Data::Dumper for PMC .dump files
Oops. I replied to this on the RT site, but it looks like I neglected to tell it to copy the list (or you). I'll cutpaste my response below. On Tue, 21 Aug 2007 21:02:39 -0400 James E Keenan [EMAIL PROTECTED] wrote: I do have some qualms. (1) I know that there have been issues with incompatibility among different versions of Storable. I myself have been bit by these issues with different versions of Storable distributed with different versions of Perl 5.8 (not to mention 5.6). Some of these issues are alluded to in the POD (http://search.cpan.org/dist/Storable/Storable.pm#FORWARD_COMPATIBILITY). I have never heard such compatibility issues with respect to Data::Dumper. This is not a killer objection, but it should be considered. (2) Not that I'm opposed to Storable entirely. Hey, I use it in Parrot::Configure::Trace! But there, as in other places I've used it, I've always found I got better mileage by using 'nstore' instead of 'store'. Hi! I agree, nstore is more useful for stuff that's kept around for a while, exchanged between machines and so forth. But, keeping in mind these files are built by pmc2c.pl as part of the parrot build process, rebuilt whenever the pmc file changes, and removed whenever you do a make clean, does forwards compatibility (or even endian-portability) actually matter? Correct me if I'm wrong, but I don't think we keep any of these files around. Mark
Parrot 0.4.15 Augean Stable released!
On behalf of the Parrot team, I'm proud to announce Parrot 0.4.15 Augean Stable. Parrot (http://parrotcode.org/) is a virtual machine aimed at running all dynamic languages. Parrot 0.4.15 can be obtained via CPAN (soon), or follow the download instructions at http://parrotcode.org/source.html. For those who would like to develop on Parrot, or help develop Parrot itself, we recommend using Subversion or SVK on the source code repository to get the latest and best Parrot code. Parrot 0.4.15 News: - Implementation: + Lots of code review, many bugs fixed + Many more code cleanups and compiler warning levels + Started a new jit engine for 64-bit processors + Refactored configure process, with tests and new diagnostic options + Added new CodeString PMC for dynamic generation of PIR code + More pdd15 support for object metamodel. - Languages: + Added NQP (Not Quite Perl), a very lightweight Perl 6-like language + Significant improvements and refactors to PCT (Parrot Compiler Toolkit) + perl6 passes more spec tests + Lua works now with a PGE/TGE/PAST-pm based compiler, lives in one pbc, and the interpreter has same behavior as original. - Documentation + Added a committers' HOWTO + More PIR tutorial examples + Added PAUSE guide Thanks to all our contributors for making this possible, and our sponsors for supporting this project. Enjoy!
[perl #44865] [BUG] t/stm/basic_mt.t fails on x86_64
On Wed Aug 22 09:49:20 2007, pmichaud wrote: # Failed test (t/stm/basic_mt.t at line 168) # Exited with error code: 134 # Received: # src/stm/backend.c:608: failed assertion 'successp' I get the same failure, intermittently, on dual-CPU x86. It looks like a thread race condition, not specific to x86_64. t/stm/basic_mtNOK 3/4 # Failed test (t/stm/basic_mt.t at line 161) # Exited with error code: [SIGNAL 6] # Received: # src/stm/backend.c:608: failed assertion 'successp' # Backtrace - Obtained 13 stack frames (max trace depth is 32). # Parrot_print_backtrace # Parrot_confess # (unknown) # Parrot_STM_commit # Parrot_stm_commit_ic # runops_slow_core # runops_int # runops # (unknown) # Parrot_runops_fromc_args # (unknown) # (unknown) # __clone # # Expected: # /okay/ # # Looks like you failed 1 test of 4.
[perl #44855] [BUG] msvc: embedders can't link against libparrot.dll
# New Ticket Created by Mark Glines # Please include the string: [perl #44855] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=44855 t/src/compiler.t fails on msvc/win32 because the linker can't find the PMCNULL variable. Apparently this symbol is exported by the dll properly, but not imported by the embedded application properly. The background: 11:19 @Ron The story goes like this. 11:19 @Ron When building a DLL you need to tell the compiler to export the symbol. 11:20 @Ron This is done by __declspec(dllexport). 11:20 @Ron When using the DLL you need to tell the compiler to import it, with __declspec(dllimport). 11:21 @Ron This is done in include/parrot/config.h, but tied to #define PARROT_IN_EXTENSION. 11:22 @Ron Which makes sense, because it was mostly relevant for the extensions, which are separate shared objects, linked against libparrot. The problem: Embedded applications (such as those compiled by t/src/compiler.t) do not get the __declspec(dllimport) tag defined properly, and thus, do not import symbols from the dll correctly. This prevents third party applications from embedding parrot, by linking against libparrot. The proposed solution: 11:46 @Ron Infinoid, how about this. 11:46 @Ron in config.h, PARROT_API uses dllimport by default. 11:46 @Ron only uses dllexport if PARROT_EXPORTS is defined. 11:47 @Ron When compiling the sources that belong to libparrot.lib we'd need to define PARROT_EXPORTS. 11:48 @Infinoid will that be a headerfile define, or passed on the compiler command-line? 11:48 @Ron I think passed on the command line. The tests in t/src/compiler.t are skipped so it'll pass today's 0.4.15 release, but should be unskipped for testing whether this issue is resolved. Mark
[perl #44853] compilers/pirc borken on win32
# New Ticket Created by Klaas-Jan Stol # Please include the string: [perl #44853] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=44853 Hello, I found that compilers/pirc is currently not compiling using MS VC. It says something about not knowing PARROT_ASSERT. No time to look into it deeply right now, so this bug report instead. regards, klaas-jan
Re: [perl #44853] compilers/pirc borken on win32
Also borked on gcc 4.0.1 osx/intel. See attached, result of cd compilers/pirc make On Aug 22, 2007, at 12:07 PM, Klaas-Jan Stol (via RT) wrote: # New Ticket Created by Klaas-Jan Stol # Please include the string: [perl #44853] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=44853 Hello, I found that compilers/pirc is currently not compiling using MS VC. It says something about not knowing PARROT_ASSERT. No time to look into it deeply right now, so this bug report instead. regards, klaas-jan -- Will Coke Coleda [EMAIL PROTECTED] errors.out Description: Binary data
[perl #44875] YA Tcl segfault
# New Ticket Created by Will Coleda # Please include the string: [perl #44875] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=44875 During a routine svn up today, I noticed Tcl was segfaulting yet again. svn_binary_search tells me* the offending revision was: http://perlsix.org/svn/parrot/revision/?rev=20766 So now it's apparently a three-way death match between lua, tcl, and perl6. * Actually, svn_binary_search got it down to after 20762 and no later than 20767 - I then did a quick scan of the log in that range to find the culprit** ** I did actually compile both 20765 and 20766 to verify this was the culprit. -- Will Coke Coleda [EMAIL PROTECTED]
Re: [perl #44845] [PATCH] C++ cleanups for Solaris CC
On Wed, Aug 22, 2007 at 05:40:45PM +0200, Paul Cochrane wrote: We can leave it out, but then we'll never be able to compile Parrot with Solaris CC. I just tried to compile Parrot with suncc and everything works (the CC isn't cc (C++ compiler versus C compiler) Nicholas Clark