[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Intel icc finds too many errors in guile 1.8.8 to compile

From: Neil Jerram
Subject: Re: Intel icc finds too many errors in guile 1.8.8 to compile
Date: Wed, 07 Oct 2009 22:09:50 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)

address@hidden (Ludovic Courtès) writes:

>> But wouldn't this approach break as soon as we added another flag, in
>> the way that I described in my previous email?
> Yes it would.
> But the underlying question is: is the set of flags likely to change?
> If the answer is “no” (which I think it is), it’s probably safe to go
> for an ‘enum’, as these flags cannot be combined anyway.

Hmm.  I think that's quite inelegant, to use a representation of flags
that would break if there was ever more than one flag (!).

I was going to conclude "So I'll revert my change and just add the zero
value instead", but then I wondered if we have any clear reason to
believe that that would help ICC.  There are several occurrences in
libguile of scm_dynwind_begin (0), and ICC could still complain, and
only be happy with scm_dynwind_begin (SCM_F_DYNWIND_NO_FLAGS).

So instead I'll just revert my change, and wait until we get more data
that a possible solution actually works for ICC.

Inge, if you're following this, can you try changing the enum
definitions to

  typedef enum {
  } scm_t_dynwind_flags;
  typedef enum {
    SCM_F_WIND_EXPLICITLY = (1 << 0)
  } scm_t_wind_flags;

and report if that removes the related ICC errors?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]