[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_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