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

[Neil Jerram <neil@ossau.uklinux.net>]

ludo@gnu.org (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_F_DYNWIND_NO_FLAGS = 0,
    SCM_F_DYNWIND_REWINDABLE = (1 << 0)
  } scm_t_dynwind_flags;
  
  typedef enum {
    SCM_F_WIND_NO_FLAGS = 0,
    SCM_F_WIND_EXPLICITLY = (1 << 0)
  } scm_t_wind_flags;

and report if that removes the related ICC errors?

Thanks,
        Neil