Compiling 1.7.0 with gcc-3.3

Compiling 1.7.0 with gcc-3.3

[Mikael Djurfeldt]

I've tried to compile CVS HEAD (1.7.0) with gcc-3.3.

Of course, I'd like this to work with the default
--enable-error-on-warning.  However, there are two problematic
instances.  One is the use of SCM_STACKITEM.  For example:

eval.c:1965:
  if (scm_stack_checking_enabled_p
      && SCM_STACK_OVERFLOW_P ((SCM_STACKITEM *) &proc))

The cast into (SCM_STACKITEM *) causes a warning that the pointer can
cause errors due to aliasing optimizations if it is dereferenced
(which it isn't, BTW).  -fstrict-aliasing is turned on by -O2 in
gcc-3.3.

This could be "solved" by adding -Wno-strict-aliasing to the
compilation options, but that might remove better motivated warnings.

Another problem seems more difficult:

gcc -DHAVE_CONFIG_H -I. -I../../../guile-core-new/libguile -I.. -I.. -I../../../guile-core-new -I../../../guile-core-new/libguile-ltdl -g -O2 -Werror -Wall -Wmissing-prototypes -Wno-strict-aliasing -MT numbers.lo -MD -MP -MF .deps/numbers.Tpo -c ../../../guile-core-new/libguile/numbers.c  -fPIC -DPIC -o .libs/numbers.lo
In file included from ../../../guile-core-new/libguile/numbers.c:4084:
../../../guile-core-new/libguile/num2integral.i.c: In function `scm_num2long_long':
../../../guile-core-new/libguile/num2integral.i.c:65: warning: comparison is always false due to limited range of data type
In file included from ../../../guile-core-new/libguile/numbers.c:4092:
../../../guile-core-new/libguile/num2integral.i.c: In function `scm_num2ulong_long':
../../../guile-core-new/libguile/num2integral.i.c:65: warning: comparison is always false due to limited range of data type

I think this is a stupid warning message.  In any case, you'd want to
be able to shut it off.  I can't find any way to do that.  Maybe we
should talk to the gcc people about this?

I've tried to enclose the code causing the warning with a surrounding
conditional which tests the sizes of the data types, but the compiler
outputs the above warning even though the code isn't going to be
compiled.

I think it's important to resolve this in some way.  If we can't, I'm
going to suggest that we shut off error-on-warning as a default, which
would be sad.  But Guile should compile "out-of-the-box".

Mikael


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Compiling 1.7.0 with gcc-3.3

[Rob Browning]

Mikael Djurfeldt <mdj@kvast.blakulla.net> writes:

> Of course, I'd like this to work with the default
> --enable-error-on-warning.  However, there are two problematic
> instances.  One is the use of SCM_STACKITEM.  For example:
>
> eval.c:1965:
>   if (scm_stack_checking_enabled_p
>       && SCM_STACK_OVERFLOW_P ((SCM_STACKITEM *) &proc))

Right I posted this to guile-devel a week or so ago.  Someone posted a
(void *) coercion fix, but I haven't had a chance to look in to it.

> This could be "solved" by adding -Wno-strict-aliasing to the
> compilation options, but that might remove better motivated warnings.

I'd be happier with -fno-strict-aliasing, but I don't really want that
either.  I'd rather see if we can alter the code to avoid the warning.

> I think this is a stupid warning message.  In any case, you'd want to
> be able to shut it off.  I can't find any way to do that.  Maybe we
> should talk to the gcc people about this?
>
> I've tried to enclose the code causing the warning with a surrounding
> conditional which tests the sizes of the data types, but the compiler
> outputs the above warning even though the code isn't going to be
> compiled.

We've worked around a bunch of warnings of this type before (I think
Marius fixed most of them), so hopefully we can just adjust the code
to avoid these too.

> I think it's important to resolve this in some way.  If we can't, I'm
> going to suggest that we shut off error-on-warning as a default, which
> would be sad.  But Guile should compile "out-of-the-box".

I'd be strongly opposed to turning off -Werror.  I'd like to consider
that a last resort.

-- 
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Compiling 1.7.0 with gcc-3.3

[Bruce Korb]

Rob Browning wrote:

> > eval.c:1965:
> >   if (scm_stack_checking_enabled_p
> >       && SCM_STACK_OVERFLOW_P ((SCM_STACKITEM *) &proc))
> 
> Right I posted this to guile-devel a week or so ago.  Someone posted a
> (void *) coercion fix, but I haven't had a chance to look in to it.
> 
> > This could be "solved" by adding -Wno-strict-aliasing to the
> > compilation options, but that might remove better motivated warnings.
> 
> I'd be happier with -fno-strict-aliasing, but I don't really want that
> either.  I'd rather see if we can alter the code to avoid the warning.

The (void*) coercion explicitly tells the compiler that the memory
named ``proc'' can be referenced in aliasing-unfriendly ways.
The other mechanism is to make ``proc'' be a union of whatever it
currently is with SCM_STACKITEM, so that other references become:

   proc.normal

and this reference becomes (without a cast):

  &proc.stackitem

In this context, ``(uintptr_t)&proc'' seems more appropriate and
less hassle, but it's your call.


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

Re: Compiling 1.7.0 with gcc-3.3

[Mikael Djurfeldt]

Rob Browning <rlb@defaultvalue.org> writes:

> We've worked around a bunch of warnings of this type before (I think
> Marius fixed most of them), so hopefully we can just adjust the code
> to avoid these too.

We could.

Thanks to pushes from you and Bruce Korb the warnings went away and I
will whine no more.

M


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Compiling 1.7.0 with gcc-3.3

[Bruce Korb]

Mikael Djurfeldt wrote:
> 
> I've tried to compile CVS HEAD (1.7.0) with gcc-3.3.
> 
> Of course, I'd like this to work with the default
> --enable-error-on-warning.  However, there are two problematic
> instances.  One is the use of SCM_STACKITEM.  For example:
> 
> eval.c:1965:
>   if (scm_stack_checking_enabled_p
>       && SCM_STACK_OVERFLOW_P ((SCM_STACKITEM *) &proc))
> 
> The cast into (SCM_STACKITEM *) causes a warning that the pointer can
> cause errors due to aliasing optimizations if it is dereferenced
> (which it isn't, BTW).  -fstrict-aliasing is turned on by -O2 in
> gcc-3.3.

Cast it through a void* cast:

> eval.c:1965:
>   if (scm_stack_checking_enabled_p
>       && SCM_STACK_OVERFLOW_P ((SCM_STACKITEM *) (void*) &proc))

> Another problem seems more difficult:
> 
> gcc -DHAVE_CONFIG_H -I. -I../../../guile-core-new/libguile -I.. -I.. -I../../../guile-core-new -I../../../guile-core-new/libguile-ltdl -g -O2 -Werror -Wall -Wmissing-prototypes -Wno-strict-aliasing -MT numbers.lo -MD -MP -MF .deps/numbers.Tpo -c ../../../guile-core-new/libguile/numbers.c  -fPIC -DPIC -o .libs/numbers.lo
> In file included from ../../../guile-core-new/libguile/numbers.c:4084:
> ../../../guile-core-new/libguile/num2integral.i.c: In function `scm_num2long_long':
> ../../../guile-core-new/libguile/num2integral.i.c:65: warning: comparison is always false due to limited range of data type
> In file included from ../../../guile-core-new/libguile/numbers.c:4092:
> ../../../guile-core-new/libguile/num2integral.i.c: In function `scm_num2ulong_long':
> ../../../guile-core-new/libguile/num2integral.i.c:65: warning: comparison is always false due to limited range of data type
> 
> I think this is a stupid warning message.  In any case, you'd want to
> be able to shut it off.  I can't find any way to do that.  Maybe we
> should talk to the gcc people about this?

Well, your test is:  (unsigned long)(some-value) > (unsigned long)~0
and it cannot ever be true.  That being the case, delete the code.
Do you really mean:  (unsigned long)(some-value) > ((unsigned long)~0)>>1
??

> I've tried to enclose the code causing the warning with a surrounding
> conditional which tests the sizes of the data types, but the compiler
> outputs the above warning even though the code isn't going to be
> compiled.

"isn't going to be compiled" or "would never get executed"?
``#if 0'' should effectively silence it.  The preprocessor
knows nothing of this stuff.  Clearly, this code gets analyized
before the dead code removal comes along.  Maybe put the code under:

  #if SIZEOF_SCM_T_BITS > SIZEOF_LONG

Can I get scm_c_eval_string_from_file_line() added, please?
All other solutions have proven intractable.


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Compiling 1.7.0 with gcc-3.3

[Mikael Djurfeldt]

Bruce Korb <bkorb@veritas.com> writes:

> Mikael Djurfeldt wrote:
>> 
>> I've tried to compile CVS HEAD (1.7.0) with gcc-3.3.
>> 
>> Of course, I'd like this to work with the default
>> --enable-error-on-warning.  However, there are two problematic
>> instances.  One is the use of SCM_STACKITEM.  For example:
>> 
>> eval.c:1965:
>>   if (scm_stack_checking_enabled_p
>>       && SCM_STACK_OVERFLOW_P ((SCM_STACKITEM *) &proc))
>> 
>> The cast into (SCM_STACKITEM *) causes a warning that the pointer can
>> cause errors due to aliasing optimizations if it is dereferenced
>> (which it isn't, BTW).  -fstrict-aliasing is turned on by -O2 in
>> gcc-3.3.
>
> Cast it through a void* cast:

Done.  Thanks.

>> eval.c:1965:
>>   if (scm_stack_checking_enabled_p
>>       && SCM_STACK_OVERFLOW_P ((SCM_STACKITEM *) (void*) &proc))
>
>> Another problem seems more difficult:
>> 
>> gcc -DHAVE_CONFIG_H -I. -I../../../guile-core-new/libguile -I.. -I.. -I../../../guile-core-new -I../../../guile-core-new/libguile-ltdl -g -O2 -Werror -Wall -Wmissing-prototypes -Wno-strict-aliasing -MT numbers.lo -MD -MP -MF .deps/numbers.Tpo -c ../../../guile-core-new/libguile/numbers.c  -fPIC -DPIC -o .libs/numbers.lo
>> In file included from ../../../guile-core-new/libguile/numbers.c:4084:
>> ../../../guile-core-new/libguile/num2integral.i.c: In function `scm_num2long_long':
>> ../../../guile-core-new/libguile/num2integral.i.c:65: warning: comparison is always false due to limited range of data type
>> In file included from ../../../guile-core-new/libguile/numbers.c:4092:
>> ../../../guile-core-new/libguile/num2integral.i.c: In function `scm_num2ulong_long':
>> ../../../guile-core-new/libguile/num2integral.i.c:65: warning: comparison is always false due to limited range of data type
>> 
>> I think this is a stupid warning message.  In any case, you'd want to
>> be able to shut it off.  I can't find any way to do that.  Maybe we
>> should talk to the gcc people about this?
>
> Well, your test is:  (unsigned long)(some-value) > (unsigned long)~0
> and it cannot ever be true.

Well, it's really

  if (((scm_t_bits) n) > UNSIGNED_ITYPE_MAX)
    scm_out_of_range (s_caller, num);

where UNSIGNED_ITYPE_MAX is different depending on which instance of
num2intergral.i.c is compiled (the file is included into numbers.c
several times, with different values of the C macros).

It's true that the conditional cannot ever be true when
UNSIGNED_ITYPE_MAX is (unsigned long)~0.

What I meant with "stupid warning message" (which is a too strong
wording) is that I want to be free to write conditionals which never
will be true.  In that case, I want the compiler to silently exclude
the piece of dead code.  On the other hand, other users might regard
this condition as a sign of error and want the warning message.
Ideally, one should then be able to customize whether to get the
warning or not.

In our case, we will now probably need to resort to preprocessor
conditionals, which means less power and the need to add extra
information in the form of new C preprocessor macros.
    
> Can I get scm_c_eval_string_from_file_line() added, please?
> All other solutions have proven intractable.

Hmm... I guess I will find a reference to your problem in some other
thread.  Will go looking later.

Anyway, thanks for your input!

Best regards,
Mikael


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