From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ken Raeburn Newsgroups: gmane.lisp.guile.devel Subject: Re: more compilation failures: -DSCM_DEBUG_TYPING_STRICTNESS=2 Date: Wed, 18 Nov 2009 15:40:21 -0500 Message-ID: References: <87aayk2my2.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 (Apple Message framework v936) Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1258576869 24420 80.91.229.12 (18 Nov 2009 20:41:09 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 18 Nov 2009 20:41:09 +0000 (UTC) Cc: guile-devel@gnu.org To: =?ISO-8859-1?Q?Ludovic_Court=E8s?= Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Wed Nov 18 21:41:01 2009 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1NArKn-0001uV-5p for guile-devel@m.gmane.org; Wed, 18 Nov 2009 21:41:01 +0100 Original-Received: from localhost ([127.0.0.1]:39564 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NArKm-0004Gu-OV for guile-devel@m.gmane.org; Wed, 18 Nov 2009 15:41:00 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NArKR-00048r-No for guile-devel@gnu.org; Wed, 18 Nov 2009 15:40:39 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NArKM-00046F-9k for guile-devel@gnu.org; Wed, 18 Nov 2009 15:40:38 -0500 Original-Received: from [199.232.76.173] (port=48638 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NArKM-000469-6a for guile-devel@gnu.org; Wed, 18 Nov 2009 15:40:34 -0500 Original-Received: from splat.raeburn.org ([69.25.196.39]:39980 helo=raeburn.org) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NArKB-00075S-9Z; Wed, 18 Nov 2009 15:40:31 -0500 Original-Received: from [10.0.0.158] ([10.0.0.158]) by raeburn.org (8.14.3/8.14.1) with ESMTP id nAIKeLmY011815; Wed, 18 Nov 2009 15:40:21 -0500 (EST) In-Reply-To: <87aayk2my2.fsf@gnu.org> X-Mailer: Apple Mail (2.936) X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:9699 Archived-At: On Nov 18, 2009, at 04:37, Ludovic Court=E8s wrote: > =46rom time to time, I test it on some =93exotic=94 hardware = architectures =20 > of > the GCC Compile Farm (MIPS, Alpha, PPC64, etc.), and it=92s been = working > pretty well so far. I also got accounts on Tru64, AIX, and now =20 > Solaris > and HP-UX, which I=92m hoping to put to good use by the time we =20 > release 2.0. Actually, I wouldn't consider any of those terribly "exotic", unless =20 you're using one of the early Alphas that didn't support byte-access =20 operations. But at least we get some tests with strict memory =20 alignment requirements, etc. Windows testing would be kind of =20 important, too. Have access to any embedded systems? (Of course, if =20= they're not POSIX, the thread system would require some more porting =20 work... and it might show up areas where we've made other unwarranted =20= assumptions.) Actually, Alpha is also interesting in that the spec permits weak =20 memory ordering -- so that one processor could execute "x =3D 1; y =3D = 2;" =20 and even without the compiler playing games, a second processor may =20 see y modified before x. Such a machine can easily support C =20 (multiprocessor interactions are outside the spec) and POSIX (mutex =20 calls can incorporate memory barriers to force synchronization), but I =20= believe libguile assumes strict ordering between threads. I don't =20 know if the actual processor implementations or OSes permit such =20 reordering. Testing Guile on a multiprocessor system using weak =20 memory ordering would be interesting; I suspect, though, that it would =20= simply not work reliably. > That said, I=92m not too worried about the Cray pointer thing. IOW, =20= > it=92s > OK for me to live with potential Cray breakage until someone with =20 > access > to such a machine (how many are there around the world?) can come up > with a bug report or a fix. It would be "better" in some sense if someone could try it out and let =20= us know for sure what the situation is -- if any of the machines still =20= exist. I wouldn't try to fix it for the Cray without someone out =20 there actively interested in using that version, but I don't want to =20 turn a blind eye to problems I'm confident would come up for people =20 in reasonable (if unusual) C environments. And I'm concerned that the =20= fixes would involve things like changing a macro, that currently works =20= with SCM or pointer types, into two macros, one for SCM values and one =20= for pointers -- that would mean an API change might be required in =20 order to finish a port. > Now, if =91SCM_DEBUG_TYPING_STRICTNESS=92 can help us prevent = breakage, > that=92s nice. I=92ve never used it so far, and never felt the need = to =20 > use > it, but I=92d be glad to follow your lead on this matter. :-) That's one... ;-) Ken=