unofficial mirror of bug-guile@gnu.org 
 help / color / mirror / Atom feed
* FW: problem compiling guile on IA64 by Intel compiler
@ 2003-07-08 15:46 Sysoltsev, Vyatcheslav
  0 siblings, 0 replies; 7+ messages in thread
From: Sysoltsev, Vyatcheslav @ 2003-07-08 15:46 UTC (permalink / raw)
  Cc: Denis Briltz (E-mail)

I expect some reply to ensure that this is not dummy mailbox.
	--Slava

-----Original Message-----
From: Sysoltsev, Vyatcheslav 
Sent: Tuesday, June 24, 2003 4:45 PM
To: 'bug-guile@gnu.org'
Cc: Denis Briltz (E-mail)
Subject: problem compiling guile on IA64 by Intel compiler


Hi there!
Because Intel compiler doesn't support asm inlines on IA64 I cannot compile
guile from sources on IA64 due to SCM_FENCE macro from libguile/__scm.h.
Here is this macro:
/* Anthony Green writes:
   When the compiler sees...
           DEFER_INTS;
           [critical code here]
           ALLOW_INTS;
   ...it doesn't actually promise to keep the critical code within the
   boundries of the DEFER/ALLOW_INTS instructions. It may very well
   schedule it outside of the magic defined in those macros.

   However, GCC's volatile asm feature forms a barrier over which code is
   never moved. So if you add...
           asm ("");
   ...to each of the DEFER_INTS and ALLOW_INTS macros, the critical
   code will always remain in place.  asm's without inputs or outputs
   are implicitly volatile. */
#ifdef __GNUC__
#define SCM_FENCE asm /* volatile */ ("")
#else
#define SCM_FENCE
#endif

So I'd change the condition
#ifdef __GNUC__
... to ...
#if defined(__GNUC__) && !(defined(__INTEL_COMPILER) && defined(__ia64))

In this case the code will be acceptable both with gcc and Intel compiler.
However as I understand from the comment defining SCM_FENCE to nothing is
dangerous because of the compiler optimization. If you've got a real problem
with it, let me know and I will cope with this further.
		-- Slava Sysoltsev

----------------------------------------------------------------------------
----------------------
--- libguile/__scm.h.orig       2003-06-24 16:33:40.000000000 +0400
+++ libguile/__scm.h    2003-06-24 16:34:35.000000000 +0400
@@ -362,7 +362,7 @@
    ...to each of the DEFER_INTS and ALLOW_INTS macros, the critical
    code will always remain in place.  asm's without inputs or outputs
    are implicitly volatile. */
-#ifdef __GNUC__
+#if defined(__GNUC__) && !(defined(__INTEL_COMPILER) && defined(__ia64))
 #define SCM_FENCE asm /* volatile */ ("")
 #else
 #define SCM_FENCE


_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-guile


^ permalink raw reply	[flat|nested] 7+ messages in thread

* RE: FW: problem compiling guile on IA64 by Intel compiler
@ 2003-07-09  5:03 Sysoltsev, Vyatcheslav
  2003-07-09  9:44 ` Thien-Thi Nguyen
  0 siblings, 1 reply; 7+ messages in thread
From: Sysoltsev, Vyatcheslav @ 2003-07-09  5:03 UTC (permalink / raw)
  Cc: bug-guile, Denis Briltz (E-mail)

Starting from 8.0 Intel compiler defines GNUC macroses.
Thanks for response.
	--Slava

-----Original Message-----
From: Thien-Thi Nguyen [mailto:ttn@glug.org]
Sent: Tuesday, July 08, 2003 10:06 PM
To: Sysoltsev, Vyatcheslav
Cc: bug-guile@gnu.org; Briltz, Denis
Subject: Re: FW: problem compiling guile on IA64 by Intel compiler


   From: "Sysoltsev, Vyatcheslav" <vyatcheslav.sysoltsev@intel.com>
   Date: Tue, 8 Jul 2003 19:46:20 +0400 

   -#ifdef __GNUC__
   +#if defined(__GNUC__) && !(defined(__INTEL_COMPILER) ...

why does the intel compiler define __GNUC__ ?
perhaps there is a bug in another guile header?

thi


_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-guile


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: FW: problem compiling guile on IA64 by Intel compiler
  2003-07-09  5:03 Sysoltsev, Vyatcheslav
@ 2003-07-09  9:44 ` Thien-Thi Nguyen
  0 siblings, 0 replies; 7+ messages in thread
From: Thien-Thi Nguyen @ 2003-07-09  9:44 UTC (permalink / raw)
  Cc: bug-guile, Denis.Briltz

   From: "Sysoltsev, Vyatcheslav" <vyatcheslav.sysoltsev@intel.com>
   Date: Wed, 9 Jul 2003 09:03:57 +0400 

   Starting from 8.0 Intel compiler defines GNUC macroses.

that's very strange (IMHO).  anyway, does the intel compiler have plans
to support ia64 inline asm in the future?  we would have to change the
code again at that time.

thi


_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-guile


^ permalink raw reply	[flat|nested] 7+ messages in thread

* RE: FW: problem compiling guile on IA64 by Intel compiler
@ 2003-07-09  9:49 Sysoltsev, Vyatcheslav
  2003-07-09 10:24 ` Thien-Thi Nguyen
  0 siblings, 1 reply; 7+ messages in thread
From: Sysoltsev, Vyatcheslav @ 2003-07-09  9:49 UTC (permalink / raw)
  Cc: bug-guile, Denis Briltz (E-mail)

No, Intel compiler doesn't plan to support ia64 asm inlines in foreseeable
future.
	--Slava

-----Original Message-----
From: Thien-Thi Nguyen [mailto:ttn@glug.org]
Sent: Wednesday, July 09, 2003 1:44 PM
To: Sysoltsev, Vyatcheslav
Cc: Briltz, Denis; bug-guile@gnu.org
Subject: Re: FW: problem compiling guile on IA64 by Intel compiler


   From: "Sysoltsev, Vyatcheslav" <vyatcheslav.sysoltsev@intel.com>
   Date: Wed, 9 Jul 2003 09:03:57 +0400 

   Starting from 8.0 Intel compiler defines GNUC macroses.

that's very strange (IMHO).  anyway, does the intel compiler have plans
to support ia64 inline asm in the future?  we would have to change the
code again at that time.

thi


_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-guile


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: FW: problem compiling guile on IA64 by Intel compiler
  2003-07-09  9:49 FW: problem compiling guile on IA64 by Intel compiler Sysoltsev, Vyatcheslav
@ 2003-07-09 10:24 ` Thien-Thi Nguyen
  0 siblings, 0 replies; 7+ messages in thread
From: Thien-Thi Nguyen @ 2003-07-09 10:24 UTC (permalink / raw)
  Cc: bug-guile, Denis.Briltz

   From: "Sysoltsev, Vyatcheslav" <vyatcheslav.sysoltsev@intel.com>
   Date: Wed, 9 Jul 2003 13:49:20 +0400 

   No, Intel compiler doesn't plan to support ia64 asm inlines in
   foreseeable future.

looking at __scm.h closely, i see the inline asm is just an
implementation detail of SCM_FENCE, but SCM_FENCE is important
anyway (having it be defined to be nothing is indeed dangerous).

so the question becomes: does the intel compiler have an alternate
method to guarantee ordering as required by SCM_FENCE?  sorry for
not asking this earlier, when you had said you would be willing to
dig into the issue.

thi


_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-guile


^ permalink raw reply	[flat|nested] 7+ messages in thread

* RE: FW: problem compiling guile on IA64 by Intel compiler
@ 2003-07-09 12:23 Sysoltsev, Vyatcheslav
  2003-07-09 14:26 ` Thien-Thi Nguyen
  0 siblings, 1 reply; 7+ messages in thread
From: Sysoltsev, Vyatcheslav @ 2003-07-09 12:23 UTC (permalink / raw)
  Cc: bug-guile, Denis Briltz (E-mail)

There is intrinsic in Intel compiler: void __memory_barrier(void);
This intrinsic does not generate code, but it creates a barrier across which
the compiler will not schedule data access instructions. Is this what is
needed?
	--Slava

-----Original Message-----
From: Thien-Thi Nguyen [mailto:ttn@glug.org]
Sent: Wednesday, July 09, 2003 2:25 PM
To: Sysoltsev, Vyatcheslav
Cc: Briltz, Denis; bug-guile@gnu.org
Subject: Re: FW: problem compiling guile on IA64 by Intel compiler


   From: "Sysoltsev, Vyatcheslav" <vyatcheslav.sysoltsev@intel.com>
   Date: Wed, 9 Jul 2003 13:49:20 +0400 

   No, Intel compiler doesn't plan to support ia64 asm inlines in
   foreseeable future.

looking at __scm.h closely, i see the inline asm is just an
implementation detail of SCM_FENCE, but SCM_FENCE is important
anyway (having it be defined to be nothing is indeed dangerous).

so the question becomes: does the intel compiler have an alternate
method to guarantee ordering as required by SCM_FENCE?  sorry for
not asking this earlier, when you had said you would be willing to
dig into the issue.

thi


_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-guile


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: FW: problem compiling guile on IA64 by Intel compiler
  2003-07-09 12:23 Sysoltsev, Vyatcheslav
@ 2003-07-09 14:26 ` Thien-Thi Nguyen
  0 siblings, 0 replies; 7+ messages in thread
From: Thien-Thi Nguyen @ 2003-07-09 14:26 UTC (permalink / raw)
  Cc: bug-guile, Denis.Briltz

   Delivery-date: Wed, 09 Jul 2003 08:23:23 -0400
   From: "Sysoltsev, Vyatcheslav" <vyatcheslav.sysoltsev@intel.com>

   void __memory_barrier(void);
   Is this what is needed?

i believe so.  perhaps inhibition of only data-access instructions is
not as strong as is necessary, but it's a start.  code for 1.4.x now
reads as follows:

#if defined (__INTEL_COMPILER) && defined (__ia64)
#define SCM_FENCE __memory_barrier()
#else
...
#endif

we can update this should it prove insufficient.  thanks for the info.

thi


_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-guile


^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2003-07-09 14:26 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2003-07-09  9:49 FW: problem compiling guile on IA64 by Intel compiler Sysoltsev, Vyatcheslav
2003-07-09 10:24 ` Thien-Thi Nguyen
  -- strict thread matches above, loose matches on Subject: below --
2003-07-09 12:23 Sysoltsev, Vyatcheslav
2003-07-09 14:26 ` Thien-Thi Nguyen
2003-07-09  5:03 Sysoltsev, Vyatcheslav
2003-07-09  9:44 ` Thien-Thi Nguyen
2003-07-08 15:46 Sysoltsev, Vyatcheslav

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).